From owner-freebsd-stable@FreeBSD.ORG Sun Feb 19 06:37: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 BD06A1065674 for ; Sun, 19 Feb 2012 06:37:05 +0000 (UTC) (envelope-from kob6558@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 261D58FC0A for ; Sun, 19 Feb 2012 06:37:04 +0000 (UTC) Received: by wibhn14 with SMTP id hn14so3652467wib.13 for ; Sat, 18 Feb 2012 22:37: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=6k1xHi7tjjRGx5btZZ4YKTwmLl3LblBKB4P2Gz3x05s=; b=EZYU4amd0/HXuV+8tFRxPf8jdm4NXqJAZzB9ZAE290nnsrZWFq5xQEDKLW5dKOr73v Tge9Jtt5LTLyGXGEY1+6PgmqVwKVxtjtFEy/z3ZPgO+kHQdoKa7zcJMOkAPiF0VFXU9y 5vLBWpiN2Ci9ddnig4hvw4a2n2XMs4G9V5aV8= MIME-Version: 1.0 Received: by 10.180.107.67 with SMTP id ha3mr6745698wib.8.1329633424001; Sat, 18 Feb 2012 22:37:04 -0800 (PST) Received: by 10.223.158.143 with HTTP; Sat, 18 Feb 2012 22:37:03 -0800 (PST) In-Reply-To: References: <20120217.160430.406937514120319292.hrs@allbsd.org> <4F3E3000.9000206@FreeBSD.org> <20120217.232843.2212672671663755444.hrs@allbsd.org> <4F3EC8DD.6040500@FreeBSD.org> Date: Sat, 18 Feb 2012 22:37:03 -0800 Message-ID: From: Kevin Oberman To: Freddie Cash Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: wblock@wonkity.com, mandrews@bit0.com, 000.fbsd@quip.cz, Andriy Gapon , 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: Sun, 19 Feb 2012 06:37:05 -0000 On Fri, Feb 17, 2012 at 1:50 PM, Freddie Cash wrote: > 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, Errat= a 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 seco= nd >>> logical block), and the backup GPT Header must be located in the last L= BA >>> of the device. >> >> I can not see any ambiguity or openness to interpretation in this paragr= aph. > > Unless it's specified somewhere else (which is possible), in this > paragraph, "device" does not necessarily mean "physical disk". =A0"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 provid= es. > > After all, LBAs are logical addresses (it's right there in the name!), > not hardwired physical sector addresses. =A0;) =A0If they were hardwired, > then how would internal sector remapping work? =A0;) Please remember that some disks are dual-boot. FreeBSD may understand geom has the backup one block from the last LBA on the disk, but no other OS is likely to do so. Unless I am missing something, this should be a non-starter. Totally unacceptable. The backup belongs in the last and only in the last LBA on the physical disk. --=20 R. Kevin Oberman, Network Engineer E-mail: kob6558@gmail.com From owner-freebsd-stable@FreeBSD.ORG Sun Feb 19 06:37: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 7C2311065672 for ; Sun, 19 Feb 2012 06:37:14 +0000 (UTC) (envelope-from ask@develooper.com) Received: from mbox1.develooper.com (mbox1.develooper.com [207.171.7.178]) by mx1.freebsd.org (Postfix) with ESMTP id 4B2468FC16 for ; Sun, 19 Feb 2012 06:37:14 +0000 (UTC) Received: (qmail 4990 invoked from network); 19 Feb 2012 06:10:33 -0000 Received: from cpe-76-172-28-38.socal.res.rr.com (HELO embla.bn.dev) (ask@mail.dev@76.172.28.38) by smtp.develooper.com with ESMTPA; 19 Feb 2012 06:10:33 -0000 From: =?iso-8859-1?Q?Ask_Bj=F8rn_Hansen?= Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sat, 18 Feb 2012 22:10:32 -0800 Message-Id: <770EEEFF-B41D-4851-AD74-C3F96FFB1683@develooper.com> To: freebsd-stable@freebsd.org, freebsd-zfs@freebsd.org Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) Cc: Subject: Can't read a full block, only got 8193 bytes. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 19 Feb 2012 06:37:14 -0000 Hi everyone, We're recycling an old database server with room for 16 disks as a = backup server (our old database servers had 12-20 15k disks; the new = ones one or two SSDs and they're faster). We have a box running FreeBSD 8.2 with 7 disks in a ZFS raidz2 (and a = spare). It's using an older 3ware card with all the disks (2TB WD green = "ears" ones) setup as a "single" unit on the 3ware controller and though = slow is basically working great. We have a small program to smartly = purge old snapshots that I wrote after a year and tens of thousands of = snapshots: https://github.com/abh/zfs-snapshot-cleaner The new box is running 9.0 with a 3ware 9690SA-4I4E card with the latest = firmware (4.10.00.024). We're using Seagate 3TB barracuda disks (big = and cheap; good for backups). Now for the problem: When running bonnie++ we get a few ZFS checksum = errors and (weirder) we get this error from bonnie: "Can't read a full block, only got 8193 bytes." This seems to only be when testing a single ZFS disk or a UFS partition. = Testing a raidz1 we just get checksum errors noted in zpool status, but = no errors reading (though read speeds are ~10MB/second across four disks = -- writing sequentially was ~230MB/second). Any ideas where to start look? Our best guess is that the 3ware controller can't play nicely with the = disks; we're planning to try some older/smaller disks on Monday and then = trying the same system and disks with Linux to see if the 3ware driver = there works differently. Ask= From owner-freebsd-stable@FreeBSD.ORG Sun Feb 19 07:09:07 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E61BF1065670; Sun, 19 Feb 2012 07:09:07 +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 81BA48FC13; Sun, 19 Feb 2012 07:09:07 +0000 (UTC) Received: by vcmm1 with SMTP id m1so4427985vcm.13 for ; Sat, 18 Feb 2012 23:09: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=ve3gqBE7uUBBSbOEc7tzg3avshdZ0ykEJdFvXIsZysY=; b=p8PxCWkgjo+e8z9q05sp+nQA1O/Twqmc6KFPPs+11QOwuUFarqohqIFEsXkhAyssjS RJkRTTwIMDycbA3+Fvd0GyzvNwajBdeGUTLUlOeVBKl5aYDZqvCcS6q0sQXhIcUSN27T vXJNbxUvHHGH9DM4VraiIeusd+K4nGlPqDSOo= MIME-Version: 1.0 Received: by 10.220.141.133 with SMTP id m5mr6907244vcu.67.1329635346678; Sat, 18 Feb 2012 23:09:06 -0800 (PST) Received: by 10.220.192.135 with HTTP; Sat, 18 Feb 2012 23:09:06 -0800 (PST) Received: by 10.220.192.135 with HTTP; Sat, 18 Feb 2012 23:09:06 -0800 (PST) In-Reply-To: References: <20120217.160430.406937514120319292.hrs@allbsd.org> <4F3E3000.9000206@FreeBSD.org> <20120217.232843.2212672671663755444.hrs@allbsd.org> <4F3EC8DD.6040500@FreeBSD.org> Date: Sat, 18 Feb 2012 23:09:06 -0800 Message-ID: From: Freddie Cash To: Kevin Oberman Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: wblock@wonkity.com, freebsd-stable@freebsd.org, 000.fbsd@quip.cz, Andriy Gapon , 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: Sun, 19 Feb 2012 07:09:08 -0000 If you're mirroring the disk with gmirror, how are you dual-booting the disk? This discussion is about using gmirror to mirror two entire disks, and then use GPT to partition the mirror device. Dual-booting has no bearing on that, as gmirror is a FreeBSD-only technology. Cheers, Freddie Cash fjwcash@gmail.com On Feb 18, 2012 10:37 PM, "Kevin Oberman" wrote: > On Fri, Feb 17, 2012 at 1:50 PM, Freddie Cash wrote: > > 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? ;) > > Please remember that some disks are dual-boot. FreeBSD may understand > geom has the backup one block from the last LBA on the disk, but no > other OS is likely to do so. > > Unless I am missing something, this should be a non-starter. Totally > unacceptable. The backup belongs in the last and only in the last LBA > on the physical disk. > -- > R. Kevin Oberman, Network Engineer > E-mail: kob6558@gmail.com > From owner-freebsd-stable@FreeBSD.ORG Sun Feb 19 13:26: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 65A771065673 for ; Sun, 19 Feb 2012 13:26:49 +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 CEDCC8FC0A for ; Sun, 19 Feb 2012 13:26:48 +0000 (UTC) Received: from pop1.hm.net.br (pop1.hm.net.br [186.222.208.166]) by msrv.matik.com.br (8.14.5/8.14.2) with ESMTP id q1JDQiSj045910; Sun, 19 Feb 2012 11:26:44 -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=1329658004; bh=2YYObVDdm9Xv1tLBjE8zfLZ55XrAr/+PRhjjuO1YiVA=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=F5BlbHTwmXVZUijumv6OsxYJ4rIpIJSlz88YfP7d1JEF5Pj76nh4HXNmShbzWEojb Q8pKKOoYhm9WN0dlDiUCfeSVEqIxzzIicaRv6aVrFTuG3NL365aiKU9Hz2JGmqihU4 jHJpimcpANBuamMAuegOMEouxbzesoJtbwekgf4U= 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=A1HIQpURtDe5ROJUnV0RfngAY04UFeSmTV89ka7BwG4BvbwjtWFJSK+bQ4QoD4O1G WnQ8YrD9jsmC/qmx82S3o83Q30xS3cqf0aO0Rjvvrq3I34tDjP0Zhz1ZRaFdMiKxZAB nZUCcsaKjCljoqolvUWv6/8P8j3K+r5cUbCqSVU= 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: <4F40F8CA.4030705@hm.net.br> Date: Sun, 19 Feb 2012 11:27:38 -0200 From: H User-Agent: Mozilla/5.0 MIME-Version: 1.0 To: Doug Barton 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> <4F40231D.2080308@FreeBSD.org> In-Reply-To: <4F40231D.2080308@FreeBSD.org> X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-0.3 required=5.0 tests=AWL, BAYES_00, T_DKIM_INVALID, T_RP_MATCHES_RCVD autolearn=ham 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 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: Sun, 19 Feb 2012 13:26:49 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Doug Barton wrote: > 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. > > Hi no idea what you referring to in your "top post" but since we are both "newcomers" here we're still learning and skip it ok :) now, 4FBSD really changed for me the face of the system, generally, I have much better response, thank you for the hint, it is ok now can you tell if it is worth checking this out on amd64 servers also? but seems that the principal delay came as present from a pkg maintainer who dares piping shit into the system config without telling or asking: echo 'fusefs_enable="YES"' >> ${LOADER_CONFIG} fusefs-kmod I'm talking about, where LOADER_CONF is rc.conf for his script - -- H +55 (17)4141.2222 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk9A+MoACgkQvKVfg5xjCDzsDQCcC5GScZyOc6tFxag5IU5Fy9E2 Vt0AoJAXa23jc+qXJnL2kZV88vdokJVW =TpKf -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Sun Feb 19 14:16: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 BC56B1065670; Sun, 19 Feb 2012 14:16:13 +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 2D0578FC14; Sun, 19 Feb 2012 14:16:12 +0000 (UTC) Received: from mailscan.giulioferro.ch (unknown [192.168.115.2]) by mx1.giulioferro.ch (Postfix) with ESMTP id C1D763AED7; Sun, 19 Feb 2012 15:16:11 +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 Wv3g4su3EF2n; Sun, 19 Feb 2012 15:16:09 +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 2076E3AEBD; Sun, 19 Feb 2012 15:16:09 +0100 (CET) Received: from ext.zirakzigil.org (unknown [192.168.1.2]) by mail.zirakzigil.org (Postfix) with ESMTP id D8D8F19345B; Sun, 19 Feb 2012 15:16:08 +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 7CqypNtGAT7S; Sun, 19 Feb 2012 15:16:08 +0100 (CET) Received: from [192.168.229.36] (ext [192.168.1.2]) (Authenticated sender: auryn@zirakzigil.org) by mail.zirakzigil.org (Postfix) with ESMTPA id 2D162193456; Sun, 19 Feb 2012 15:16:08 +0100 (CET) Message-ID: <4F410427.6050703@zirakzigil.org> Date: Sun, 19 Feb 2012 15:16:07 +0100 From: Giulio Ferro User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Rick Macklem , freebsd-net@freebsd.org, freebsd-stable@freebsd.org References: <1905075320.1616773.1329616553940.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <1905075320.1616773.1329616553940.JavaMail.root@erie.cs.uoguelph.ca> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: 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: Sun, 19 Feb 2012 14:16:13 -0000 On 02/19/2012 02:55 AM, Rick Macklem wrote: > I just updated the patch: > http://people.freebsd.org/~rmacklem/rpcsec_gss-9.patch > > If you already downloaded it, please do so again, because > it had two arguments reversed in order and would not have > worked. > > I think this one is correct, although I don't currently > have a Kerberos setup to test it with. > > Good luck with it, rick > Thanks a lot. I'm trying next week. From owner-freebsd-stable@FreeBSD.ORG Sun Feb 19 16: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 548241065672; Sun, 19 Feb 2012 16:55:46 +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 BBE0F8FC0A; Sun, 19 Feb 2012 16:55:45 +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 q1JGtInM021294 ; Sun, 19 Feb 2012 17:55:31 +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 q1JGsoLU054604; Sun, 19 Feb 2012 17:54:50 +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 q1JGsoIr054599; Sun, 19 Feb 2012 17:54:50 +0100 (CET) (envelope-from arno) To: Martin Simmons From: "Arno J. Klaassen" References: <201202141820.q1EIK1MP032526@higson.cam.lispworks.com> Date: Sun, 19 Feb 2012 17:54:50 +0100 In-Reply-To: (Arno J. Klaassen's message of "Sat\, 18 Feb 2012 18\:55\:17 +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 4F412976.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 4F412976.000/134.157.184.22/heho.snv.jussieu.fr/heho.snv.jussieu.fr/ Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org Subject: 9-stable: one-device ZFS fails [was: 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: Sun, 19 Feb 2012 16:55:46 -0000 a followup to myself > 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 tested a bit more this afternoon : - zpool create zgpart /dev/ada0s4d => KO - split ada0s4 in two equally sized partitions and then zpool create zgpart mirror /dev/ada0s4d /dev/ada0s4e => works like a charm ..... ( [root@cc /zgpart]# zpool status -v zgpart pool: zgpart state: ONLINE scan: scrub repaired 0 in 0h36m with 0 errors on Sun Feb 19 17:20:34 2012 config: NAME STATE READ WRITE CKSUM zgpart ONLINE 0 0 0 mirror-0 ONLINE 0 0 0 ada0s4d ONLINE 0 0 0 ada0s4e ONLINE 0 0 0 errors: No known data errors ) FYI, best, Arno > > 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 >>> > >>> > >>> > > _______________________________________________ > 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 Sun Feb 19 16:55: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 BEFE71065678 for ; Sun, 19 Feb 2012 16:55:54 +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 9AB6A8FC12 for ; Sun, 19 Feb 2012 16:55:54 +0000 (UTC) Received: from fruiteater.riseup.net (fruiteater-pn.riseup.net [10.0.1.74]) (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 10A5C588FC for ; Sun, 19 Feb 2012 08:55:54 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: nzp@fruiteater.riseup.net) with ESMTPSA id E4E955DB Date: Sun, 19 Feb 2012 17:55:49 +0100 From: Nikola =?utf-8?B?UGF2bG92acSH?= To: freebsd-stable@freebsd.org Message-ID: <20120219165549.GA33591@sputnjik.localdomain> Mail-Followup-To: freebsd-stable@freebsd.org References: <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> <4F40231D.2080308@FreeBSD.org> <4F40F8CA.4030705@hm.net.br> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F40F8CA.4030705@hm.net.br> 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: 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: Sun, 19 Feb 2012 16:55:54 -0000 On Sun, Feb 19, 2012 at 11:27:38AM -0200, H wrote: > Doug Barton wrote: > > 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. > > > > > > > Hi > > no idea what you referring to in your "top post" but since we are both > "newcomers" here we're still learning and skip it ok :) > If no one points out your mistake how are you going to learn? :) He is referring to the fact that you started your thread by replying to an existing one, namely "disk devices speed is ugly". By doing that you made your initial message's headers to refer to that thread, which makes threading mail clients sort it to that thread. This is not "just" a cosmetic or netiquette problem since people might use "delete-thread" on previous thread deleting your unrelated message in the process, thus your message gets ignored (unintentionally). > now, 4FBSD really changed for me the face of the system, generally, I > have much better response, thank you for the hint, it is ok now > > can you tell if it is worth checking this out on amd64 servers also? > > > but seems that the principal delay came as present from a pkg > maintainer who dares piping shit into the system config without > telling or asking: > > echo 'fusefs_enable="YES"' >> ${LOADER_CONFIG} > > fusefs-kmod I'm talking about, where LOADER_CONF is rc.conf for his script > You told it to do that yourself. From the Makefile: OPTIONS= AUTOSETUP "Automatic global config file setup" off You see, off by default. I suggest you should be careful to not accuse others of "piping shit" into something before you make sure you're not doing it yourself. And if changing the scheduler fixed the problem how did you suddenly jump to the conclusion that the problem is in enabling FUSE at boot time? -- For every credibility gap, there is a gullibility fill. -- R. Clopton From owner-freebsd-stable@FreeBSD.ORG Sun Feb 19 20:10: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 D63AA106567F for ; Sun, 19 Feb 2012 20:10:40 +0000 (UTC) (envelope-from artemb@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 92D0D8FC1D for ; Sun, 19 Feb 2012 20:10:40 +0000 (UTC) Received: by yhfs35 with SMTP id s35so2734026yhf.13 for ; Sun, 19 Feb 2012 12:10:39 -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 :content-transfer-encoding; bh=FBLgUAYqXwRgBzXnYQXJaEvTq0beJFEc1edO1KKwH5k=; b=GLkVAA4kccISBXpkzmt69zoaxj012dYvkprppKal+P+2SOgGrlANzK/djdojJLWULj DoqmXCH7st9YDePJPntFAHGtP6uFnhFoFqPbxq9avf4pg5Tt3uw03Tt5YdvxlMSDh8st xPYdweqwpfNFR4pGvaPGJKuC5UYhoDCAjlcRw= MIME-Version: 1.0 Received: by 10.236.184.167 with SMTP id s27mr19679481yhm.8.1329682239541; Sun, 19 Feb 2012 12:10:39 -0800 (PST) Sender: artemb@gmail.com Received: by 10.147.47.6 with HTTP; Sun, 19 Feb 2012 12:10:39 -0800 (PST) In-Reply-To: <770EEEFF-B41D-4851-AD74-C3F96FFB1683@develooper.com> References: <770EEEFF-B41D-4851-AD74-C3F96FFB1683@develooper.com> Date: Sun, 19 Feb 2012 12:10:39 -0800 X-Google-Sender-Auth: d0bGxaZWLc_oyXETgumniOOc97k Message-ID: From: Artem Belevich To: =?ISO-8859-1?Q?Ask_Bj=F8rn_Hansen?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org, freebsd-zfs@freebsd.org Subject: Re: Can't read a full block, only got 8193 bytes. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 19 Feb 2012 20:10:40 -0000 On Sat, Feb 18, 2012 at 10:10 PM, Ask Bj=F8rn Hansen w= rote: > Hi everyone, > > We're recycling an old database server with room for 16 disks as a backup= server (our old database servers had 12-20 15k disks; the new ones one or = two SSDs and they're faster). > > We have a box running FreeBSD 8.2 with 7 disks in a ZFS raidz2 (and a spa= re). =A0It's using an older 3ware card with all the disks (2TB WD green "ea= rs" ones) setup as a "single" unit on the 3ware controller and though slow = is basically working great. =A0We have a small program to smartly purge old= snapshots that I wrote after a year and tens of thousands of snapshots: ht= tps://github.com/abh/zfs-snapshot-cleaner > > The new box is running 9.0 with a 3ware 9690SA-4I4E card with the latest = firmware (4.10.00.024). =A0We're using Seagate 3TB barracuda disks (big and= cheap; good for backups). > > Now for the problem: When running bonnie++ we get a few ZFS checksum erro= rs and (weirder) we get this error from bonnie: > > "Can't read a full block, only got 8193 bytes." That's probably just a side effect of ZFS checksum errors. ZFS will happily read the file until it hits a record with checksum. If redundant info is available (raidz or mirror), ZFS will attempt to recover your data. If there's no redundancy you will get read error. If you do "zpool status -v" you should see list of files affected by corruption. > > This seems to only be when testing a single ZFS disk or a UFS partition. = =A0Testing a raidz1 we just get checksum errors noted in zpool status, but = no errors reading (though read speeds are ~10MB/second across four disks --= writing sequentially was ~230MB/second). > > Any ideas where to start look? You need to figure out why you're getting checksum errors. Alas there's probably no easy way to troubleshoot it. The issue could be hardware related and possible culprits may include bad RAM, bad SATA cables, quirks of particular firmware revision on disk controller and/or hard drive. > Our best guess is that the 3ware controller can't play nicely with the di= sks; we're planning to try some older/smaller disks on Monday and then tryi= ng the same system and disks with Linux to see if the 3ware driver there wo= rks differently. --Artem From owner-freebsd-stable@FreeBSD.ORG Sun Feb 19 21:36: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 498581065676 for ; Sun, 19 Feb 2012 21:36:16 +0000 (UTC) (envelope-from jeremie@le-hen.org) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [IPv6:2a01:e0c:1:1599::14]) by mx1.freebsd.org (Postfix) with ESMTP id 7D8718FC1B for ; Sun, 19 Feb 2012 21:36:13 +0000 (UTC) Received: from endor.tataz.chchile.org (unknown [82.233.239.98]) by smtp5-g21.free.fr (Postfix) with ESMTP id E270BD48062 for ; Sun, 19 Feb 2012 22:36:08 +0100 (CET) Received: from felucia.tataz.chchile.org (felucia.tataz.chchile.org [192.168.1.9]) by endor.tataz.chchile.org (Postfix) with ESMTP id AF68320CE; Sun, 19 Feb 2012 21:36:07 +0000 (UTC) Received: by felucia.tataz.chchile.org (Postfix, from userid 1000) id 6C26C3E53; Sun, 19 Feb 2012 21:36:07 +0000 (UTC) Date: Sun, 19 Feb 2012 22:36:07 +0100 From: Jeremie Le Hen To: freebsd-stable@FreeBSD.org Message-ID: <20120219213607.GO31770@felucia.tataz.chchile.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Cc: jeremie@le-hen.org Subject: "File too large" error when appending to a file of 130 MB X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 19 Feb 2012 21:36:16 -0000 Hi list, Can you please Cc: me when replying as I'm not subscribed, thanks. I have a problem with procmail which gets a "File too large" error when it tries to write at the end of some mailbox file. I truss'ed it and I found the following: % stat("/home/jlh/Mail//mbox1",{ mode=-rw------- ,inode=336983,size=138744672,blksize=131072 }) = 0 (0x0) % open("/home/jlh/Mail//mbox1",O_WRONLY|O_APPEND|O_CREAT,0667) = 5 (0x5) % lseek(5,0x0,SEEK_END) = 138744672 (0x8451360) % wait4(0xffffffff,0x0,0x1,0x0,0x3,0x5) ERR#10 'No child processes' % lseek(5,0x0,SEEK_CUR) = 138744672 (0x8451360) % fcntl(5,F_SETLKW,0xffffd9a4) = 0 (0x0) % lseek(5,0x0,SEEK_END) = 138744672 (0x8451360) % write(5,"F",1) ERR#27 'File too large' % fstat(5,{ mode=-rw------- ,inode=336983,size=138744672,blksize=131072 }) = 0 (0x0) % write(5,"rom lionel.messien+caf_=jlh=chch"...,3627) ERR#27 'File too large' I can append something to the file manually. I wonder if the error doesn't come from the SETLKW fnctl(2) call, but I cannot experiment it because truss(1) doesn't show the content of the flock structure. If I change the procmail recipe to write to another file (which doesn't exist), the file is successfully created and messages can be appended. I narrowed down the failure threshold between 48 MB and 49 MB (in steps of 64 KB, it failed between 781 and 782 blocks). This is a 8.2 32 bits jail on a 8.2 amd64 host. In the jail, /home is a nullfs mounted ZFS filesystem. The mailbox is not that big: % felucia:jlh$ ls -l Mail/mbox1 % -rw-------+ 1 jlh jlh 138744672 Feb 19 11:46 Mail/mbox1 (( For some unknown reason some ACL keep appearing, but the problem if still there anyway if I do setfacl -b on it: % felucia:jlh$ getfacl Mail/mbox1 % # file: Mail/mbox1 % # owner: jlh % # group: jlh % owner@:rw-p--aARWcCos:------:allow % group@:------a-R-c--s:------:allow % everyone@:------a-R-c--s:------:allow )) Does anyone have an idea about this error? Besides, if someone knows why those ACLs keep appearing, I would be glad to know it :). Thanks. -- Jeremie Le Hen Men are born free and equal. Later on, they're on their own. Jean Yanne From owner-freebsd-stable@FreeBSD.ORG Sun Feb 19 21:47: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 EF00C1065673; Sun, 19 Feb 2012 21:47:16 +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 5ACC68FC0C; Sun, 19 Feb 2012 21:47:16 +0000 (UTC) Date: Sun, 19 Feb 2012 22:47:13 +0100 From: vermaden To: Hans Petter Selasky X-Mailer: interia.pl/pf09 In-Reply-To: <201202181409.08859.hselasky@c2i.net> References: <4F3EE186.4020801@gmail.com> <201202181409.08859.hselasky@c2i.net> 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=1329688033; bh=9/MNWYs7Ft6MAEHGeE9EwQnSnOeFjfXZh4BfC/b/IK8=; 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=I0ywxDhUIu/61lMN/0q9rgCmTaecSOhwOq2jcjXDYLF53uRlkNVnn5LfKKDCP4UU0 bCz19PNQYijxEeKxwhvOLPVvuff2eUtlidndqCqVS6uscFxPOKsCdUxs8gBQQ+9Ig8 QizOzo4n76GD3bMSh5zdaZ8JA+VIfMqhYu4W1DVE= Cc: matt , gleb.kurtsou@gmail.com, freebsd-stable@freebsd.org, uffe@uffe.org, freebsd-hackers@freebsd.org, joe.culler@gmail.com, freebsd-current@freebsd.org, lars.engels@0x20.net 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: Sun, 19 Feb 2012 21:47:17 -0000 Hi, sorry for late response, but I currently have quite a lot 'weekend activities' that are definitely not near a computer ;) written by Gleb Kurtsou ...=20 >> __state_lock() { >> while [ -f ${STATE}.lock ]; do sleep 0.5; done >> :> ${STATE}.lock >> } > > Why not keep it stateless, unmounting by hand would kill integrity. The state file is needed for automatic umount of fuse-based mounts, the device that script would be triggered will be /dev/da0 for example while the 'virtual' device that was actually used for the mount was /dev/fuse0, that is why I need to track what is mounted and how. These functions are mostly to keep that 'state file' integral, to prevent two various event writing at the file simultanously, which would probable killed the information integrity. Unmounting the device does not kill integrity at all, I also thought about that, You may plug the device, do whatever You want, event change the filesystem there and mount it again, but when You umount it and unplug it, then the script will umount that device (yes pointless here at this moment) and remove the entry from state file. > Usage of `file` is a big security concern. Can You explain why? > 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. geom config? I also make use of the list of mounted filesystems, but the problem with fuse-based devices remain as I stated earlier. > I'm using a python script for mounting/unmounting removable disks, > but having similar tool written in sh would be great. >=20 > https://github.com/glk/mmount Thanks for sharing, maybe I will find some ideas there ;) written by Uffe Jakobsen ... > Nice, Thanks. > Instead of requiring modification to /etc/devd.conf why not just > put a "plugin" conf-file in /etc/devd/ - well even better put in > /usr/local/etc/devd/ - that way your devd.conf modifications are > not lost upon patching/updating base os. Great advice, I will do that in the next 'release' ;) > There is an existing port called "automounter" by Dominic Fandrey > which is much similar to your work. Yes but its amd based. > His "automounter" also works with disk labels > (as found in /dev/ufs/ and /dev/msdosfs/ etc) The labels are only 'an addition' to appearing device nodes at /dev, Yes it would be nice to see that /dev/msdosfs/BACKUP is mounted instead of /dev/da0s1, but I will have to make a lot of additional check to see if that new label is part of that or other device etc. > You should consider make a port out of your work. I probably will try to do that, but I think it stil needs polish ;) written by Lars Engels ... > And please don't hardcode polish locales in mount_msdosfs :-) I already changed that, I also plan to create simple config file, it was just not 'the most important thing' that I was dealing with at that time, its easy to move options into variables, its harder to make script work the way it should ;) But thanks for suggestion, good point. written by Joe Culler ... > Thanks for working on it. It works great for me, thanks! Thanks, good to know ;) > I have a question, could you export a fusefs-exfat or > fusefs-ntfs share directory over NFS? I can't get it work. > If you have a solution, please let me know, thanks. I will try to do that tomorrow ane let You know. Regards, vermaden --- From owner-freebsd-stable@FreeBSD.ORG Sun Feb 19 22:46:02 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 F1CBB106566B for ; Sun, 19 Feb 2012 22:46:01 +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 2F647152D3B; Sun, 19 Feb 2012 22:46:01 +0000 (UTC) Message-ID: <4F417BA8.6000301@FreeBSD.org> Date: Sun, 19 Feb 2012 14:46:00 -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> <4F40231D.2080308@FreeBSD.org> <4F40F8CA.4030705@hm.net.br> In-Reply-To: <4F40F8CA.4030705@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: Sun, 19 Feb 2012 22:46:02 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 02/19/2012 05:27, H wrote: > Doug Barton wrote: >> 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. > > > > > Hi > > no idea what you referring to in your "top post" When you posted your first message you hit "Reply" to an existing message on the list, and then changed the subject line. Don't do that. Instead, create a new message, and paste the address of the list into your new message. > but since we are both "newcomers" here Um ... I'm not exactly a newcomer. :) > we're still learning and skip it ok :) No, if you're still learning this is something you actually *need* to learn. When you hijack someone else's thread your message shows up "under" the old thread for anyone using a properly threaded mail reader (which is most of the people on this list). That's bad for the list because what you're talking about is a new topic, and should be treated as such both in the ongoing discussion and in the archives. It's also bad for *you* because anyone who's ignoring that old thread is not going to see your new message. > now, 4FBSD really changed for me the face of the system, generally, > I have much better response, thank you for the hint, it is ok now I'm glad to hear that. > can you tell if it is worth checking this out on amd64 servers > also? Yes. > but seems that the principal delay came as present from a pkg > maintainer who dares piping ... Please keep your language on our public lists family-friendly. 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/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iQEcBAEBCAAGBQJPQXuoAAoJEFzGhvEaGryEt18IAIb4npCHz/fqpyZS86ZNr55K INscFNcpnXoKiG5M2ruAqohh5ykflNfyuEM6sV1OXcOIqAbM6N6TBeNcMeh2nkI4 Xd8rwtB+CXENGlufkoYlydLbmC/IGSvz5+RNOfWPSCKiWYbJjNDxoR3ReQM9qk7I B491KhWmpFWvODG94+vyTLHQXHv5EKXqOkJoiwU4NS+uKF7J+WSxqmSBGwNqzEoB 4z7d0KuxkbPO3GlKZMqE3IzSGzbfCzVB7i6MzyyedjKvBsh9nfIz6TE3e7+F2YRH XJGKCtLVi7XU2e0RahtCWWUVY1q8ncG80z3BdAfJGwslaQ49Kpq+seCRpcQi4m4= =JiCq -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Mon Feb 20 00:46: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 84408106564A for ; Mon, 20 Feb 2012 00:46:43 +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 36C608FC0A for ; Mon, 20 Feb 2012 00:46:42 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap8EAHqXQU+DaFvO/2dsb2JhbABEhRKuHoFzAQEBAwEBAQEgKyALBRYYAgINGQIpAQkmBggHBAEcBIdfCadmkH+BL4gdAYIyGg4IAQECFgEJAgkQAoM0ATMFAgIBAgECAQsBAw2CLoEWBIhOikGCKJMLgT4 X-IronPort-AV: E=Sophos;i="4.73,447,1325480400"; d="scan'208";a="160203661" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 19 Feb 2012 19:46:42 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 1153AB3F7F; Sun, 19 Feb 2012 19:46:42 -0500 (EST) Date: Sun, 19 Feb 2012 19:46:42 -0500 (EST) From: Rick Macklem To: Jeremie Le Hen Message-ID: <1984136644.1631414.1329698802016.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <20120219213607.GO31770@felucia.tataz.chchile.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-stable@FreeBSD.org Subject: Re: "File too large" error when appending to a file of 130 MB X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 20 Feb 2012 00:46:43 -0000 Jeremie Le Hen wrote: > Hi list, > > Can you please Cc: me when replying as I'm not subscribed, thanks. > > I have a problem with procmail which gets a "File too large" error > when > it tries to write at the end of some mailbox file. > > I truss'ed it and I found the following: > > % stat("/home/jlh/Mail//mbox1",{ mode=-rw------- > ,inode=336983,size=138744672,blksize=131072 }) = 0 (0x0) > % open("/home/jlh/Mail//mbox1",O_WRONLY|O_APPEND|O_CREAT,0667) = 5 > (0x5) > % lseek(5,0x0,SEEK_END) = 138744672 (0x8451360) > % wait4(0xffffffff,0x0,0x1,0x0,0x3,0x5) ERR#10 'No child processes' > % lseek(5,0x0,SEEK_CUR) = 138744672 (0x8451360) > % fcntl(5,F_SETLKW,0xffffd9a4) = 0 (0x0) > % lseek(5,0x0,SEEK_END) = 138744672 (0x8451360) > % write(5,"F",1) ERR#27 'File too large' > % fstat(5,{ mode=-rw------- > ,inode=336983,size=138744672,blksize=131072 }) = 0 (0x0) > % write(5,"rom lionel.messien+caf_=jlh=chch"...,3627) ERR#27 'File too > large' > > I can append something to the file manually. I wonder if the error > doesn't come from the SETLKW fnctl(2) call, but I cannot experiment it > because truss(1) doesn't show the content of the flock structure. > > If I change the procmail recipe to write to another file (which > doesn't > exist), the file is successfully created and messages can be appended. > I narrowed down the failure threshold between 48 MB and 49 MB (in > steps > of 64 KB, it failed between 781 and 782 blocks). > > > This is a 8.2 32 bits jail on a 8.2 amd64 host. In the jail, /home is > a > nullfs mounted ZFS filesystem. The mailbox is not that big: > > % felucia:jlh$ ls -l Mail/mbox1 > % -rw-------+ 1 jlh jlh 138744672 Feb 19 11:46 Mail/mbox1 > > > (( For some unknown reason some ACL keep appearing, but the problem if > still there > anyway if I do setfacl -b on it: > > % felucia:jlh$ getfacl Mail/mbox1 > % # file: Mail/mbox1 > % # owner: jlh > % # group: jlh > % owner@:rw-p--aARWcCos:------:allow > % group@:------a-R-c--s:------:allow > % everyone@:------a-R-c--s:------:allow > )) > > > Does anyone have an idea about this error? Besides, if someone knows > why those ACLs keep appearing, I would be glad to know it :). > AFAIK, NFSv4 style ACLs are always enabled for ZFS and cannot be turned off. > Thanks. > -- > Jeremie Le Hen > > Men are born free and equal. Later on, they're on their own. > Jean Yanne > _______________________________________________ > 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 20 05:51: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 DE27B106564A; Mon, 20 Feb 2012 05:51:51 +0000 (UTC) (envelope-from kob6558@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 44F938FC1A; Mon, 20 Feb 2012 05:51:50 +0000 (UTC) Received: by wgbgn7 with SMTP id gn7so2827593wgb.1 for ; Sun, 19 Feb 2012 21:51:50 -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=LetQNojZsqSO1pp+bHH1MJUC6BD9dXXsyntoNxosW+U=; b=TkUZcI+eQQlrbaSKrxZEYpPg1Ue3TNiRa6aKkQaFx2nmDpwpbjl2xFuVAtrE/hlMCD 4qMGxwU0NpyscAw1wawpZCBuERMxJy+5DO8Uzm/Kh2VK144cd4h6lmSLoJlBV9d28k03 9IPfRReSmTFKduJ+1Jh1bXchDK6tUTAIoDtSw= MIME-Version: 1.0 Received: by 10.180.92.229 with SMTP id cp5mr11755216wib.8.1329717110084; Sun, 19 Feb 2012 21:51:50 -0800 (PST) Received: by 10.223.158.143 with HTTP; Sun, 19 Feb 2012 21:51:49 -0800 (PST) In-Reply-To: References: <20120217.160430.406937514120319292.hrs@allbsd.org> <4F3E3000.9000206@FreeBSD.org> <20120217.232843.2212672671663755444.hrs@allbsd.org> <4F3EC8DD.6040500@FreeBSD.org> Date: Sun, 19 Feb 2012 21:51:49 -0800 Message-ID: From: Kevin Oberman To: Freddie Cash Content-Type: text/plain; charset=ISO-8859-1 Cc: wblock@wonkity.com, freebsd-stable@freebsd.org, 000.fbsd@quip.cz, Andriy Gapon , 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: Mon, 20 Feb 2012 05:51:51 -0000 On Sat, Feb 18, 2012 at 11:09 PM, Freddie Cash wrote: > If you're mirroring the disk with gmirror, how are you dual-booting the > disk? > > This discussion is about using gmirror to mirror two entire disks, and then > use GPT to partition the mirror device. > > Dual-booting has no bearing on that, as gmirror is a FreeBSD-only > technology. Yes, this discussion is about mirroring and that is only applicable to FreeBSD (as is GEOM, itself), but a full disk geom will use the last block in the disk and GPT does not allow this. If a disk is geomified for any reason and is a dual-boot disk (and I'll admit I can't think of any case where this would make be done today), the compatibility of GEOM and GPT will lead to problems that will get increasingly serious as time passes. It just seems like a very bad idea to play fast and loose with an industry standard like this. It comes back to bite you in the butt all too often. -- R. Kevin Oberman, Network Engineer E-mail: kob6558@gmail.com From owner-freebsd-stable@FreeBSD.ORG Mon Feb 20 08:44: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 E9EBF1065676; Mon, 20 Feb 2012 08:44:02 +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 206DA8FC14; Mon, 20 Feb 2012 08:44:01 +0000 (UTC) Date: Mon, 20 Feb 2012 09:43:59 +0100 From: vermaden To: freebsd-hackers@freebsd.org X-Mailer: interia.pl/pf09 In-Reply-To: References: <4F3EE186.4020801@gmail.com> <201202181409.08859.hselasky@c2i.net> X-Originating-IP: 194.0.181.128 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=1329727440; bh=Y2RQtiVWb64sEd6ziEaKIGP2Phh1yUxw3chpfQYoeLM=; 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=HlMzE1bAx8j0q5mto4JZKu8gr2EtQJQJp2xx194Fr7JTHDxlwLWWbhDCJnKeJ6hbl /7iZc2gyvnbAe+IkYM/f0bod2rcbExM18ADAeDRlxeLmwIk60qz2ssdjD9DtsQ10G0 Tesr+04xfusR2W4jzLqGNqgWz/2IhlwHhbEOv2lI= Cc: matt , gleb.kurtsou@gmail.com, freebsd-stable@freebsd.org, uffe@uffe.org, joe.culler@gmail.com, Hans Petter Selasky , freebsd-current@freebsd.org, lars.engels@0x20.net 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: Mon, 20 Feb 2012 08:44:03 -0000 Hi, new version with new features (and BUGs ;p) Added check if ntfsfix from sysutils/ntfsprogs is available, if Yes then try to fix the NTFS filesystem before mouting it. Added GPL3 License ... just joking ;) ... added FreeBSD License to the file= . Added 'noatime' as a default mount option when possible. Added TIMEOUT so when an 'orphan' STATE file lock remains, it will be delet= ed after a TIMEOUT. Added /usr/local/etc/devd/automount.devd file instead of messing with the b= ase system config at /etc/devd.conf. Added config file to be used from /usr/local/etc/automount.conf file, possi= ble options are (these are defaults): MNTPREFIX=3D"/media" LOG=3D"/var/log/automount.log" STATE=3D"/var/run/automount.state" ENCODING=3D"en_US.ISO8859-1" CODEPAGE=3D"cp437" DATEFMT=3D"%Y-%m-%d %H:%M:%S" USERUMOUNT=3D"NO" Mine config currently has only these: ENCODING=3D"pl_PL.ISO8859-2" CODEPAGE=3D"cp852" USERUMOUNT=3D"YES" The USERMOUNT otions if set to YES (default to NO) will 'chmod +s /sbin/umo= unt', so You can click the ^ button on the devices list in NAUTILUS. These newly mounted devices appear on NAUTILUS sidebar (only with /media pr= efix). But THUNAR and PCMANFM does not do that, You know any other FMs that displa= y mounted thumb drives/devices? EXAMPLE: http://i.imgur.com/qdKdl.png First BUG: (not fixed yet, but workaround already is working) TEST/BUG/CASE: Plug in FAT32 and NTFS drives at the same time, when FAT32 device will be d= etected first, it will get mounted and the NTFS drive will be mounted TWICE= , so I added __check_already_mounted function to check if it is not already= mounted. Below are current script and config files. /usr/local/etc/devd/automount.devd ---------------------------------------------------------------------------= ---- notify 0 { match "system" "DEVFS"; match "type" "CREATE"; match "cdev" "(da|mmcsd)[0-9]+"; action "/usr/local/sbin/automount.sh $cdev attach"; }; notify 0 { match "system" "DEVFS"; match "type" "DESTROY"; match "cdev" "(da|mmcsd)[0-9]+"; action "/usr/local/sbin/automount.sh $cdev detach"; }; ---------------------------------------------------------------------------= ---- /usr/local/etc/automout.conf (can be empty) ---------------------------------------------------------------------------= ---- MNTPREFIX=3D"/media" LOG=3D"/var/log/automount.log" STATE=3D"/var/run/automount.state" ENCODING=3D"en_US.ISO8859-1" CODEPAGE=3D"cp437" DATEFMT=3D"%Y-%m-%d %H:%M:%S" USERUMOUNT=3D"NO" ---------------------------------------------------------------------------= ---- /usr/local/sbin/automount.sh ---------------------------------------------------------------------------= ---- #! /bin/sh # Copyright (c) 2011 Slawomir Wojciech Wojtczak (vermaden) # All rights reserved. # # Redistribution and use in source and binary forms, with or without # modification, are permitted provided that the following conditions are me= t: # 1. Redistributions of source code must retain the above copyright # notice, this list of conditions and the following disclaimer. # 2. Redistributions in binary form must reproduce the above copyright # notice, this list of conditions and the following disclaimer in the # documentation and/or other materials provided with the distribution. # # THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS 'AS IS' AND ANY # EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED # WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE # DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE FOR A= NY # DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGE= S # (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVIC= ES; # LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED A= ND # ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TOR= T # (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF # THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. PATH=3D/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin [ -f /usr/local/etc/automount.conf ] && . /usr/local/etc/automount.conf : ${MNTPREFIX=3D"/media"} : ${LOG=3D"/var/log/automount.log"} : ${STATE=3D"/var/run/automount.state"} : ${ENCODING=3D"en_US.ISO8859-1"} # /* US/Canada */ : ${CODEPAGE=3D"cp437"} # /* US/Canada */ : ${DATEFMT=3D"%Y-%m-%d %H:%M:%S"} # /* 2012-02-20 07:49:09 */ : ${USERUMOUNT=3D"NO"} # /* when YES add suid bit to umoun= t(8) */ [ "${USERUMOUNT}" =3D "YES" ] && chmod u+s /sbin/umount # /* WHEEL group me= mber */ __create_mount_point() { # /* 1=3DDEV */ MNT=3D"${MNTPREFIX}/$( basename ${1} )" mkdir -p ${MNT} chown 1000 ${MNT} } __check_already_mounted() { # /* 1=3DMNT */ mount | grep " ${1} " 1> /dev/null 2> /dev/null && { __log "${I}:already mounted (ntfs)" continue } } __state_lock() { TIMEOUT=3D60 COUNT=3D0 while [ -f ${STATE}.lock ] do sleep 0.5 [ ${COUNT} -gt ${TIMEOUT} ] && break COUNT=3D$(( ${COUNT} + 1 )) 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' ) # /* backslash the slashes ;) = */ sed -i '' "/${BSMNT}\$/d" ${2} } __log() { # /* @=3DMESSAGE */ echo $( date +"${DATEFMT}" ) ${@} >> ${LOG} } case ${2} in (attach) for I in /dev/${1}* do case $( file -b -L -s ${I} | sed -E 's/label:\ \".*\"//g' ) in (*NTFS*) dd < ${I} count=3D1 2> /dev/null | strings | head -1 | grep -q "N= TFS" && { __create_mount_point ${I} which ntfsfix 1> /dev/null 2> /dev/null && { ntfsfix ${I} # /* sysutils/ntfsprogs */ } __check_already_mounted ${MNT} which ntfs-3g 1> /dev/null 2> /dev/null && { ntfs-3g -o noatime ${I} ${MNT} # /* sysutils/fusefs-ntfs */ } || { mount_ntfs -o noatime ${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} __check_already_mounted ${MNT} mount_msdosfs -o large -L ${ENCODING} -D ${CODEPAGE} ${I} ${M= NT} __log "${I}:mount (fat)" } ;; (*ext2*) __create_mount_point ${I} fsck.ext2 -y ${I} mount -t ext2fs -o noatime ${I} ${MNT} __check_already_mounted ${MNT} __log "${I}:mount (ext2)" ;; (*ext3*) __create_mount_point ${I} fsck.ext3 -y ${I} __check_already_mounted ${MNT} mount -t ext2fs -o noatime ${I} ${MNT} __log "${I}:mount (ext3)" ;; (*ext4*) __create_mount_point ${I} fsck.ext4 -y ${I} __check_already_mounted ${MNT} ext4fuse ${I} ${MNT} # /* sysutils/fusefs-ext4fuse */ __log "${I}:mount (ext4)" ;; (*Unix\ Fast\ File*) __create_mount_point ${I} fsck_ufs -y ${I} __check_already_mounted ${MNT} mount -o noatime ${I} ${MNT} __log "${I}:mount (ufs)" ;; (*) case $( dd < ${I} count=3D1 2> /dev/null | strings | head -1 ) in (EXFAT) __create_mount_point ${I} __check_already_mounted ${MNT} mount.exfat -o noatime ${I} ${MNT} # /* sysutils/fusefs-exfat= */ __log "${I}:mount (ufs)" ;; (*) continue ;; esac ;; esac __state_add ${I} $( mount | grep -m 1 " ${MNT} " | awk '{printf $1}' = ) ${MNT} 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 ---------------------------------------------------------------------------= ---- From owner-freebsd-stable@FreeBSD.ORG Mon Feb 20 09:26: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 2D2F5106564A; Mon, 20 Feb 2012 09:26:41 +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 C16028FC1C; Mon, 20 Feb 2012 09:26:39 +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 LAA09696; Mon, 20 Feb 2012 11:26:36 +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 1RzPVz-000Idj-LH; Mon, 20 Feb 2012 11:26:35 +0200 Message-ID: <4F4211BA.6040600@FreeBSD.org> Date: Mon, 20 Feb 2012 11:26:18 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.1) Gecko/20120215 Thunderbird/10.0.1 MIME-Version: 1.0 To: vermaden References: <4F3EE186.4020801@gmail.com> <201202181409.08859.hselasky@c2i.net> In-Reply-To: X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: 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: Mon, 20 Feb 2012 09:26:41 -0000 [cc list trimmed] Hey, this seems like a quite nice tool. Can you create a web-page and/or port for it? It would be more convenient to follow its development that way. Thank you! on 20/02/2012 10:43 vermaden said the following: > Hi, > > new version with new features (and BUGs ;p) > > Added check if ntfsfix from sysutils/ntfsprogs is available, if Yes then > try to fix the NTFS filesystem before mouting it. > > Added GPL3 License ... just joking ;) ... added FreeBSD License to the file. > > Added 'noatime' as a default mount option when possible. > > Added TIMEOUT so when an 'orphan' STATE file lock remains, it will be deleted after a TIMEOUT. > > Added /usr/local/etc/devd/automount.devd file instead of messing with the base system config at /etc/devd.conf. > > Added config file to be used from /usr/local/etc/automount.conf file, possible options are (these are defaults): > MNTPREFIX="/media" > LOG="/var/log/automount.log" > STATE="/var/run/automount.state" > ENCODING="en_US.ISO8859-1" > CODEPAGE="cp437" > DATEFMT="%Y-%m-%d %H:%M:%S" > USERUMOUNT="NO" > > Mine config currently has only these: > ENCODING="pl_PL.ISO8859-2" > CODEPAGE="cp852" > USERUMOUNT="YES" > > The USERMOUNT otions if set to YES (default to NO) will 'chmod +s /sbin/umount', > so You can click the ^ button on the devices list in NAUTILUS. > > These newly mounted devices appear on NAUTILUS sidebar (only with /media prefix). > > But THUNAR and PCMANFM does not do that, You know any other FMs that display mounted thumb drives/devices? > > EXAMPLE: http://i.imgur.com/qdKdl.png > > First BUG: (not fixed yet, but workaround already is working) > > TEST/BUG/CASE: > Plug in FAT32 and NTFS drives at the same time, when FAT32 device will be detected first, it will get mounted and the NTFS drive will be mounted TWICE, so I added __check_already_mounted function to check if it is not already mounted. > > > > Below are current script and config files. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Mon Feb 20 10:07: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 706FD1065670; Mon, 20 Feb 2012 10:07:37 +0000 (UTC) (envelope-from fidaj@ukr.net) Received: from fsm1.ukr.net (fsm1.ukr.net [195.214.192.120]) by mx1.freebsd.org (Postfix) with ESMTP id 213A08FC12; Mon, 20 Feb 2012 10:07:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ukr.net; s=fsm; h=Content-Transfer-Encoding:Content-Type:Mime-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=6R2YKB35g3YxXyYRdDWy2kbxBVDpk9bEjzPKqKi3OWE=; b=XdF4tilzSQrlIjeNPxTakwmn1ssLmdakMRR8AqUf753YyWFci5M5dfUGX0UNiKOKxCI7UktVuW7TvL0hLGgxls3KQlDtcBFW/h55AJGm9hMlMu1AvQAKH1ZmdfNub+rHuwNgYIaS6N273Hp4bYLKCkCDSNggTL9jSVeyvLNcPAQ=; Received: from [178.137.138.140] (helo=nonamehost.) by fsm1.ukr.net with esmtpsa ID 1RzPro-000Hgk-Pa ; Mon, 20 Feb 2012 11:49:08 +0200 Date: Mon, 20 Feb 2012 11:49:07 +0200 From: Ivan Klymenko To: vermaden Message-ID: <20120220114907.59c76417@nonamehost.> In-Reply-To: References: <4F3EE186.4020801@gmail.com> <201202181409.08859.hselasky@c2i.net> X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.6; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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: Mon, 20 Feb 2012 10:07:37 -0000 =D0=92 Mon, 20 Feb 2012 09:43:59 +0100 vermaden =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > Hi, >=20 > new version with new features (and BUGs ;p) >=20 > Added check if ntfsfix from sysutils/ntfsprogs is available, if Yes > then try to fix the NTFS filesystem before mouting it. >=20 > Added GPL3 License ... just joking ;) ... added FreeBSD License to > the file. >=20 > Added 'noatime' as a default mount option when possible. >=20 > Added TIMEOUT so when an 'orphan' STATE file lock remains, it will be > deleted after a TIMEOUT. >=20 > Added /usr/local/etc/devd/automount.devd file instead of messing with > the base system config at /etc/devd.conf. >=20 > Added config file to be used from /usr/local/etc/automount.conf file, > possible options are (these are defaults): MNTPREFIX=3D"/media" > LOG=3D"/var/log/automount.log" > STATE=3D"/var/run/automount.state" > ENCODING=3D"en_US.ISO8859-1" > CODEPAGE=3D"cp437" > DATEFMT=3D"%Y-%m-%d %H:%M:%S" > USERUMOUNT=3D"NO" >=20 > Mine config currently has only these: > ENCODING=3D"pl_PL.ISO8859-2" > CODEPAGE=3D"cp852" > USERUMOUNT=3D"YES" >=20 > The USERMOUNT otions if set to YES (default to NO) will 'chmod > +s /sbin/umount', so You can click the ^ button on the devices list > in NAUTILUS. >=20 > These newly mounted devices appear on NAUTILUS sidebar (only > with /media prefix). >=20 > But THUNAR and PCMANFM does not do that, You know any other FMs that > display mounted thumb drives/devices? >=20 > EXAMPLE: http://i.imgur.com/qdKdl.png >=20 > First BUG: (not fixed yet, but workaround already is working) >=20 > TEST/BUG/CASE: > Plug in FAT32 and NTFS drives at the same time, when FAT32 device > will be detected first, it will get mounted and the NTFS drive will > be mounted TWICE, so I added __check_already_mounted function to > check if it is not already mounted. Thank you so much! Could you update, please first post in the forum? http://forums.freebsd.org/showthread.php?t=3D29895 Thanks! From owner-freebsd-stable@FreeBSD.ORG Mon Feb 20 13:16: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 6D7831065672; Mon, 20 Feb 2012 13:16: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 2678A8FC13; Mon, 20 Feb 2012 13:16:29 +0000 (UTC) Date: Mon, 20 Feb 2012 14:16:27 +0100 From: vermaden To: Andriy Gapon X-Mailer: interia.pl/pf09 In-Reply-To: <4F4211BA.6040600@FreeBSD.org> References: <4F3EE186.4020801@gmail.com> <201202181409.08859.hselasky@c2i.net> <4F4211BA.6040600@FreeBSD.org> X-Originating-IP: 194.0.181.128 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=1329743787; bh=517K+7IXdEdFEHLJt9a19sgrvhBcN2w+CMgHA/O6fBk=; 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=qBNeApRFCMUL2hJgROvMtR3awPeYnYeja1SWdSb69SR86J8gZYD3wVhy/24FxSsOw pXEWcy82RoHtHn5W9JS0VxKM8uVd3Xvw+HcORQANy/uHowa/KrM2bYUgX5BluaB/jy eLIONBMHze/tBk2Gr/TEmARfPUW+4nqEj90U+wck= Cc: 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: Mon, 20 Feb 2012 13:16:29 -0000 written by Andriy Gapon ... > Hey, this seems like a quite nice tool. > Can you create a web-page and/or port for it? > It would be more convenient to follow its development that way. > Thank you! Sure, its now available here, I will try to create port later: https://github.com/vermaden/automount written by Ivan Klymenko ... > Thank you so much! Welcome ;) > Could you update, please first post in the forum? > http://forums.freebsd.org/showthread.php?t=3D29895 I will do that after I sent this mail ;) Regards, vermaden ... From owner-freebsd-stable@FreeBSD.ORG Mon Feb 20 13:27: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 0CAD0106566B; Mon, 20 Feb 2012 13:27:19 +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 B8B308FC17; Mon, 20 Feb 2012 13:27:18 +0000 (UTC) Date: Mon, 20 Feb 2012 14:27:17 +0100 From: vermaden To: freebsd-hackers@freebsd.org X-Mailer: interia.pl/pf09 In-Reply-To: References: <4F3EE186.4020801@gmail.com> <201202181409.08859.hselasky@c2i.net> X-Originating-IP: 194.0.181.128 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=1329744437; bh=eGPVCiTg2TrYYocs0g18zqWUvpG1TOTXPQw7BC0c598=; 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=k+vRDkwAFtNmVAwhkRuKIUi1g1yI6Zf4we4zLt71I+NvqFBjXUMiaZXyW73QxyqeY oFLj8mv30VMQIJtkD45DADDpCUXzOEaZQ1IwtAQ2S4Iivp8WdTYv29BI5hHj3qjhvN OwHOwDk2VUSMpC705elVU8Xkgit8gi6kJkXn023Q= Cc: 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: Mon, 20 Feb 2012 13:27:19 -0000 written by ${ME} ... > First BUG: (not fixed yet, but workaround already is working) >=20 > TEST/BUG/CASE: > Plug in FAT32 and NTFS drives at the same time, when FAT32 device > will be detected first, it will get mounted and the NTFS drive will be > mounted TWICE, so I added > __check_already_mounted function > to check if it is not already mounted. This BUG is fixed, I was in wrong assumption, that the script would be only executed for /dev/da0 but it was executed for every device/partition node that appeared separately, like /dev/da0, /dev/da0s1, /dev/da0s2 etc. Currently there is no knows bugs, but the prepared earlier 'workaround functions' remain just in case. As I written before its now available here: https://github.com/vermaden/automount Regards, vermaden --- From owner-freebsd-stable@FreeBSD.ORG Mon Feb 20 14: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 7F745106566B for ; Mon, 20 Feb 2012 14:13:57 +0000 (UTC) (envelope-from peter.maloney@brockmann-consult.de) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.10]) by mx1.freebsd.org (Postfix) with ESMTP id EEB0D8FC17 for ; Mon, 20 Feb 2012 14:13:56 +0000 (UTC) Received: from [10.3.0.26] ([141.4.215.32]) by mrelayeu.kundenserver.de (node=mreu2) with ESMTP (Nemesis) id 0Lr6Jj-1ScvYW1aOx-00eFkZ; Mon, 20 Feb 2012 15:13:55 +0100 Message-ID: <4F425523.9060709@brockmann-consult.de> Date: Mon, 20 Feb 2012 15:13:55 +0100 From: Peter Maloney User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110922 Thunderbird/3.1.15 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: In-Reply-To: X-Enigmail-Version: 1.1.2 X-Provags-ID: V02:K0:L+ElOytJP6iEa2GYxeMGrN7GaiYVksZd+Uf2zsJHXvL g2vOlnUSNYXoEZ4USedtniIlgUtvbASm7pmyvOnnZxk1RoD2Tk Idut1QCWsDhqJBsKwEOYbktrOSFfbGKubEahdpfFY4Ag65Ja37 7n1qIHs5nFR9ObxBSw4MmDevqyHvJ8kREfUGkhmdYf+pZpOHw6 M4JvGnnCiO1Tzz0zUsmZax2/1k4Jr9VnVY2N4cBBb1HlPjMaPW wY6w6uTiXtLcQKxD0aluPwwDg7T3gElGewwL0bUEnKvXSPYsty Po7Pehg/XK1j6KfSkyoKtMbHYiYF0zkFPHgTt7ZUylx/yRflfj K277oVUWhXJVfn5QQh1h6PVxja+9wsIjLssqi/ThB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: 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: Mon, 20 Feb 2012 14:13:57 -0000 Am 17.02.2012 21:08, schrieb Edwin L. Culp W.: > 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. To create a full document from scratch explaining everything is likely beyond the capabilites of any individual. If you had more specific questions or topics, it would help us to help you more efficiently. What are you looking for? A gpart howto? Mirroring and other types of devices? mbr vs gpt? Whether or not to have separate partitions for /usr and /var, etc.? And then when you get your answers, submit a PR including the details of what you expected in the handbook, and what you learned elsewhere that should be added, and then in the PR, ask them to add what you wrote in the PR to the handbook. Personally, I can tell you a bunch about gpart, zfs, and explain or elaborate on technical jargon, but I don't know too much about sysinstall, bsdlabel, UFS, different boot options or FreeBSD software raid configuration files. All my FreeBSD machines are running pure ZFS, and I've only created temporary gpart, gstripe, etc. for tests so far. If I needed to put together a real software raid UFS system, I would need to look through documentation. > 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. I think he means something like this, but I don't know how to use bsdlabel, so here is gpart (one of the new things you should learn anyway). And also I don't know if the result of my code below would even boot, which bootcode to use, or what to put in /boot/loader.conf to make it boot. # create a gpt table (rather than MBR) gpart create -s gpt da0 #(not sure... boot loader needed outside the mirror?) gpart add -s 64k -l boot1 -t freebsd-boot da0 # add a slice for your mirror (aka. partition). # from quote: "But even with one mirror," gpart add -s 80g -l mirrorslice1 -t mbr da0 # set up the second disk gpart create -s gpt da1 #(not sure... boot loader needed outside the mirror?) gpart add -s 64k -l boot2 -t freebsd-boot da1 # from quote: "you can mirror *a big partiton* covering the whole drive" gpart add -s 80g -l mirrorslice2 -t mbr da1 # Not sure if "mbr" is the right choice for the type above... I also tried guessing "gpt" which didn't work and is not in the manual. # create the mirror device (I don't know the proper way to do this... I just tried this and don't know if it persists on boot, etc.) # from quote: "*you can mirror* a big partiton covering the whole drive" gmirror load gmirror label mymirror gpt/mirrorslice1 gpt/mirrorslice2 # slice the mirror device as if it was a regular disk # from quote: "and then carve that up with bsdlabel" (but I used gpart instead of bsdlabel) gpart create -s gpt gmirror/mymirror gpart add -s 1g -l root -t freebsd-ufs gmirror/mymirror gpart add -s 1g -l usr -t freebsd-ufs gmirror/mymirror newfs gpt/root newfs gpt/usr Further explanation of other things he said not involved in the above: "wasn't suggesting that you should always mirror the individual partititons" gpart create -s gpt da0 gpart create -s gpt da1 gpart add -s 1g -l root1 -t freebsd-ufs da0 gpart add -s 1g -l root2 -t freebsd-ufs da1 gpart add -s 1g -l usr1 -t freebsd-ufs da0 gpart add -s 1g -l usr2 -t freebsd-ufs da1 ... gmirror label rootmirror gpt/root1 gpt/root2 gmirror label mymirror gpt/usr1 gpt/usr2 ... #and an example of what he said you don't need to do: # from quote: "No need to ever mirror actual raw discs" gmirror label mymirror da0 da1 raw disk = da0 gpt slice/partition = da0p1 where 1 is the index seen in "gpart show" or gpt slice/partition = gpt/root1 where root1 is the label seen in "gpart show -l" and set in "gpart add ... -l labelhere" mirror device = mirror/mymirror etc. Be sure to align properly. I didn't do any aligning above. Use the "-a ..." option. Units in gpart are sectors unless you specify another, and sizes are in base-2 (eg. "-s 5g" would be a size of 5 GiB not 5GB) And you would also need a boot slice separate from the mirror unless the bootloader understands the mirror, and install the bootloader on both disks. I don't know if it does support this, or if it will work at all this way. You need to find this out somewhere other than from me. > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Mon Feb 20 18:56:41 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 12DFB106564A; Mon, 20 Feb 2012 18:56:41 +0000 (UTC) (envelope-from fernando.apesteguia@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 2513D8FC19; Mon, 20 Feb 2012 18:56:39 +0000 (UTC) Received: by lagz14 with SMTP id z14so9803374lag.13 for ; Mon, 20 Feb 2012 10:56:38 -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=VkG3S8yeRiyCDUkbWLfUqPnE/9PntwquzUJ1FS0q7DY=; b=i0Jm5vGK3PyCdEG22urQge/pTpR1GNTCrS6JZXG3JObrH1G1X0rjqoK0XgYazZWIF9 DC9yVA7T9a/ZuLvTl/6OQT8mKc973Hglr6HYEh+xDb8WfRtUX78efkqrPYd+lNHg4Ecg 0D0A2VOfa4HCB1B99Bz8bm6+YUftmeFvf92jw= MIME-Version: 1.0 Received: by 10.152.147.1 with SMTP id tg1mr13743934lab.22.1329762687569; Mon, 20 Feb 2012 10:31:27 -0800 (PST) Received: by 10.152.13.72 with HTTP; Mon, 20 Feb 2012 10:31:27 -0800 (PST) In-Reply-To: References: <4F3EE186.4020801@gmail.com> <201202181409.08859.hselasky@c2i.net> Date: Mon, 20 Feb 2012 19:31:27 +0100 Message-ID: From: =?ISO-8859-1?Q?Fernando_Apestegu=EDa?= To: vermaden Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 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: Mon, 20 Feb 2012 18:56:41 -0000 On Mon, Feb 20, 2012 at 2:27 PM, vermaden wrote: > written by ${ME} ... > > > First BUG: (not fixed yet, but workaround already is working) > > > > TEST/BUG/CASE: > > Plug in FAT32 and NTFS drives at the same time, when FAT32 device > > will be detected first, it will get mounted and the NTFS drive will be > > mounted TWICE, so I added > __check_already_mounted function > > to check if it is not already mounted. > > This BUG is fixed, I was in wrong assumption, that the script would > be only executed for /dev/da0 but it was executed for every > device/partition node that appeared separately, like /dev/da0, > /dev/da0s1, /dev/da0s2 etc. > > Currently there is no knows bugs, but the prepared earlier > 'workaround functions' remain just in case. > > As I written before its now available here: > https://github.com/vermaden/automount > What a nice piece of work. I just downloaded it and try it on a FreeBSD 9.0-RELEASE with custom kernel. It works like a charm. I tried three different USB devices without noticing any problems (and I was very impolite when I unplugged them). Thanks for this script. > Regards, > vermaden > > > > > > > > > > > > > > > > > > > --- > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Mon Feb 20 19:17: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 C95731065670; Mon, 20 Feb 2012 19:17:26 +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 8001D8FC0A; Mon, 20 Feb 2012 19:17:26 +0000 (UTC) Date: Mon, 20 Feb 2012 20:17:23 +0100 From: vermaden To: Freddie Cash , fernando.apesteguia@gmail.com X-Mailer: interia.pl/pf09 In-Reply-To: References: <4F3EE186.4020801@gmail.com> <201202181409.08859.hselasky@c2i.net> 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=1329765444; bh=uMYrSnlaRG9ek8YMAgsT8vbd52OexD3LRy6eEC9BVjo=; 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=B9jfS8mYmxD+kO+8tg/2zIHZvojmdcM5v8h6HN3DCTpeZgAJvAY/ylRNwhUhPZSVm rRmK4tUb5YC9NQN0CoHV9r/jq98j0jGWTnWy2Kdw3lHqzm6ZJEWORJXgG1Wp4p2BBr udXzBYjvpKe1def6q4PDWPg93UmECufpl4J7qWQU= 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: Mon, 20 Feb 2012 19:17:26 -0000 Hi, I removed the state_lock and stat_unlock mechanisms as they appeared to be not needed, I have shufled with 3 drives all the time and the 'integrity' has not been lost, at it was a lot faster, because the lock always had to wait for the 'slowest' drive (in term of initializing the device, like USB hard drive). I simplified the 'attach' section a lot, now each filesystem contains only check/fsck (if possible), mount and log info. I also simplified and improved the 'detach' section a little. I have added an option to automatically launch the set-up in config file manager (Yes, like in Windows ;p).=20 These are options that I currently successfully use for NAUTILUS file manager, You need to set-up all three of them to make it work. | POPUP=3DYES | FM=3D"nautilus --browser --no-desktop" | USER=3Dvermaden My whole config looks like that now: | USERUMOUNT=3DYES | POPUP=3DYES | FM=3D"nautilus --browser --no-desktop" | USER=3Dvermaden | ENCODING=3Dpl_PL.ISO8859-2 | CODEPAGE=3Dcp852 All latest updates are available at GITHUB: https://github.com/vermaden/automount written by Freddie Cash ... > Konqueror (KDE 3.x and 4.x) and Dolphin (KDE 4.x mainly, but I > believe there's a KDE 3.x version) also show automatically > mounted and removable media in the sidebar. Works nicely > with HAL. Haven't tested your script yet, but am intrigued by it. > Will see if I can test it sometime this week. >=20 > Native solutions are so much nicer than ported ones. :) Thanks, looking forward to hear some more input about it from You ;) written by Fernando Apestegu=C3=ADa ... > What a nice piece of work. Thanks mate. > I just downloaded it and try it on a FreeBSD 9.0-RELEASE with > custom kernel. It works like a charm. I tried three different > USB devices without noticing any problems (and I was very > impolite when I unplugged them). >=20 > Thanks for this script. Good to know, try the latest new version from repo, should be even better ;= ) Regards, vermaden From owner-freebsd-stable@FreeBSD.ORG Mon Feb 20 19:24: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 05724106564A for ; Mon, 20 Feb 2012 19:24:59 +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 B077F8FC1E for ; Mon, 20 Feb 2012 19:24:58 +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 1RzYqt-000My1-M6; Mon, 20 Feb 2012 21:24:49 +0200 Message-ID: <4F429DFB.8050003@os2.kiev.ua> Date: Mon, 20 Feb 2012 20:24:43 +0100 From: Alex Samorukov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 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: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SA-Score: -1.0 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: Mon, 20 Feb 2012 19:24:59 -0000 On 02/15/2012 05:50 AM, Scott Long wrote: > > 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. > > 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?. May be its possible to provide some generic interface for fuse based filesystems to use this generic cache? I can test it and report performance. From owner-freebsd-stable@FreeBSD.ORG Mon Feb 20 19: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 C4BE51065674; Mon, 20 Feb 2012 19:30:03 +0000 (UTC) (envelope-from kensmith@buffalo.edu) Received: from localmailA.acsu.buffalo.edu (localmaila.acsu.buffalo.edu [128.205.5.196]) by mx1.freebsd.org (Postfix) with ESMTP id 8A2C38FC12; Mon, 20 Feb 2012 19:30:03 +0000 (UTC) Received: from localmailA.acsu.buffalo.edu (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id E7EFCB5DB; Mon, 20 Feb 2012 14:30:00 -0500 (EST) Received: from localmailA.acsu.buffalo.edu (localhost [127.0.0.1]) by localmailA.acsu.buffalo.edu (Postfix) with ESMTP id A376CD7D9; Mon, 20 Feb 2012 14:29:59 -0500 (EST) Received: from smtp3.acsu.buffalo.edu (smtp3.acsu.buffalo.edu [128.205.5.226]) by localmailA.acsu.buffalo.edu (Prefixe) with ESMTP id 8C3B4D7BE; Mon, 20 Feb 2012 14:29:59 -0500 (EST) Received: from [128.205.32.76] (bauer.cse.buffalo.edu [128.205.32.76]) (Authenticated sender: kensmith@buffalo.edu) by smtp3.acsu.buffalo.edu (Postfix) with ESMTPSA id 61C574A676; Mon, 20 Feb 2012 14:29:59 -0500 (EST) From: Ken Smith To: freebsd-stable Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-YOoeoQkIHvhngAvIsve7" Date: Mon, 20 Feb 2012 14:29:58 -0500 Message-ID: <1329766198.28432.20.camel@bauer.cse.buffalo.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port X-PM-EL-Spam-Prob: : 8% Cc: re Subject: FreeBSD 8.3-BETA1 Available... X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 20 Feb 2012 19:30:03 -0000 --=-YOoeoQkIHvhngAvIsve7 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The first BETA build of the 8.3-RELEASE release cycle is now available on the FTP servers for the amd64, i386, and pc98 architectures. The MD5/SHA256 sums are tacked on to the bottom of this message. The ISO and, for architectures that support it, the memory stick images are available here: ftp://ftp.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/8.3/ (or any of the FreeBSD mirror sites). 8.3-BETA1 images have also been published for Amazon EC2. Since the stable/8 branch is relatively mature we hope there will only be one BETA build for this release cycle. If testing does not turn up any show-stopper caliber problems the next test build will be RC1. If you notice problems you can report them through the normal Gnats PR system or here on the -stable mailing list. If you would like to use csup/cvsup mechanisms to do a source-based update of an existing system the branch tag to use is "RELENG_8". If you would like to use SVN instead use "stable/8". The freebsd-update(8) utility supports binary upgrades of i386 and amd64= =20 systems running earlier FreeBSD releases. Systems running 8.1-RELEASE or 8.2-RELEASE can upgrade as follows: # freebsd-update upgrade -r 8.3-BETA1 During this process, FreeBSD Update may ask the user to help by merging=20 some configuration files or by confirming that the automatically performed merging was done correctly. # freebsd-update install The system must be rebooted with the newly installed kernel before=20 continuing. # shutdown -r now After rebooting, freebsd-update needs to be run again to install the new= =20 userland components, and the system needs to be rebooted again: # freebsd-update install # shutdown -r now Users of earlier FreeBSD releases (FreeBSD 7.x) can also use freebsd-update to upgrade to FreeBSD 8.3-BETA1, but will be prompted to rebuild all third-party applications (e.g., anything installed from the ports tree) after the second invocation of "freebsd-update install", in order to handle differences in the system libraries between FreeBSD 7.x and FreeBSD 8.x. Checksums: MD5 (FreeBSD-8.3-BETA1-amd64-bootonly.iso) =3D 7388a064ca3b0bc940689ba19e69= cd6d MD5 (FreeBSD-8.3-BETA1-amd64-disc1.iso) =3D 27a802d54dc5bf7fa4048ee8aec9967= 0 MD5 (FreeBSD-8.3-BETA1-amd64-dvd1.iso) =3D 231339687c8e0830b4bf94330dc6f1a2 MD5 (FreeBSD-8.3-BETA1-amd64-livefs.iso) =3D 006ef033296c7af3c0742a9740ff57= c8 MD5 (FreeBSD-8.3-BETA1-amd64-memstick.img) =3D b366d83103944347a1334ea84086= 4a90 MD5 (FreeBSD-8.3-BETA1-i386-bootonly.iso) =3D 5f4706c8bd618eaba404aa870dd7d= 5f7 MD5 (FreeBSD-8.3-BETA1-i386-disc1.iso) =3D e8772d8cc14eab349f061dc635f9e668 MD5 (FreeBSD-8.3-BETA1-i386-dvd1.iso) =3D f958c31608eed50a280e4330840b6c84 MD5 (FreeBSD-8.3-BETA1-i386-livefs.iso) =3D b5c86e5f1d71166d440323be7a84625= 4 MD5 (FreeBSD-8.3-BETA1-i386-memstick.img) =3D d4fb497ceb71350ae601b5c8b7cc8= 304 MD5 (FreeBSD-8.3-BETA1-pc98-bootonly.iso) =3D 9b5b97c805cbdd74198523cb62db5= 0c8 MD5 (FreeBSD-8.3-BETA1-pc98-disc1.iso) =3D 120117ba0ff961c6c6e1fbecc2981b80 MD5 (FreeBSD-8.3-BETA1-pc98-livefs.iso) =3D 8cd151d1a81c8c3b589214a8650ace6= 1 SHA256 (FreeBSD-8.3-BETA1-amd64-bootonly.iso) =3D 8ce4221a7cffdf253ec5ccfec= 986ab4a7bbd5b15a628358087557a11c27dc7ae SHA256 (FreeBSD-8.3-BETA1-amd64-disc1.iso) =3D b9aa0aca927adb3b0fc552039ccc= 0814d0334c6b4036ce94423c92c240abc0dc SHA256 (FreeBSD-8.3-BETA1-amd64-dvd1.iso) =3D ac007c1c68cb3509d148361a2f441= 6950d065bd0769843232f478074bb6dad33 SHA256 (FreeBSD-8.3-BETA1-amd64-livefs.iso) =3D 0255be23addea15cdc04fc0a6e6= 8ddf522ca7b414825fcf0dc26ccd88f361be6 SHA256 (FreeBSD-8.3-BETA1-amd64-memstick.img) =3D a50b3816aa92e07199b6f2148= 8a20cb8a21ba15fb5fc6daff1d28511945676d4 SHA256 (FreeBSD-8.3-BETA1-i386-bootonly.iso) =3D a74e7427ee770f37b91a5087e6= 36d5fff069ef1ec6e40971b9eee7f0f780d129 SHA256 (FreeBSD-8.3-BETA1-i386-disc1.iso) =3D 79888894fe9293b8b5baab164cd98= 5722b9392adc18471056bc24d75f63699ac SHA256 (FreeBSD-8.3-BETA1-i386-dvd1.iso) =3D e77903e9920d7b5231a1ac11e9e7ed= c9938e8ff2f72f2e15a158f952b4561723 SHA256 (FreeBSD-8.3-BETA1-i386-livefs.iso) =3D ea175a30dce0071c5f3e25d5bb73= c467f4c143a55d367eb873922c91e11c703e SHA256 (FreeBSD-8.3-BETA1-i386-memstick.img) =3D a2d093be060a0f09a6c11376b2= fb27fa38ebaf9892b30e771b465370230f50c0 SHA256 (FreeBSD-8.3-BETA1-pc98-bootonly.iso) =3D d353ae427f610c9d8346cbddbc= 2c5bae9a0b5929f4767041f0fe1b6f397a122c SHA256 (FreeBSD-8.3-BETA1-pc98-disc1.iso) =3D ff54d85eb982b64b3665a3b940be8= 0447b9732f013f5997a78638ab74ee85bee SHA256 (FreeBSD-8.3-BETA1-pc98-livefs.iso) =3D a7a99525552c0771d84fdbdea494= 31e482ab854e327fe02b84d271eb5757dead --=20 Ken Smith - From there to here, from here to | kensmith@buffalo.edu there, funny things are everywhere. | - Theodor Geisel | --=-YOoeoQkIHvhngAvIsve7 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) iEYEABECAAYFAk9CnysACgkQ/G14VSmup/b/YwCfXThyzWg3JHS01c3sDq9htryM fDEAn3zOfrE3JCadfWi06LtN9IL1zp5m =rYgO -----END PGP SIGNATURE----- --=-YOoeoQkIHvhngAvIsve7-- From owner-freebsd-stable@FreeBSD.ORG Mon Feb 20 20:25: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 D84E8106566B for ; Mon, 20 Feb 2012 20:25:28 +0000 (UTC) (envelope-from jeremie@le-hen.org) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [IPv6:2a01:e0c:1:1599::14]) by mx1.freebsd.org (Postfix) with ESMTP id 35D648FC16 for ; Mon, 20 Feb 2012 20:25:26 +0000 (UTC) Received: from endor.tataz.chchile.org (unknown [82.233.239.98]) by smtp5-g21.free.fr (Postfix) with ESMTP id 290DDD4802F; Mon, 20 Feb 2012 21:25:18 +0100 (CET) Received: from felucia.tataz.chchile.org (felucia.tataz.chchile.org [192.168.1.9]) by endor.tataz.chchile.org (Postfix) with ESMTP id 0039322C2; Mon, 20 Feb 2012 20:25:17 +0000 (UTC) Received: by felucia.tataz.chchile.org (Postfix, from userid 1000) id C9AD73279; Mon, 20 Feb 2012 20:25:17 +0000 (UTC) Date: Mon, 20 Feb 2012 21:25:17 +0100 From: Jeremie Le Hen To: Rick Macklem Message-ID: <20120220202517.GC37684@felucia.tataz.chchile.org> References: <20120219213607.GO31770@felucia.tataz.chchile.org> <1984136644.1631414.1329698802016.JavaMail.root@erie.cs.uoguelph.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1984136644.1631414.1329698802016.JavaMail.root@erie.cs.uoguelph.ca> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@FreeBSD.org, Jeremie Le Hen Subject: Re: "File too large" error when appending to a file of 130 MB X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 20 Feb 2012 20:25:28 -0000 Hi Rick, On Sun, Feb 19, 2012 at 07:46:42PM -0500, Rick Macklem wrote: > > This is a 8.2 32 bits jail on a 8.2 amd64 host. In the jail, /home is > > a > > nullfs mounted ZFS filesystem. The mailbox is not that big: > > > > % felucia:jlh$ ls -l Mail/mbox1 > > % -rw-------+ 1 jlh jlh 138744672 Feb 19 11:46 Mail/mbox1 > > > > > > (( For some unknown reason some ACL keep appearing, but the problem if > > still there > > anyway if I do setfacl -b on it: > > > > % felucia:jlh$ getfacl Mail/mbox1 > > % # file: Mail/mbox1 > > % # owner: jlh > > % # group: jlh > > % owner@:rw-p--aARWcCos:------:allow > > % group@:------a-R-c--s:------:allow > > % everyone@:------a-R-c--s:------:allow > > )) > > > > > > Does anyone have an idea about this error? Besides, if someone knows > > why those ACLs keep appearing, I would be glad to know it :). > > > AFAIK, NFSv4 style ACLs are always enabled for ZFS and cannot be turned > off. Weirdly, some of my mailboxes don't have such ACLs, including some I've recently written into. How is it possible? -- Jeremie Le Hen Men are born free and equal. Later on, they're on their own. Jean Yanne From owner-freebsd-stable@FreeBSD.ORG Mon Feb 20 21:14:14 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 5283E1065670 for ; Mon, 20 Feb 2012 21:14:14 +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 ED2ED8FC1E for ; Mon, 20 Feb 2012 21:14:13 +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 q1KLBU30004378; Mon, 20 Feb 2012 16:13:43 -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 UIH83414; Mon, 20 Feb 2012 16:13:43 -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 q1KLDgwC031178 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 20 Feb 2012 16:13:42 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Paul Mather In-Reply-To: <20120218012746.GA3283@deviant.kiev.zoral.com.ua> Date: Mon, 20 Feb 2012 16:13:42 -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> <20120218012746.GA3283@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.0A02020B.4F42B787.000E,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: Mon, 20 Feb 2012 21:14:14 -0000 On Feb 17, 2012, at 8:27 PM, Konstantin Belousov wrote: > 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 = 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". >>=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 = 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 >=20 > This is indeed strange. It can only occur if td pointer is damaged. >=20 > Please, try to get a core and at least print the content of *td in = this case. Hopefully, I will be able to get a crash dump tonight. I disabled the = Tivoli "dsmc schedule" job over the weekend, because I don't have ready = physical access to the machine and prefer it not to be down for very = extended periods of time. (As I reported previously, for some reason = the system seems to get stuck saving the crash dump. If this persists, = maybe it might be better to get the system to drop into the debugger on = panic instead of hoping forlornly for a successful crash dump.) Cheers, Paul. From owner-freebsd-stable@FreeBSD.ORG Mon Feb 20 22:21: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 2BD7D106566C for ; Mon, 20 Feb 2012 22:21:01 +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 CD8228FC16 for ; Mon, 20 Feb 2012 22:21:00 +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 q1KMKtdZ035218; Mon, 20 Feb 2012 15:20:55 -0700 (MST) (envelope-from scottl@samsco.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Scott Long In-Reply-To: <4F429DFB.8050003@os2.kiev.ua> Date: Mon, 20 Feb 2012 15:20:54 -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> <4F429DFB.8050003@os2.kiev.ua> To: Alex Samorukov X-Mailer: Apple Mail (2.1257) 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, 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: Mon, 20 Feb 2012 22:21:01 -0000 On Feb 20, 2012, at 12:24 PM, Alex Samorukov wrote: > On 02/15/2012 05:50 AM, Scott Long wrote: >>=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?. > May be its possible to provide some generic interface for fuse based = filesystems to use this generic cache? I can test it and report = performance. >=20 What you're asking for is to bring back the cached raw devices. I don't = have a strong opinion on this one way or another, except that it's a = pretty specific use case. Does the inherent performance gap with user = land filesystems warrant this? Maybe a simple cache layer can be put = into FUSE that would allow client filesystems the same control over = block caching and clustering that is afforded in the kernel? Scott From owner-freebsd-stable@FreeBSD.ORG Mon Feb 20 23:05: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 563511065701 for ; Mon, 20 Feb 2012 23:05:18 +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 0CBB98FC0C for ; Mon, 20 Feb 2012 23:05:17 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap8EAP3QQk+DaFvO/2dsb2JhbABDhRKtcoFzAQEBBAEBASArIAsbGAICDRkCKQEJJgYIBwQBHASHaKZ5khOBL4gdAYJaCAEBAhYBCQIJDQMCgzQBMwUCAgECAQIBCwEDDYIugRYEiE6KQYIokwuBPg X-IronPort-AV: E=Sophos;i="4.73,453,1325480400"; d="scan'208";a="157177462" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 20 Feb 2012 18:05:17 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id F2AF6B3EB2; Mon, 20 Feb 2012 18:05:16 -0500 (EST) Date: Mon, 20 Feb 2012 18:05:16 -0500 (EST) From: Rick Macklem To: Jeremie Le Hen Message-ID: <501878740.1651247.1329779116977.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <20120220202517.GC37684@felucia.tataz.chchile.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-stable@FreeBSD.org Subject: Re: "File too large" error when appending to a file of 130 MB X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 20 Feb 2012 23:05:18 -0000 Jeremie Le Hen wrote: > Hi Rick, > > On Sun, Feb 19, 2012 at 07:46:42PM -0500, Rick Macklem wrote: > > > This is a 8.2 32 bits jail on a 8.2 amd64 host. In the jail, /home > > > is > > > a > > > nullfs mounted ZFS filesystem. The mailbox is not that big: > > > > > > % felucia:jlh$ ls -l Mail/mbox1 > > > % -rw-------+ 1 jlh jlh 138744672 Feb 19 11:46 Mail/mbox1 > > > > > > > > > (( For some unknown reason some ACL keep appearing, but the > > > problem if > > > still there > > > anyway if I do setfacl -b on it: > > > > > > % felucia:jlh$ getfacl Mail/mbox1 > > > % # file: Mail/mbox1 > > > % # owner: jlh > > > % # group: jlh > > > % owner@:rw-p--aARWcCos:------:allow > > > % group@:------a-R-c--s:------:allow > > > % everyone@:------a-R-c--s:------:allow > > > )) > > > > > > > > > Does anyone have an idea about this error? Besides, if someone > > > knows > > > why those ACLs keep appearing, I would be glad to know it :). > > > > > AFAIK, NFSv4 style ACLs are always enabled for ZFS and cannot be > > turned > > off. > > Weirdly, some of my mailboxes don't have such ACLs, including some > I've > recently written into. How is it possible? > Sorry, I have no idea. Maybe one of the ZFS folks knows when ACLs are generated. (It might happen as a side effect of a "chmod". You could experiment with that?) rick > -- > Jeremie Le Hen > > Men are born free and equal. Later on, they're on their own. > Jean Yanne > _______________________________________________ > 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 21 01:49: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 53C07106564A for ; Tue, 21 Feb 2012 01:49:39 +0000 (UTC) (envelope-from pmurray@nevada.net.nz) Received: from bellagio.open2view.net (bellagio.open2view.net [210.48.79.75]) by mx1.freebsd.org (Postfix) with ESMTP id 1622F8FC12 for ; Tue, 21 Feb 2012 01:49:38 +0000 (UTC) Received: from bellagio.open2view.net (localhost [127.0.0.1]) by bellagio.open2view.net (Postfix) with ESMTP id 4873912AA4FA; Tue, 21 Feb 2012 14:24:41 +1300 (NZDT) X-Virus-Scanned: amavisd-new at open2view.com Received: from bellagio.open2view.net ([127.0.0.1]) by bellagio.open2view.net (bellagio.open2view.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v9fhxGlQ9dtg; Tue, 21 Feb 2012 14:24:40 +1300 (NZDT) Received: from mayfair.hlz-office.open2view.net (ip-58-28-153-152.static-xdsl.xnet.co.nz [58.28.153.152]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: pmurray@nevada.net.nz) by bellagio.open2view.net (Postfix) with ESMTPSA id 0B29712AA4C4; Tue, 21 Feb 2012 14:24:40 +1300 (NZDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Phil Murray In-Reply-To: <20120219213607.GO31770@felucia.tataz.chchile.org> Date: Tue, 21 Feb 2012 14:24:39 +1300 Content-Transfer-Encoding: quoted-printable Message-Id: <98300781-0B38-45FA-9BA7-737619BA07F5@nevada.net.nz> References: <20120219213607.GO31770@felucia.tataz.chchile.org> To: freebsd-stable@freebsd.org X-Mailer: Apple Mail (2.1257) Cc: Jeremie Le Hen Subject: Re: "File too large" error when appending to a file of 130 MB X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 21 Feb 2012 01:49:39 -0000 On 20/02/2012, at 10:36 AM, Jeremie Le Hen wrote: > Hi list, >=20 > Can you please Cc: me when replying as I'm not subscribed, thanks. >=20 > I have a problem with procmail which gets a "File too large" error = when > it tries to write at the end of some mailbox file. >=20 >=20 Is procmail running from Postfix (or some other MTA)? I've hit this = problem where Postfix has set a filesize ulimit, which all the scripts = spawned from Postfix will inherit.=20 In my case, I had a script that was hitting the filesize limit trying to = log it's results to a logfile that doesn't get rotated. I imagine the = same thing could happen with procmail, if postfix was calling it. Cheers Phil From owner-freebsd-stable@FreeBSD.ORG Tue Feb 21 09:05: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 6DCF2106564A; Tue, 21 Feb 2012 09:05:24 +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 1EAE08FC18; Tue, 21 Feb 2012 09:05:23 +0000 (UTC) Date: Tue, 21 Feb 2012 10:05:22 +0100 From: vermaden To: freebsd-hackers@freebsd.org X-Mailer: interia.pl/pf09 In-Reply-To: References: <4F3EE186.4020801@gmail.com> <201202181409.08859.hselasky@c2i.net> X-Originating-IP: 194.0.181.128 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=1329815122; bh=kmwOHtHR5bhiMVZuwRExLZKoT5Rqmfon/cKRsOSPsWE=; 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=VfYJxUC0c4Xej3WV0V/5cC2PPcfl5l3sVhKdiCbEDAnn5d+PYBpOJyzuy96JJhyLl 5YuNBKP36PErjTHdF96Rni2GLjMV07wNIIx87fksMhbqQbCPtXwF3U3CnjZ3RHb8ud qQu5hc2vvrmKLZPILuKcI/ZqiQXLP30Kjl/Tg+so= Cc: 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: Tue, 21 Feb 2012 09:05:24 -0000 Hi,=20 I have created a PORT at last, its in the 'port' directory in the usual pla= ce: https://github.com/vermaden/automount/ Its my first PORT so feel free to bash me about my mistakes ;) After latest 'commits' I think that its ready for day-to-day use. To make 'full advantage' of *automount* install these ports: sysutils/ntfsprogs sysutils/fusefs-ntfs sysutils/fusefs-ext4fuse sysutils/fusefs-exfat I will try to add these ports as OPTIONS in the Makefile later. I will have to think about creating a man page through ... Feel free to submit Your propositions about next changes/development, because I think that I already created everything 'I' needed.=20 Regards, vermaden --- =20 From owner-freebsd-stable@FreeBSD.ORG Tue Feb 21 09:49: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 CAD071065672 for ; Tue, 21 Feb 2012 09:49:20 +0000 (UTC) (envelope-from jeremie@le-hen.org) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [IPv6:2a01:e0c:1:1599::14]) by mx1.freebsd.org (Postfix) with ESMTP id 254098FC18 for ; Tue, 21 Feb 2012 09:49:18 +0000 (UTC) Received: from endor.tataz.chchile.org (unknown [82.233.239.98]) by smtp5-g21.free.fr (Postfix) with ESMTP id B4605D480C9; Tue, 21 Feb 2012 10:49:12 +0100 (CET) Received: from felucia.tataz.chchile.org (felucia.tataz.chchile.org [192.168.1.9]) by endor.tataz.chchile.org (Postfix) with ESMTP id 7D5CC23D6; Tue, 21 Feb 2012 09:49:11 +0000 (UTC) Received: by felucia.tataz.chchile.org (Postfix, from userid 1000) id 641D23671; Tue, 21 Feb 2012 09:49:11 +0000 (UTC) Date: Tue, 21 Feb 2012 10:49:11 +0100 From: Jeremie Le Hen To: Phil Murray Message-ID: <20120221094911.GD37684@felucia.tataz.chchile.org> References: <20120219213607.GO31770@felucia.tataz.chchile.org> <98300781-0B38-45FA-9BA7-737619BA07F5@nevada.net.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <98300781-0B38-45FA-9BA7-737619BA07F5@nevada.net.nz> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Jeremie Le Hen , freebsd-stable@freebsd.org Subject: Re: "File too large" error when appending to a file of 130 MB X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 21 Feb 2012 09:49:20 -0000 Hi Phil, On Tue, Feb 21, 2012 at 02:24:39PM +1300, Phil Murray wrote: > > On 20/02/2012, at 10:36 AM, Jeremie Le Hen wrote: > > > > I have a problem with procmail which gets a "File too large" error when > > it tries to write at the end of some mailbox file. > > Is procmail running from Postfix (or some other MTA)? I've hit this > problem where Postfix has set a filesize ulimit, which all the scripts > spawned from Postfix will inherit. > > In my case, I had a script that was hitting the filesize limit trying > to log it's results to a logfile that doesn't get rotated. I imagine > the same thing could happen with procmail, if postfix was calling it. Yes that was the problem indeed. Someone already contacted me (privately, but I didn't notice at that time) pointing out the problem. I've disabled the mailbox_size_limit in Postfix and the problem vanished. Thanks for your help. Regards, -- Jeremie Le Hen Men are born free and equal. Later on, they're on their own. Jean Yanne From owner-freebsd-stable@FreeBSD.ORG Tue Feb 21 13:35: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 B7C27106566B; Tue, 21 Feb 2012 13:35:58 +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 2133C8FC17; Tue, 21 Feb 2012 13:35:57 +0000 (UTC) Received: from outgoing.leidinger.net (p5796D1ED.dip.t-dialin.net [87.150.209.237]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id 6478A844855; Tue, 21 Feb 2012 14:35: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 B138356E1; Tue, 21 Feb 2012 14:35:39 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=leidinger.net; s=outgoing-alex; t=1329831339; bh=x6C84oYcO7m3aPqiTBVOm87R1xY0F417ZK4lFUDia5M=; h=Date:Message-ID:From:To:Subject:Content-Type:MIME-Version; b=KtgkASP2nKijB1mJe9mo7vasp9S+aDheCKtwh0om6xtnKCcS+OgFrcbUoU8kxi5rW on0/MJJqS1IDAH9d6S5My/VypBarveV+Rzu8Eb+Rzco0eubfvO4WxfPfz2hKXEJ6EE 6t4dUvTriLWOlCiiNuHsGNfcPKVnB3a1owxZLh5FsT/72Nu0sGBOIST0oA24RzdF8I WorX03N1tKG2LE4WiQ+kq/BjTyLv8GAhMSRfg8UbrNZ/7ted7IOBHMBjM5pTuCkJUY sf7o+IEUJL0XNs1gEUjDKWTdUM4TjOWB6bSR6Xy9gBzX9Jo8TWMnr4b+u4Gb2NIpLO gaCbX1Wd1Pz9g== Received: (from www@localhost) by webmail.leidinger.net (8.14.5/8.14.4/Submit) id q1LDZdep039948; Tue, 21 Feb 2012 14:35: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.20 ([85.94.224.20]) by webmail.leidinger.net (Horde Framework) with HTTP; Tue, 21 Feb 2012 14:35:39 +0100 Date: Tue, 21 Feb 2012 14:35:37 +0100 Message-ID: <20120221143537.Horde.deyFDZjmRSRPQ52pxBIpnLA@webmail.leidinger.net> From: Alexander Leidinger To: current@FreeBSD.org, stable@FreeBSD.org 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: 6478A844855.A06DB X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=0.259, required 6, autolearn=disabled, AWL -1.40, 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_EQ 0.08, TW_QC 0.08, T_RP_MATCHES_RCVD -0.01) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1330436143.85177@uWDe72kcRGSnHkdXY4ghNA X-EBL-Spam-Status: No Cc: Subject: [CFT] modular kernel config X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 21 Feb 2012 13:35:58 -0000 Hi, I created a kernel config for i386/amd64 (should work on -current and 9.x) and a suitable loader.conf which: - tries to provide as much features as GENERIC (I lost one or two disk controllers, they are not available as a module... or I didn't find them) - incorporates some more features based upon a poll on stable@ (see below) - loads as much as possible as a module I've compile-tested them on i386 and amd64, but I didn't had time yet to give it a try on a spare machine. I may get some time next week to test (i386 only). It would be nice if someone could help testing: - compile the kernel - make _sure_ you have a way to recover the system in case the new kernel+loader.conf fails - verify that the example loader.conf contains all devices which are important for you - copy the example loader.conf to /boot/loader.conf - give it a try You can download from http://www.Leidinger.net/FreeBSD/current-patches/ The files are - i386_SMALL - i386_SMALL_loader.conf - amd64_SMALL - amd64_SMALL_loader.conf I didn't provide direct links for eqch one on purpose. If you do not know how to recover a system with an unsuitable loader.conf, don't give this a try (you could check a diff between GENERIC and SMALL, and make sure all removed devices which are imporant for you are in the loader.conf). They should work on -current and on 9.x, for 8.x I'm not sure if it woll work without removing some stuff (GENERIC on 8.x comes without some more debugging options, make sure you don't get surprised by them, but those may not be the only differences). I didn't use the name MODULAR on purpose, I've chosen a name where the first letter does not yet exist in the kernel config directory, to make tab-completion more easy. If you are not happy with the name, keep your opinion for yourself please, until after you tested this on a (maybe virtual) system. The loader.conf was generated with a script from a diff between GENERIC and SMALL, if there's a name mismatch between the config-name and the module-name, the script may have missed the module (I added some missing sound modules, but I may have overlooked something). You better double-check before giving it a try. The loader.conf is also supposed to disable some features (at the end of the file) which are new compared to what is in GENERIC, if the particular feature could cause a change in behavior. The new stuff in the kernel config compared to GENERIC is (in order of number of requests from users): - IPSEC (+ device enc + IPSEC_NAT_T) - ALTQ - SW_WATCHDOG - QUOTA - IPSTEALTH (disabled in loader.conf) - IPFIREWALL_FORWARD (touches every packet, power users which need a bigger PPS but not this feature can recompile the kernel, discussed with julian@) - FLOWTABLE (disabled in loader.conf) - BPF_JITTER In the poll there where some more options requested, but most of them can be handled via the loader or sysctl (e.g. the firewalls can be loaded as modules). For some of them I added some comments at the end of the SMALL config to make it more easy to find the correct way of configuring them. Doc-committers may want to have a look, maybe there's an opportunity to improve existing documentation. I'm interested in success reports, failure reports, and reports about missing stuff in loader.conf (mainly compared to the devices available in GENERIC, but missing stuff which could help getting a system installed and booted is welcome even if what you propose is not in GENERIC). 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 Tue Feb 21 16:58: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 435E0106566B for ; Tue, 21 Feb 2012 16:58:54 +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 E94458FC15 for ; Tue, 21 Feb 2012 16:58:53 +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 q1LGwM1Q011369; Tue, 21 Feb 2012 11:58:22 -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 TYK21733; Tue, 21 Feb 2012 11:58:22 -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 q1LGwMQe023316 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 21 Feb 2012 11:58:22 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Paul Mather In-Reply-To: <20120218012746.GA3283@deviant.kiev.zoral.com.ua> Date: Tue, 21 Feb 2012 11:58:21 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <94989401-FC07-4155-AC02-9628F0019D26@gromit.dlib.vt.edu> References: <20120215004753.GQ3283@deviant.kiev.zoral.com.ua> <8F48D496-59BD-431D-B7F1-962A79C7ACC5@gromit.dlib.vt.edu> <20120216154932.GM3283@deviant.kiev.zoral.com.ua> <20120218012746.GA3283@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.0A02020A.4F43CD2E.0064,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: Tue, 21 Feb 2012 16:58:54 -0000 On Feb 17, 2012, at 8:27 PM, Konstantin Belousov wrote: > 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 = 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". >>=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 = 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 >=20 > This is indeed strange. It can only occur if td pointer is damaged. >=20 > Please, try to get a core and at least print the content of *td in = this case. Alas, I was unable to obtain a crash dump (or even a panic) last night, = but I have learned more about the circumstances that lead to this panic. In attempting to find a workaround for this panic (because having = nightly backups instead of panics is a good thing:) I discovered two = successful approaches. In the original situation that causes a reliable = panic I have a daemonised Tivoli "dsmc schedule" job running. This = communicates with the Tivoli TSM server to determine when it should run = its scheduled backup. When the backup is run, there is defined in a = Tivoli client config file (in = /compat/linux/opt/tivoli/tsm/client/ba/bin/dsm.sys) a preschedulecmd and = a postschedulecmd, which are /usr/local/bin/make_zfs_backup_snapshot and = /usr/local/bin/remove_zfs_backup_snapshot respectively. The = preschedulecmd script (run prior to the actual backup) basically makes = ZFS snapshots of all filesets and nullfs-mounts them under /backup. It = then creates /compat/linux/etc/mtab to list these nullfs filesystems as = ext2 file systems, so that the Tivoli backup client can know about them = to back them up. The postschedulecmd (run after the actual backup) = unmounts all the nullfs-mounted filesystems corresponding to the ZFS = backup snapshots and then destroys all the backup snapshots. The first workaround that doesn't lead to a panic is this: Do not run = "dsmc schedule". Instead, via cron, run this simple script: #!/bin/sh /usr/local/bin/make_zfs_backup_snapshot /compat/linux/opt/tivoli/tsm/client/ba/bin/dsmc incremental /usr/local/bin/remove_zfs_backup_snapshot (Note: the pre- and post- scripts are being run outside of dsmc.) The = script is run at 2 am nightly (around the time that "dsmc schedule" = usually ends up performing the scheduled backup) and completes before = the regular 3 am "periodic daily" job that normally leads to a panic. = This workaround avoids a panic. The second workaround that doesn't lead to a panic is this: In the = /usr/local/bin/make_zfs_backup_snapshot and = /usr/local/bin/remove_zfs_backup_snapshot scripts, replace "#!/bin/sh" = with "#!/rescue/sh" to force the scripts to run the FreeBSD-branded sh = rather than the Linux-branded /compat/linux/bin/sh: gromit# brandelf /rescue/sh File '/rescue/sh' is of brand 'FreeBSD' (9). gromit# brandelf /compat/linux/bin/sh File '/compat/linux/bin/sh' is of brand 'Linux' (3). (Because the script is run by the Linux "dsmc" binary I am presuming it = will run /compat/linux/bin/sh when it reads "#!/bin/sh" at the start of = the pre/postschedulecmd scripts, because the "/bin/sh" that is installed = as part of linux_base-f10-10_4 shadows the FreeBSD /bin/sh.) So, it seems that the circumstances that lead to a reliable panic are = running the daemonised Linux "dsmc schedule" that invokes scripts that = run under the Linux "/bin/sh" (/compat/linux/bin/sh). I'll revert the pre/postschedulecmd script "#!" paths back to /bin/sh to = try and obtain a crash dump, but hopefully the above workarounds I found = and described above might offer some insight as to where the cause of = this panic lies. Cheers, Paul. From owner-freebsd-stable@FreeBSD.ORG Wed Feb 22 00:06: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 8CF87106564A for ; Wed, 22 Feb 2012 00:06:36 +0000 (UTC) (envelope-from janm@transactionware.com) Received: from midgard.transactionware.com (mail2.transactionware.com [203.14.245.36]) by mx1.freebsd.org (Postfix) with SMTP id 9E9A38FC1D for ; Wed, 22 Feb 2012 00:06:35 +0000 (UTC) Received: (qmail 10471 invoked by uid 907); 22 Feb 2012 00:06:32 -0000 Received: from jmmacpro.transactionware.com (HELO jmmacpro.transactionware.com) (192.168.1.33) by midgard.transactionware.com (qpsmtpd/0.82) with ESMTP; Wed, 22 Feb 2012 11:06:32 +1100 From: Jan Mikkelsen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 22 Feb 2012 11:06:32 +1100 Message-Id: To: FreeBSD Stable Mailing List Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) Subject: "who /var/log/utx.log" broken in 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: Wed, 22 Feb 2012 00:06:36 -0000 Hi, According to the who(1) manpage in 9.0-RELEASE, "who /var/log/utx.log" = should be roughly similar to "who /var/log/wtmp" in 8.whever (and = earlier). I'm getting this on multiple 9.0-RELEASE systems: janm@mlb-primary: log $ who /var/log/utx.log who: /var/log/utx.log: Inappropriate file type or format Is the manpage wrong? Thanks, Jan. From owner-freebsd-stable@FreeBSD.ORG Wed Feb 22 00:33: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 B83EB1065670 for ; Wed, 22 Feb 2012 00:33:23 +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 63B078FC0C for ; Wed, 22 Feb 2012 00:33:23 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.5/8.14.5) with ESMTP id q1M0GEU1069323 for ; Tue, 21 Feb 2012 17:16:14 -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 q1M0GExD069320 for ; Tue, 21 Feb 2012 17:16:14 -0700 (MST) (envelope-from wblock@wonkity.com) Date: Tue, 21 Feb 2012 17:16:14 -0700 (MST) From: Warren Block To: 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 IP whitelisted, not delayed by milter-greylist-4.2.7 (wonkity.com [127.0.0.1]); Tue, 21 Feb 2012 17:16:14 -0700 (MST) Cc: Subject: ssh-add echos passphrase X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Feb 2012 00:33:23 -0000 Is anyone else seeing ssh-add echo the passphrase on a recent 8-stable? FreeBSD lightning 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Tue Feb 21 15:37:08 MST 2012 root@lightning:/usr/obj/usr/src/sys/LIGHTNING i386 From owner-freebsd-stable@FreeBSD.ORG Wed Feb 22 00:36:54 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id E5BFC1065672 for ; Wed, 22 Feb 2012 00:36:54 +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 ABE2A14D8D5; Wed, 22 Feb 2012 00:36:54 +0000 (UTC) Message-ID: <4F4438A6.9010808@FreeBSD.org> Date: Tue, 21 Feb 2012 16:36:54 -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: Warren Block References: In-Reply-To: X-Enigmail-Version: 1.3.5 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org Subject: Re: ssh-add echos passphrase X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Feb 2012 00:36:55 -0000 On 02/21/2012 16:16, Warren Block wrote: > Is anyone else seeing ssh-add echo the passphrase on a recent 8-stable? No. Are you sure that you're running the agent before you ssh-add? 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 Wed Feb 22 01:01:09 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 4C8631065679 for ; Wed, 22 Feb 2012 01:01:09 +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 0AF4A8FC14 for ; Wed, 22 Feb 2012 01:01:08 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.5/8.14.5) with ESMTP id q1M118Ii069626; Tue, 21 Feb 2012 18:01:08 -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 q1M118W8069623; Tue, 21 Feb 2012 18:01:08 -0700 (MST) (envelope-from wblock@wonkity.com) Date: Tue, 21 Feb 2012 18:01:08 -0700 (MST) From: Warren Block To: Doug Barton In-Reply-To: <4F4438A6.9010808@FreeBSD.org> Message-ID: References: <4F4438A6.9010808@FreeBSD.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (wonkity.com [127.0.0.1]); Tue, 21 Feb 2012 18:01:08 -0700 (MST) Cc: stable@FreeBSD.org Subject: Re: ssh-add echos passphrase X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Feb 2012 01:01:09 -0000 On Tue, 21 Feb 2012, Doug Barton wrote: > On 02/21/2012 16:16, Warren Block wrote: >> Is anyone else seeing ssh-add echo the passphrase on a recent 8-stable? > > No. Are you sure that you're running the agent before you ssh-add? 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Tue Feb 21 # pkill ssh-agent % ssh-add ~/keyfile Could not open a connection to your authentication agent. % eval `ssh-agent -c` Agent pid 2658 % ssh-add ~/keyfile Enter passphrase for /home/wblock/keyfile: abc123 Another system has -stable from January 13 and works as expected (no passphrase echo). From owner-freebsd-stable@FreeBSD.ORG Wed Feb 22 04:21: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 E29B0106567B for ; Wed, 22 Feb 2012 04:21:58 +0000 (UTC) (envelope-from timp87@gmail.com) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) by mx1.freebsd.org (Postfix) with ESMTP id BB3618FC13 for ; Wed, 22 Feb 2012 04:21:58 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1S03T6-00050m-12 for freebsd-stable@freebsd.org; Tue, 21 Feb 2012 20:06:16 -0800 Date: Tue, 21 Feb 2012 20:06:16 -0800 (PST) From: timp To: freebsd-stable@freebsd.org Message-ID: <1329883576025-5504065.post@n5.nabble.com> In-Reply-To: <20120210145604.Horde.ewjpSpjmRSRPNSH0YRHxgAk@webmail.leidinger.net> References: <20120210145604.Horde.ewjpSpjmRSRPNSH0YRHxgAk@webmail.leidinger.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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, 22 Feb 2012 04:21:59 -0000 Hi! Finally someone thought about this! My 5 cents: IPFIREWALL_FORWARD <- no comment)) options VIMAGE <- not yet production ready, but keep in mind it Forgot this two very usefull options: options RACCT <- resource limits for jail and etc. options RCTL <- resource limits for jail and etc. -- View this message in context: http://freebsd.1045724.n5.nabble.com/Reducing-the-need-to-compile-a-custom-kernel-tp5472542p5504065.html Sent from the freebsd-stable mailing list archive at Nabble.com. From owner-freebsd-stable@FreeBSD.ORG Wed Feb 22 05:56: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 149DD1065670 for ; Wed, 22 Feb 2012 05:56:05 +0000 (UTC) (envelope-from timp87@gmail.com) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) by mx1.freebsd.org (Postfix) with ESMTP id E193A8FC13 for ; Wed, 22 Feb 2012 05:56:04 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1S05BM-0007vz-65 for freebsd-stable@freebsd.org; Tue, 21 Feb 2012 21:56:04 -0800 Date: Tue, 21 Feb 2012 21:56:04 -0800 (PST) From: timp To: freebsd-stable@freebsd.org Message-ID: <1329890164178-5504219.post@n5.nabble.com> In-Reply-To: <20120221143537.Horde.deyFDZjmRSRPQ52pxBIpnLA@webmail.leidinger.net> References: <20120221143537.Horde.deyFDZjmRSRPQ52pxBIpnLA@webmail.leidinger.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [CFT] modular kernel config X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Feb 2012 05:56:05 -0000 Sorry, but for loader.conf you need use 'load' instead of 'enable' sed -e "s/enable/load/" loader.conf -- View this message in context: http://freebsd.1045724.n5.nabble.com/CFT-modular-kernel-config-tp5502195p5504219.html Sent from the freebsd-stable mailing list archive at Nabble.com. From owner-freebsd-stable@FreeBSD.ORG Wed Feb 22 06:41: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 0D206106566B for ; Wed, 22 Feb 2012 06:41:06 +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 A592D8FC0C for ; Wed, 22 Feb 2012 06:41:05 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.5/8.14.5) with ESMTP id q1M6f48W074960 for ; Tue, 21 Feb 2012 23:41:04 -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 q1M6f4E5074957 for ; Tue, 21 Feb 2012 23:41:04 -0700 (MST) (envelope-from wblock@wonkity.com) Date: Tue, 21 Feb 2012 23:41:04 -0700 (MST) From: Warren Block To: stable@freebsd.org In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (wonkity.com [127.0.0.1]); Tue, 21 Feb 2012 23:41:04 -0700 (MST) Cc: Subject: Re: ssh-add echos passphrase X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Feb 2012 06:41:06 -0000 On Tue, 21 Feb 2012, Warren Block wrote: > Is anyone else seeing ssh-add echo the passphrase on a recent 8-stable? > > FreeBSD lightning 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Tue Feb 21 > 15:37:08 MST 2012 root@lightning:/usr/obj/usr/src/sys/LIGHTNING i386 After backdating a few days with no change, then csupping back to RELENG-8, ssh-add is back to normal. Wish I had an idea why. From owner-freebsd-stable@FreeBSD.ORG Wed Feb 22 08:07:24 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 BE2371065675 for ; Wed, 22 Feb 2012 08:07:24 +0000 (UTC) (envelope-from bra@fsn.hu) Received: from people.fsn.hu (people.fsn.hu [195.228.252.137]) by mx1.freebsd.org (Postfix) with ESMTP id B903E8FC08 for ; Wed, 22 Feb 2012 08:07:23 +0000 (UTC) Received: by people.fsn.hu (Postfix, from userid 1001) id 63AB3C218DB; Wed, 22 Feb 2012 08:49:32 +0100 (CET) X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.2 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MF-ACE0E1EA [pR: 13.0387] X-CRM114-CacheID: sfid-20120222_08493_38C9C13D X-CRM114-Status: Good ( pR: 13.0387 ) X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Wed Feb 22 08:49:32 2012 X-DSPAM-Confidence: 0.9960 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 4f449e0c471075234915224 X-DSPAM-Factors: 27, From*Attila Nagy , 0.00010, FreeBSD, 0.00053, FreeBSD, 0.00053, ports, 0.00069, ports, 0.00069, kernel, 0.00142, kernel, 0.00142, flags, 0.00381, flags, 0.00381, =+0, 0.00406, =+0, 0.00406, 0), 0.00425, 0), 0.00425, root, 0.00451, root, 0.00451, timeout, 0.00468, To*stable+freebsd.org, 0.00487, STABLE, 0.00553, boot, 0.00579, boot, 0.00579, To*stable, 0.00585, I+get, 0.00588, I+get, 0.00588, console, 0.00608, the+kernel, 0.00608, 3+3, 0.00657, X-Spambayes-Classification: ham; 0.00 Received: from japan.t-online.private (japan.t-online.co.hu [195.228.243.99]) by people.fsn.hu (Postfix) with ESMTPSA id 4DB01C218CF for ; Wed, 22 Feb 2012 08:49:31 +0100 (CET) Message-ID: <4F449E0B.2040909@fsn.hu> Date: Wed, 22 Feb 2012 08:49:31 +0100 From: Attila Nagy User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.23) Gecko/20090817 Thunderbird/2.0.0.23 Mnenhy/0.7.6.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: Fatal trap 19, Stopped at bge_init_locked+ and bge booting problems X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Feb 2012 08:07:24 -0000 Hi, I get this on a recent stable/9 system with uhci support removed from the kernel config: da0 at ciss0 bus 0 scbus0 target 0 lun 0 da0: Fixed Direct Access SCSI-5 device da0: 135.168MB/s transfers da0: Command Queueing enabled da0: 286070MB (585871964 512 byte sectors: 255H 32S/T 65535C) cd0 at ata3 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 NMI ISA 70, EISA ff I/O channel check, likely hardware failure. Fatal trap 19: non-maskable interrupt trap while in kernel mode cpuid = 0; apic id = 00 instruction pointer = 0x20:0xffffffff804543fb stack pointer = 0x28:0xffffffff81251e40 frame pointer = 0x28:0xffffffff814cf660 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, IOPL = 0 current process = 0 (swapper) [ thread pid 0 tid 100000 ] Stopped at bge_init_locked+0x233b: movl 0x81c(%rsi),%eax db> and this with a plain GENERIC kernel: da0 at ciss0 bus 0 scbus0 target 0 lun 0 da0: Fixed Direct Access SCSI-5 device da0: 135.168MB/s transfers da0: Command Queueing enabled da0: 286070MB (585871964 512 byte sectors: 255H 32S/T 65535C) cd0 at ata3 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 NMI ISA 70, EISA ff I/O channel check, likely hardware failure. Fatal trap 19: non-maskable interrupt trap while in kernel mode cpuid = 0; apic id = 00 instruction pointer = 0x20:0xffffffff80711dc5 stack pointer = 0x28:0xffffffff81272040 frame pointer = 0x28:0xffffff907cf44b40 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, IOPL = 0 current process = 12 (irq16: uhci0) [ thread pid 12 tid 100098 ] Stopped at uhci_interrupt+0x65: movzwl %ax,%eax db> KDB: stack backtrace: KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a kdb_backtrace() at kdb_backtrace+0x37 mi_switch() at mi_switch+0x27a turnstile_wait() at turnstile_wait+0x1cb _mtx_lock_sleep() at _mtx_lock_sleep+0xb0 ukbd_poll() at ukbd_poll+0xbe kbdmux_poll() at kbdmux_poll+0x3f sc_cngetc() at sc_cngetc+0xec cncheckc() at cncheckc+0x4a cngetc() at cngetc+0x1c db_readline() at db_readline+0x77 db_read_line() at db_read_line+0x15 db_command_loop() at db_command_loop+0x38 db_trap() at db_trap+0x89 kdb_trap() at kdb_trap+0x101 trap_fatal() at trap_fatal+0x29d trap() at trap+0x10a nmi_calltrap() at nmi_calltrap+0x8 --- trap 0x13, rip = 0xffffffff80711dc5, rsp = 0xffffffff81272040, rbp = 0xffffff907cf44b40 --- uhci_interrupt() at uhci_interrupt+0x65 intr_event_execute_handlers() at intr_event_execute_handlers+0x104 ithread_loop() at ithread_loop+0xa4 fork_exit() at fork_exit+0x11f fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff907cf44d00, rbp = 0 --- db> After disabling stopping on NMI (kdb_on_nmi), I still can't boot from bge (this is a PXE booted machine), I get this in an infinite loop: bge1: link state changed to DOWN DHCP/BOOTP timeout for server 255.255.255.255 bge1: 3 link states coalesced bge1: link state changed to UP bge0: 2 link states coalesced bge0: link state changed to DOWN bge0: link state changed to UP bge1: link state changed to DOWN bge0: link state changed to DOWN bge0: link state changed to UP bge0: link state changed to DOWN bge1: 2 link states coalesced bge1: link state changed to DOWN bge0: link state changed to UP bge0: link state changed to DOWN bge0: 2 link states coalesced bge0: link state changed to DOWN bge1: 2 link states coalesced bge1: link state changed to DOWN bge0: link state changed to UP bge0: link state changed to DOWN bge0: link state changed to UP bge0: link state changed to DOWN Linux and Windows boot fine on the machine. dmesg up to the point where it crashes: 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 #3: Tue Feb 21 11:57:33 CET 2012 root@boot.lab:/usr/obj/usr/src/sys/BOOTCLNT amd64 CPU: Intel(R) Xeon(R) CPU E5-2680 0 @ 2.70GHz (2693.57-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x206d6 Family = 6 Model = 2d Stepping = 6 Features=0xbfebfbff Features2=0x15bee3ff AMD Features=0x2c100800 AMD Features2=0x1 TSC: P-state invariant, performance statistics real memory = 34359738368 (32768 MB) avail memory = 32991268864 (31462 MB) Event timer "LAPIC" quality 600 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 32 CPUs FreeBSD/SMP: 2 package(s) x 8 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 cpu8 (AP): APIC ID: 8 cpu9 (AP): APIC ID: 9 cpu10 (AP): APIC ID: 10 cpu11 (AP): APIC ID: 11 cpu12 (AP): APIC ID: 12 cpu13 (AP): APIC ID: 13 cpu14 (AP): APIC ID: 14 cpu15 (AP): APIC ID: 15 cpu16 (AP): APIC ID: 32 cpu17 (AP): APIC ID: 33 cpu18 (AP): APIC ID: 34 cpu19 (AP): APIC ID: 35 cpu20 (AP): APIC ID: 36 cpu21 (AP): APIC ID: 37 cpu22 (AP): APIC ID: 38 cpu23 (AP): APIC ID: 39 cpu24 (AP): APIC ID: 40 cpu25 (AP): APIC ID: 41 cpu26 (AP): APIC ID: 42 cpu27 (AP): APIC ID: 43 cpu28 (AP): APIC ID: 44 cpu29 (AP): APIC ID: 45 cpu30 (AP): APIC ID: 46 cpu31 (AP): APIC ID: 47 ACPI Warning: Invalid length for Pm1aControlBlock: 32, using default 16 (20110527/tbfadt-638) ACPI Warning: Invalid length for Pm2ControlBlock: 32, using default 8 (20110527/tbfadt-638) ioapic1 irqs 24-47 on motherboard ioapic0 irqs 0-23 on motherboard ioapic2 irqs 48-71 on motherboard kbd1 at kbdmux0 ctl: CAM Target Layer loaded 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 0x908-0x90b on acpi0 cpu0: on acpi0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 cpu4: on acpi0 cpu5: on acpi0 cpu6: on acpi0 cpu7: on acpi0 cpu8: on acpi0 cpu9: on acpi0 cpu10: on acpi0 cpu11: on acpi0 cpu12: on acpi0 cpu13: on acpi0 cpu14: on acpi0 cpu15: on acpi0 cpu16: on acpi0 cpu17: on acpi0 cpu18: on acpi0 cpu19: on acpi0 cpu20: on acpi0 cpu21: on acpi0 cpu22: on acpi0 cpu23: on acpi0 cpu24: on acpi0 cpu25: on acpi0 cpu26: on acpi0 cpu27: on acpi0 cpu28: on acpi0 cpu29: on acpi0 cpu30: on acpi0 cpu31: on acpi0 pcib0: on acpi0 pci0: on pcib0 pcib1: at device 1.0 on pci0 pci7: on pcib1 pcib2: at device 1.1 on pci0 pci19: on pcib2 pcib3: at device 2.0 on pci0 pci3: on pcib3 pci0:3:0:0: failed to read VPD data. bge0: mem 0xf6bf0000-0xf6bfffff,0xf6be0000-0xf6beffff,0xf6bd0000-0xf6bdffff irq 32 at device 0.0 on pci3 bge0: CHIP ID 0x05719001; ASIC REV 0x5719; CHIP REV 0x57190; PCI-E bge0: Try again miibus0: on bge0 ukphy0: PHY 1 on miibus0 ukphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow bge0: Ethernet address: 3c:4a:92:b2:3c:08 pci0:3:0:1: failed to read VPD data. bge1: mem 0xf6bc0000-0xf6bcffff,0xf6bb0000-0xf6bbffff,0xf6ba0000-0xf6baffff irq 36 at device 0.1 on pci3 bge1: CHIP ID 0x05719001; ASIC REV 0x5719; CHIP REV 0x57190; PCI-E miibus1: on bge1 brgphy0: PHY 2 on miibus1 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow bge1: Ethernet address: 3c:4a:92:b2:3c:09 pci0:3:0:2: failed to read VPD data. bge2: mem 0xf6b90000-0xf6b9ffff,0xf6b80000-0xf6b8ffff,0xf6b70000-0xf6b7ffff irq 32 at device 0.2 on pci3 bge2: CHIP ID 0x05719001; ASIC REV 0x5719; CHIP REV 0x57190; PCI-E miibus2: on bge2 brgphy1: PHY 3 on miibus2 brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow bge2: Ethernet address: 3c:4a:92:b2:3c:0a pci0:3:0:3: failed to read VPD data. bge3: mem 0xf6b60000-0xf6b6ffff,0xf6b50000-0xf6b5ffff,0xf6b40000-0xf6b4ffff irq 36 at device 0.3 on pci3 bge3: CHIP ID 0x05719001; ASIC REV 0x5719; CHIP REV 0x57190; PCI-E miibus3: on bge3 brgphy2: PHY 4 on miibus3 brgphy2: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow bge3: Ethernet address: 3c:4a:92:b2:3c:0b pcib4: at device 2.1 on pci0 pci20: on pcib4 pcib5: at device 2.2 on pci0 pci2: on pcib5 ciss0: port 0x5000-0x50ff mem 0xf7f00000-0xf7ffffff,0xf7ef0000-0xf7ef03ff irq 34 at device 0.0 on pci2 ciss0: PERFORMANT Transport pcib6: at device 2.3 on pci0 pci21: on pcib6 pcib7: at device 3.0 on pci0 pci4: on pcib7 pcib8: at device 3.1 on pci0 pci22: on pcib8 pcib9: at device 3.2 on pci0 pci23: on pcib9 pcib10: at device 3.3 on pci0 pci24: on pcib10 pci0: at device 4.0 (no driver attached) pci0: at device 4.1 (no driver attached) pci0: at device 4.2 (no driver attached) pci0: at device 4.3 (no driver attached) pci0: at device 4.4 (no driver attached) pci0: at device 4.5 (no driver attached) pci0: at device 4.6 (no driver attached) pci0: at device 4.7 (no driver attached) pci0: at device 5.0 (no driver attached) pci0: at device 5.2 (no driver attached) pcib11: at device 17.0 on pci0 pci26: on pcib11 ehci0: mem 0xf6c60000-0xf6c603ff irq 21 at device 26.0 on pci0 usbus0: EHCI version 1.0 usbus0: on ehci0 pcib12: at device 28.0 on pci0 pci10: on pcib12 pcib13: at device 28.7 on pci0 pci1: on pcib13 pci1: at device 0.0 (no driver attached) vgapci0: mem 0xf5000000-0xf5ffffff,0xf7de0000-0xf7de3fff,0xf7000000-0xf77fffff irq 16 at device 0.1 on pci1 pci1: at device 0.2 (no driver attached) uhci0: port 0x3c00-0x3c1f irq 16 at device 0.4 on pci1 usbus1: on uhci0 ehci1: mem 0xf6c50000-0xf6c503ff irq 20 at device 29.0 on pci0 usbus2: EHCI version 1.0 usbus2: on ehci1 pcib14: at device 30.0 on pci0 pci25: on pcib14 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x4000-0x4007,0x4008-0x400b,0x4010-0x4017,0x4018-0x401b,0x4020-0x402f,0x4030-0x403f irq 17 at device 31.2 on pci0 ata2: at channel 0 on atapci0 ata3: at channel 1 on atapci0 pcib15: on acpi0 pci32: on pcib15 pcib16: at device 0.0 on pci32 pci43: on pcib16 pcib17: at device 1.0 on pci32 pci36: on pcib17 pcib18: at device 1.1 on pci32 pci37: on pcib18 pcib19: at device 2.0 on pci32 pci35: on pcib19 pcib20: at device 2.1 on pci32 pci38: on pcib20 pcib21: at device 2.2 on pci32 pci34: on pcib21 pcib22: at device 2.3 on pci32 pci39: on pcib22 pcib23: at device 3.0 on pci32 pci33: on pcib23 pcib24: at device 3.1 on pci32 pci40: on pcib24 pcib25: at device 3.2 on pci32 pci41: on pcib25 pcib26: at device 3.3 on pci32 pci42: on pcib26 pci32: at device 4.0 (no driver attached) pci32: at device 4.1 (no driver attached) pci32: at device 4.2 (no driver attached) pci32: at device 4.3 (no driver attached) pci32: at device 4.4 (no driver attached) pci32: at device 4.5 (no driver attached) pci32: at device 4.6 (no driver attached) pci32: at device 4.7 (no driver attached) pci32: at device 5.0 (no driver attached) pci32: at device 5.2 (no driver attached) acpi_tz0: 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 hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 950 Event timer "HPET" frequency 14318180 Hz quality 450 Event timer "HPET1" frequency 14318180 Hz quality 440 Event timer "HPET2" frequency 14318180 Hz quality 440 Event timer "HPET3" frequency 14318180 Hz quality 440 Event timer "HPET4" frequency 14318180 Hz quality 440 Event timer "HPET5" frequency 14318180 Hz quality 440 Event timer "HPET6" frequency 14318180 Hz quality 440 Event timer "HPET7" frequency 14318180 Hz quality 440 atrtc0: port 0x70-0x71 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] uart1: port 0x2f8-0x2ff irq 3 on acpi0 orm0: at iomem 0xc0000-0xc7fff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ppc0: cannot reserve I/O port range uart0: at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 uart0: console (9600,n,8,1) est0: on cpu0 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 24d400001f00 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 24d400001f00 device_attach: est1 attach returned 6 p4tcc1: on cpu1 est2: on cpu2 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 24d400001f00 device_attach: est2 attach returned 6 p4tcc2: on cpu2 est3: on cpu3 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 24d400001f00 device_attach: est3 attach returned 6 p4tcc3: on cpu3 est4: on cpu4 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 24d400001f00 device_attach: est4 attach returned 6 p4tcc4: on cpu4 est5: on cpu5 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 24d400001f00 device_attach: est5 attach returned 6 p4tcc5: on cpu5 est6: on cpu6 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 24d400001f00 device_attach: est6 attach returned 6 p4tcc6: on cpu6 est7: on cpu7 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 24d400001f00 device_attach: est7 attach returned 6 p4tcc7: on cpu7 est8: on cpu8 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 24d400001f00 device_attach: est8 attach returned 6 p4tcc8: on cpu8 est9: on cpu9 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 24d400001f00 device_attach: est9 attach returned 6 p4tcc9: on cpu9 est10: on cpu10 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 24d400001f00 device_attach: est10 attach returned 6 p4tcc10: on cpu10 est11: on cpu11 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 24d400001f00 device_attach: est11 attach returned 6 p4tcc11: on cpu11 est12: on cpu12 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 24d400001f00 device_attach: est12 attach returned 6 p4tcc12: on cpu12 est13: on cpu13 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 24d400001f00 device_attach: est13 attach returned 6 p4tcc13: on cpu13 est14: on cpu14 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 24d400001f00 device_attach: est14 attach returned 6 p4tcc14: on cpu14 est15: on cpu15 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 24d400001f00 device_attach: est15 attach returned 6 p4tcc15: on cpu15 est16: on cpu16 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 24d400001f00 device_attach: est16 attach returned 6 p4tcc16: on cpu16 est17: on cpu17 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 24d400001f00 device_attach: est17 attach returned 6 p4tcc17: on cpu17 est18: on cpu18 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 24d400001f00 device_attach: est18 attach returned 6 p4tcc18: on cpu18 est19: on cpu19 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 24d400001f00 device_attach: est19 attach returned 6 p4tcc19: on cpu19 est20: on cpu20 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 24d400001f00 device_attach: est20 attach returned 6 p4tcc20: on cpu20 est21: on cpu21 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 24d400001f00 device_attach: est21 attach returned 6 p4tcc21: on cpu21 est22: on cpu22 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 24d400001f00 device_attach: est22 attach returned 6 p4tcc22: on cpu22 est23: on cpu23 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 24d400001f00 device_attach: est23 attach returned 6 p4tcc23: on cpu23 est24: on cpu24 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 24d400001f00 device_attach: est24 attach returned 6 p4tcc24: on cpu24 est25: on cpu25 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 24d400001f00 device_attach: est25 attach returned 6 p4tcc25: on cpu25 est26: on cpu26 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 24d400001f00 device_attach: est26 attach returned 6 p4tcc26: on cpu26 est27: on cpu27 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 24d400001f00 device_attach: est27 attach returned 6 p4tcc27: on cpu27 est28: on cpu28 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 24d400001f00 device_attach: est28 attach returned 6 p4tcc28: on cpu28 est29: on cpu29 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 24d400001f00 device_attach: est29 attach returned 6 p4tcc29: on cpu29 est30: on cpu30 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 24d400001f00 device_attach: est30 attach returned 6 p4tcc30: on cpu30 est31: on cpu31 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 24d400001f00 device_attach: est31 attach returned 6 p4tcc31: on cpu31 Timecounters tick every 1.000 msec usbus0: 480Mbps High Speed USB v2.0 usbus1: 12Mbps Full Speed USB v1.0 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: <0x103c> at usbus1 uhub1: <0x103c UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus1 usbus2: 480Mbps High Speed USB v2.0 ugen2.1: at usbus2 uhub2: on usbus2 uhub1: 2 ports with 2 removable, self powered uhub0: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered ugen1.2: at usbus1 ukbd0: on usbus1 (probe0:ciss0:0:0:0): REPORT LUNS. CDB: a0 0 0 0 0 0 0 0 0 10 0 0 (probe0:ciss0:0:0:0): CAM status: SCSI Status Error (probe0:ciss0:0:0:0): SCSI status: Check Condition (probe0:ciss0:0:0:0): SCSI sense: ILLEGAL REQUEST asc:20,0 (Invalid command operation code) kbd2 at ukbd0 ums0: on usbus1 da0 at ciss0 bus 0 scbus0 target 0 lun 0 da0: Fixed Direct Access SCSI-5 device da0: 135.168MB/s transfers da0: Command Queueing enabled da0: 286070MB (585871964 512 byte sectors: 255H 32S/T 65535C) cd0 at ata3 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 From owner-freebsd-stable@FreeBSD.ORG Wed Feb 22 11:42: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 902481065673 for ; Wed, 22 Feb 2012 11:42:17 +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 5A5FB8FC12 for ; Wed, 22 Feb 2012 11:42:17 +0000 (UTC) Received: by pbcxa7 with SMTP id xa7so89137pbc.13 for ; Wed, 22 Feb 2012 03:42:16 -0800 (PST) Received-SPF: pass (google.com: domain of pyunyh@gmail.com designates 10.68.196.161 as permitted sender) client-ip=10.68.196.161; Authentication-Results: mr.google.com; spf=pass (google.com: domain of pyunyh@gmail.com designates 10.68.196.161 as permitted sender) smtp.mail=pyunyh@gmail.com; dkim=pass header.i=pyunyh@gmail.com Received: from mr.google.com ([10.68.196.161]) by 10.68.196.161 with SMTP id in1mr22589747pbc.96.1329910936939 (num_hops = 1); Wed, 22 Feb 2012 03:42:16 -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=dm3CZ/RJZ/9g/HxSFryHVRJngzXWza+F0E8AdGI6e5I=; b=iYW7cokDpm8f3/h+t5YnwhkyYBxyWBVYbg4QcsSZkF19mUYc9lMCDIUHzapkg1+Np/ Ug/LhAtK/h6uWMg7K07qLklJxoXb+/d0eDav7QutIpBxDalkKwH7agKeNkMudMAguZcA xKN0y5holCWsHttpC7SmDvm4CBrjNMF/VIYGI= Received: by 10.68.196.161 with SMTP id in1mr18206035pbc.96.1329909327273; Wed, 22 Feb 2012 03:15:27 -0800 (PST) Received: from pyunyh@gmail.com ([114.111.62.249]) by mx.google.com with ESMTPS id q8sm30321806pbi.1.2012.02.22.03.15.21 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 22 Feb 2012 03:15:26 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Wed, 22 Feb 2012 20:15:16 -0800 From: YongHyeon PYUN Date: Wed, 22 Feb 2012 20:15:16 -0800 To: Attila Nagy Message-ID: <20120223041516.GI6861@michelle.cdnetworks.com> References: <4F449E0B.2040909@fsn.hu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F449E0B.2040909@fsn.hu> User-Agent: Mutt/1.4.2.3i Cc: stable@freebsd.org Subject: Re: Fatal trap 19, Stopped at bge_init_locked+ and bge booting problems 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, 22 Feb 2012 11:42:17 -0000 On Wed, Feb 22, 2012 at 08:49:31AM +0100, Attila Nagy wrote: > Hi, > > I get this on a recent stable/9 system with uhci support removed from > the kernel config: > da0 at ciss0 bus 0 scbus0 target 0 lun 0 > da0: Fixed Direct Access SCSI-5 device > da0: 135.168MB/s transfers > da0: Command Queueing enabled > da0: 286070MB (585871964 512 byte sectors: 255H 32S/T 65535C) > cd0 at ata3 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 > NMI ISA 70, EISA ff > I/O channel check, likely hardware failure. > > Fatal trap 19: non-maskable interrupt trap while in kernel mode > cpuid = 0; apic id = 00 > instruction pointer = 0x20:0xffffffff804543fb > stack pointer = 0x28:0xffffffff81251e40 > frame pointer = 0x28:0xffffffff814cf660 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = interrupt enabled, IOPL = 0 > current process = 0 (swapper) > [ thread pid 0 tid 100000 ] > Stopped at bge_init_locked+0x233b: movl 0x81c(%rsi),%eax > db> > > and this with a plain GENERIC kernel: > da0 at ciss0 bus 0 scbus0 target 0 lun 0 > da0: Fixed Direct Access SCSI-5 device > da0: 135.168MB/s transfers > da0: Command Queueing enabled > da0: 286070MB (585871964 512 byte sectors: 255H 32S/T 65535C) > cd0 at ata3 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 > NMI ISA 70, EISA ff > I/O channel check, likely hardware failure. > > Fatal trap 19: non-maskable interrupt trap while in kernel mode > cpuid = 0; apic id = 00 > instruction pointer = 0x20:0xffffffff80711dc5 > stack pointer = 0x28:0xffffffff81272040 > frame pointer = 0x28:0xffffff907cf44b40 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = interrupt enabled, IOPL = 0 > current process = 12 (irq16: uhci0) > [ thread pid 12 tid 100098 ] > Stopped at uhci_interrupt+0x65: movzwl %ax,%eax > db> KDB: stack backtrace: > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > kdb_backtrace() at kdb_backtrace+0x37 > mi_switch() at mi_switch+0x27a > turnstile_wait() at turnstile_wait+0x1cb > _mtx_lock_sleep() at _mtx_lock_sleep+0xb0 > ukbd_poll() at ukbd_poll+0xbe > kbdmux_poll() at kbdmux_poll+0x3f > sc_cngetc() at sc_cngetc+0xec > cncheckc() at cncheckc+0x4a > cngetc() at cngetc+0x1c > db_readline() at db_readline+0x77 > db_read_line() at db_read_line+0x15 > db_command_loop() at db_command_loop+0x38 > db_trap() at db_trap+0x89 > kdb_trap() at kdb_trap+0x101 > trap_fatal() at trap_fatal+0x29d > trap() at trap+0x10a > nmi_calltrap() at nmi_calltrap+0x8 > --- trap 0x13, rip = 0xffffffff80711dc5, rsp = 0xffffffff81272040, rbp = > 0xffffff907cf44b40 --- > uhci_interrupt() at uhci_interrupt+0x65 > intr_event_execute_handlers() at intr_event_execute_handlers+0x104 > ithread_loop() at ithread_loop+0xa4 > fork_exit() at fork_exit+0x11f > fork_trampoline() at fork_trampoline+0xe > --- trap 0, rip = 0, rsp = 0xffffff907cf44d00, rbp = 0 --- > db> > > After disabling stopping on NMI (kdb_on_nmi), I still can't boot from > bge (this is a PXE booted machine), I get this in an infinite loop: > bge1: link state changed to DOWN > DHCP/BOOTP timeout for server 255.255.255.255 > bge1: 3 link states coalesced > bge1: link state changed to UP > bge0: 2 link states coalesced > bge0: link state changed to DOWN > bge0: link state changed to UP > bge1: link state changed to DOWN > bge0: link state changed to DOWN > bge0: link state changed to UP > bge0: link state changed to DOWN > bge1: 2 link states coalesced > bge1: link state changed to DOWN > bge0: link state changed to UP > bge0: link state changed to DOWN > bge0: 2 link states coalesced > bge0: link state changed to DOWN > bge1: 2 link states coalesced > bge1: link state changed to DOWN > bge0: link state changed to UP > bge0: link state changed to DOWN > bge0: link state changed to UP > bge0: link state changed to DOWN > > Linux and Windows boot fine on the machine. > > dmesg up to the point where it crashes: > 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 #3: Tue Feb 21 11:57:33 CET 2012 > root@boot.lab:/usr/obj/usr/src/sys/BOOTCLNT amd64 > CPU: Intel(R) Xeon(R) CPU E5-2680 0 @ 2.70GHz (2693.57-MHz K8-class CPU) > Origin = "GenuineIntel" Id = 0x206d6 Family = 6 Model = 2d > Stepping = 6 > > Features=0xbfebfbff > > Features2=0x15bee3ff > AMD Features=0x2c100800 > AMD Features2=0x1 > TSC: P-state invariant, performance statistics > real memory = 34359738368 (32768 MB) > avail memory = 32991268864 (31462 MB) > Event timer "LAPIC" quality 600 > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 32 CPUs > FreeBSD/SMP: 2 package(s) x 8 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 > cpu8 (AP): APIC ID: 8 > cpu9 (AP): APIC ID: 9 > cpu10 (AP): APIC ID: 10 > cpu11 (AP): APIC ID: 11 > cpu12 (AP): APIC ID: 12 > cpu13 (AP): APIC ID: 13 > cpu14 (AP): APIC ID: 14 > cpu15 (AP): APIC ID: 15 > cpu16 (AP): APIC ID: 32 > cpu17 (AP): APIC ID: 33 > cpu18 (AP): APIC ID: 34 > cpu19 (AP): APIC ID: 35 > cpu20 (AP): APIC ID: 36 > cpu21 (AP): APIC ID: 37 > cpu22 (AP): APIC ID: 38 > cpu23 (AP): APIC ID: 39 > cpu24 (AP): APIC ID: 40 > cpu25 (AP): APIC ID: 41 > cpu26 (AP): APIC ID: 42 > cpu27 (AP): APIC ID: 43 > cpu28 (AP): APIC ID: 44 > cpu29 (AP): APIC ID: 45 > cpu30 (AP): APIC ID: 46 > cpu31 (AP): APIC ID: 47 > ACPI Warning: Invalid length for Pm1aControlBlock: 32, using default 16 > (20110527/tbfadt-638) > ACPI Warning: Invalid length for Pm2ControlBlock: 32, using default 8 > (20110527/tbfadt-638) > ioapic1 irqs 24-47 on motherboard > ioapic0 irqs 0-23 on motherboard > ioapic2 irqs 48-71 on motherboard > kbd1 at kbdmux0 > ctl: CAM Target Layer loaded > 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 0x908-0x90b on acpi0 > cpu0: on acpi0 > cpu1: on acpi0 > cpu2: on acpi0 > cpu3: on acpi0 > cpu4: on acpi0 > cpu5: on acpi0 > cpu6: on acpi0 > cpu7: on acpi0 > cpu8: on acpi0 > cpu9: on acpi0 > cpu10: on acpi0 > cpu11: on acpi0 > cpu12: on acpi0 > cpu13: on acpi0 > cpu14: on acpi0 > cpu15: on acpi0 > cpu16: on acpi0 > cpu17: on acpi0 > cpu18: on acpi0 > cpu19: on acpi0 > cpu20: on acpi0 > cpu21: on acpi0 > cpu22: on acpi0 > cpu23: on acpi0 > cpu24: on acpi0 > cpu25: on acpi0 > cpu26: on acpi0 > cpu27: on acpi0 > cpu28: on acpi0 > cpu29: on acpi0 > cpu30: on acpi0 > cpu31: on acpi0 > pcib0: on acpi0 > pci0: on pcib0 > pcib1: at device 1.0 on pci0 > pci7: on pcib1 > pcib2: at device 1.1 on pci0 > pci19: on pcib2 > pcib3: at device 2.0 on pci0 > pci3: on pcib3 > pci0:3:0:0: failed to read VPD data. > bge0: mem > 0xf6bf0000-0xf6bfffff,0xf6be0000-0xf6beffff,0xf6bd0000-0xf6bdffff irq 32 > at device 0.0 on pci3 > bge0: CHIP ID 0x05719001; ASIC REV 0x5719; CHIP REV 0x57190; PCI-E ^^^^^^^^^^ This controller is new one. Probably BCM5719 A1 but not sure. > bge0: Try again This message indicates your controller has ASF/IPMI firmware. Try disabling ASF and see whether it makes any difference. (Change hw.bge.allow_asf tunable to 0). > miibus0: on bge0 > ukphy0: PHY 1 on miibus0 > ukphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, > 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, > auto-flow I think the use of ukphy(4) here is the side effect of ASF. BCM5719 should use brgphy(4). > bge0: Ethernet address: 3c:4a:92:b2:3c:08 > pci0:3:0:1: failed to read VPD data. > bge1: mem > 0xf6bc0000-0xf6bcffff,0xf6bb0000-0xf6bbffff,0xf6ba0000-0xf6baffff irq 36 > at device 0.1 on pci3 > bge1: CHIP ID 0x05719001; ASIC REV 0x5719; CHIP REV 0x57190; PCI-E > miibus1: on bge1 > brgphy0: PHY 2 on miibus1 > brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, > 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow > bge1: Ethernet address: 3c:4a:92:b2:3c:09 > pci0:3:0:2: failed to read VPD data. > bge2: mem > 0xf6b90000-0xf6b9ffff,0xf6b80000-0xf6b8ffff,0xf6b70000-0xf6b7ffff irq 32 > at device 0.2 on pci3 > bge2: CHIP ID 0x05719001; ASIC REV 0x5719; CHIP REV 0x57190; PCI-E > miibus2: on bge2 > brgphy1: PHY 3 on miibus2 > brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, > 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow > bge2: Ethernet address: 3c:4a:92:b2:3c:0a > pci0:3:0:3: failed to read VPD data. > bge3: mem > 0xf6b60000-0xf6b6ffff,0xf6b50000-0xf6b5ffff,0xf6b40000-0xf6b4ffff irq 36 > at device 0.3 on pci3 > bge3: CHIP ID 0x05719001; ASIC REV 0x5719; CHIP REV 0x57190; PCI-E > miibus3: on bge3 > brgphy2: PHY 4 on miibus3 > brgphy2: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, > 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow > bge3: Ethernet address: 3c:4a:92:b2:3c:0b > pcib4: at device 2.1 on pci0 > pci20: on pcib4 > pcib5: at device 2.2 on pci0 > pci2: on pcib5 > ciss0: port 0x5000-0x50ff mem > 0xf7f00000-0xf7ffffff,0xf7ef0000-0xf7ef03ff irq 34 at device 0.0 on pci2 > ciss0: PERFORMANT Transport > pcib6: at device 2.3 on pci0 > pci21: on pcib6 > pcib7: at device 3.0 on pci0 > pci4: on pcib7 > pcib8: at device 3.1 on pci0 > pci22: on pcib8 > pcib9: at device 3.2 on pci0 > pci23: on pcib9 > pcib10: at device 3.3 on pci0 > pci24: on pcib10 > pci0: at device 4.0 (no driver attached) > pci0: at device 4.1 (no driver attached) > pci0: at device 4.2 (no driver attached) > pci0: at device 4.3 (no driver attached) > pci0: at device 4.4 (no driver attached) > pci0: at device 4.5 (no driver attached) > pci0: at device 4.6 (no driver attached) > pci0: at device 4.7 (no driver attached) > pci0: at device 5.0 (no driver attached) > pci0: at device 5.2 (no driver attached) > pcib11: at device 17.0 on pci0 > pci26: on pcib11 > ehci0: mem 0xf6c60000-0xf6c603ff irq > 21 at device 26.0 on pci0 > usbus0: EHCI version 1.0 > usbus0: on ehci0 > pcib12: at device 28.0 on pci0 > pci10: on pcib12 > pcib13: at device 28.7 on pci0 > pci1: on pcib13 > pci1: at device 0.0 (no driver attached) > vgapci0: mem > 0xf5000000-0xf5ffffff,0xf7de0000-0xf7de3fff,0xf7000000-0xf77fffff irq 16 > at device 0.1 on pci1 > pci1: at device 0.2 (no driver attached) > uhci0: port 0x3c00-0x3c1f irq 16 at > device 0.4 on pci1 > usbus1: on uhci0 > ehci1: mem 0xf6c50000-0xf6c503ff irq > 20 at device 29.0 on pci0 > usbus2: EHCI version 1.0 > usbus2: on ehci1 > pcib14: at device 30.0 on pci0 > pci25: on pcib14 > isab0: at device 31.0 on pci0 > isa0: on isab0 > atapci0: port > 0x4000-0x4007,0x4008-0x400b,0x4010-0x4017,0x4018-0x401b,0x4020-0x402f,0x4030-0x403f > irq 17 at device 31.2 on pci0 > ata2: at channel 0 on atapci0 > ata3: at channel 1 on atapci0 > pcib15: on acpi0 > pci32: on pcib15 > pcib16: at device 0.0 on pci32 > pci43: on pcib16 > pcib17: at device 1.0 on pci32 > pci36: on pcib17 > pcib18: at device 1.1 on pci32 > pci37: on pcib18 > pcib19: at device 2.0 on pci32 > pci35: on pcib19 > pcib20: at device 2.1 on pci32 > pci38: on pcib20 > pcib21: at device 2.2 on pci32 > pci34: on pcib21 > pcib22: at device 2.3 on pci32 > pci39: on pcib22 > pcib23: at device 3.0 on pci32 > pci33: on pcib23 > pcib24: at device 3.1 on pci32 > pci40: on pcib24 > pcib25: at device 3.2 on pci32 > pci41: on pcib25 > pcib26: at device 3.3 on pci32 > pci42: on pcib26 > pci32: at device 4.0 (no driver attached) > pci32: at device 4.1 (no driver attached) > pci32: at device 4.2 (no driver attached) > pci32: at device 4.3 (no driver attached) > pci32: at device 4.4 (no driver attached) > pci32: at device 4.5 (no driver attached) > pci32: at device 4.6 (no driver attached) > pci32: at device 4.7 (no driver attached) > pci32: at device 5.0 (no driver attached) > pci32: at device 5.2 (no driver attached) > acpi_tz0: 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 > hpet0: iomem 0xfed00000-0xfed003ff on acpi0 > Timecounter "HPET" frequency 14318180 Hz quality 950 > Event timer "HPET" frequency 14318180 Hz quality 450 > Event timer "HPET1" frequency 14318180 Hz quality 440 > Event timer "HPET2" frequency 14318180 Hz quality 440 > Event timer "HPET3" frequency 14318180 Hz quality 440 > Event timer "HPET4" frequency 14318180 Hz quality 440 > Event timer "HPET5" frequency 14318180 Hz quality 440 > Event timer "HPET6" frequency 14318180 Hz quality 440 > Event timer "HPET7" frequency 14318180 Hz quality 440 > atrtc0: port 0x70-0x71 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] > uart1: port 0x2f8-0x2ff irq > 3 on acpi0 > orm0: at iomem 0xc0000-0xc7fff on isa0 > sc0: at flags 0x100 on isa0 > sc0: VGA <16 virtual consoles, flags=0x300> > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 > ppc0: cannot reserve I/O port range > uart0: at port 0x3f8-0x3ff > irq 4 flags 0x10 on isa0 > uart0: console (9600,n,8,1) > est0: on cpu0 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 24d400001f00 > 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 24d400001f00 > device_attach: est1 attach returned 6 > p4tcc1: on cpu1 > est2: on cpu2 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 24d400001f00 > device_attach: est2 attach returned 6 > p4tcc2: on cpu2 > est3: on cpu3 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 24d400001f00 > device_attach: est3 attach returned 6 > p4tcc3: on cpu3 > est4: on cpu4 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 24d400001f00 > device_attach: est4 attach returned 6 > p4tcc4: on cpu4 > est5: on cpu5 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 24d400001f00 > device_attach: est5 attach returned 6 > p4tcc5: on cpu5 > est6: on cpu6 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 24d400001f00 > device_attach: est6 attach returned 6 > p4tcc6: on cpu6 > est7: on cpu7 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 24d400001f00 > device_attach: est7 attach returned 6 > p4tcc7: on cpu7 > est8: on cpu8 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 24d400001f00 > device_attach: est8 attach returned 6 > p4tcc8: on cpu8 > est9: on cpu9 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 24d400001f00 > device_attach: est9 attach returned 6 > p4tcc9: on cpu9 > est10: on cpu10 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 24d400001f00 > device_attach: est10 attach returned 6 > p4tcc10: on cpu10 > est11: on cpu11 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 24d400001f00 > device_attach: est11 attach returned 6 > p4tcc11: on cpu11 > est12: on cpu12 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 24d400001f00 > device_attach: est12 attach returned 6 > p4tcc12: on cpu12 > est13: on cpu13 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 24d400001f00 > device_attach: est13 attach returned 6 > p4tcc13: on cpu13 > est14: on cpu14 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 24d400001f00 > device_attach: est14 attach returned 6 > p4tcc14: on cpu14 > est15: on cpu15 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 24d400001f00 > device_attach: est15 attach returned 6 > p4tcc15: on cpu15 > est16: on cpu16 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 24d400001f00 > device_attach: est16 attach returned 6 > p4tcc16: on cpu16 > est17: on cpu17 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 24d400001f00 > device_attach: est17 attach returned 6 > p4tcc17: on cpu17 > est18: on cpu18 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 24d400001f00 > device_attach: est18 attach returned 6 > p4tcc18: on cpu18 > est19: on cpu19 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 24d400001f00 > device_attach: est19 attach returned 6 > p4tcc19: on cpu19 > est20: on cpu20 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 24d400001f00 > device_attach: est20 attach returned 6 > p4tcc20: on cpu20 > est21: on cpu21 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 24d400001f00 > device_attach: est21 attach returned 6 > p4tcc21: on cpu21 > est22: on cpu22 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 24d400001f00 > device_attach: est22 attach returned 6 > p4tcc22: on cpu22 > est23: on cpu23 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 24d400001f00 > device_attach: est23 attach returned 6 > p4tcc23: on cpu23 > est24: on cpu24 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 24d400001f00 > device_attach: est24 attach returned 6 > p4tcc24: on cpu24 > est25: on cpu25 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 24d400001f00 > device_attach: est25 attach returned 6 > p4tcc25: on cpu25 > est26: on cpu26 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 24d400001f00 > device_attach: est26 attach returned 6 > p4tcc26: on cpu26 > est27: on cpu27 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 24d400001f00 > device_attach: est27 attach returned 6 > p4tcc27: on cpu27 > est28: on cpu28 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 24d400001f00 > device_attach: est28 attach returned 6 > p4tcc28: on cpu28 > est29: on cpu29 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 24d400001f00 > device_attach: est29 attach returned 6 > p4tcc29: on cpu29 > est30: on cpu30 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 24d400001f00 > device_attach: est30 attach returned 6 > p4tcc30: on cpu30 > est31: on cpu31 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 24d400001f00 > device_attach: est31 attach returned 6 > p4tcc31: on cpu31 > Timecounters tick every 1.000 msec > usbus0: 480Mbps High Speed USB v2.0 > usbus1: 12Mbps Full Speed USB v1.0 > ugen0.1: at usbus0 > uhub0: on usbus0 > ugen1.1: <0x103c> at usbus1 > uhub1: <0x103c UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus1 > usbus2: 480Mbps High Speed USB v2.0 > ugen2.1: at usbus2 > uhub2: on usbus2 > uhub1: 2 ports with 2 removable, self powered > uhub0: 2 ports with 2 removable, self powered > uhub2: 2 ports with 2 removable, self powered > ugen1.2: at usbus1 > ukbd0: on usbus1 > (probe0:ciss0:0:0:0): REPORT LUNS. CDB: a0 0 0 0 0 0 0 0 0 10 0 0 > (probe0:ciss0:0:0:0): CAM status: SCSI Status Error > (probe0:ciss0:0:0:0): SCSI status: Check Condition > (probe0:ciss0:0:0:0): SCSI sense: ILLEGAL REQUEST asc:20,0 (Invalid > command operation code) > kbd2 at ukbd0 > ums0: on usbus1 > da0 at ciss0 bus 0 scbus0 target 0 lun 0 > da0: Fixed Direct Access SCSI-5 device > da0: 135.168MB/s transfers > da0: Command Queueing enabled > da0: 286070MB (585871964 512 byte sectors: 255H 32S/T 65535C) > cd0 at ata3 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 From owner-freebsd-stable@FreeBSD.ORG Wed Feb 22 07:00: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 88261106567D for ; Wed, 22 Feb 2012 07:00:28 +0000 (UTC) (envelope-from erich@alogreentechnologies.com) Received: from alogreentechnologies.com (alogreentechnologies.com [67.212.226.44]) by mx1.freebsd.org (Postfix) with ESMTP id 524648FC14 for ; Wed, 22 Feb 2012 07:00:28 +0000 (UTC) Received: from amd620.ovitrap.com ([49.128.188.2]) (authenticated bits=0) by alogreentechnologies.com (8.13.1/8.13.1) with ESMTP id q1M6Yhx6030800 for ; Tue, 21 Feb 2012 23:34:45 -0700 From: Erich Dollansky Organization: ALO Green Technologies Pte Ltd To: freebsd-stable@freebsd.org Date: Wed, 22 Feb 2012 13:34:36 +0700 User-Agent: KMail/1.13.7 (FreeBSD/8.3-PRERELEASE; KDE/4.7.4; amd64; ; ) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201202221334.36484.erich@alogreentechnologies.com> X-Mailman-Approved-At: Wed, 22 Feb 2012 12:04:23 +0000 Subject: random problem with 8.3 from yesterday X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Feb 2012 07:00:28 -0000 Hi, I got a new thumb drive which was FAT formatted. I use this script to change this: !/bin/tcsh # # This script format a thumb drive connected to USB as da0. # printf "You have to run this script as 'root' to succeed.\n" printf "Warning this script will delete all your data from /dev/da0. Continue? > " set Eingabe = $< if ("$Eingabe" == "y") then printf "\nDeleting the device " dd if=/dev/zero of=/dev/da0 bs=1k count=1 printf "\nWriting the BSD label " bsdlabel -Bw da0 auto printf "\nEditing the BSD label " bsdlabel -e da0 newfs /dev/da0a printf "\nThe device /dev/da0 was formated to be used with FreeBSD.\n" else printf "\nScript aborted!\n" endif I then call manually tunefs -L NewDeviceName /dev/da0a Either this call or the mount command does not work randomly. When I then try to mount the device on /dev/da0a it does not work always. I do not know what this causes, I am only randomly able to reproduce it. It might be affected by removing the device or keeping it plugged in. uname says: FreeBSD AMD620.ovitrap.com 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #28: Tue Feb 21 17:15:07 WIT 2012 erich@AMD620.ovitrap.com:/usr/obj/usr/src/sys/AsusAMD620 amd64 dmesg says: ugen1.2: at usbus1 umass0: on usbus1 umass0: SCSI over Bulk-Only; quirks = 0x4001 umass0:2:0:-1: Attached to scbus2 da0 at umass-sim0 bus 0 scbus2 target 0 lun 0 da0: < USB FLASH DRIVE PMAP> Removable Direct Access SCSI-0 device da0: 40.000MB/s transfers da0: 15272MB (31277056 512 byte sectors: 255H 63S/T 1946C) It is not an urgent problem. Erich From owner-freebsd-stable@FreeBSD.ORG Wed Feb 22 13:03: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 A3657106566B for ; Wed, 22 Feb 2012 13:03: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 4B4848FC12 for ; Wed, 22 Feb 2012 13:03:27 +0000 (UTC) Received: from outgoing.leidinger.net (p5796D942.dip.t-dialin.net [87.150.217.66]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id 2BE4F8443F3; Wed, 22 Feb 2012 14:03:14 +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 7120F57BB; Wed, 22 Feb 2012 14:03:11 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=leidinger.net; s=outgoing-alex; t=1329915791; bh=nkGO3vZQuuUhcqkwPzdzjvDreuHrAqEf321k4TWQwso=; h=Date:Message-ID:From:To:Cc:Subject:References:In-Reply-To: Content-Type:MIME-Version; b=PxkLJqfxiwrb+1/kjAF4pABL4qs2/E06P3IP5qvg33xuPJ0i+yMpXkKOmPp66wmD5 pHGCd1RiXNCkcyupxIQPbt6GEAoLfHWZ1vtJ/Jh7TBpSz/a2pBu/GX1258DNdfBdub 6ha84LJ6NiCPf+V6UmSGRlMYrYD1/O0SUt4VyeK2NqnXvoE41XQwsU0PY+7kT/bZgS xxBI0xwcoiaOK649rRJLFlPXnLty7axbesYm+OWjUaPQqLn0ByJs4PXmaDTMLF3E9K 3QM0k3NjQ8A1Y6Qc3EOaqYHQeLcF+cP3o6QE1R64yiyvgGHFmFKdPntFR/XkIicHaq ScB8P3PjxyIbw== Received: (from www@localhost) by webmail.leidinger.net (8.14.5/8.14.4/Submit) id q1MD3AZA010845; Wed, 22 Feb 2012 14:03: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.21 ([85.94.224.21]) by webmail.leidinger.net (Horde Framework) with HTTP; Wed, 22 Feb 2012 14:03:10 +0100 Date: Wed, 22 Feb 2012 14:03:08 +0100 Message-ID: <20120222140308.Horde.RjSecpjmRSRPROeM24KCgsA@webmail.leidinger.net> From: Alexander Leidinger To: timp References: <20120221143537.Horde.deyFDZjmRSRPQ52pxBIpnLA@webmail.leidinger.net> <1329890164178-5504219.post@n5.nabble.com> In-Reply-To: <1329890164178-5504219.post@n5.nabble.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: 2BE4F8443F3.A3726 X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=-0.608, required 6, autolearn=disabled, AWL -0.50, 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: 1330520594.39088@VWgE2AdzGReqT2V9IMT9FQ X-EBL-Spam-Status: No Cc: freebsd-stable@freebsd.org Subject: Re: [CFT] modular kernel config X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Feb 2012 13:03:27 -0000 Quoting timp (from Tue, 21 Feb 2012 21:56:04 -0800 (PST)): > Sorry, but for loader.conf you need use 'load' instead of 'enable' > sed -e "s/enable/load/" loader.conf [blush]fixed[/blush] Thanks, Alexander. -- At least I thought I was dancing, 'til somebody stepped on my hand. -- J. B. White 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 Wed Feb 22 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 496D4106564A for ; Wed, 22 Feb 2012 13:54:37 +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 E9F5D8FC13 for ; Wed, 22 Feb 2012 13:54:36 +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 q1MDs6Y7018718; Wed, 22 Feb 2012 08:54:06 -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 TYQ23583; Wed, 22 Feb 2012 08:54:05 -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 q1MDs5Mg027264 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 22 Feb 2012 08:54:05 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Paul Mather In-Reply-To: <20120218012746.GA3283@deviant.kiev.zoral.com.ua> Date: Wed, 22 Feb 2012 08:54:05 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <19091D0B-79C0-4255-807B-A2B89053B498@gromit.dlib.vt.edu> References: <20120215004753.GQ3283@deviant.kiev.zoral.com.ua> <8F48D496-59BD-431D-B7F1-962A79C7ACC5@gromit.dlib.vt.edu> <20120216154932.GM3283@deviant.kiev.zoral.com.ua> <20120218012746.GA3283@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.0A020205.4F44F37E.0006,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, 22 Feb 2012 13:54:37 -0000 On Feb 17, 2012, at 8:27 PM, Konstantin Belousov wrote: > 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 = 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". >>=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 = 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 >=20 > This is indeed strange. It can only occur if td pointer is damaged. >=20 > Please, try to get a core and at least print the content of *td in = this case. Another panic last night, after reverting "dsmc schedule" scripts to use = "/bin/sh" (actually /compat/linux/bin/sh): Fatal trap 12: page fault while in kernel mode cpuid =3D 1; apic id =3D 01 fault virtual address =3D 0x308 fault code =3D supervisor read data, page not present instruction pointer =3D 0x20:0xffffffff806026ef stack pointer =3D 0x28:0xffffff8094af02d0 frame pointer =3D 0x28:0xffffff8094af0350 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 90872 (df) trap number =3D 12 panic: page fault cpuid =3D 1 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 Alas, the system became "hung" here: there is no further output = indicating memory being dumped to the dumpdev and no core dump was found = during subsequent (forced) reboot. :-( Note that this panic is different to the previous one. Also, the = presence of nullfs_statfs in the backtrace above is very curious. = According to my logs, the daily backup had already finished successfully = and thus the nullfs-mounted file systems would have been unmounted = before the system panicked: 02/22/12 02:08:11 --- SCHEDULEREC STATUS END 02/22/12 02:08:11 --- SCHEDULEREC OBJECT END DESKTOP_DAILY_BACKUP = 02/22/12 02:00:00 02/22/12 02:08:11=20 Executing Operating System command or script: /usr/local/bin/remove_zfs_backup_snapshot 02/22/12 02:08:12 Finished command. Return code is: 0 02/22/12 02:08:12 Scheduled event 'DESKTOP_DAILY_BACKUP' completed = successfully. 02/22/12 02:08:12 Sending results for scheduled event = 'DESKTOP_DAILY_BACKUP'. 02/22/12 02:08:12 Results sent to server for scheduled event = 'DESKTOP_DAILY_BACKUP'. 02/22/12 02:08:12 ANS1483I Schedule log pruning started. 02/22/12 02:08:15 ANS1484I Schedule log pruning finished successfully. Other logs indicate that the system was up until 3 am, whereupon, = presumably, "periodic daily" precipitated a panic somewhere during its = execution. Cheers, Paul. From owner-freebsd-stable@FreeBSD.ORG Wed Feb 22 14:06: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 63E77106566C; Wed, 22 Feb 2012 14:06:50 +0000 (UTC) (envelope-from Kashyap.Desai@lsi.com) Received: from na3sys009aog103.obsmtp.com (na3sys009aog103.obsmtp.com [74.125.149.71]) by mx1.freebsd.org (Postfix) with ESMTP id 3725C8FC08; Wed, 22 Feb 2012 14:06:49 +0000 (UTC) Received: from paledge01.lsi.com ([192.19.193.42]) (using TLSv1) by na3sys009aob103.postini.com ([74.125.148.12]) with SMTP ID DSNKT0T2d4Rru1pBG8ieQf/ueudZpkfUU6/H@postini.com; Wed, 22 Feb 2012 06:06:49 PST Received: from PALHUB01.lsi.com (128.94.213.114) by PALEDGE01.lsi.com (192.19.193.42) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 22 Feb 2012 09:11:34 -0500 Received: from inbexch02.lsi.com (135.36.98.40) by PALHUB01.lsi.com (128.94.213.114) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 22 Feb 2012 09:06:46 -0500 Received: from inbmail01.lsi.com ([135.36.98.64]) by inbexch02.lsi.com ([135.36.98.40]) with mapi; Wed, 22 Feb 2012 19:36:43 +0530 From: "Desai, Kashyap" To: "freebsd-scsi@freebsd.org" , freebsd-stable Date: Wed, 22 Feb 2012 19:36:42 +0530 Thread-Topic: mpslsi0 : Trying sleep, but thread marked as sleeping prohibited Thread-Index: AczxazPnpqiOme5iTReYEw8tAgtfPg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Justin T. Gibbs" , "Kenneth D. Merry" , "McConnell, Stephen" Subject: mpslsi0 : Trying sleep, but thread marked as sleeping prohibited X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Feb 2012 14:06:50 -0000 Hi, I am doing some code changes in mps dirver. While working on those changes,= I come to know about something which is new to me. Some expert help is required to clarify my doubt. 1. When any irq is register with FreeBSD OS, it sets " TDP_NOSLEEPING" pfla= g. It means though irq in freebsd is treated as thread, We cannot sleep in IRQ because of " "TDP_NOSLEEPING " set. 2. In mps driver we have below code snippet in ISR routine. mps_dprint(sc, MPS_TRACE, "%s\n", __func__); mps_lock(sc); mps_intr_locked(data); mps_unlock(sc); I wonder why there is no issue with above code ? Theoretical we cannot slee= p in ISR. (as explained in #1) Any thoughts ? 3. I recently added few place msleep() instead of DELAY in ISR context and = I see=20 " Trying sleep, but thread marked as sleeping prohibited". ` Kashyap From owner-freebsd-stable@FreeBSD.ORG Wed Feb 22 14:40:00 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 86BE3106566C for ; Wed, 22 Feb 2012 14:40:00 +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 6FEAE8FC12 for ; Wed, 22 Feb 2012 14:39:57 +0000 (UTC) Received: from alph.allbsd.org (p1012-ipbf2105funabasi.chiba.ocn.ne.jp [114.148.160.12]) (authenticated bits=128) by mail.allbsd.org (8.14.4/8.14.4) with ESMTP id q1MEdZRl016840 for ; Wed, 22 Feb 2012 23:39:45 +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 q1MEdYHG055557 for ; Wed, 22 Feb 2012 23:39:34 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Wed, 22 Feb 2012 23:38:14 +0900 (JST) Message-Id: <20120222.233814.1255848524636250830.hrs@allbsd.org> To: stable@FreeBSD.org From: Hiroki Sato 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: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.allbsd.org [133.31.130.32]); Wed, 22 Feb 2012 23:39:51 +0900 (JST) X-Spam-Status: No, score=-99.3 required=13.0 tests=BAYES_00, CONTENT_TYPE_PRESENT, FAKEDWORD_ONE, FAKEDWORD_VERTICALLINE, FAKEDWORD_ZERO, RCVD_IN_PBL, RCVD_IN_RP_RNBL, 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: Subject: panic in 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: Wed, 22 Feb 2012 14:40:00 -0000 Hi, Just a report, but I got the following panic on an NFS server running 8.3-PRERELEASE: ----(from here)---- pool.allbsd.org dumped core - see /var/crash/vmcore.0 Tue Feb 21 10:59:44 JST 2012 FreeBSD pool.allbsd.org 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #7: Thu Feb 16 19:29:19 JST 2012 hrs@pool.allbsd.org:/usr/obj/usr/src/sys/POOL amd64 panic: Assertion lock == sq->sq_lock failed at /usr/src/sys/kern/subr_sleepqueue.c:335 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"... Unread portion of the kernel message buffer: Reading symbols from /boot/kernel/geom_mirror.ko...Reading symbols from /boot/kernel/geom_mirror.ko.symbols...done. done. Loaded symbols for /boot/kernel/geom_mirror.ko Reading symbols from /boot/kernel/zfs.ko...Reading symbols from /boot/kernel/zfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/zfs.ko Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols from /boot/kernel/opensolaris.ko.symbols...done. done. Loaded symbols for /boot/kernel/opensolaris.ko Reading symbols from /boot/kernel/ipfw.ko...Reading symbols from /boot/kernel/ipfw.ko.symbols...done. done. Loaded symbols for /boot/kernel/ipfw.ko #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:263 263 if (textdump_pending) (kgdb) #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:263 #1 0xffffffff801f8cfc in db_fncall (dummy1=Variable "dummy1" is not available. ) at /usr/src/sys/ddb/db_command.c:548 #2 0xffffffff801f9031 in db_command (last_cmdp=0xffffffff80d37f40, cmd_table=Variable "cmd_table" is not available. ) at /usr/src/sys/ddb/db_command.c:445 #3 0xffffffff801f9280 in db_command_loop () at /usr/src/sys/ddb/db_command.c:498 #4 0xffffffff801fb369 in db_trap (type=Variable "type" is not available. ) at /usr/src/sys/ddb/db_main.c:229 #5 0xffffffff8069e021 in kdb_trap (type=3, code=0, tf=0xffffff86c5f7e640) at /usr/src/sys/kern/subr_kdb.c:548 #6 0xffffffff80946766 in trap (frame=0xffffff86c5f7e640) at /usr/src/sys/amd64/amd64/trap.c:595 #7 0xffffffff8092d324 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:228 #8 0xffffffff8069de7b in kdb_enter (why=0xffffffff80a891dd "panic", msg=0xa
) at cpufunc.h:63 #9 0xffffffff8066afc0 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:597 #10 0xffffffff806a9360 in sleepq_add (wchan=0xffffff0073b97a00, lock=0xffffffff80d6af00, wmesg=0xffffffff80a7bb28 "nfsrc", flags=0, queue=0) at /usr/src/sys/kern/subr_sleepqueue.c:335 #11 0xffffffff80673e4f in _sleep (ident=0xffffff0073b97a00, lock=0xffffffff80d6af00, priority=Variable "priority" is not available. ) at /usr/src/sys/kern/kern_synch.c:218 #12 0xffffffff805fe01e in nfsrvd_updatecache (nd=0xffffff86c5f7e960, so=0xffffff002217c000) at /usr/src/sys/fs/nfsserver/nfs_nfsdcache.c:697 #13 0xffffffff805ea934 in nfssvc_program (rqst=0xffffff0476070800, xprt=0xffffff000edd0a00) at /usr/src/sys/fs/nfsserver/nfs_nfsdkrpc.c:333 #14 0xffffffff8084c76b in svc_run_internal (pool=0xffffff000c876600, ismaster=0) at /usr/src/sys/rpc/svc.c:895 #15 0xffffffff8084cc8b in svc_thread_start (arg=Variable "arg" is not available. ) at /usr/src/sys/rpc/svc.c:1200 #16 0xffffffff80640865 in fork_exit ( callout=0xffffffff8084cc80 , arg=0xffffff000c876600, frame=0xffffff86c5f7ec50) at /usr/src/sys/kern/kern_fork.c:876 #17 0xffffffff8092d86e in fork_trampoline () at /usr/src/sys/amd64/amd64/exception.S:602 #18 0x0000000000000080 in ?? () #19 0x00007fffffffe700 in ?? () #20 0x000000000000002e in ?? () #21 0x0000000000000000 in ?? () #22 0xfffffffffffffef4 in ?? () #23 0xffffff000e1028c0 in ?? () #24 0x000000000000009b in ?? () #25 0x00007fffffffe700 in ?? () #26 0x0000000000000006 in ?? () #27 0x0000000000000003 in ?? () #28 0x00000000ffffffff in ?? () #29 0x00007fffffffe720 in ?? () #30 0x0000000000000000 in ?? () #31 0x0000000000000000 in ?? () #32 0x0000000000000001 in ?? () #33 0x001b00130000000c in ?? () #34 0x00007fffffffffe8 in ?? () #35 0x003b003b00000001 in ?? () #36 0x0000000000000002 in ?? () #37 0x00000008006a1dac in ?? () #38 0x0000000000000043 in ?? () #39 0x0000000000000202 in ?? () #40 0x00007fffffffe6c8 in ?? () #41 0x000000000000003b in ?? () #42 0xffffff0022262470 in ?? () #43 0x0000000000000000 in ?? () #44 0xffffffff80d80e40 in tdq_cpu () #45 0xffffff00057958c0 in ?? () #46 0xffffff86c5f7e930 in ?? () #47 0xffffff86c5f7e8d8 in ?? () #48 0xffffff002218c8c0 in ?? () #49 0xffffffff80691397 in sched_switch (td=0xffffff000c876600, newtd=0xffffffff8084cc80, flags=Variable "flags" is not available. ) at /usr/src/sys/kern/sched_ule.c:1861 Previous frame inner to this frame (corrupt stack?) (kgdb) ------------------------------------------------------------------------ ps -axl UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME COMMAND 0 0 0 0 -8 0 0 0 - DLs ?? 138141186720:38.04 [kernel] 0 1 0 0 46 0 3200 0 wait DLs ?? 32872919:34.00 [init] 0 2 0 0 -8 0 0 0 - DL ?? 2384800:02.00 [g_event] 0 3 0 0 -8 0 0 0 - DL ?? 34443954063:22.00 [g_up] 0 4 0 0 -8 0 0 0 - DL ?? 52261177097:30.00 [g_down] 0 5 0 0 -16 0 0 0 mps_sc DL ?? 22268598:50.00 [mps_scan0] 0 6 0 0 -16 0 0 0 waitin DL ?? 1938:00.00 [sctp_itera 0 7 0 0 -16 0 0 0 ccb_sc DL ?? 0:00.00 [xpt_thrd] 0 8 0 0 -16 0 0 0 zfs:lo DL ?? 279189757877:10.00 [pagedaemon 0 9 0 0 -16 0 0 0 psleep DL ?? 30647760:24.00 [vmdaemon] 0 10 0 0 -16 0 0 0 audit_ DL ?? 0:00.00 [audit] 0 11 0 0 171 0 0 0 - RL ?? 98310602660:37.92 [idle] 0 12 0 0 -60 0 0 0 - WL ?? 128367001717:26.00 [intr] 0 13 0 0 -16 0 0 0 - DL ?? 13126281049:04.00 [yarrow] 0 14 0 0 -40 0 0 0 - DL ?? 355171576:34.00 [usb] 0 15 0 0 76 0 0 0 pgzero DL ?? 83753:16.00 [pagezero] 0 16 0 0 -16 0 0 0 psleep DL ?? 28138575:06.00 [bufdaemon] 0 17 0 0 47 0 0 0 vlruwt DL ?? 4907694216:30.00 [vnlru] 0 18 0 0 20 0 0 0 vmwait DL ?? 25925591442:54.00 [syncer] 0 19 0 0 -16 0 0 0 sdflus DL ?? 275943437:00.00 [softdepflu 0 20 0 0 -8 0 0 0 m:w1 DL ?? 210842046:32.00 [g_mirror g 0 60 0 0 -8 0 0 0 zio->i DL ?? 178867118477:46.00 [zfskern] 0 110 0 0 -8 0 0 0 mdwait DL ?? 99721:48.00 [md0] 0 150 1 0 76 0 5832 40 pause DWs ?? 0:00.00 [adjkerntz] 0 735 1 0 44 0 6920 0 pfault DLs ?? 55753471:38.00 [syslogd] 0 805 1 0 44 0 7976 0 pfault DLs ?? 42986590:04.00 [rpcbind] 0 840 1 0 76 0 6920 0 select Ds ?? 65452:44.00 [mountd] 0 858 1 0 76 0 5832 40 pause DWs ?? 0:00.00 [nfsuserd] 0 859 858 0 44 0 5832 0 pfault DL ?? 25445708:36.00 [nfsuserd] 0 860 858 0 44 0 5832 0 pfault DL ?? 26084710:00.00 [nfsuserd] 0 861 858 0 44 0 5832 0 pfault DL ?? 25778143:28.00 [nfsuserd] 0 862 858 0 44 0 5832 0 pfault DL ?? 25787518:58.00 [nfsuserd] 0 864 1 0 4 0 5828 0 pfault DLs ?? 5920534:50.00 [nfsd] 0 865 864 0 44 0 5828 0 tx->tx D ?? 86066872402:20.97 [nfsd] 0 868 1 0 44 0 269036 0 pfault DLs ?? 24517994:48.00 [rpc.statd] 0 871 1 0 44 0 7976 0 rpcsvc Ds ?? 6817289856:50.00 [rpc.lockd] 0 907 1 0 44 0 11804 0 pfault DLs ?? 992700928:44.00 [ntpd] 1 915 1 0 44 0 5828 0 - WWs ?? 0:00.00 [rwhod] 0 926 1 0 44 0 20908 0 pfault DLs ?? 2969327208:22.00 [perl5.10.1 0 1015 1 0 4 0 26172 0 pfault DLs ?? 27567638:00.00 [sshd] 0 1046 1 0 44 0 12024 0 pfault DLs ?? 672303813:46.00 [sendmail] 25 1059 1 0 44 0 12024 0 - WWs ?? 0:00.00 [sendmail] 0 1073 1 0 44 0 7976 0 - WWs ?? 0:00.00 [cron] 0 1165 1 0 76 0 6916 0 ttyin Ds+ ?? 84842:48.00 [getty] 0 1166 1 0 76 0 6916 0 ttyin Ds+ ?? 76490:46.00 [getty] 0 1167 1 0 44 0 6916 0 ttyin Ds+ ?? 87267:10.00 [getty] 0 1169 1015 0 45 0 29808 112 sbwait DWs ?? 0:00.00 [sshd] 20001 1171 1169 0 44 0 29808 0 select D ?? 1745296:04.00 [sshd] 20001 1172 1171 0 44 0 10336 0 ttyin Ds+ ?? 2023326:04.00 [tcsh] ------------------------------------------------------------------------ vmstat -s 2457092079 cpu context switches 1948268860 device interrupts 114326248 software interrupts 94980728 traps 57483687 system calls 22 kernel threads created 288912 fork() calls 1543 vfork() calls 0 rfork() calls 1942408 swap pager pageins 2087687 swap pager pages paged in 10577326 swap pager pageouts 11536354 swap pager pages paged out 419067 vnode pager pageins 536269 vnode pager pages paged in 5 vnode pager pageouts 5 vnode pager pages paged out 23209842 page daemon wakeups 1235694508 pages examined by the page daemon 48357847 pages reactivated 19134152 copy-on-write faults 6670 copy-on-write optimized faults 14214203 zero fill pages zeroed 1133 zero fill pages prezeroed 2094959 intransit blocking page faults 92125016 total VM faults taken 0 pages affected by kernel thread creation 75840248 pages affected by fork() 430154 pages affected by vfork() 0 pages affected by rfork() 58565695 pages cached 981678745 pages freed 8 pages freed by daemon 19820409 pages freed by exiting processes 0 pages active 0 pages inactive 0 pages in VM cache 6092264 pages wired down 0 pages free 4096 bytes per page 556146802 total name lookups cache hits (11% pos + 1% neg) system 0% per-directory deletions 0%, falsehits 0%, toolong 0% ------------------------------------------------------------------------ vmstat -m Type InUse MemUse HighUse Requests Size(s) isadev 6 1K - 6 128 ata_pci 2 1K - 2 64 acpidev 106 7K - 106 64 cdev 8 2K - 8 256 entropy 1024 64K - 1024 64 sigio 1 1K - 1 64 filedesc 51 27K - 290480 512,1024 kenv 117 12K - 125 16,32,64,128 kqueue 0 0K - 296 256,2048 proc-args 27 2K - 227134 16,32,64,128,256 hhook 2 1K - 2 128 ithread 151 26K - 151 32,128,256 KTRACE 100 13K - 100 128 linker 194 882K - 220 16,32,64,128,256,512,1024,2048,4096 lockf 20 3K - 572 64,128 ip6ndp 19 2K - 23 64,128 temp 112 28K - 276586783 16,32,64,128,256,512,1024,2048,4096 devbuf 5153 17331K - 8647 16,32,64,128,256,512,1024,2048,4096 module 432 54K - 432 128 mtx_pool 2 16K - 2 osd 259 5K - 260 16,64 subproc 1971 1157K - 292401 512,4096 proc 2 16K - 2 session 21 3K - 38828 128 pgrp 21 3K - 38840 128 cred 624 98K - 3107692200 64,256 uidinfo 5 3K - 74066 128,2048 plimit 9 3K - 19773 256 UART 6 4K - 6 16,512,1024 sysctltmp 0 0K - 11884 16,32,64,128,256,4096 sysctloid 7764 385K - 7945 16,32,64,128 sysctl 0 0K - 238540 16,32,64 callout 11 5632K - 11 umtx 2688 336K - 2688 128 p1003.1b 1 1K - 1 16 SWAP 2 4373K - 2 64 SCSI SES 1 2K - 1 2048 bus-sc 146 437K - 8556 16,32,64,128,256,512,1024,2048,4096 bus 2313 424K - 13021 16,32,64,128,256,512,1024,2048 devstat 40 81K - 40 32,4096 eventhandler 81 7K - 81 64,128 ddb_capture 1 48K - 1 kobj 299 1196K - 463 4096 Per-cpu 1 1K - 1 32 pci_link 16 2K - 16 64,128 rman 250 31K - 750 16,32,128 acpi_perf 12 3K - 12 256 sbuf 0 0K - 3404 16,32,64,128,256,512,1024,2048,4096 acpica 5270 577K - 101779 16,32,64,128,256,512,1024,2048 stack 0 0K - 2 256 taskqueue 75 7K - 105 16,32,64,128,1024 Unitno 12 1K - 368 32,64 USBdev 40 12K - 40 64,128,512,1024 USB 66 36K - 68 16,32,64,128,256,2048,4096 kbdmux 7 10K - 7 16,512,1024,2048,4096 Witness 1 128K - 1 iov 0 0K - 18370 16,64,128,256,512 select 1679 210K - 1679 128 ioctlops 0 0K - 332354 16,32,64,128,256,512,1024 msg 4 30K - 4 2048,4096 sem 4 11K - 4 512,1024 shm 1 20K - 1 tty 22 22K - 24 1024,2048 pts 1 1K - 1 256 mbuf_tag 8 1K - 61159597 32,128 ksem 1 8K - 1 shmfd 1 8K - 1 LED 8 1K - 8 16,128 pcb 35 157K - 14585 16,32,128,1024,2048,4096 soname 7 1K - 3119925 16,32,128 acl 0 0K - 5960255 4096 biobuf 0 0K - 6 2048 vfscache 1 4096K - 1 cl_savebuf 0 0K - 1556 64,128 export_host 166 42K - 166 256 vfs_hash 1 2048K - 1 vnodes 2 1K - 2 256 md_disk 1 2K - 1 2048 vnodemarker 0 0K - 126408 512 mount 255 15K - 8568 16,32,64,128,256,512 BPF 14 2K - 14 128 ether_multi 78 5K - 92 16,32,64 ifaddr 131 30K - 131 32,64,128,256,512,4096 ifnet 15 29K - 15 128,2048 clone 6 24K - 6 4096 arpcom 5 1K - 5 16 lltable 63 23K - 177 256,512 acpitask 1 2K - 1 2048 CAM queue 45 27K - 3661 16,32,64,128,256,512,1024,2048 mps 27 464K - 142 16,32,64,128,256,512,1024,2048,4096 acpisem 16 2K - 16 128 routetbl 194 76K - 7875 32,64,128,256,512 igmp 14 4K - 14 256 CAM SIM 6 2K - 6 256 CAM periph 30 8K - 543 16,32,64,128,256 DEVFS1 175 88K - 195 512 in_multi 3 1K - 3 256 sctp_iter 0 0K - 5 256 sctp_ifn 3 1K - 3 128 sctp_ifa 9 2K - 9 128 sctp_vrf 1 1K - 1 64 sctp_a_it 0 0K - 5 16 hostcache 1 28K - 1 syncache 1 96K - 1 DEVFS3 201 51K - 222 256 ip6_moptions 2 1K - 2 32,256 in6_multi 41 5K - 41 32,256 in6_mfilter 1 1K - 1 1024 DEVFS 20 1K - 21 16,128 mld 14 2K - 14 128 NLM 2 4K - 3 32,2048 rpc 498 295K - 3136399322 16,32,64,128,256,512,1024,2048 audit_evclass 172 6K - 211 32 savedino 0 0K - 381 256 dirrem 0 0K - 2552 64 mkdir 0 0K - 12 64 diradd 0 0K - 2556 64 freefile 0 0K - 457 64 freeblks 0 0K - 492 256 freefrag 0 0K - 3510 64 allocindir 0 0K - 1576357 128 indirdep 0 0K - 1989 64 allocdirect 0 0K - 904 256 bmsafemap 0 0K - 2063 128 newblk 1 1K - 1577262 64,512 inodedep 1 2048K - 3097 256 pagedep 1 512K - 433 128 ufs_dirhash 307 154K - 37379 16,32,64,128,256,512 ufs_mount 16 45K - 25 128,512,2048,4096 UMAHash 3 4101K - 20 512,1024,2048,4096 vm_pgdata 2 129K - 2 128 io_apic 2 4K - 2 2048 memdesc 1 4K - 1 4096 NFSD usrgroup 76 10K - 76 128 atkbddev 2 1K - 2 64 NFSD string 1 1K - 1 16 NFSD srvcache 406 51K - 1548524470 128 pfs_nodes 21 6K - 21 256 CAM XPT 661 1112K - 3885 16,32,64,128,256,1024,2048 GEOM 466 92K - 2728 16,32,64,128,256,512,1024 scsi_da 0 0K - 366 16 CAM dev queue 6 1K - 6 128 qpidrv 1 1K - 1 16 MCA 13 2K - 13 128 msi 9 2K - 9 128 nexusdev 4 1K - 4 16 mirror_data 3 1K - 39945 64,128,512 solaris 11691962 13925065K - 2722517546 16,32,64,128,256,512,1024,2048,4096 kstat_data 4 1K - 4 64 IpFw/IpAcct 36 5K - 70 16,32,64,128,256,512 ------------------------------------------------------------------------ vmstat -z ITEM SIZE LIMIT USED FREE REQUESTS FAILURES UMA Kegs: 208, 0, 184, 3, 184, 0 UMA Zones: 576, 0, 184, 2, 184, 0 UMA Slabs: 568, 0, 1204399, 868, 136164851, 2 UMA RCntSlabs: 568, 0, 3007, 458, 59379755, 0 UMA Hash: 256, 0, 78, 12, 81, 0 16 Bucket: 152, 0, 43, 132, 202, 0 32 Bucket: 280, 0, 156, 82, 431, 0 64 Bucket: 536, 0, 109, 66, 635, 52 128 Bucket: 1048, 0, 894, 150, 42524901, 249667 VM OBJECT: 216, 0, 217809, 134145, 205023219, 0 MAP: 232, 0, 7, 25, 7, 0 KMAP ENTRY: 120, 786222, 34101, 66711, 356681687, 0 MAP ENTRY: 120, 0, 626, 2071, 13286492, 0 DP fakepg: 120, 0, 0, 0, 0, 0 SG fakepg: 120, 0, 0, 0, 0, 0 mt_zone: 2056, 0, 287, 35, 287, 0 16: 16, 0, 1675440, 672528, 260550357, 0 32: 32, 0, 2194930, 308254, 295507810, 0 64: 64, 0, 2752681, 166207, 2445436087, 0 128: 128, 0, 599877, 103663, 2012557000, 0 256: 256, 0, 130698, 1767, 1910531783, 0 512: 512, 0, 3600727, 170355, 632542169, 0 1024: 1024, 0, 41809, 1419, 17651556, 0 2048: 2048, 0, 45994, 1520, 3137694214, 0 4096: 4096, 0, 217698, 1305, 22805804, 0 Files: 80, 0, 106, 1964, 5239206, 0 TURNSTILE: 136, 0, 2689, 191, 2689, 0 umtx pi: 96, 0, 0, 0, 0, 0 MAC labels: 40, 0, 0, 0, 0, 0 PROC: 1136, 0, 48, 1872, 290477, 0 THREAD: 1120, 0, 2444, 244, 2602, 0 SLEEPQUEUE: 88, 0, 2689, 240, 2689, 0 VMSPACE: 392, 0, 27, 1833, 290457, 0 cpuset: 72, 0, 2, 98, 2, 0 audit_record: 952, 0, 0, 0, 0, 0 mbuf_packet: 256, 0, 3463, 571, 3053225165, 14877915 mbuf: 256, 0, 886, 718, 13477896975, 532 mbuf_cluster: 2048, 25600, 4367, 791, 2946391169, 14863813 mbuf_jumbo_page: 4096, 12800, 0, 422, 4199, 0 mbuf_jumbo_9k: 9216, 19200, 0, 0, 0, 0 mbuf_jumbo_16k: 16384, 12800, 0, 0, 0, 0 mbuf_ext_refcnt: 4, 0, 0, 0, 0, 0 g_bio: 232, 0, 0, 1232, 275916552, 0 ttyinq: 160, 0, 225, 183, 630, 0 ttyoutq: 256, 0, 117, 168, 327, 0 ata_request: 328, 0, 1, 803, 40002602, 0 ata_composite: 336, 0, 0, 0, 0, 0 VNODE: 472, 0, 215060, 72084, 386781863, 0 VNODEPOLL: 112, 0, 0, 0, 0, 0 NAMEI: 1024, 0, 1944818, 1394, 534155455, 0 S VFS Cache: 108, 0, 211506, 103644, 467683632, 0 L VFS Cache: 328, 0, 493, 6683, 9684321, 0 DIRHASH: 1024, 0, 0, 1756, 50430, 0 NCLNODE: 600, 0, 0, 0, 0, 0 pipe: 728, 0, 1, 1634, 236978, 0 ksiginfo: 112, 0, 1913, 1420, 16178, 0 itimer: 344, 0, 1, 32, 2, 0 KNOTE: 128, 0, 0, 290, 296, 0 socket: 680, 25602, 95, 475, 49127, 11600 unpcb: 240, 25600, 10, 486, 8807, 0 ipq: 56, 819, 0, 0, 0, 0 udp_inpcb: 336, 25608, 28, 258, 27781, 0 udpcb: 16, 25704, 28, 1652, 27781, 0 tcp_inpcb: 336, 25608, 56, 681, 9316, 0 tcpcb: 944, 25600, 56, 296, 9316, 0 tcptw: 72, 5150, 0, 800, 1020, 0 syncache: 144, 15366, 10, 224, 10161216, 0 hostcache: 136, 15372, 13, 295, 92, 0 tcpreass: 40, 1680, 0, 1428, 31283, 0 sackhole: 32, 0, 0, 2525, 263849, 0 sctp_ep: 1304, 25602, 0, 0, 0, 0 sctp_asoc: 2288, 40000, 0, 0, 0, 0 sctp_laddr: 48, 80064, 0, 216, 8, 0 sctp_raddr: 696, 80000, 0, 0, 0, 0 sctp_chunk: 136, 400008, 0, 0, 0, 0 sctp_readq: 104, 400032, 0, 0, 0, 0 sctp_stream_msg_out: 112, 400026, 0, 0, 0, 0 sctp_asconf: 40, 400008, 0, 0, 0, 0 sctp_asconf_ack: 48, 400032, 0, 0, 0, 0 ripcb: 336, 25608, 0, 231, 3216, 0 rtentry: 200, 0, 28, 29, 28, 0 selfd: 56, 0, 2191, 1778, 2855424, 0 SWAPMETA: 288, 116519, 511, 2349, 2187939, 0 Mountpoints: 752, 0, 12, 13, 12, 0 FFS inode: 168, 0, 85761, 96377, 974750, 0 FFS1 dinode: 128, 0, 0, 0, 0, 0 FFS2 dinode: 256, 0, 85761, 94059, 974103, 0 taskq_zone: 48, 0, 0, 2232, 661225, 0 zio_cache: 880, 0, 122, 1042, 488025233, 0 zio_link_cache: 48, 0, 104, 1048, 314016714, 0 zio_buf_512: 512, 0, 0, 0, 0, 0 zio_data_buf_512: 512, 0, 0, 0, 0, 0 zio_buf_1024: 1024, 0, 0, 0, 0, 0 zio_data_buf_1024: 1024, 0, 0, 0, 0, 0 zio_buf_1536: 1536, 0, 0, 0, 0, 0 zio_data_buf_1536: 1536, 0, 0, 0, 0, 0 zio_buf_2048: 2048, 0, 0, 0, 0, 0 zio_data_buf_2048: 2048, 0, 0, 0, 0, 0 zio_buf_2560: 2560, 0, 0, 0, 0, 0 zio_data_buf_2560: 2560, 0, 0, 0, 0, 0 zio_buf_3072: 3072, 0, 0, 0, 0, 0 zio_data_buf_3072: 3072, 0, 0, 0, 0, 0 zio_buf_3584: 3584, 0, 0, 0, 0, 0 zio_data_buf_3584: 3584, 0, 0, 0, 0, 0 zio_buf_4096: 4096, 0, 0, 0, 0, 0 zio_data_buf_4096: 4096, 0, 0, 0, 0, 0 zio_buf_5120: 5120, 0, 0, 0, 0, 0 zio_data_buf_5120: 5120, 0, 0, 0, 0, 0 zio_buf_6144: 6144, 0, 0, 0, 0, 0 zio_data_buf_6144: 6144, 0, 0, 0, 0, 0 zio_buf_7168: 7168, 0, 0, 0, 0, 0 zio_data_buf_7168: 7168, 0, 0, 0, 0, 0 zio_buf_8192: 8192, 0, 0, 0, 0, 0 zio_data_buf_8192: 8192, 0, 0, 0, 0, 0 zio_buf_10240: 10240, 0, 0, 0, 0, 0 zio_data_buf_10240: 10240, 0, 0, 0, 0, 0 zio_buf_12288: 12288, 0, 0, 0, 0, 0 zio_data_buf_12288: 12288, 0, 0, 0, 0, 0 zio_buf_14336: 14336, 0, 0, 0, 0, 0 zio_data_buf_14336: 14336, 0, 0, 0, 0, 0 zio_buf_16384: 16384, 0, 0, 0, 0, 0 zio_data_buf_16384: 16384, 0, 0, 0, 0, 0 zio_buf_20480: 20480, 0, 0, 0, 0, 0 zio_data_buf_20480: 20480, 0, 0, 0, 0, 0 zio_buf_24576: 24576, 0, 0, 0, 0, 0 zio_data_buf_24576: 24576, 0, 0, 0, 0, 0 zio_buf_28672: 28672, 0, 0, 0, 0, 0 zio_data_buf_28672: 28672, 0, 0, 0, 0, 0 zio_buf_32768: 32768, 0, 0, 0, 0, 0 zio_data_buf_32768: 32768, 0, 0, 0, 0, 0 zio_buf_36864: 36864, 0, 0, 0, 0, 0 zio_data_buf_36864: 36864, 0, 0, 0, 0, 0 zio_buf_40960: 40960, 0, 0, 0, 0, 0 zio_data_buf_40960: 40960, 0, 0, 0, 0, 0 zio_buf_45056: 45056, 0, 0, 0, 0, 0 zio_data_buf_45056: 45056, 0, 0, 0, 0, 0 zio_buf_49152: 49152, 0, 0, 0, 0, 0 zio_data_buf_49152: 49152, 0, 0, 0, 0, 0 zio_buf_53248: 53248, 0, 0, 0, 0, 0 zio_data_buf_53248: 53248, 0, 0, 0, 0, 0 zio_buf_57344: 57344, 0, 0, 0, 0, 0 zio_data_buf_57344: 57344, 0, 0, 0, 0, 0 zio_buf_61440: 61440, 0, 0, 0, 0, 0 zio_data_buf_61440: 61440, 0, 0, 0, 0, 0 zio_buf_65536: 65536, 0, 0, 0, 0, 0 zio_data_buf_65536: 65536, 0, 0, 0, 0, 0 zio_buf_69632: 69632, 0, 0, 0, 0, 0 zio_data_buf_69632: 69632, 0, 0, 0, 0, 0 zio_buf_73728: 73728, 0, 0, 0, 0, 0 zio_data_buf_73728: 73728, 0, 0, 0, 0, 0 zio_buf_77824: 77824, 0, 0, 0, 0, 0 zio_data_buf_77824: 77824, 0, 0, 0, 0, 0 zio_buf_81920: 81920, 0, 0, 0, 0, 0 zio_data_buf_81920: 81920, 0, 0, 0, 0, 0 zio_buf_86016: 86016, 0, 0, 0, 0, 0 zio_data_buf_86016: 86016, 0, 0, 0, 0, 0 zio_buf_90112: 90112, 0, 0, 0, 0, 0 zio_data_buf_90112: 90112, 0, 0, 0, 0, 0 zio_buf_94208: 94208, 0, 0, 0, 0, 0 zio_data_buf_94208: 94208, 0, 0, 0, 0, 0 zio_buf_98304: 98304, 0, 0, 0, 0, 0 zio_data_buf_98304: 98304, 0, 0, 0, 0, 0 zio_buf_102400: 102400, 0, 0, 0, 0, 0 zio_data_buf_102400: 102400, 0, 0, 0, 0, 0 zio_buf_106496: 106496, 0, 0, 0, 0, 0 zio_data_buf_106496: 106496, 0, 0, 0, 0, 0 zio_buf_110592: 110592, 0, 0, 0, 0, 0 zio_data_buf_110592: 110592, 0, 0, 0, 0, 0 zio_buf_114688: 114688, 0, 0, 0, 0, 0 zio_data_buf_114688: 114688, 0, 0, 0, 0, 0 zio_buf_118784: 118784, 0, 0, 0, 0, 0 zio_data_buf_118784: 118784, 0, 0, 0, 0, 0 zio_buf_122880: 122880, 0, 0, 0, 0, 0 zio_data_buf_122880: 122880, 0, 0, 0, 0, 0 zio_buf_126976: 126976, 0, 0, 0, 0, 0 zio_data_buf_126976: 126976, 0, 0, 0, 0, 0 zio_buf_131072: 131072, 0, 0, 0, 0, 0 zio_data_buf_131072: 131072, 0, 0, 0, 0, 0 sa_cache: 80, 0, 129266, 27244, 385801818, 0 dnode_t: 856, 0, 3449429, 67491, 28031304, 0 dmu_buf_impl_t: 224, 0, 4169264, 253694, 64122423, 0 arc_buf_hdr_t: 216, 0, 2429176, 277376, 13824588, 0 arc_buf_t: 104, 0, 883770, 96294, 36277716, 0 zil_lwb_cache: 192, 0, 6, 2054, 2397885, 0 zfs_znode_cache: 400, 0, 129266, 21628, 385801818, 0 IPFW dynamic rule: 120, 0, 0, 0, 0, 0 ------------------------------------------------------------------------ vmstat -i interrupt total rate irq0: 1 0 stray irq0 1 0 irq3: uart1 4419 7 irq18: ehci0 uhci5 2 0 irq19: uhci2 uhci4* 39609030 64404 irq21: uhci1 21 0 cpu0: timer 344418159 560029 irq256: mps0 44097160 71702 irq257: em0 1140342912 1854216 irq258: em1 724215315 1177585 cpu1: timer 344386653 559978 cpu9: timer 344386682 559978 cpu8: timer 344386687 559978 cpu3: timer 344386670 559978 cpu6: timer 344386654 559978 cpu2: timer 344386597 559978 cpu11: timer 344386687 559978 cpu5: timer 344386682 559978 cpu10: timer 344386685 559978 cpu7: timer 344386647 559978 cpu4: timer 344386688 559978 Total 6080940352 9887707 ------------------------------------------------------------------------ pstat -T 106/131072 files 16M/30719M swap space ------------------------------------------------------------------------ pstat -s Device 512-blocks Used Avail Capacity /dev/ada0p3 62914304 34672 62879632 0% ------------------------------------------------------------------------ ----(to here)---- From owner-freebsd-stable@FreeBSD.ORG Wed Feb 22 14:43: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 513691065670 for ; Wed, 22 Feb 2012 14:43:58 +0000 (UTC) (envelope-from bra@fsn.hu) Received: from people.fsn.hu (people.fsn.hu [195.228.252.137]) by mx1.freebsd.org (Postfix) with ESMTP id A62948FC08 for ; Wed, 22 Feb 2012 14:43:57 +0000 (UTC) Received: by people.fsn.hu (Postfix, from userid 1001) id 07EB4C22E49; Wed, 22 Feb 2012 15:43:55 +0100 (CET) X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.2 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MF-ACE0E1EA [pR: 14.9993] X-CRM114-CacheID: sfid-20120222_15435_A7207EE8 X-CRM114-Status: Good ( pR: 14.9993 ) X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Wed Feb 22 15:43:55 2012 X-DSPAM-Confidence: 0.7012 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 4f44ff2b478181892546333 X-DSPAM-Factors: 27, From*Attila Nagy , 0.00010, ports, 0.00069, ports, 0.00069, wrote+>, 0.00163, >+>, 0.00261, >+>>, 0.00348, 0), 0.00425, timeout, 0.00468, timeout, 0.00468, wrote, 0.00475, 09), 0.00553, descriptor, 0.00553, descriptor, 0.00553, I+get, 0.00588, References*fsn.hu>, 0.00675, >+on, 0.00866, I/O, 0.01000, SCSI, 0.01000, byte, 0.01000, DOWN, 0.99000, DOWN, 0.99000, 2+ports, 0.01000, (on+the, 0.01000, Subject*Fatal, 0.01000, Received*22+Feb, 0.99000, forget+that, 0.01000, X-Spambayes-Classification: ham; 0.00 Received: from japan.t-online.private (japan.t-online.co.hu [195.228.243.99]) by people.fsn.hu (Postfix) with ESMTPSA id 08FCFC22E3C; Wed, 22 Feb 2012 15:43:55 +0100 (CET) Message-ID: <4F44FF2A.9050505@fsn.hu> Date: Wed, 22 Feb 2012 15:43:54 +0100 From: Attila Nagy User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.23) Gecko/20090817 Thunderbird/2.0.0.23 Mnenhy/0.7.6.0 MIME-Version: 1.0 To: pyunyh@gmail.com References: <4F449E0B.2040909@fsn.hu> <20120223041516.GI6861@michelle.cdnetworks.com> In-Reply-To: <20120223041516.GI6861@michelle.cdnetworks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org Subject: Re: Fatal trap 19, Stopped at bge_init_locked+ and bge booting problems X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Feb 2012 14:43:58 -0000 On 02/23/12 05:15, YongHyeon PYUN wrote: > bge0: mem > 0xf6bf0000-0xf6bfffff,0xf6be0000-0xf6beffff,0xf6bd0000-0xf6bdffff irq 32 > at device 0.0 on pci3 > bge0: CHIP ID 0x05719001; ASIC REV 0x5719; CHIP REV 0x57190; PCI-E > ^^^^^^^^^^ > > This controller is new one. Probably BCM5719 A1 but not sure. Yes, it's in a new machine. > >> bge0: Try again > This message indicates your controller has ASF/IPMI firmware. > Try disabling ASF and see whether it makes any difference. > (Change hw.bge.allow_asf tunable to 0). Oh, I always forget that (on the other machines this is set). This is what I get with machdep.panic_on_nmi: 0 machdep.kdb_on_nmi: 0 hw.bge.allow_asf: 0 bge0: mem 0xf6bf0000-0xf6bfffff,0xf6be0000-0xf6beffff,0xf6bd0000-0xf6bdffff irq 32 at device 0.0 on pci3 bge0: CHIP ID 0x05719001; ASIC REV 0x5719; CHIP REV 0x57190; PCI-E bge0: Try again miibus0: on bge0 ukphy0: PHY 1 on miibus0 ukphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow bge0: Ethernet address: 3c:4a:92:b2:3c:08 pci0:3:0:1: failed to read VPD data. bge1: mem 0xf6bc0000-0xf6bcffff,0xf6bb0000-0xf6bbffff,0xf6ba0000-0xf6baffff irq 36 at device 0.1 on pci3 bge1: CHIP ID 0x05719001; ASIC REV 0x5719; CHIP REV 0x57190; PCI-E miibus1: on bge1 brgphy0: PHY 2 on miibus1 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow bge1: Ethernet address: 3c:4a:92:b2:3c:09 pci0:3:0:2: failed to read VPD data. bge2: mem 0xf6b90000-0xf6b9ffff,0xf6b80000-0xf6b8ffff,0xf6b70000-0xf6b7ffff irq 32 at device 0.2 on pci3 bge2: CHIP ID 0x05719001; ASIC REV 0x5719; CHIP REV 0x57190; PCI-E miibus2: on bge2 brgphy1: PHY 3 on miibus2 brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow bge2: Ethernet address: 3c:4a:92:b2:3c:0a pci0:3:0:3: failed to read VPD data. bge3: mem 0xf6b60000-0xf6b6ffff,0xf6b50000-0xf6b5ffff,0xf6b40000-0xf6b4ffff irq 36 at device 0.3 on pci3 bge3: CHIP ID 0x05719001; ASIC REV 0x5719; CHIP REV 0x57190; PCI-E miibus3: on bge3 brgphy2: PHY 4 on miibus3 brgphy2: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow bge3: Ethernet address: 3c:4a:92:b2:3c:0b [...] da0: 286070MB (585871964 512 byte sectors: 255H 32S/T 65535C) NMI ISA 60, EISA ff I/O channel check, likely hardware failure.Sending DHCP Discover packet from interface bge0 (3c:4a:92:b2:3c:08) cd0 at ata3 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 bge0: 11 link states coalesced bge0: link state changed to DOWN ugen0.2: at usbus0 uhub3: on usbus0 bge1: 5 link states coalesced bge1: link state changed to DOWN bge2: link state changed to DOWN bge3: link state changed to DOWN bge0: ugen2.2: at usbus2 uhub4: on usbus2 2 link states coalesced bge0: link state changed to DOWN bge1: 4 link states coalesced bge1: link state changed to DOWN bge0: 4 link states coalesced bge0: link state changed to DOWN Sending DHCP Discover packet from interface bge1 (3c:4a:92:b2:3c:09) uhub3: 6 ports with 6 removable, self powered bge0: usb_alloc_device: set address 2 failed (USB_ERR_TIMEOUT, ignored) 6 link states coalesced bge0: link state changed to DOWN bge1: 2 link states coalesced bge1: link state changed to DOWN Sending DHCP Discover packet from interface bge2 (3c:4a:92:b2:3c:0a) bge0: 2 link states coalesced bge0: link state changed to DOWN bge1: usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT 10 link states coalesced bge1: link state changed to DOWN uhub4: 8 ports with 8 removable, self powered bge0: 4 link states coalesced bge0: link state changed to DOWN bge1: 2 link states coalesced bge1: link state changed to DOWN Sending DHCP Discover packet from interface bge3 (3c:4a:92:b2:3c:0b) bge0: 2 link states coalesced bge0: link state changed to DOWN bge1: 2 link states coalesced bge1: link state changed to DOWN ugen2.3: at usbus2 uhub5: on usbus2 bge0: watchdog timeout -- resetting bge0: link state changed to UP usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, ignored) bge1: 2 link states coalesced bge1: link state changed to DOWN uhub5: 2 ports with 1 removable, self powered bge0: link state changed to DOWN bge1: watchdog timeout -- resetting bge1: usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT 2 link states coalesced bge1: link state changed to DOWN bge0: 2 link states coalesced bge0: link state changed to DOWN ugen1.2: at usbus1 ukbd0: on usbus1 kbd2 at ukbd0 ums0: on usbus1 bge1: 4 link states coalesced bge1: link state changed to DOWN bge0: 2 link states coalesced bge0: link state changed to DOWN bge1: 2 link states coalesced bge1: link state changed to DOWN bge1: 3 link states coalesced bge1: link state changed to UP bge0: 2 link states coalesced bge0: link state changed to DOWN bge1: link state changed to DOWN bge0: 2 link states coalesced bge0: link state changed to DOWN bge1: 2 link states coalesced bge1: link state changed to DOWN bge1: 10 link states coalesced bge1: link state changed to DOWN bge0: 2 link states coalesced bge0: link state changed to DOWN bge1: 2 link states coalesced bge1: link state changed to DOWN bge1: link state changed to UP bge0: watchdog timeout -- resetting bge0: 2 link states coalesced bge0: link state changed to DOWN bge1: link state changed to DOWN bge1: watchdog timeout -- resetting bge1: 2 link states coalesced bge1: link state changed to DOWN bge0: 2 link states coalesced bge0: link state changed to DOWN bge1: 2 link states coalesced bge1: link state changed to DOWN bge1: 2 link states coalesced bge1: link state changed to DOWN bge0: 4 link states coalesced bge0: link state changed to DOWN bge1: 2 link states coalesced bge1: link state changed to DOWN bge0: 2 link states coalesced bge0: link state changed to DOWN bge1: 2 link states coalesced bge1: link state changed to DOWN bge0: 2 link states coalesced bge0: link state changed to DOWN bge1: link state changed to UP bge1: link state changed to DOWN [...] Still no go. From owner-freebsd-stable@FreeBSD.ORG Wed Feb 22 15:18: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 B48A11065689 for ; Wed, 22 Feb 2012 15:18:54 +0000 (UTC) (envelope-from slackbie@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 748E88FC1F for ; Wed, 22 Feb 2012 15:18:54 +0000 (UTC) Received: by iaeo4 with SMTP id o4so209026iae.13 for ; Wed, 22 Feb 2012 07:18:54 -0800 (PST) Received-SPF: pass (google.com: domain of slackbie@gmail.com designates 10.50.156.225 as permitted sender) client-ip=10.50.156.225; Authentication-Results: mr.google.com; spf=pass (google.com: domain of slackbie@gmail.com designates 10.50.156.225 as permitted sender) smtp.mail=slackbie@gmail.com; dkim=pass header.i=slackbie@gmail.com Received: from mr.google.com ([10.50.156.225]) by 10.50.156.225 with SMTP id wh1mr27243249igb.0.1329923934114 (num_hops = 1); Wed, 22 Feb 2012 07:18: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 :cc:content-type; bh=kYxRLkb+3wVGrgLUNInTBUxTFba9t8yN0QkPLz659TU=; b=Urb3z6jrqtQzUhmcWOjdKewiHxcVhWkFvHT9d2U0qntc5SXuuPkK3x0stCIDRlcrsK XBH0Ld0zEmFg/oLaYLMKClnR72md7hotjMmdxjzCXtBKHqHhxVRyLkCoqY3/5OHSp5Mc ixqTK8IGexxrCap8h1VSlkDDe7XM84qxYQp2U= MIME-Version: 1.0 Received: by 10.50.156.225 with SMTP id wh1mr21950744igb.0.1329922436289; Wed, 22 Feb 2012 06:53:56 -0800 (PST) Received: by 10.42.1.68 with HTTP; Wed, 22 Feb 2012 06:53:56 -0800 (PST) In-Reply-To: <20120222140308.Horde.RjSecpjmRSRPROeM24KCgsA@webmail.leidinger.net> References: <20120221143537.Horde.deyFDZjmRSRPQ52pxBIpnLA@webmail.leidinger.net> <1329890164178-5504219.post@n5.nabble.com> <20120222140308.Horde.RjSecpjmRSRPROeM24KCgsA@webmail.leidinger.net> Date: Wed, 22 Feb 2012 21:53:56 +0700 Message-ID: From: "~Lst" To: Alexander Leidinger Content-Type: text/plain; charset=ISO-8859-1 Cc: timp , freebsd-stable@freebsd.org Subject: Re: [CFT] modular kernel config X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Feb 2012 15:18:54 -0000 On Wed, Feb 22, 2012 at 8:03 PM, Alexander Leidinger wrote: > Quoting timp (from Tue, 21 Feb 2012 21:56:04 -0800 > (PST)): > >> Sorry, but for loader.conf you need use 'load' instead of 'enable' >> sed -e "s/enable/load/" loader.conf > > > [blush]fixed[/blush] > > Thanks, > Alexander. It's typo too .. net.inet.ip.stealth: IP stealth mode, no TTL decrementation on forwarding In your file's (i386|amd64)__SMALL_loader.conf : # Disable stealth forwarding and flowtable. net.inet.ip.stealt=0 net.inet6.ip6.stealt=0 Rgds, -- ~Lst From owner-freebsd-stable@FreeBSD.ORG Wed Feb 22 16:30: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 AB7AD106566B for ; Wed, 22 Feb 2012 16:30:27 +0000 (UTC) (envelope-from erichfreebsdlist@ovitrap.com) Received: from alogreentechnologies.com (alogreentechnologies.com [67.212.226.44]) by mx1.freebsd.org (Postfix) with ESMTP id 0BE218FC08 for ; Wed, 22 Feb 2012 16:30:26 +0000 (UTC) Received: from amd620.ovitrap.com ([49.128.188.2]) (authenticated bits=0) by alogreentechnologies.com (8.13.1/8.13.1) with ESMTP id q1MG0YSr032295 for ; Wed, 22 Feb 2012 09:00:36 -0700 From: Erich Dollansky To: stable@freebsd.org Date: Wed, 22 Feb 2012 23:00:40 +0700 User-Agent: KMail/1.13.7 (FreeBSD/8.3-PRERELEASE; KDE/4.7.4; amd64; ; ) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201202222300.40208.erichfreebsdlist@ovitrap.com> Cc: Subject: Firefox crash after upgrade to 8.3 as of yesterday X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Feb 2012 16:30:27 -0000 Hi, I installed 8.3 as of yesterday: uname says: FreeBSD AMD620.ovitrap.com 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #28: Tue Feb 21 17:15:07 WIT 2012 erich@AMD620.ovitrap.com:/usr/obj/usr/src/sys/AsusAMD620 amd64 Open i.e. www.freebsd.org with firefox and do one of the following to crash firefox: Right click on any link and try to open it in a new tab. Click on help --> About. Firefox worked on this machine the day before the upgrade without problems. What can I do to help locating the problem? Erich From owner-freebsd-stable@FreeBSD.ORG Wed Feb 22 16:58:42 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 32422106566C; Wed, 22 Feb 2012 16:58:42 +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 49FC28FC14; Wed, 22 Feb 2012 16:58:40 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAEAPQWRU+DaFvO/2dsb2JhbABBAxaFFq4igXMBAQEDAQEBARcJBCcgCwUWDgoRGQIEJQEJJgYIBwQBHASHYAmsVYo7iWMEgl8NBnWEZYESBgUKDxWCDYEWBIhPhgCEQYIokwuBNgg X-IronPort-AV: E=Sophos;i="4.73,464,1325480400"; d="scan'208";a="160532576" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 22 Feb 2012 11:29:40 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 1F53DB3F2F; Wed, 22 Feb 2012 11:29:40 -0500 (EST) Date: Wed, 22 Feb 2012 11:29:40 -0500 (EST) From: Rick Macklem To: Hiroki Sato Message-ID: <810873252.1742743.1329928180108.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <20120222.233814.1255848524636250830.hrs@allbsd.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1742742_1830441393.1329928180106" 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: stable@FreeBSD.org, John Baldwin Subject: Re: panic in 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: Wed, 22 Feb 2012 16:58:42 -0000 ------=_Part_1742742_1830441393.1329928180106 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Hiroki Sato wrote: > Hi, > > Just a report, but I got the following panic on an NFS server running > 8.3-PRERELEASE: > > ----(from here)---- > pool.allbsd.org dumped core - see /var/crash/vmcore.0 > > Tue Feb 21 10:59:44 JST 2012 > > FreeBSD pool.allbsd.org 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #7: Thu > Feb 16 19:29:19 JST 2012 hrs@pool.allbsd.org:/usr/obj/usr/src/sys/POOL > amd64 > > panic: Assertion lock == sq->sq_lock failed at > /usr/src/sys/kern/subr_sleepqueue.c:335 > Oops, I didn't know that mixing msleep() and tsleep() calls on the same event wasn't allowed. There are two places in the code where it did a: mtx_unlock(); tsleep(); left over from the days when it was written for OpenBSD. I don't think the mix would actually break anything, except that the MPASS() assertion fails, but I've cc'd jhb@ since he seems to have been the author of the sleep() stuff. Anyhow, please try the attached patch which replaces the mtx_unlock(); tsleep(); with msleep()s using PDROP. If the attachment gets lost, the patch is also here: http://people.freebsd.org/~rmacklem/tsleep.patch Thanks for reporting this, rick ps: Is mtx_lock() now preferred over msleep()? > 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"... > > Unread portion of the kernel message buffer: > > > Reading symbols from /boot/kernel/geom_mirror.ko...Reading symbols > from /boot/kernel/geom_mirror.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/geom_mirror.ko > Reading symbols from /boot/kernel/zfs.ko...Reading symbols from > /boot/kernel/zfs.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/zfs.ko > Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols > from /boot/kernel/opensolaris.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/opensolaris.ko > Reading symbols from /boot/kernel/ipfw.ko...Reading symbols from > /boot/kernel/ipfw.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/ipfw.ko > #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:263 > 263 if (textdump_pending) > (kgdb) #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:263 > #1 0xffffffff801f8cfc in db_fncall (dummy1=Variable "dummy1" is not > available. > ) > at /usr/src/sys/ddb/db_command.c:548 > #2 0xffffffff801f9031 in db_command (last_cmdp=0xffffffff80d37f40, > cmd_table=Variable "cmd_table" is not available. > ) > at /usr/src/sys/ddb/db_command.c:445 > #3 0xffffffff801f9280 in db_command_loop () > at /usr/src/sys/ddb/db_command.c:498 > #4 0xffffffff801fb369 in db_trap (type=Variable "type" is not > available. > ) at /usr/src/sys/ddb/db_main.c:229 > #5 0xffffffff8069e021 in kdb_trap (type=3, code=0, > tf=0xffffff86c5f7e640) > at /usr/src/sys/kern/subr_kdb.c:548 > #6 0xffffffff80946766 in trap (frame=0xffffff86c5f7e640) > at /usr/src/sys/amd64/amd64/trap.c:595 > #7 0xffffffff8092d324 in calltrap () > at /usr/src/sys/amd64/amd64/exception.S:228 > #8 0xffffffff8069de7b in kdb_enter (why=0xffffffff80a891dd "panic", > msg=0xa
) at cpufunc.h:63 > #9 0xffffffff8066afc0 in panic (fmt=Variable "fmt" is not available. > ) at /usr/src/sys/kern/kern_shutdown.c:597 > #10 0xffffffff806a9360 in sleepq_add (wchan=0xffffff0073b97a00, > lock=0xffffffff80d6af00, wmesg=0xffffffff80a7bb28 "nfsrc", flags=0, > queue=0) at /usr/src/sys/kern/subr_sleepqueue.c:335 > #11 0xffffffff80673e4f in _sleep (ident=0xffffff0073b97a00, > lock=0xffffffff80d6af00, priority=Variable "priority" is not > available. > ) at /usr/src/sys/kern/kern_synch.c:218 > #12 0xffffffff805fe01e in nfsrvd_updatecache (nd=0xffffff86c5f7e960, > so=0xffffff002217c000) at > /usr/src/sys/fs/nfsserver/nfs_nfsdcache.c:697 > #13 0xffffffff805ea934 in nfssvc_program (rqst=0xffffff0476070800, > xprt=0xffffff000edd0a00) at > /usr/src/sys/fs/nfsserver/nfs_nfsdkrpc.c:333 > #14 0xffffffff8084c76b in svc_run_internal (pool=0xffffff000c876600, > ismaster=0) at /usr/src/sys/rpc/svc.c:895 > #15 0xffffffff8084cc8b in svc_thread_start (arg=Variable "arg" is not > available. > ) > at /usr/src/sys/rpc/svc.c:1200 > #16 0xffffffff80640865 in fork_exit ( > callout=0xffffffff8084cc80 , arg=0xffffff000c876600, > frame=0xffffff86c5f7ec50) at /usr/src/sys/kern/kern_fork.c:876 > #17 0xffffffff8092d86e in fork_trampoline () > at /usr/src/sys/amd64/amd64/exception.S:602 > #18 0x0000000000000080 in ?? () > #19 0x00007fffffffe700 in ?? () > #20 0x000000000000002e in ?? () > #21 0x0000000000000000 in ?? () > #22 0xfffffffffffffef4 in ?? () > #23 0xffffff000e1028c0 in ?? () > #24 0x000000000000009b in ?? () > #25 0x00007fffffffe700 in ?? () > #26 0x0000000000000006 in ?? () > #27 0x0000000000000003 in ?? () > #28 0x00000000ffffffff in ?? () > #29 0x00007fffffffe720 in ?? () > #30 0x0000000000000000 in ?? () > #31 0x0000000000000000 in ?? () > #32 0x0000000000000001 in ?? () > #33 0x001b00130000000c in ?? () > #34 0x00007fffffffffe8 in ?? () > #35 0x003b003b00000001 in ?? () > #36 0x0000000000000002 in ?? () > #37 0x00000008006a1dac in ?? () > #38 0x0000000000000043 in ?? () > #39 0x0000000000000202 in ?? () > #40 0x00007fffffffe6c8 in ?? () > #41 0x000000000000003b in ?? () > #42 0xffffff0022262470 in ?? () > #43 0x0000000000000000 in ?? () > #44 0xffffffff80d80e40 in tdq_cpu () > #45 0xffffff00057958c0 in ?? () > #46 0xffffff86c5f7e930 in ?? () > #47 0xffffff86c5f7e8d8 in ?? () > #48 0xffffff002218c8c0 in ?? () > #49 0xffffffff80691397 in sched_switch (td=0xffffff000c876600, > newtd=0xffffffff8084cc80, flags=Variable "flags" is not available. > ) at /usr/src/sys/kern/sched_ule.c:1861 > Previous frame inner to this frame (corrupt stack?) > (kgdb) > > ------------------------------------------------------------------------ > ps -axl > > UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME COMMAND > 0 0 0 0 -8 0 0 0 - DLs ?? 138141186720:38.04 [kernel] > 0 1 0 0 46 0 3200 0 wait DLs ?? 32872919:34.00 [init] > 0 2 0 0 -8 0 0 0 - DL ?? 2384800:02.00 [g_event] > 0 3 0 0 -8 0 0 0 - DL ?? 34443954063:22.00 [g_up] > 0 4 0 0 -8 0 0 0 - DL ?? 52261177097:30.00 [g_down] > 0 5 0 0 -16 0 0 0 mps_sc DL ?? 22268598:50.00 [mps_scan0] > 0 6 0 0 -16 0 0 0 waitin DL ?? 1938:00.00 [sctp_itera > 0 7 0 0 -16 0 0 0 ccb_sc DL ?? 0:00.00 [xpt_thrd] > 0 8 0 0 -16 0 0 0 zfs:lo DL ?? 279189757877:10.00 [pagedaemon > 0 9 0 0 -16 0 0 0 psleep DL ?? 30647760:24.00 [vmdaemon] > 0 10 0 0 -16 0 0 0 audit_ DL ?? 0:00.00 [audit] > 0 11 0 0 171 0 0 0 - RL ?? 98310602660:37.92 [idle] > 0 12 0 0 -60 0 0 0 - WL ?? 128367001717:26.00 [intr] > 0 13 0 0 -16 0 0 0 - DL ?? 13126281049:04.00 [yarrow] > 0 14 0 0 -40 0 0 0 - DL ?? 355171576:34.00 [usb] > 0 15 0 0 76 0 0 0 pgzero DL ?? 83753:16.00 [pagezero] > 0 16 0 0 -16 0 0 0 psleep DL ?? 28138575:06.00 [bufdaemon] > 0 17 0 0 47 0 0 0 vlruwt DL ?? 4907694216:30.00 [vnlru] > 0 18 0 0 20 0 0 0 vmwait DL ?? 25925591442:54.00 [syncer] > 0 19 0 0 -16 0 0 0 sdflus DL ?? 275943437:00.00 [softdepflu > 0 20 0 0 -8 0 0 0 m:w1 DL ?? 210842046:32.00 [g_mirror g > 0 60 0 0 -8 0 0 0 zio->i DL ?? 178867118477:46.00 [zfskern] > 0 110 0 0 -8 0 0 0 mdwait DL ?? 99721:48.00 [md0] > 0 150 1 0 76 0 5832 40 pause DWs ?? 0:00.00 [adjkerntz] > 0 735 1 0 44 0 6920 0 pfault DLs ?? 55753471:38.00 [syslogd] > 0 805 1 0 44 0 7976 0 pfault DLs ?? 42986590:04.00 [rpcbind] > 0 840 1 0 76 0 6920 0 select Ds ?? 65452:44.00 [mountd] > 0 858 1 0 76 0 5832 40 pause DWs ?? 0:00.00 [nfsuserd] > 0 859 858 0 44 0 5832 0 pfault DL ?? 25445708:36.00 [nfsuserd] > 0 860 858 0 44 0 5832 0 pfault DL ?? 26084710:00.00 [nfsuserd] > 0 861 858 0 44 0 5832 0 pfault DL ?? 25778143:28.00 [nfsuserd] > 0 862 858 0 44 0 5832 0 pfault DL ?? 25787518:58.00 [nfsuserd] > 0 864 1 0 4 0 5828 0 pfault DLs ?? 5920534:50.00 [nfsd] > 0 865 864 0 44 0 5828 0 tx->tx D ?? 86066872402:20.97 [nfsd] > 0 868 1 0 44 0 269036 0 pfault DLs ?? 24517994:48.00 [rpc.statd] > 0 871 1 0 44 0 7976 0 rpcsvc Ds ?? 6817289856:50.00 [rpc.lockd] > 0 907 1 0 44 0 11804 0 pfault DLs ?? 992700928:44.00 [ntpd] > 1 915 1 0 44 0 5828 0 - WWs ?? 0:00.00 [rwhod] > 0 926 1 0 44 0 20908 0 pfault DLs ?? 2969327208:22.00 [perl5.10.1 > 0 1015 1 0 4 0 26172 0 pfault DLs ?? 27567638:00.00 [sshd] > 0 1046 1 0 44 0 12024 0 pfault DLs ?? 672303813:46.00 [sendmail] > 25 1059 1 0 44 0 12024 0 - WWs ?? 0:00.00 [sendmail] > 0 1073 1 0 44 0 7976 0 - WWs ?? 0:00.00 [cron] > 0 1165 1 0 76 0 6916 0 ttyin Ds+ ?? 84842:48.00 [getty] > 0 1166 1 0 76 0 6916 0 ttyin Ds+ ?? 76490:46.00 [getty] > 0 1167 1 0 44 0 6916 0 ttyin Ds+ ?? 87267:10.00 [getty] > 0 1169 1015 0 45 0 29808 112 sbwait DWs ?? 0:00.00 [sshd] > 20001 1171 1169 0 44 0 29808 0 select D ?? 1745296:04.00 [sshd] > 20001 1172 1171 0 44 0 10336 0 ttyin Ds+ ?? 2023326:04.00 [tcsh] > > ------------------------------------------------------------------------ > vmstat -s > > 2457092079 cpu context switches > 1948268860 device interrupts > 114326248 software interrupts > 94980728 traps > 57483687 system calls > 22 kernel threads created > 288912 fork() calls > 1543 vfork() calls > 0 rfork() calls > 1942408 swap pager pageins > 2087687 swap pager pages paged in > 10577326 swap pager pageouts > 11536354 swap pager pages paged out > 419067 vnode pager pageins > 536269 vnode pager pages paged in > 5 vnode pager pageouts > 5 vnode pager pages paged out > 23209842 page daemon wakeups > 1235694508 pages examined by the page daemon > 48357847 pages reactivated > 19134152 copy-on-write faults > 6670 copy-on-write optimized faults > 14214203 zero fill pages zeroed > 1133 zero fill pages prezeroed > 2094959 intransit blocking page faults > 92125016 total VM faults taken > 0 pages affected by kernel thread creation > 75840248 pages affected by fork() > 430154 pages affected by vfork() > 0 pages affected by rfork() > 58565695 pages cached > 981678745 pages freed > 8 pages freed by daemon > 19820409 pages freed by exiting processes > 0 pages active > 0 pages inactive > 0 pages in VM cache > 6092264 pages wired down > 0 pages free > 4096 bytes per page > 556146802 total name lookups > cache hits (11% pos + 1% neg) system 0% per-directory > deletions 0%, falsehits 0%, toolong 0% > > ------------------------------------------------------------------------ > vmstat -m > > Type InUse MemUse HighUse Requests Size(s) > isadev 6 1K - 6 128 > ata_pci 2 1K - 2 64 > acpidev 106 7K - 106 64 > cdev 8 2K - 8 256 > entropy 1024 64K - 1024 64 > sigio 1 1K - 1 64 > filedesc 51 27K - 290480 512,1024 > kenv 117 12K - 125 16,32,64,128 > kqueue 0 0K - 296 256,2048 > proc-args 27 2K - 227134 16,32,64,128,256 > hhook 2 1K - 2 128 > ithread 151 26K - 151 32,128,256 > KTRACE 100 13K - 100 128 > linker 194 882K - 220 16,32,64,128,256,512,1024,2048,4096 > lockf 20 3K - 572 64,128 > ip6ndp 19 2K - 23 64,128 > temp 112 28K - 276586783 16,32,64,128,256,512,1024,2048,4096 > devbuf 5153 17331K - 8647 16,32,64,128,256,512,1024,2048,4096 > module 432 54K - 432 128 > mtx_pool 2 16K - 2 > osd 259 5K - 260 16,64 > subproc 1971 1157K - 292401 512,4096 > proc 2 16K - 2 > session 21 3K - 38828 128 > pgrp 21 3K - 38840 128 > cred 624 98K - 3107692200 64,256 > uidinfo 5 3K - 74066 128,2048 > plimit 9 3K - 19773 256 > UART 6 4K - 6 16,512,1024 > sysctltmp 0 0K - 11884 16,32,64,128,256,4096 > sysctloid 7764 385K - 7945 16,32,64,128 > sysctl 0 0K - 238540 16,32,64 > callout 11 5632K - 11 > umtx 2688 336K - 2688 128 > p1003.1b 1 1K - 1 16 > SWAP 2 4373K - 2 64 > SCSI SES 1 2K - 1 2048 > bus-sc 146 437K - 8556 16,32,64,128,256,512,1024,2048,4096 > bus 2313 424K - 13021 16,32,64,128,256,512,1024,2048 > devstat 40 81K - 40 32,4096 > eventhandler 81 7K - 81 64,128 > ddb_capture 1 48K - 1 > kobj 299 1196K - 463 4096 > Per-cpu 1 1K - 1 32 > pci_link 16 2K - 16 64,128 > rman 250 31K - 750 16,32,128 > acpi_perf 12 3K - 12 256 > sbuf 0 0K - 3404 16,32,64,128,256,512,1024,2048,4096 > acpica 5270 577K - 101779 16,32,64,128,256,512,1024,2048 > stack 0 0K - 2 256 > taskqueue 75 7K - 105 16,32,64,128,1024 > Unitno 12 1K - 368 32,64 > USBdev 40 12K - 40 64,128,512,1024 > USB 66 36K - 68 16,32,64,128,256,2048,4096 > kbdmux 7 10K - 7 16,512,1024,2048,4096 > Witness 1 128K - 1 > iov 0 0K - 18370 16,64,128,256,512 > select 1679 210K - 1679 128 > ioctlops 0 0K - 332354 16,32,64,128,256,512,1024 > msg 4 30K - 4 2048,4096 > sem 4 11K - 4 512,1024 > shm 1 20K - 1 > tty 22 22K - 24 1024,2048 > pts 1 1K - 1 256 > mbuf_tag 8 1K - 61159597 32,128 > ksem 1 8K - 1 > shmfd 1 8K - 1 > LED 8 1K - 8 16,128 > pcb 35 157K - 14585 16,32,128,1024,2048,4096 > soname 7 1K - 3119925 16,32,128 > acl 0 0K - 5960255 4096 > biobuf 0 0K - 6 2048 > vfscache 1 4096K - 1 > cl_savebuf 0 0K - 1556 64,128 > export_host 166 42K - 166 256 > vfs_hash 1 2048K - 1 > vnodes 2 1K - 2 256 > md_disk 1 2K - 1 2048 > vnodemarker 0 0K - 126408 512 > mount 255 15K - 8568 16,32,64,128,256,512 > BPF 14 2K - 14 128 > ether_multi 78 5K - 92 16,32,64 > ifaddr 131 30K - 131 32,64,128,256,512,4096 > ifnet 15 29K - 15 128,2048 > clone 6 24K - 6 4096 > arpcom 5 1K - 5 16 > lltable 63 23K - 177 256,512 > acpitask 1 2K - 1 2048 > CAM queue 45 27K - 3661 16,32,64,128,256,512,1024,2048 > mps 27 464K - 142 16,32,64,128,256,512,1024,2048,4096 > acpisem 16 2K - 16 128 > routetbl 194 76K - 7875 32,64,128,256,512 > igmp 14 4K - 14 256 > CAM SIM 6 2K - 6 256 > CAM periph 30 8K - 543 16,32,64,128,256 > DEVFS1 175 88K - 195 512 > in_multi 3 1K - 3 256 > sctp_iter 0 0K - 5 256 > sctp_ifn 3 1K - 3 128 > sctp_ifa 9 2K - 9 128 > sctp_vrf 1 1K - 1 64 > sctp_a_it 0 0K - 5 16 > hostcache 1 28K - 1 > syncache 1 96K - 1 > DEVFS3 201 51K - 222 256 > ip6_moptions 2 1K - 2 32,256 > in6_multi 41 5K - 41 32,256 > in6_mfilter 1 1K - 1 1024 > DEVFS 20 1K - 21 16,128 > mld 14 2K - 14 128 > NLM 2 4K - 3 32,2048 > rpc 498 295K - 3136399322 16,32,64,128,256,512,1024,2048 > audit_evclass 172 6K - 211 32 > savedino 0 0K - 381 256 > dirrem 0 0K - 2552 64 > mkdir 0 0K - 12 64 > diradd 0 0K - 2556 64 > freefile 0 0K - 457 64 > freeblks 0 0K - 492 256 > freefrag 0 0K - 3510 64 > allocindir 0 0K - 1576357 128 > indirdep 0 0K - 1989 64 > allocdirect 0 0K - 904 256 > bmsafemap 0 0K - 2063 128 > newblk 1 1K - 1577262 64,512 > inodedep 1 2048K - 3097 256 > pagedep 1 512K - 433 128 > ufs_dirhash 307 154K - 37379 16,32,64,128,256,512 > ufs_mount 16 45K - 25 128,512,2048,4096 > UMAHash 3 4101K - 20 512,1024,2048,4096 > vm_pgdata 2 129K - 2 128 > io_apic 2 4K - 2 2048 > memdesc 1 4K - 1 4096 > NFSD usrgroup 76 10K - 76 128 > atkbddev 2 1K - 2 64 > NFSD string 1 1K - 1 16 > NFSD srvcache 406 51K - 1548524470 128 > pfs_nodes 21 6K - 21 256 > CAM XPT 661 1112K - 3885 16,32,64,128,256,1024,2048 > GEOM 466 92K - 2728 16,32,64,128,256,512,1024 > scsi_da 0 0K - 366 16 > CAM dev queue 6 1K - 6 128 > qpidrv 1 1K - 1 16 > MCA 13 2K - 13 128 > msi 9 2K - 9 128 > nexusdev 4 1K - 4 16 > mirror_data 3 1K - 39945 64,128,512 > solaris 11691962 13925065K - 2722517546 > 16,32,64,128,256,512,1024,2048,4096 > kstat_data 4 1K - 4 64 > IpFw/IpAcct 36 5K - 70 16,32,64,128,256,512 > > ------------------------------------------------------------------------ > vmstat -z > > ITEM SIZE LIMIT USED FREE REQUESTS FAILURES > > UMA Kegs: 208, 0, 184, 3, 184, 0 > UMA Zones: 576, 0, 184, 2, 184, 0 > UMA Slabs: 568, 0, 1204399, 868, 136164851, 2 > UMA RCntSlabs: 568, 0, 3007, 458, 59379755, 0 > UMA Hash: 256, 0, 78, 12, 81, 0 > 16 Bucket: 152, 0, 43, 132, 202, 0 > 32 Bucket: 280, 0, 156, 82, 431, 0 > 64 Bucket: 536, 0, 109, 66, 635, 52 > 128 Bucket: 1048, 0, 894, 150, 42524901, 249667 > VM OBJECT: 216, 0, 217809, 134145, 205023219, 0 > MAP: 232, 0, 7, 25, 7, 0 > KMAP ENTRY: 120, 786222, 34101, 66711, 356681687, 0 > MAP ENTRY: 120, 0, 626, 2071, 13286492, 0 > DP fakepg: 120, 0, 0, 0, 0, 0 > SG fakepg: 120, 0, 0, 0, 0, 0 > mt_zone: 2056, 0, 287, 35, 287, 0 > 16: 16, 0, 1675440, 672528, 260550357, 0 > 32: 32, 0, 2194930, 308254, 295507810, 0 > 64: 64, 0, 2752681, 166207, 2445436087, 0 > 128: 128, 0, 599877, 103663, 2012557000, 0 > 256: 256, 0, 130698, 1767, 1910531783, 0 > 512: 512, 0, 3600727, 170355, 632542169, 0 > 1024: 1024, 0, 41809, 1419, 17651556, 0 > 2048: 2048, 0, 45994, 1520, 3137694214, 0 > 4096: 4096, 0, 217698, 1305, 22805804, 0 > Files: 80, 0, 106, 1964, 5239206, 0 > TURNSTILE: 136, 0, 2689, 191, 2689, 0 > umtx pi: 96, 0, 0, 0, 0, 0 > MAC labels: 40, 0, 0, 0, 0, 0 > PROC: 1136, 0, 48, 1872, 290477, 0 > THREAD: 1120, 0, 2444, 244, 2602, 0 > SLEEPQUEUE: 88, 0, 2689, 240, 2689, 0 > VMSPACE: 392, 0, 27, 1833, 290457, 0 > cpuset: 72, 0, 2, 98, 2, 0 > audit_record: 952, 0, 0, 0, 0, 0 > mbuf_packet: 256, 0, 3463, 571, 3053225165, 14877915 > mbuf: 256, 0, 886, 718, 13477896975, 532 > mbuf_cluster: 2048, 25600, 4367, 791, 2946391169, 14863813 > mbuf_jumbo_page: 4096, 12800, 0, 422, 4199, 0 > mbuf_jumbo_9k: 9216, 19200, 0, 0, 0, 0 > mbuf_jumbo_16k: 16384, 12800, 0, 0, 0, 0 > mbuf_ext_refcnt: 4, 0, 0, 0, 0, 0 > g_bio: 232, 0, 0, 1232, 275916552, 0 > ttyinq: 160, 0, 225, 183, 630, 0 > ttyoutq: 256, 0, 117, 168, 327, 0 > ata_request: 328, 0, 1, 803, 40002602, 0 > ata_composite: 336, 0, 0, 0, 0, 0 > VNODE: 472, 0, 215060, 72084, 386781863, 0 > VNODEPOLL: 112, 0, 0, 0, 0, 0 > NAMEI: 1024, 0, 1944818, 1394, 534155455, 0 > S VFS Cache: 108, 0, 211506, 103644, 467683632, 0 > L VFS Cache: 328, 0, 493, 6683, 9684321, 0 > DIRHASH: 1024, 0, 0, 1756, 50430, 0 > NCLNODE: 600, 0, 0, 0, 0, 0 > pipe: 728, 0, 1, 1634, 236978, 0 > ksiginfo: 112, 0, 1913, 1420, 16178, 0 > itimer: 344, 0, 1, 32, 2, 0 > KNOTE: 128, 0, 0, 290, 296, 0 > socket: 680, 25602, 95, 475, 49127, 11600 > unpcb: 240, 25600, 10, 486, 8807, 0 > ipq: 56, 819, 0, 0, 0, 0 > udp_inpcb: 336, 25608, 28, 258, 27781, 0 > udpcb: 16, 25704, 28, 1652, 27781, 0 > tcp_inpcb: 336, 25608, 56, 681, 9316, 0 > tcpcb: 944, 25600, 56, 296, 9316, 0 > tcptw: 72, 5150, 0, 800, 1020, 0 > syncache: 144, 15366, 10, 224, 10161216, 0 > hostcache: 136, 15372, 13, 295, 92, 0 > tcpreass: 40, 1680, 0, 1428, 31283, 0 > sackhole: 32, 0, 0, 2525, 263849, 0 > sctp_ep: 1304, 25602, 0, 0, 0, 0 > sctp_asoc: 2288, 40000, 0, 0, 0, 0 > sctp_laddr: 48, 80064, 0, 216, 8, 0 > sctp_raddr: 696, 80000, 0, 0, 0, 0 > sctp_chunk: 136, 400008, 0, 0, 0, 0 > sctp_readq: 104, 400032, 0, 0, 0, 0 > sctp_stream_msg_out: 112, 400026, 0, 0, 0, 0 > sctp_asconf: 40, 400008, 0, 0, 0, 0 > sctp_asconf_ack: 48, 400032, 0, 0, 0, 0 > ripcb: 336, 25608, 0, 231, 3216, 0 > rtentry: 200, 0, 28, 29, 28, 0 > selfd: 56, 0, 2191, 1778, 2855424, 0 > SWAPMETA: 288, 116519, 511, 2349, 2187939, 0 > Mountpoints: 752, 0, 12, 13, 12, 0 > FFS inode: 168, 0, 85761, 96377, 974750, 0 > FFS1 dinode: 128, 0, 0, 0, 0, 0 > FFS2 dinode: 256, 0, 85761, 94059, 974103, 0 > taskq_zone: 48, 0, 0, 2232, 661225, 0 > zio_cache: 880, 0, 122, 1042, 488025233, 0 > zio_link_cache: 48, 0, 104, 1048, 314016714, 0 > zio_buf_512: 512, 0, 0, 0, 0, 0 > zio_data_buf_512: 512, 0, 0, 0, 0, 0 > zio_buf_1024: 1024, 0, 0, 0, 0, 0 > zio_data_buf_1024: 1024, 0, 0, 0, 0, 0 > zio_buf_1536: 1536, 0, 0, 0, 0, 0 > zio_data_buf_1536: 1536, 0, 0, 0, 0, 0 > zio_buf_2048: 2048, 0, 0, 0, 0, 0 > zio_data_buf_2048: 2048, 0, 0, 0, 0, 0 > zio_buf_2560: 2560, 0, 0, 0, 0, 0 > zio_data_buf_2560: 2560, 0, 0, 0, 0, 0 > zio_buf_3072: 3072, 0, 0, 0, 0, 0 > zio_data_buf_3072: 3072, 0, 0, 0, 0, 0 > zio_buf_3584: 3584, 0, 0, 0, 0, 0 > zio_data_buf_3584: 3584, 0, 0, 0, 0, 0 > zio_buf_4096: 4096, 0, 0, 0, 0, 0 > zio_data_buf_4096: 4096, 0, 0, 0, 0, 0 > zio_buf_5120: 5120, 0, 0, 0, 0, 0 > zio_data_buf_5120: 5120, 0, 0, 0, 0, 0 > zio_buf_6144: 6144, 0, 0, 0, 0, 0 > zio_data_buf_6144: 6144, 0, 0, 0, 0, 0 > zio_buf_7168: 7168, 0, 0, 0, 0, 0 > zio_data_buf_7168: 7168, 0, 0, 0, 0, 0 > zio_buf_8192: 8192, 0, 0, 0, 0, 0 > zio_data_buf_8192: 8192, 0, 0, 0, 0, 0 > zio_buf_10240: 10240, 0, 0, 0, 0, 0 > zio_data_buf_10240: 10240, 0, 0, 0, 0, 0 > zio_buf_12288: 12288, 0, 0, 0, 0, 0 > zio_data_buf_12288: 12288, 0, 0, 0, 0, 0 > zio_buf_14336: 14336, 0, 0, 0, 0, 0 > zio_data_buf_14336: 14336, 0, 0, 0, 0, 0 > zio_buf_16384: 16384, 0, 0, 0, 0, 0 > zio_data_buf_16384: 16384, 0, 0, 0, 0, 0 > zio_buf_20480: 20480, 0, 0, 0, 0, 0 > zio_data_buf_20480: 20480, 0, 0, 0, 0, 0 > zio_buf_24576: 24576, 0, 0, 0, 0, 0 > zio_data_buf_24576: 24576, 0, 0, 0, 0, 0 > zio_buf_28672: 28672, 0, 0, 0, 0, 0 > zio_data_buf_28672: 28672, 0, 0, 0, 0, 0 > zio_buf_32768: 32768, 0, 0, 0, 0, 0 > zio_data_buf_32768: 32768, 0, 0, 0, 0, 0 > zio_buf_36864: 36864, 0, 0, 0, 0, 0 > zio_data_buf_36864: 36864, 0, 0, 0, 0, 0 > zio_buf_40960: 40960, 0, 0, 0, 0, 0 > zio_data_buf_40960: 40960, 0, 0, 0, 0, 0 > zio_buf_45056: 45056, 0, 0, 0, 0, 0 > zio_data_buf_45056: 45056, 0, 0, 0, 0, 0 > zio_buf_49152: 49152, 0, 0, 0, 0, 0 > zio_data_buf_49152: 49152, 0, 0, 0, 0, 0 > zio_buf_53248: 53248, 0, 0, 0, 0, 0 > zio_data_buf_53248: 53248, 0, 0, 0, 0, 0 > zio_buf_57344: 57344, 0, 0, 0, 0, 0 > zio_data_buf_57344: 57344, 0, 0, 0, 0, 0 > zio_buf_61440: 61440, 0, 0, 0, 0, 0 > zio_data_buf_61440: 61440, 0, 0, 0, 0, 0 > zio_buf_65536: 65536, 0, 0, 0, 0, 0 > zio_data_buf_65536: 65536, 0, 0, 0, 0, 0 > zio_buf_69632: 69632, 0, 0, 0, 0, 0 > zio_data_buf_69632: 69632, 0, 0, 0, 0, 0 > zio_buf_73728: 73728, 0, 0, 0, 0, 0 > zio_data_buf_73728: 73728, 0, 0, 0, 0, 0 > zio_buf_77824: 77824, 0, 0, 0, 0, 0 > zio_data_buf_77824: 77824, 0, 0, 0, 0, 0 > zio_buf_81920: 81920, 0, 0, 0, 0, 0 > zio_data_buf_81920: 81920, 0, 0, 0, 0, 0 > zio_buf_86016: 86016, 0, 0, 0, 0, 0 > zio_data_buf_86016: 86016, 0, 0, 0, 0, 0 > zio_buf_90112: 90112, 0, 0, 0, 0, 0 > zio_data_buf_90112: 90112, 0, 0, 0, 0, 0 > zio_buf_94208: 94208, 0, 0, 0, 0, 0 > zio_data_buf_94208: 94208, 0, 0, 0, 0, 0 > zio_buf_98304: 98304, 0, 0, 0, 0, 0 > zio_data_buf_98304: 98304, 0, 0, 0, 0, 0 > zio_buf_102400: 102400, 0, 0, 0, 0, 0 > zio_data_buf_102400: 102400, 0, 0, 0, 0, 0 > zio_buf_106496: 106496, 0, 0, 0, 0, 0 > zio_data_buf_106496: 106496, 0, 0, 0, 0, 0 > zio_buf_110592: 110592, 0, 0, 0, 0, 0 > zio_data_buf_110592: 110592, 0, 0, 0, 0, 0 > zio_buf_114688: 114688, 0, 0, 0, 0, 0 > zio_data_buf_114688: 114688, 0, 0, 0, 0, 0 > zio_buf_118784: 118784, 0, 0, 0, 0, 0 > zio_data_buf_118784: 118784, 0, 0, 0, 0, 0 > zio_buf_122880: 122880, 0, 0, 0, 0, 0 > zio_data_buf_122880: 122880, 0, 0, 0, 0, 0 > zio_buf_126976: 126976, 0, 0, 0, 0, 0 > zio_data_buf_126976: 126976, 0, 0, 0, 0, 0 > zio_buf_131072: 131072, 0, 0, 0, 0, 0 > zio_data_buf_131072: 131072, 0, 0, 0, 0, 0 > sa_cache: 80, 0, 129266, 27244, 385801818, 0 > dnode_t: 856, 0, 3449429, 67491, 28031304, 0 > dmu_buf_impl_t: 224, 0, 4169264, 253694, 64122423, 0 > arc_buf_hdr_t: 216, 0, 2429176, 277376, 13824588, 0 > arc_buf_t: 104, 0, 883770, 96294, 36277716, 0 > zil_lwb_cache: 192, 0, 6, 2054, 2397885, 0 > zfs_znode_cache: 400, 0, 129266, 21628, 385801818, 0 > IPFW dynamic rule: 120, 0, 0, 0, 0, 0 > > > ------------------------------------------------------------------------ > vmstat -i > > interrupt total rate > irq0: 1 0 > stray irq0 1 0 > irq3: uart1 4419 7 > irq18: ehci0 uhci5 2 0 > irq19: uhci2 uhci4* 39609030 64404 > irq21: uhci1 21 0 > cpu0: timer 344418159 560029 > irq256: mps0 44097160 71702 > irq257: em0 1140342912 1854216 > irq258: em1 724215315 1177585 > cpu1: timer 344386653 559978 > cpu9: timer 344386682 559978 > cpu8: timer 344386687 559978 > cpu3: timer 344386670 559978 > cpu6: timer 344386654 559978 > cpu2: timer 344386597 559978 > cpu11: timer 344386687 559978 > cpu5: timer 344386682 559978 > cpu10: timer 344386685 559978 > cpu7: timer 344386647 559978 > cpu4: timer 344386688 559978 > Total 6080940352 9887707 > > ------------------------------------------------------------------------ > pstat -T > > 106/131072 files > 16M/30719M swap space > > ------------------------------------------------------------------------ > pstat -s > > Device 512-blocks Used Avail Capacity > /dev/ada0p3 62914304 34672 62879632 0% > > ------------------------------------------------------------------------ > ----(to here)---- > _______________________________________________ > 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" ------=_Part_1742742_1830441393.1329928180106 Content-Type: text/x-patch; name=tsleep.patch Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=tsleep.patch LS0tIGZzL25mc3NlcnZlci9uZnNfbmZzZGNhY2hlLmMuc2F2CTIwMTItMDItMjIgMTA6NTU6MTcu MDAwMDAwMDAwIC0wNTAwCisrKyBmcy9uZnNzZXJ2ZXIvbmZzX25mc2RjYWNoZS5jCTIwMTItMDIt MjIgMTE6MDY6NTUuMDAwMDAwMDAwIC0wNTAwCkBAIC0zMzYsOSArMzM2LDggQEAgbG9vcDoKIAkJ bmZzYWRkcl9tYXRjaChORVRGQU1JTFkocnApLCAmcnAtPnJjX2hhZGRyLCBuZC0+bmRfbmFtKSkg ewogCQkJaWYgKChycC0+cmNfZmxhZyAmIFJDX0xPQ0tFRCkgIT0gMCkgewogCQkJCXJwLT5yY19m bGFnIHw9IFJDX1dBTlRFRDsKLQkJCQlORlNVTkxPQ0tDQUNIRSgpOwotCQkJCSh2b2lkKSB0c2xl ZXAoKGNhZGRyX3QpcnAsIFBaRVJPIC0gMSwKLQkJCQkgICAgIm5mc3JjIiwgMTAgKiBoeik7CisJ CQkJKHZvaWQpbXNsZWVwKHJwLCBORlNDQUNIRU1VVEVYUFRSLAorCQkJCSAgICAoUFpFUk8gLSAx KSB8IFBEUk9QLCAibmZzcmMiLCAxMCAqIGh6KTsKIAkJCQlnb3RvIGxvb3A7CiAJCQl9CiAJCQlp ZiAocnAtPnJjX2ZsYWcgPT0gMCkKQEAgLTYyMiw4ICs2MjEsOCBAQCB0cnlhZ2FpbjoKIAkJcnAg PSBoaXRycDsKIAkJaWYgKChycC0+cmNfZmxhZyAmIFJDX0xPQ0tFRCkgIT0gMCkgewogCQkJcnAt PnJjX2ZsYWcgfD0gUkNfV0FOVEVEOwotCQkJTkZTVU5MT0NLQ0FDSEUoKTsKLQkJCSh2b2lkKSB0 c2xlZXAoKGNhZGRyX3QpcnAsIFBaRVJPLTEsICJuZnNyYyIsIDEwICogaHopOworCQkJKHZvaWQp bXNsZWVwKHJwLCBORlNDQUNIRU1VVEVYUFRSLAorCQkJICAgIChQWkVSTyAtIDEpIHwgUERST1As ICJuZnNyYyIsIDEwICogaHopOwogCQkJZ290byB0cnlhZ2FpbjsKIAkJfQogCQlpZiAocnAtPnJj X2ZsYWcgPT0gMCkK ------=_Part_1742742_1830441393.1329928180106-- From owner-freebsd-stable@FreeBSD.ORG Wed Feb 22 17:51: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 2A08A106564A; Wed, 22 Feb 2012 17:51:45 +0000 (UTC) (envelope-from Kashyap.Desai@lsi.com) Received: from na3sys009aog120.obsmtp.com (na3sys009aog120.obsmtp.com [74.125.149.140]) by mx1.freebsd.org (Postfix) with ESMTP id 05A7B8FC0A; Wed, 22 Feb 2012 17:51:43 +0000 (UTC) Received: from paledge01.lsi.com ([192.19.193.42]) (using TLSv1) by na3sys009aob120.postini.com ([74.125.148.12]) with SMTP ID DSNKT0UrLvPOKXWND7dy5zLJDlEh+3VyNd51@postini.com; Wed, 22 Feb 2012 09:51:44 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; Wed, 22 Feb 2012 12:56:29 -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; Wed, 22 Feb 2012 12:51:41 -0500 Received: from inbmail01.lsi.com ([135.36.98.64]) by inbexch02.lsi.com ([135.36.98.40]) with mapi; Wed, 22 Feb 2012 23:21:38 +0530 From: "Desai, Kashyap" To: "freebsd-scsi@freebsd.org" , freebsd-stable , "ed@FreeBSD.org" , "joerg@FreeBSD.org" Date: Wed, 22 Feb 2012 23:21:36 +0530 Thread-Topic: mpslsi0 : Trying sleep, but thread marked as sleeping prohibited Thread-Index: AczxazPnpqiOme5iTReYEw8tAgtfPgAHxL5Q Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Justin T. Gibbs" , "Kenneth D. Merry" , "McConnell, Stephen" Subject: RE: mpslsi0 : Trying sleep, but thread marked as sleeping prohibited X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Feb 2012 17:51:45 -0000 Adding Ed Schouten and Jorg Wunsch as I see there are author of msleep/mtx= related APIs. > -----Original Message----- > From: Desai, Kashyap > Sent: Wednesday, February 22, 2012 7:37 PM > To: freebsd-scsi@freebsd.org; freebsd-stable > Cc: 'Kenneth D. Merry'; McConnell, Stephen; Justin T. Gibbs > Subject: mpslsi0 : Trying sleep, but thread marked as sleeping > prohibited >=20 > Hi, >=20 > I am doing some code changes in mps dirver. While working on those > changes, I come to know about something which is new to me. > Some expert help is required to clarify my doubt. >=20 > 1. When any irq is register with FreeBSD OS, it sets " TDP_NOSLEEPING" > pflag. It means though irq in freebsd is treated as thread, > We cannot sleep in IRQ because of " "TDP_NOSLEEPING " set. > 2. In mps driver we have below code snippet in ISR routine. >=20 >=20 > mps_dprint(sc, MPS_TRACE, "%s\n", __func__); > mps_lock(sc); > mps_intr_locked(data); > mps_unlock(sc); >=20 > I wonder why there is no issue with above code ? Theoretical we cannot > sleep in ISR. (as explained in #1) > Any thoughts ? >=20 >=20 > 3. I recently added few place msleep() instead of DELAY in ISR context > and I see > " Trying sleep, but thread marked as sleeping prohibited". >=20 >=20 > ` Kashyap From owner-freebsd-stable@FreeBSD.ORG Wed Feb 22 19:16: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 52F41106566C for ; Wed, 22 Feb 2012 19:16:54 +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 D9E0F8FC0A for ; Wed, 22 Feb 2012 19:16:53 +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 q1MJFK1b096717; Wed, 22 Feb 2012 21:15:20 +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 q1MJFJqN039916; Wed, 22 Feb 2012 21:15:19 +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 q1MJFJGQ039915; Wed, 22 Feb 2012 21:15:19 +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, 22 Feb 2012 21:15:19 +0200 From: Konstantin Belousov To: "Desai, Kashyap" Message-ID: <20120222191519.GT55074@deviant.kiev.zoral.com.ua> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mgIE+9cwyCTt+85Z" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: "freebsd-scsi@freebsd.org" , "Kenneth D. Merry" , "Justin T. Gibbs" , freebsd-stable , "McConnell, Stephen" Subject: Re: mpslsi0 : Trying sleep, but thread marked as sleeping prohibited X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Feb 2012 19:16:54 -0000 --mgIE+9cwyCTt+85Z Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 22, 2012 at 07:36:42PM +0530, Desai, Kashyap wrote: > Hi, >=20 > I am doing some code changes in mps dirver. While working on those change= s, I come to know about something which is new to me. > Some expert help is required to clarify my doubt. >=20 > 1. When any irq is register with FreeBSD OS, it sets " TDP_NOSLEEPING" pf= lag. It means though irq in freebsd is treated as thread, > We cannot sleep in IRQ because of " "TDP_NOSLEEPING " set. > 2. In mps driver we have below code snippet in ISR routine. >=20 >=20 > mps_dprint(sc, MPS_TRACE, "%s\n", __func__); > mps_lock(sc); > mps_intr_locked(data); > mps_unlock(sc); >=20 > I wonder why there is no issue with above code ? Theoretical we cannot sl= eep in ISR. (as explained in #1) > Any thoughts ? >=20 >=20 > 3. I recently added few place msleep() instead of DELAY in ISR context an= d I see=20 > " Trying sleep, but thread marked as sleeping prohibited". >=20 FreeBSD has several basic ways to prevent a thread from executing on CPU. They mostly fall into two categories: bounded sleep, sometimes called blocking, and unbounded sleep, usually abbreviated as sleep. The bounded there refers to amount of code executed by other thread that hold resource preventing blocked thread from making a progress. Examples of the blocking primitives are mutexes, rw locks and rm locks. The blocking is not counted as sleeping, so interrupt threads, which are designated as non-sleeping, still can lock mutexes. Examples of the sleeping primitives are msleep(), sx locks, lockmgr locks and conditional variables. In essence, the locking facilities are split into several classes that form the hierarchy, and you cannot legally obtain the lock of higher class while holding a lock of lower class: spin mutexes -> blocking locks -> sleeping locks. It establishes some meta-order on the all locks. Does this make sense ? --mgIE+9cwyCTt+85Z Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk9FPsYACgkQC3+MBN1Mb4jg3wCeLVn0cKBcNva+KW7kkXym2wQf MIUAoNvRwD93Sxnykix6rw/vR+lmSa0z =IYv+ -----END PGP SIGNATURE----- --mgIE+9cwyCTt+85Z-- From owner-freebsd-stable@FreeBSD.ORG Wed Feb 22 19:28: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 B444E1065673; Wed, 22 Feb 2012 19:28:17 +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 43FCB8FC1C; Wed, 22 Feb 2012 19:28:16 +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 q1MJOGBO006179; Wed, 22 Feb 2012 21:24:16 +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 q1MJOFiE039961; Wed, 22 Feb 2012 21:24:15 +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 q1MJOEgv039960; Wed, 22 Feb 2012 21:24:14 +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, 22 Feb 2012 21:24:14 +0200 From: Konstantin Belousov To: Rick Macklem Message-ID: <20120222192414.GU55074@deviant.kiev.zoral.com.ua> References: <20120222.233814.1255848524636250830.hrs@allbsd.org> <810873252.1742743.1329928180108.JavaMail.root@erie.cs.uoguelph.ca> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="1PHmS26pdpOR3Xc0" Content-Disposition: inline In-Reply-To: <810873252.1742743.1329928180108.JavaMail.root@erie.cs.uoguelph.ca> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: stable@freebsd.org, John Baldwin Subject: Re: panic in 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: Wed, 22 Feb 2012 19:28:17 -0000 --1PHmS26pdpOR3Xc0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 22, 2012 at 11:29:40AM -0500, Rick Macklem wrote: > Hiroki Sato wrote: > > Hi, > >=20 > > Just a report, but I got the following panic on an NFS server running > > 8.3-PRERELEASE: > >=20 > > ----(from here)---- > > pool.allbsd.org dumped core - see /var/crash/vmcore.0 > >=20 > > Tue Feb 21 10:59:44 JST 2012 > >=20 > > FreeBSD pool.allbsd.org 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #7: Thu > > Feb 16 19:29:19 JST 2012 hrs@pool.allbsd.org:/usr/obj/usr/src/sys/POOL > > amd64 > >=20 > > panic: Assertion lock =3D=3D sq->sq_lock failed at > > /usr/src/sys/kern/subr_sleepqueue.c:335 > >=20 > Oops, I didn't know that mixing msleep() and tsleep() calls on the same > event wasn't allowed. > There are two places in the code where it did a: > mtx_unlock(); > tsleep(); > left over from the days when it was written for OpenBSD. This sequence allows to lost the wakeup which is happen right after cache unlock (together with clearing the RC_WANTED flag) but before the thread enters sleep state. The tsleep has a timeout so thread should recover in 10 seconds, but still. Anyway, you should use consistent outer lock for the same wchan, i.e. no lock (tsleep) or mtx (msleep), but not mix them. >=20 > I don't think the mix would actually break anything, except that the > MPASS() assertion fails, but I've cc'd jhb@ since he seems to have been > the author of the sleep() stuff. >=20 > Anyhow, please try the attached patch which replaces the mtx_unlock(); ts= leep(); with > msleep()s using PDROP. If the attachment gets lost, the patch is also her= e: > http://people.freebsd.org/~rmacklem/tsleep.patch >=20 > Thanks for reporting this, rick > ps: Is mtx_lock() now preferred over msleep()? What do you mean ? --1PHmS26pdpOR3Xc0 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk9FQN4ACgkQC3+MBN1Mb4gw4ACdHm3DYVwa4IgiNsKItQHq/v3n F34AoMxhJ6kp65aGIHlpxTUqo9d4LeMG =M9Gi -----END PGP SIGNATURE----- --1PHmS26pdpOR3Xc0-- From owner-freebsd-stable@FreeBSD.ORG Wed Feb 22 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 69BD1106566C; Wed, 22 Feb 2012 20:03:02 +0000 (UTC) (envelope-from lacombar@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 CB82F8FC14; Wed, 22 Feb 2012 20:03:01 +0000 (UTC) Received: by wgbdq11 with SMTP id dq11so396000wgb.31 for ; Wed, 22 Feb 2012 12:03: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=xeaLOupKGvd8pL1y/XJI4rK9wlhyyJ8aP4SDOUI2akE=; b=pC/vXu0ZIr6X5bFaqbF1GQ1ajU0DsDaRiwydsAoSy6TCgJMTxhHh8FM4JTr3xlsCwq wxPWvWh8AQrWEo04beJq4FvAcxLSvFTIfI4NdZUEIzkC5cdWamVuIBiYye6dbov7Yh4/ H6GuQT95kX0y+Ujey4KNE8alNVK1JVgtGbc9Q= MIME-Version: 1.0 Received: by 10.180.79.229 with SMTP id m5mr31977151wix.6.1329940980264; Wed, 22 Feb 2012 12:03:00 -0800 (PST) Received: by 10.216.158.133 with HTTP; Wed, 22 Feb 2012 12:03:00 -0800 (PST) In-Reply-To: References: Date: Wed, 22 Feb 2012 15:03:00 -0500 Message-ID: From: Arnaud Lacombe To: Jack Vogel Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Net , FreeBSD stable , re Subject: Re: nmbclusters: how do we want to fix this for 8.3 ? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Feb 2012 20:03:02 -0000 Hi, On Wed, Feb 22, 2012 at 2:56 PM, Jack Vogel wrote: > Using igb and/or ixgbe on a reasonably powered server requires 1K mbuf > clusters per MSIX vector, > that's how many are in a ring. Either driver will configure 8 queues on a > system with that many or more > cores, so 8K clusters per port... > > My test engineer has a system with 2 igb ports, and 2 10G ixgbe, this is > hardly heavy duty, and yet this > exceeds the default mbuf pool on the installed kernel (1024 + maxusers * > 64). > > Now, this can be immediately fixed by a sysadmin after that first boot, but > it does result in the second > driver that gets started to complain about inadequate buffers. > > I think the default calculation is dated and should be changed, but am not > sure the best way, so are > there suggestions/opinions about this, and might we get it fixed before 8.3 > is baked? > get rid of the limit once and for all, it is pointless. - Arnaud From owner-freebsd-stable@FreeBSD.ORG Wed Feb 22 20:18: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 2A864106564A; Wed, 22 Feb 2012 20:18:20 +0000 (UTC) (envelope-from jfvogel@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 87C058FC0A; Wed, 22 Feb 2012 20:18:19 +0000 (UTC) Received: by wibhn14 with SMTP id hn14so458680wib.13 for ; Wed, 22 Feb 2012 12:18:18 -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=MNKO8AUKN4XcZzcNgK+huXunvuMsSkOTvgaGzaEb7Pg=; b=E8r5UUGByl9FdIZS8qlSs5C7EVoxJG8LU+vPDytvSxmxvjSk3rfpT6LDyBwm4z7U91 q7XLjpecnMOJ3k6BPxC0HUhxpTHSYhYRiJ5+LAERDLGO1gYV28xQJjnmosxeWeRQ0ogr iamDg00OUe3sOAb3qt8NEX2IbZbNj5fqhzsgo= MIME-Version: 1.0 Received: by 10.180.93.232 with SMTP id cx8mr32890006wib.14.1329940590025; Wed, 22 Feb 2012 11:56:30 -0800 (PST) Received: by 10.180.102.97 with HTTP; Wed, 22 Feb 2012 11:56:29 -0800 (PST) Date: Wed, 22 Feb 2012 11:56:29 -0800 Message-ID: From: Jack Vogel To: FreeBSD Net , FreeBSD stable , re Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: nmbclusters: how do we want to fix this for 8.3 ? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Feb 2012 20:18:20 -0000 Using igb and/or ixgbe on a reasonably powered server requires 1K mbuf clusters per MSIX vector, that's how many are in a ring. Either driver will configure 8 queues on a system with that many or more cores, so 8K clusters per port... My test engineer has a system with 2 igb ports, and 2 10G ixgbe, this is hardly heavy duty, and yet this exceeds the default mbuf pool on the installed kernel (1024 + maxusers * 64). Now, this can be immediately fixed by a sysadmin after that first boot, but it does result in the second driver that gets started to complain about inadequate buffers. I think the default calculation is dated and should be changed, but am not sure the best way, so are there suggestions/opinions about this, and might we get it fixed before 8.3 is baked? Cheers, Jack From owner-freebsd-stable@FreeBSD.ORG Wed Feb 22 20:27: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 0EDDD1065670; Wed, 22 Feb 2012 20:27:25 +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 C30218FC0A; Wed, 22 Feb 2012 20:27:24 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.5/8.14.5) with ESMTP id q1MKROS0079648; Wed, 22 Feb 2012 13:27:24 -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 q1MKROOP079645; Wed, 22 Feb 2012 13:27:24 -0700 (MST) (envelope-from wblock@wonkity.com) Date: Wed, 22 Feb 2012 13:27:24 -0700 (MST) From: Warren Block To: Omer Faruk SEN In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (wonkity.com [127.0.0.1]); Wed, 22 Feb 2012 13:27:24 -0700 (MST) Cc: freebsd-stable@freebsd.org, FreeBSD Subject: Re: 8.3-BETA1 installation 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, 22 Feb 2012 20:27:25 -0000 On Wed, 22 Feb 2012, Omer Faruk SEN wrote: > I am trying to install FreeBSD 8.3-BETA1 to a system with ssd disk > recognized as ad6. At fixit mode i can dd device but at installer > (sysinstall) when I configured disk and using "w" installer is unable to > format devices stating that > > "Unable to find device node for /dev/ad6s1b in dev. The creation of file > systems will be aborted" > > any suggestion on what may be the reason for that or is it a bug on > installer Using "W"rite is one of the causes for that. Don't Write, just choose Quit after making selections. (There are other causes, like old partitioning information on the disk. Removing that with gpart destroy or just dd-ing zeros over it is the cure in that case.) From owner-freebsd-stable@FreeBSD.ORG Wed Feb 22 20:50: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 68EED1065673 for ; Wed, 22 Feb 2012 20:50:58 +0000 (UTC) (envelope-from omerfsen@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 1D9C88FC1A for ; Wed, 22 Feb 2012 20:50:57 +0000 (UTC) Received: by qaea17 with SMTP id a17so769859qae.13 for ; Wed, 22 Feb 2012 12:50:57 -0800 (PST) Received-SPF: pass (google.com: domain of omerfsen@gmail.com designates 10.229.135.10 as permitted sender) client-ip=10.229.135.10; Authentication-Results: mr.google.com; spf=pass (google.com: domain of omerfsen@gmail.com designates 10.229.135.10 as permitted sender) smtp.mail=omerfsen@gmail.com; dkim=pass header.i=omerfsen@gmail.com Received: from mr.google.com ([10.229.135.10]) by 10.229.135.10 with SMTP id l10mr24146054qct.14.1329943857431 (num_hops = 1); Wed, 22 Feb 2012 12:50:57 -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=92wh+tftSB+Fu7tnRBE8hmZsrCvvVNPx+PaeGpd8fXY=; b=obaWEfH0Q96FyeEtP7HNySEdXxiBVG3xb05APNuA9vxhGuj6qJYd0Cf1vUTRwKb/kn gBh+meRFGPleuz420+yIyzxGYnhlPR8zjQy7DPmdZQSTLhgEWxMjGUzM5sXnvjXuW3ld wrylNzW6+cM0AkZrs36vLYk96Vpqn/OFmURsE= MIME-Version: 1.0 Received: by 10.229.135.10 with SMTP id l10mr20352588qct.14.1329942059280; Wed, 22 Feb 2012 12:20:59 -0800 (PST) Received: by 10.229.24.81 with HTTP; Wed, 22 Feb 2012 12:20:59 -0800 (PST) Date: Wed, 22 Feb 2012 22:20:59 +0200 Message-ID: From: Omer Faruk SEN To: FreeBSD Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: 8.3-BETA1 installation 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, 22 Feb 2012 20:50:58 -0000 Hi, I am trying to install FreeBSD 8.3-BETA1 to a system with ssd disk recognized as ad6. At fixit mode i can dd device but at installer (sysinstall) when I configured disk and using "w" installer is unable to format devices stating that "Unable to find device node for /dev/ad6s1b in dev. The creation of file systems will be aborted" any suggestion on what may be the reason for that or is it a bug on installer From owner-freebsd-stable@FreeBSD.ORG Wed Feb 22 20:51: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 CA9B0106566B for ; Wed, 22 Feb 2012 20:51:24 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 896658FC25 for ; Wed, 22 Feb 2012 20:51:24 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 058657300A; Wed, 22 Feb 2012 21:52:32 +0100 (CET) Date: Wed, 22 Feb 2012 21:52:32 +0100 From: Luigi Rizzo To: Jack Vogel Message-ID: <20120222205231.GA81949@onelab2.iet.unipi.it> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: FreeBSD Net , FreeBSD stable , re Subject: Re: nmbclusters: how do we want to fix this for 8.3 ? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Feb 2012 20:51:24 -0000 On Wed, Feb 22, 2012 at 11:56:29AM -0800, Jack Vogel wrote: > Using igb and/or ixgbe on a reasonably powered server requires 1K mbuf > clusters per MSIX vector, > that's how many are in a ring. Either driver will configure 8 queues on a > system with that many or more > cores, so 8K clusters per port... > > My test engineer has a system with 2 igb ports, and 2 10G ixgbe, this is > hardly heavy duty, and yet this > exceeds the default mbuf pool on the installed kernel (1024 + maxusers * > 64). > > Now, this can be immediately fixed by a sysadmin after that first boot, but > it does result in the second > driver that gets started to complain about inadequate buffers. > > I think the default calculation is dated and should be changed, but am not > sure the best way, so are > there suggestions/opinions about this, and might we get it fixed before 8.3 > is baked? I have hit this problem recently, too. Maybe the issue mostly/only exists on 32-bit systems. Here is a possible approach: 1. nmbclusters consume the kernel virtual address space so there must be some upper limit, say VM_LIMIT = 256000 (translates to 512MB of address space) 2. also you don't want the clusters to take up too much of the available memory. This one would only trigger for minimal-memory systems, or virtual machines, but still... MEM_LIMIT = (physical_ram / 2) / 2048 3. one may try to set a suitably large, desirable number of buffers TARGET_CLUSTERS = 128000 4. and finally we could use the current default as the absolute minimum MIN_CLUSTERS = 1024 + maxusers*64 Then at boot the system could say nmbclusters = min(TARGET_CLUSTERS, VM_LIMIT, MEM_LIMIT) nmbclusters = max(nmbclusters, MIN_CLUSTERS) In turn, i believe interfaces should do their part and by default never try to allocate more than a fraction of the total number of buffers, if necessary reducing the number of active queues. what do people think ? cheers luigi From owner-freebsd-stable@FreeBSD.ORG Wed Feb 22 21:26:30 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 310E1106564A; Wed, 22 Feb 2012 21:26:30 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id E0CE88FC12; Wed, 22 Feb 2012 21:26:29 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id AB1E27300B; Wed, 22 Feb 2012 22:44:33 +0100 (CET) Date: Wed, 22 Feb 2012 22:44:33 +0100 From: Luigi Rizzo To: Ben Hutchings Message-ID: <20120222214433.GA82582@onelab2.iet.unipi.it> References: <20120222205231.GA81949@onelab2.iet.unipi.it> <1329944986.2621.46.camel@bwh-desktop> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1329944986.2621.46.camel@bwh-desktop> User-Agent: Mutt/1.4.2.3i Cc: FreeBSD Net , FreeBSD stable , Jack Vogel , re Subject: Re: nmbclusters: how do we want to fix this for 8.3 ? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Feb 2012 21:26:30 -0000 On Wed, Feb 22, 2012 at 09:09:46PM +0000, Ben Hutchings wrote: > On Wed, 2012-02-22 at 21:52 +0100, Luigi Rizzo wrote: ... > > I have hit this problem recently, too. > > Maybe the issue mostly/only exists on 32-bit systems. > > No, we kept hitting mbuf pool limits on 64-bit systems when we started > working on FreeBSD support. ok never mind then, the mechanism would be the same, though the limits (especially VM_LIMIT) would be different. > > Here is a possible approach: > > > > 1. nmbclusters consume the kernel virtual address space so there > > must be some upper limit, say > > > > VM_LIMIT = 256000 (translates to 512MB of address space) > > > > 2. also you don't want the clusters to take up too much of the available > > memory. This one would only trigger for minimal-memory systems, > > or virtual machines, but still... > > > > MEM_LIMIT = (physical_ram / 2) / 2048 > > > > 3. one may try to set a suitably large, desirable number of buffers > > > > TARGET_CLUSTERS = 128000 > > > > 4. and finally we could use the current default as the absolute minimum > > > > MIN_CLUSTERS = 1024 + maxusers*64 > > > > Then at boot the system could say > > > > nmbclusters = min(TARGET_CLUSTERS, VM_LIMIT, MEM_LIMIT) > > > > nmbclusters = max(nmbclusters, MIN_CLUSTERS) > > > > > > In turn, i believe interfaces should do their part and by default > > never try to allocate more than a fraction of the total number > > of buffers, > > Well what fraction should that be? It surely depends on how many > interfaces are in the system and how many queues the other interfaces > have. > > if necessary reducing the number of active queues. > > So now I have too few queues on my interface even after I increase the > limit. > > There ought to be a standard way to configure numbers of queues and > default queue lengths. Jack raised the problem that there is a poorly chosen default for nmbclusters, causing one interface to consume all the buffers. If the user explicitly overrides the value then the number of cluster should be what the user asks (memory permitting). The next step is on devices: if there are no overrides, the default for a driver is to be lean. I would say that topping the request between 1/4 and 1/8 of the total buffers is surely better than the current situation. Of course if there is an explicit override, then use it whatever happens to the others. cheers luigi From owner-freebsd-stable@FreeBSD.ORG Wed Feb 22 21:35:13 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2A6DE1065677; Wed, 22 Feb 2012 21:35:13 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 007788FC14; Wed, 22 Feb 2012 21:35:13 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id ACC3846B09; Wed, 22 Feb 2012 16:35:12 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 1CAB9B9A7; Wed, 22 Feb 2012 16:35:12 -0500 (EST) From: John Baldwin To: Konstantin Belousov Date: Wed, 22 Feb 2012 16:33:02 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p10; KDE/4.5.5; amd64; ; ) References: <20120222.233814.1255848524636250830.hrs@allbsd.org> <810873252.1742743.1329928180108.JavaMail.root@erie.cs.uoguelph.ca> <20120222192414.GU55074@deviant.kiev.zoral.com.ua> In-Reply-To: <20120222192414.GU55074@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201202221633.02170.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 22 Feb 2012 16:35:12 -0500 (EST) Cc: stable@freebsd.org, Rick Macklem Subject: Re: panic in 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: Wed, 22 Feb 2012 21:35:13 -0000 On Wednesday, February 22, 2012 2:24:14 pm Konstantin Belousov wrote: > On Wed, Feb 22, 2012 at 11:29:40AM -0500, Rick Macklem wrote: > > Hiroki Sato wrote: > > > Hi, > > > > > > Just a report, but I got the following panic on an NFS server running > > > 8.3-PRERELEASE: > > > > > > ----(from here)---- > > > pool.allbsd.org dumped core - see /var/crash/vmcore.0 > > > > > > Tue Feb 21 10:59:44 JST 2012 > > > > > > FreeBSD pool.allbsd.org 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #7: Thu > > > Feb 16 19:29:19 JST 2012 hrs@pool.allbsd.org:/usr/obj/usr/src/sys/POOL > > > amd64 > > > > > > panic: Assertion lock == sq->sq_lock failed at > > > /usr/src/sys/kern/subr_sleepqueue.c:335 > > > > > Oops, I didn't know that mixing msleep() and tsleep() calls on the same > > event wasn't allowed. > > There are two places in the code where it did a: > > mtx_unlock(); > > tsleep(); > > left over from the days when it was written for OpenBSD. > This sequence allows to lost the wakeup which is happen right after > cache unlock (together with clearing the RC_WANTED flag) but before > the thread enters sleep state. The tsleep has a timeout so thread should > recover in 10 seconds, but still. > > Anyway, you should use consistent outer lock for the same wchan, i.e. > no lock (tsleep) or mtx (msleep), but not mix them. Correct. > > I don't think the mix would actually break anything, except that the > > MPASS() assertion fails, but I've cc'd jhb@ since he seems to have been > > the author of the sleep() stuff. > > > > Anyhow, please try the attached patch which replaces the mtx_unlock(); tsleep(); with > > msleep()s using PDROP. If the attachment gets lost, the patch is also here: > > http://people.freebsd.org/~rmacklem/tsleep.patch > > > > Thanks for reporting this, rick > > ps: Is mtx_lock() now preferred over msleep()? > What do you mean ? mtx_sleep() is preferred over msleep(), but I doubt I will remove msleep() anytime soon. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Wed Feb 22 21:51: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 27449106570A; Wed, 22 Feb 2012 21:51:49 +0000 (UTC) (envelope-from jfvogel@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 53E4D8FC23; Wed, 22 Feb 2012 21:51:47 +0000 (UTC) Received: by wgbdq11 with SMTP id dq11so474666wgb.31 for ; Wed, 22 Feb 2012 13:51:46 -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=Psq8BF48kHsLS7MmUu4YZ6ReVaw91IXluUKaCJdDWA0=; b=mp4FDt53UNOoU9PP8BRUuCNZDb05v9NIb6zmyiDUw66YAXEPLkeywiD5kj/jOvszHo WcJ5EVshpRGoxjG9bKUcD/xM0T7mmsnHGrW7uQWyh3W8gjVjL4oxUcY7iF/WcYYS3wXT TPPMGn56F2y5SvLuFPBtBrxO0+svUCwq3Kvwk= MIME-Version: 1.0 Received: by 10.180.104.4 with SMTP id ga4mr142392wib.17.1329947506782; Wed, 22 Feb 2012 13:51:46 -0800 (PST) Received: by 10.180.102.97 with HTTP; Wed, 22 Feb 2012 13:51:46 -0800 (PST) In-Reply-To: <20120222214433.GA82582@onelab2.iet.unipi.it> References: <20120222205231.GA81949@onelab2.iet.unipi.it> <1329944986.2621.46.camel@bwh-desktop> <20120222214433.GA82582@onelab2.iet.unipi.it> Date: Wed, 22 Feb 2012 13:51:46 -0800 Message-ID: From: Jack Vogel To: Luigi Rizzo Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Ben Hutchings , FreeBSD Net , FreeBSD stable , re Subject: Re: nmbclusters: how do we want to fix this for 8.3 ? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Feb 2012 21:51:49 -0000 On Wed, Feb 22, 2012 at 1:44 PM, Luigi Rizzo wrote: > On Wed, Feb 22, 2012 at 09:09:46PM +0000, Ben Hutchings wrote: > > On Wed, 2012-02-22 at 21:52 +0100, Luigi Rizzo wrote: > ... > > > I have hit this problem recently, too. > > > Maybe the issue mostly/only exists on 32-bit systems. > > > > No, we kept hitting mbuf pool limits on 64-bit systems when we started > > working on FreeBSD support. > > ok never mind then, the mechanism would be the same, though > the limits (especially VM_LIMIT) would be different. > > > > Here is a possible approach: > > > > > > 1. nmbclusters consume the kernel virtual address space so there > > > must be some upper limit, say > > > > > > VM_LIMIT = 256000 (translates to 512MB of address space) > > > > > > 2. also you don't want the clusters to take up too much of the > available > > > memory. This one would only trigger for minimal-memory systems, > > > or virtual machines, but still... > > > > > > MEM_LIMIT = (physical_ram / 2) / 2048 > > > > > > 3. one may try to set a suitably large, desirable number of buffers > > > > > > TARGET_CLUSTERS = 128000 > > > > > > 4. and finally we could use the current default as the absolute minimum > > > > > > MIN_CLUSTERS = 1024 + maxusers*64 > > > > > > Then at boot the system could say > > > > > > nmbclusters = min(TARGET_CLUSTERS, VM_LIMIT, MEM_LIMIT) > > > > > > nmbclusters = max(nmbclusters, MIN_CLUSTERS) > > > > > > > > > In turn, i believe interfaces should do their part and by default > > > never try to allocate more than a fraction of the total number > > > of buffers, > > > > Well what fraction should that be? It surely depends on how many > > interfaces are in the system and how many queues the other interfaces > > have. > > > > if necessary reducing the number of active queues. > > > > So now I have too few queues on my interface even after I increase the > > limit. > > > > There ought to be a standard way to configure numbers of queues and > > default queue lengths. > > Jack raised the problem that there is a poorly chosen default for > nmbclusters, causing one interface to consume all the buffers. > If the user explicitly overrides the value then > the number of cluster should be what the user asks (memory permitting). > The next step is on devices: if there are no overrides, the default > for a driver is to be lean. I would say that topping the request between > 1/4 and 1/8 of the total buffers is surely better than the current > situation. Of course if there is an explicit override, then use > it whatever happens to the others. > > cheers > luigi > Hmmm, well, I could make the default use only 1 queue or something like that, was thinking more of what actual users of the hardware would want. After the installed kernel is booted and the admin would do whatever post install modifications they wish it could be changed, along with nmbclusters. This was why i sought opinions, of the algorithm itself, but also anyone using ixgbe and igb in heavy use, what would you find most convenient? Jack From owner-freebsd-stable@FreeBSD.ORG Wed Feb 22 22:31:41 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 5BA481065674; Wed, 22 Feb 2012 22:31:41 +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 DE6F88FC17; Wed, 22 Feb 2012 22:31:40 +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 A10F325D3A00; Wed, 22 Feb 2012 22:31:39 +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 D562BBDBEDA; Wed, 22 Feb 2012 22:31:38 +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 bUorBj94lp7i; Wed, 22 Feb 2012 22:31:37 +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 BBF33BDBED9; Wed, 22 Feb 2012 22:31:37 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Bjoern A. Zeeb" In-Reply-To: <20120221143537.Horde.deyFDZjmRSRPQ52pxBIpnLA@webmail.leidinger.net> Date: Wed, 22 Feb 2012 22:31:36 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120221143537.Horde.deyFDZjmRSRPQ52pxBIpnLA@webmail.leidinger.net> To: Alexander Leidinger X-Mailer: Apple Mail (2.1084) Cc: stable@FreeBSD.org, current@FreeBSD.org Subject: Re: [CFT] modular kernel config X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Feb 2012 22:31:41 -0000 On 21. Feb 2012, at 13:35 , Alexander Leidinger wrote: > You can download from > http://www.Leidinger.net/FreeBSD/current-patches/ > The files are > - i386_SMALL > - i386_SMALL_loader.conf > - amd64_SMALL > - amd64_SMALL_loader.conf I only looked at the laoder.conf for amd64 and the only comment I have = is that I do not have the time to wait minutes for all individual = modules to be loaded. This is going to be really bad for boot time. > The new stuff in the kernel config compared to GENERIC is (in order of = number of requests from users): > - IPSEC (+ device enc + IPSEC_NAT_T) You cannot ship that on by default for non-tecnical reasons in a kernel. = Please do not commit a kernel config that can be booted (no LINT cannot = be booted) with these on without consulting appropriate hats upfront. > - ALTQ > - SW_WATCHDOG > - QUOTA > - IPSTEALTH (disabled in loader.conf) > - IPFIREWALL_FORWARD (touches every packet, power users which need > a bigger PPS but not this feature can recompile the kernel, > discussed with julian@) > - FLOWTABLE (disabled in loader.conf) Which is not the same as it's not 100% disabled and will still allocate = memory. --=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 22 23:53: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 C2F11106566B; Wed, 22 Feb 2012 23:53:56 +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 64FF58FC08; Wed, 22 Feb 2012 23:53:56 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAEALR/RU+DaFvO/2dsb2JhbABEFoUariyBcwEBAQQBAQEgBCcgCxsOCgICDRkCKQEJJgYIBwQBHASHaaYhkhSBL4g4gx0VGAECBAsDDw0CBRINCAKEToESBgUKD4IigRYEiE+KQYIokwuBPg X-IronPort-AV: E=Sophos;i="4.73,466,1325480400"; d="scan'208";a="157496760" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 22 Feb 2012 18:53:55 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 55533B3FED; Wed, 22 Feb 2012 18:53:55 -0500 (EST) Date: Wed, 22 Feb 2012 18:53:55 -0500 (EST) From: Rick Macklem To: John Baldwin Message-ID: <476361430.1773817.1329954835308.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <201202221633.02170.jhb@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: Konstantin Belousov , stable@freebsd.org Subject: Re: panic in 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: Wed, 22 Feb 2012 23:53:56 -0000 John Baldwin wrote: > On Wednesday, February 22, 2012 2:24:14 pm Konstantin Belousov wrote: > > On Wed, Feb 22, 2012 at 11:29:40AM -0500, Rick Macklem wrote: > > > Hiroki Sato wrote: > > > > Hi, > > > > > > > > Just a report, but I got the following panic on an NFS server > > > > running > > > > 8.3-PRERELEASE: > > > > > > > > ----(from here)---- > > > > pool.allbsd.org dumped core - see /var/crash/vmcore.0 > > > > > > > > Tue Feb 21 10:59:44 JST 2012 > > > > > > > > FreeBSD pool.allbsd.org 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE > > > > #7: Thu > > > > Feb 16 19:29:19 JST 2012 > > > > hrs@pool.allbsd.org:/usr/obj/usr/src/sys/POOL > > > > amd64 > > > > > > > > panic: Assertion lock == sq->sq_lock failed at > > > > /usr/src/sys/kern/subr_sleepqueue.c:335 > > > > > > > Oops, I didn't know that mixing msleep() and tsleep() calls on the > > > same > > > event wasn't allowed. > > > There are two places in the code where it did a: > > > mtx_unlock(); > > > tsleep(); > > > left over from the days when it was written for OpenBSD. > > This sequence allows to lost the wakeup which is happen right after > > cache unlock (together with clearing the RC_WANTED flag) but before > > the thread enters sleep state. The tsleep has a timeout so thread > > should > > recover in 10 seconds, but still. > > > > Anyway, you should use consistent outer lock for the same wchan, > > i.e. > > no lock (tsleep) or mtx (msleep), but not mix them. > > Correct. > > > > I don't think the mix would actually break anything, except that > > > the > > > MPASS() assertion fails, but I've cc'd jhb@ since he seems to have > > > been > > > the author of the sleep() stuff. > > > > > > Anyhow, please try the attached patch which replaces the > > > mtx_unlock(); > tsleep(); with > > > msleep()s using PDROP. If the attachment gets lost, the patch is > > > also > here: > > > http://people.freebsd.org/~rmacklem/tsleep.patch > > > > > > Thanks for reporting this, rick > > > ps: Is mtx_lock() now preferred over msleep()? > > What do you mean ? > > mtx_sleep() is preferred over msleep(), but I doubt I will remove > msleep() > anytime soon. > Ok, I'll redo the patch with mtx_sleep() and get one of you guys to review it. One question. Do you think this is serious enough to worry about for 8.3? (Just wondering if I need to rush a patch into head with a 1 week MFC. I realize it would still be up to re@, even if I rush it.) Thanks for the useful comments, rick > -- > John Baldwin > _______________________________________________ > 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 23 00:04:24 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 4DE16106564A; Thu, 23 Feb 2012 00:04:24 +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 E1B7C8FC08; Thu, 23 Feb 2012 00:04:23 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap8EAIeBRU+DaFvO/2dsb2JhbABEFoUeriuBcwEBBAEjBFIFFg4KAgINGQJZBhOIAQmsTootgS+MAgECBAsDDw0CBRINBQMChE6BHQoPgiKBFgSIT4xpkws X-IronPort-AV: E=Sophos;i="4.73,466,1325480400"; d="scan'208";a="160594858" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 22 Feb 2012 19:04:22 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id E8FEDB3F0F; Wed, 22 Feb 2012 19:04:22 -0500 (EST) Date: Wed, 22 Feb 2012 19:04:22 -0500 (EST) From: Rick Macklem To: Konstantin Belousov Message-ID: <780341943.1774154.1329955462926.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <20120222192414.GU55074@deviant.kiev.zoral.com.ua> 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: stable@freebsd.org, John Baldwin Subject: Re: panic in 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, 23 Feb 2012 00:04:24 -0000 Konstantin Belousov wrote: > On Wed, Feb 22, 2012 at 11:29:40AM -0500, Rick Macklem wrote: > > Hiroki Sato wrote: > > > Hi, > > > > > > Just a report, but I got the following panic on an NFS server > > > running > > > 8.3-PRERELEASE: > > > > > > ----(from here)---- > > > pool.allbsd.org dumped core - see /var/crash/vmcore.0 > > > > > > Tue Feb 21 10:59:44 JST 2012 > > > > > > FreeBSD pool.allbsd.org 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #7: > > > Thu > > > Feb 16 19:29:19 JST 2012 > > > hrs@pool.allbsd.org:/usr/obj/usr/src/sys/POOL > > > amd64 > > > > > > panic: Assertion lock == sq->sq_lock failed at > > > /usr/src/sys/kern/subr_sleepqueue.c:335 > > > > > Oops, I didn't know that mixing msleep() and tsleep() calls on the > > same > > event wasn't allowed. > > There are two places in the code where it did a: > > mtx_unlock(); > > tsleep(); > > left over from the days when it was written for OpenBSD. > This sequence allows to lost the wakeup which is happen right after > cache unlock (together with clearing the RC_WANTED flag) but before > the thread enters sleep state. The tsleep has a timeout so thread > should > recover in 10 seconds, but still. > Yes. > Anyway, you should use consistent outer lock for the same wchan, i.e. > no lock (tsleep) or mtx (msleep), but not mix them. > > > > I don't think the mix would actually break anything, except that the > > MPASS() assertion fails, but I've cc'd jhb@ since he seems to have > > been > > the author of the sleep() stuff. > > > > Anyhow, please try the attached patch which replaces the > > mtx_unlock(); tsleep(); with > > msleep()s using PDROP. If the attachment gets lost, the patch is > > also here: > > http://people.freebsd.org/~rmacklem/tsleep.patch > > > > Thanks for reporting this, rick > > ps: Is mtx_lock() now preferred over msleep()? > What do you mean ? It appears jhb@ figured out the typo. I meant to type mtx_sleep(), not mtx_lock(). rick From owner-freebsd-stable@FreeBSD.ORG Thu Feb 23 00:22: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 AEDF0106566B; Thu, 23 Feb 2012 00:22:20 +0000 (UTC) (envelope-from Kashyap.Desai@lsi.com) Received: from na3sys009aog102.obsmtp.com (na3sys009aog102.obsmtp.com [74.125.149.69]) by mx1.freebsd.org (Postfix) with ESMTP id BD3208FC0C; Thu, 23 Feb 2012 00:22:19 +0000 (UTC) Received: from paledge01.lsi.com ([192.19.193.42]) (using TLSv1) by na3sys009aob102.postini.com ([74.125.148.12]) with SMTP ID DSNKT0WGuoUn+p54emR2yLFS64XWnwr6OlrP@postini.com; Wed, 22 Feb 2012 16:22:20 PST Received: from PALHUB01.lsi.com (128.94.213.114) by PALEDGE01.lsi.com (192.19.193.42) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 22 Feb 2012 19:27:05 -0500 Received: from inbexch02.lsi.com (135.36.98.40) by PALHUB01.lsi.com (128.94.213.114) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 22 Feb 2012 19:22:17 -0500 Received: from inbmail01.lsi.com ([135.36.98.64]) by inbexch02.lsi.com ([135.36.98.40]) with mapi; Thu, 23 Feb 2012 05:52:14 +0530 From: "Desai, Kashyap" To: Konstantin Belousov Date: Thu, 23 Feb 2012 05:52:12 +0530 Thread-Topic: mpslsi0 : Trying sleep, but thread marked as sleeping prohibited Thread-Index: Aczxlo487pC/r7O9Q7aOJ9HCBeka5gAKHhLw Message-ID: References: <20120222191519.GT55074@deviant.kiev.zoral.com.ua> In-Reply-To: <20120222191519.GT55074@deviant.kiev.zoral.com.ua> 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-scsi@freebsd.org" , "Kenneth D. Merry" , "Justin T. Gibbs" , freebsd-stable , "McConnell, Stephen" Subject: RE: mpslsi0 : Trying sleep, but thread marked as sleeping prohibited X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 23 Feb 2012 00:22:20 -0000 > -----Original Message----- > From: Konstantin Belousov [mailto:kostikbel@gmail.com] > Sent: Thursday, February 23, 2012 12:45 AM > To: Desai, Kashyap > Cc: freebsd-scsi@freebsd.org; freebsd-stable; Justin T. Gibbs; Kenneth > D. Merry; McConnell, Stephen > Subject: Re: mpslsi0 : Trying sleep, but thread marked as sleeping > prohibited >=20 > On Wed, Feb 22, 2012 at 07:36:42PM +0530, Desai, Kashyap wrote: > > Hi, > > > > I am doing some code changes in mps dirver. While working on those > changes, I come to know about something which is new to me. > > Some expert help is required to clarify my doubt. > > > > 1. When any irq is register with FreeBSD OS, it sets " TDP_NOSLEEPING" > > pflag. It means though irq in freebsd is treated as thread, We cannot > sleep in IRQ because of " "TDP_NOSLEEPING " set. > > 2. In mps driver we have below code snippet in ISR routine. > > > > > > mps_dprint(sc, MPS_TRACE, "%s\n", __func__); > > mps_lock(sc); > > mps_intr_locked(data); > > mps_unlock(sc); > > > > I wonder why there is no issue with above code ? Theoretical we cannot > > sleep in ISR. (as explained in #1) Any thoughts ? > > > > > > 3. I recently added few place msleep() instead of DELAY in ISR context > > and I see " Trying sleep, but thread marked as sleeping prohibited". > > > FreeBSD has several basic ways to prevent a thread from executing on > CPU. > They mostly fall into two categories: bounded sleep, sometimes called > blocking, and unbounded sleep, usually abbreviated as sleep. The bounded > there refers to amount of code executed by other thread that hold > resource preventing blocked thread from making a progress. >=20 > Examples of the blocking primitives are mutexes, rw locks and rm locks. > The blocking is not counted as sleeping, so interrupt threads, which are > designated as non-sleeping, still can lock mutexes. Thanks for the tech help. .=20 As per you comment, So now I understood as "TDP_NOSLEEPING" is only for unb= ounded sleep restriction. Just curious to know, What is a reason that thread can do blocking sleep bu= t can't do unbounded sleep ? Since technically we introduced sleeping restriction on interrupt thread is= to avoid starvation and that can be fit with either of the sleep type. Is this not true ? I will be able to progress on my work based on your comment. A much thanks = for correcting my doubt. ~ Kashyap >=20 > Examples of the sleeping primitives are msleep(), sx locks, lockmgr > locks and conditional variables. >=20 > In essence, the locking facilities are split into several classes that > form the hierarchy, and you cannot legally obtain the lock of higher > class while holding a lock of lower class: > spin mutexes -> blocking locks -> sleeping locks. > It establishes some meta-order on the all locks. >=20 > Does this make sense ? From owner-freebsd-stable@FreeBSD.ORG Thu Feb 23 00:51: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 9EAD5106564A for ; Thu, 23 Feb 2012 00:51:02 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from asmtpout030.mac.com (asmtpout030.mac.com [17.148.16.105]) by mx1.freebsd.org (Postfix) with ESMTP id 820F58FC0A for ; Thu, 23 Feb 2012 00:51:02 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from cswiger1.apple.com (unknown [17.209.4.71]) by asmtp030.mac.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTPSA id <0LZT00ABFMD13060@asmtp030.mac.com>; Wed, 22 Feb 2012 16:51:02 -0800 (PST) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.6.7498,1.0.260,0.0.0000 definitions=2012-02-22_06:2012-02-21, 2012-02-22, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1012030000 definitions=main-1202220287 From: Chuck Swiger In-reply-to: Date: Wed, 22 Feb 2012 16:51:00 -0800 Message-id: References: <20120222191519.GT55074@deviant.kiev.zoral.com.ua> To: "Desai, Kashyap" X-Mailer: Apple Mail (2.1084) Cc: freebsd-scsi@freebsd.org, freebsd-stable , "McConnell, Stephen" Subject: Re: mpslsi0 : Trying sleep, but thread marked as sleeping prohibited X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 23 Feb 2012 00:51:02 -0000 On Feb 22, 2012, at 4:22 PM, Desai, Kashyap wrote: > Just curious to know, What is a reason that thread can do blocking sleep but can't do unbounded sleep ? When you block, the scheduler can run other threads and only needs to wake up and run your thread after the blocking condition is completed. However, you don't want to busy-wait in a spin lock/mutex for any lengthy period of time. If your thread was allowed to do an unbounded sleep, especially in a fast interrupt handler context, what's going to wake it up? An NMI like the reset button [1]? :-) Regards, -- -Chuck [1]: Well, you could also call STI to permit clock interrupts or something else to fire an interrupt, but then your interrupt handler needs to be re-entrant. (And watch out for multiple nested interrupts blowing out the available stack space....) From owner-freebsd-stable@FreeBSD.ORG Thu Feb 23 02:14: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 3F259106564A; Thu, 23 Feb 2012 02:14:29 +0000 (UTC) (envelope-from Kashyap.Desai@lsi.com) Received: from na3sys009aog119.obsmtp.com (na3sys009aog119.obsmtp.com [74.125.149.246]) by mx1.freebsd.org (Postfix) with ESMTP id 8E3E28FC0C; Thu, 23 Feb 2012 02:14:28 +0000 (UTC) Received: from paledge01.lsi.com ([192.19.193.42]) (using TLSv1) by na3sys009aob119.postini.com ([74.125.148.12]) with SMTP ID DSNKT0WhA8nu2WfPrFJ2KyTSxqqVWE9HEGHw@postini.com; Wed, 22 Feb 2012 18:14:28 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; Wed, 22 Feb 2012 21:19:14 -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; Wed, 22 Feb 2012 21:14:26 -0500 Received: from inbmail01.lsi.com ([135.36.98.64]) by inbexch01.lsi.com ([135.36.98.37]) with mapi; Thu, 23 Feb 2012 07:44:23 +0530 From: "Desai, Kashyap" To: Chuck Swiger Date: Thu, 23 Feb 2012 07:44:21 +0530 Thread-Topic: mpslsi0 : Trying sleep, but thread marked as sleeping prohibited Thread-Index: AczxxToJrFdKBW0ORNyNsEGs5tS+qgACqMjw Message-ID: References: <20120222191519.GT55074@deviant.kiev.zoral.com.ua> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "freebsd-scsi@freebsd.org" , freebsd-stable , "McConnell, Stephen" Subject: RE: mpslsi0 : Trying sleep, but thread marked as sleeping prohibited X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 23 Feb 2012 02:14:29 -0000 > -----Original Message----- > From: Chuck Swiger [mailto:cswiger@mac.com] > Sent: Thursday, February 23, 2012 6:21 AM > To: Desai, Kashyap > Cc: freebsd-scsi@freebsd.org; freebsd-stable; McConnell, Stephen > Subject: Re: mpslsi0 : Trying sleep, but thread marked as sleeping > prohibited >=20 > On Feb 22, 2012, at 4:22 PM, Desai, Kashyap wrote: > > Just curious to know, What is a reason that thread can do blocking > sleep but can't do unbounded sleep ? >=20 > When you block, the scheduler can run other threads and only needs to > wake up and run your thread after the blocking condition is completed. >=20 > However, you don't want to busy-wait in a spin lock/mutex for any > lengthy period of time. If your thread was allowed to do an unbounded > sleep, especially in a fast interrupt handler context, what's going to > wake it up? An NMI like the reset button [1]? :-) When I started working on freebsd, first thing I noticed was ISR in freebsd= are thread. (special thread). But at least not like linux where we don't h= ave pid associate with ISR. So In Freebsd we will have thread id for related isr routine. Consider that fact, Even in fast interrupts handler context we should be ab= le to sleep. (e.a pause("mps_pause", (hz/1000));) Schedule can put thread into wait_queue and eventually when wait condition = meet, thread will be wake by OS. I mean if we can sleep in fast interrupt handler using mtx_ call, why not m= sleep/pause ? Sorry if I am extending this conversation. I really appreciate kind of help= from freebsd forum.! ` Kashyap >=20 > Regards, > -- > -Chuck >=20 > [1]: Well, you could also call STI to permit clock interrupts or > something else to fire an interrupt, but then your interrupt handler > needs to be re-entrant. (And watch out for multiple nested interrupts > blowing out the available stack space....) From owner-freebsd-stable@FreeBSD.ORG Thu Feb 23 03:11: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 9F9481065677 for ; Thu, 23 Feb 2012 03:11:58 +0000 (UTC) (envelope-from danfe@regency.nsu.ru) Received: from mx.nsu.ru (r2b9.nsu.ru [212.192.164.39]) by mx1.freebsd.org (Postfix) with ESMTP id 3DB118FC1A for ; Thu, 23 Feb 2012 03:11:57 +0000 (UTC) Received: from regency.nsu.ru ([193.124.210.26]) by mx.nsu.ru with esmtp (Exim 4.69) (envelope-from ) id 1S0Ooq-00046c-Or for stable@freebsd.org; Thu, 23 Feb 2012 09:54:08 +0700 Received: from regency.nsu.ru (localhost [127.0.0.1]) by regency.nsu.ru (8.14.2/8.14.2) with ESMTP id q1N2wV1P067600 for ; Thu, 23 Feb 2012 09:59:14 +0700 (NOVT) (envelope-from danfe@regency.nsu.ru) Received: (from danfe@localhost) by regency.nsu.ru (8.14.2/8.14.2/Submit) id q1N2vEOM067553 for stable@freebsd.org; Thu, 23 Feb 2012 09:57:14 +0700 (NOVT) (envelope-from danfe) Date: Thu, 23 Feb 2012 09:57:14 +0700 From: Alexey Dokuchaev To: stable@freebsd.org Message-ID: <20120223025713.GA65874@regency.nsu.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Cc: Subject: Resume broken in 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, 23 Feb 2012 03:11:58 -0000 Hi, Yesterday I've updated my laptop to the latest RELENG_8, it booted just fine, however, after coming out of suspend, keyboard does not work (well, almost: I can switch between consoles, Caps Lock works, but I cannot type anything, login, etc., break into debugger with Ctrl-Alt-Esc). Network does not work as well, and since fans are going up very fast, CPU consumption must be around 100%. Kernel from Jan 17th does not exhibit this problem. Plain console, no X11. Before I start to review all the changes in this period, perhaps someone can give me a hint which commit(s) might have caused it? Thanks, ./danfe From owner-freebsd-stable@FreeBSD.ORG Thu Feb 23 03:44:08 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 AF311106564A for ; Thu, 23 Feb 2012 03:44:08 +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 7C4668FC1C for ; Thu, 23 Feb 2012 03:44:08 +0000 (UTC) Received: by pbcxa7 with SMTP id xa7so1013392pbc.13 for ; Wed, 22 Feb 2012 19:44:08 -0800 (PST) Received-SPF: pass (google.com: domain of pyunyh@gmail.com designates 10.68.237.40 as permitted sender) client-ip=10.68.237.40; Authentication-Results: mr.google.com; spf=pass (google.com: domain of pyunyh@gmail.com designates 10.68.237.40 as permitted sender) smtp.mail=pyunyh@gmail.com; dkim=pass header.i=pyunyh@gmail.com Received: from mr.google.com ([10.68.237.40]) by 10.68.237.40 with SMTP id uz8mr1044939pbc.9.1329968648229 (num_hops = 1); Wed, 22 Feb 2012 19:44:08 -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=faEJi/zT+gAxZhA7sSmFCs+2V5diN1KZaO936brXD8Q=; b=TaU8RA59MFRvZETcj3twwqqyNNbqXHY0xRpgudTzesl7bzr5wROosRw6ebExwHPg0L DfKPPy2DMk3iGk+3tjtWvrmfYklRHwTO48ZZOP3nE4mz1ZTyMVlw0bm0RxS/Uqj5K4qO GN/yvhI7eumu52b/OasRG0vtxvi6yRtzvi6tQ= Received: by 10.68.237.40 with SMTP id uz8mr909768pbc.9.1329968648185; Wed, 22 Feb 2012 19:44:08 -0800 (PST) Received: from pyunyh@gmail.com ([114.111.62.249]) by mx.google.com with ESMTPS id f3sm246907pbr.61.2012.02.22.19.44.05 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 22 Feb 2012 19:44:07 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Thu, 23 Feb 2012 12:44:01 -0800 From: YongHyeon PYUN Date: Thu, 23 Feb 2012 12:44:01 -0800 To: Attila Nagy Message-ID: <20120223204401.GB13815@michelle.cdnetworks.com> References: <4F449E0B.2040909@fsn.hu> <20120223041516.GI6861@michelle.cdnetworks.com> <4F44FF2A.9050505@fsn.hu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F44FF2A.9050505@fsn.hu> User-Agent: Mutt/1.4.2.3i Cc: stable@freebsd.org Subject: Re: Fatal trap 19, Stopped at bge_init_locked+ and bge booting problems 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: Thu, 23 Feb 2012 03:44:08 -0000 On Wed, Feb 22, 2012 at 03:43:54PM +0100, Attila Nagy wrote: > On 02/23/12 05:15, YongHyeon PYUN wrote: > >bge0: mem > >0xf6bf0000-0xf6bfffff,0xf6be0000-0xf6beffff,0xf6bd0000-0xf6bdffff irq 32 > >at device 0.0 on pci3 > >bge0: CHIP ID 0x05719001; ASIC REV 0x5719; CHIP REV 0x57190; PCI-E > > ^^^^^^^^^^ > > > >This controller is new one. Probably BCM5719 A1 but not sure. > Yes, it's in a new machine. > > > > >>bge0: Try again > >This message indicates your controller has ASF/IPMI firmware. > >Try disabling ASF and see whether it makes any difference. > >(Change hw.bge.allow_asf tunable to 0). > Oh, I always forget that (on the other machines this is set). > This is what I get with > machdep.panic_on_nmi: 0 > machdep.kdb_on_nmi: 0 > hw.bge.allow_asf: 0 > I have to ask more information for the controller to Broadcom. Not sure whether I can get some hint at this moment though. :-( Given that you also have USB related errors, could you completely remove bge(4) in your kernel and see whether it can successfully boot up? I think you can add the following entries to /boot/device.hints without rebuilding kernel. hint.bge.0.disabled="1" hint.bge.1.disabled="1" hint.bge.2.disabled="1" hint.bge.3.disabled="1" > bge0: mem > 0xf6bf0000-0xf6bfffff,0xf6be0000-0xf6beffff,0xf6bd0000-0xf6bdffff irq 32 > at device 0.0 on pci3 > bge0: CHIP ID 0x05719001; ASIC REV 0x5719; CHIP REV 0x57190; PCI-E > bge0: Try again > miibus0: on bge0 > ukphy0: PHY 1 on miibus0 > ukphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, > 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, > auto-flow > bge0: Ethernet address: 3c:4a:92:b2:3c:08 > pci0:3:0:1: failed to read VPD data. > bge1: mem > 0xf6bc0000-0xf6bcffff,0xf6bb0000-0xf6bbffff,0xf6ba0000-0xf6baffff irq 36 > at device 0.1 on pci3 > bge1: CHIP ID 0x05719001; ASIC REV 0x5719; CHIP REV 0x57190; PCI-E > miibus1: on bge1 > brgphy0: PHY 2 on miibus1 > brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, > 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow > bge1: Ethernet address: 3c:4a:92:b2:3c:09 > pci0:3:0:2: failed to read VPD data. > bge2: mem > 0xf6b90000-0xf6b9ffff,0xf6b80000-0xf6b8ffff,0xf6b70000-0xf6b7ffff irq 32 > at device 0.2 on pci3 > bge2: CHIP ID 0x05719001; ASIC REV 0x5719; CHIP REV 0x57190; PCI-E > miibus2: on bge2 > brgphy1: PHY 3 on miibus2 > brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, > 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow > bge2: Ethernet address: 3c:4a:92:b2:3c:0a > pci0:3:0:3: failed to read VPD data. > bge3: mem > 0xf6b60000-0xf6b6ffff,0xf6b50000-0xf6b5ffff,0xf6b40000-0xf6b4ffff irq 36 > at device 0.3 on pci3 > bge3: CHIP ID 0x05719001; ASIC REV 0x5719; CHIP REV 0x57190; PCI-E > miibus3: on bge3 > brgphy2: PHY 4 on miibus3 > brgphy2: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, > 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow > bge3: Ethernet address: 3c:4a:92:b2:3c:0b > [...] > da0: 286070MB (585871964 512 byte sectors: 255H 32S/T 65535C) > NMI ISA 60, EISA ff > I/O channel check, likely hardware failure.Sending DHCP Discover packet > from interface bge0 (3c:4a:92:b2:3c:08) > cd0 at ata3 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 > bge0: 11 link states coalesced > bge0: link state changed to DOWN > ugen0.2: at usbus0 > uhub3: > on usbus0 > bge1: 5 link states coalesced > bge1: link state changed to DOWN > bge2: link state changed to DOWN > bge3: link state changed to DOWN > bge0: ugen2.2: at usbus2 > uhub4: > on usbus2 > 2 link states coalesced > bge0: link state changed to DOWN > bge1: 4 link states coalesced > bge1: link state changed to DOWN > bge0: 4 link states coalesced > bge0: link state changed to DOWN > Sending DHCP Discover packet from interface bge1 (3c:4a:92:b2:3c:09) > uhub3: 6 ports with 6 removable, self powered > bge0: usb_alloc_device: set address 2 failed (USB_ERR_TIMEOUT, ignored) > 6 link states coalesced > bge0: link state changed to DOWN > bge1: 2 link states coalesced > bge1: link state changed to DOWN > Sending DHCP Discover packet from interface bge2 (3c:4a:92:b2:3c:0a) > bge0: 2 link states coalesced > bge0: link state changed to DOWN > bge1: usbd_setup_device_desc: getting device descriptor at addr 2 > failed, USB_ERR_TIMEOUT > 10 link states coalesced > bge1: link state changed to DOWN > uhub4: 8 ports with 8 removable, self powered > bge0: 4 link states coalesced > bge0: link state changed to DOWN > bge1: 2 link states coalesced > bge1: link state changed to DOWN > Sending DHCP Discover packet from interface bge3 (3c:4a:92:b2:3c:0b) > bge0: 2 link states coalesced > bge0: link state changed to DOWN > bge1: 2 link states coalesced > bge1: link state changed to DOWN > ugen2.3: at usbus2 > uhub5: > on usbus2 > bge0: watchdog timeout -- resetting > bge0: link state changed to UP > usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, > ignored) > bge1: 2 link states coalesced > bge1: link state changed to DOWN > uhub5: 2 ports with 1 removable, self powered > bge0: link state changed to DOWN > bge1: watchdog timeout -- resetting > bge1: usbd_setup_device_desc: getting device descriptor at addr 2 > failed, USB_ERR_TIMEOUT > 2 link states coalesced > bge1: link state changed to DOWN > bge0: 2 link states coalesced > bge0: link state changed to DOWN > ugen1.2: at usbus1 > ukbd0: on usbus1 > kbd2 at ukbd0 > ums0: on usbus1 > bge1: 4 link states coalesced > bge1: link state changed to DOWN > bge0: 2 link states coalesced > bge0: link state changed to DOWN > bge1: 2 link states coalesced > bge1: link state changed to DOWN > bge1: 3 link states coalesced > bge1: link state changed to UP > bge0: 2 link states coalesced > bge0: link state changed to DOWN > bge1: link state changed to DOWN > bge0: 2 link states coalesced > bge0: link state changed to DOWN > bge1: 2 link states coalesced > bge1: link state changed to DOWN > bge1: 10 link states coalesced > bge1: link state changed to DOWN > bge0: 2 link states coalesced > bge0: link state changed to DOWN > bge1: 2 link states coalesced > bge1: link state changed to DOWN > bge1: link state changed to UP > bge0: watchdog timeout -- resetting > bge0: 2 link states coalesced > bge0: link state changed to DOWN > bge1: link state changed to DOWN > bge1: watchdog timeout -- resetting > bge1: 2 link states coalesced > bge1: link state changed to DOWN > bge0: 2 link states coalesced > bge0: link state changed to DOWN > bge1: 2 link states coalesced > bge1: link state changed to DOWN > bge1: 2 link states coalesced > bge1: link state changed to DOWN > bge0: 4 link states coalesced > bge0: link state changed to DOWN > bge1: 2 link states coalesced > bge1: link state changed to DOWN > bge0: 2 link states coalesced > bge0: link state changed to DOWN > bge1: 2 link states coalesced > bge1: link state changed to DOWN > bge0: 2 link states coalesced > bge0: link state changed to DOWN > bge1: link state changed to UP > bge1: link state changed to DOWN > [...] > > Still no go. From owner-freebsd-stable@FreeBSD.ORG Thu Feb 23 06:41:29 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 88C791065673 for ; Thu, 23 Feb 2012 06:41:29 +0000 (UTC) (envelope-from bra@fsn.hu) Received: from people.fsn.hu (people.fsn.hu [195.228.252.137]) by mx1.freebsd.org (Postfix) with ESMTP id 376C08FC16 for ; Thu, 23 Feb 2012 06:41:28 +0000 (UTC) Received: by people.fsn.hu (Postfix, from userid 1001) id CAAE0C25AF4; Thu, 23 Feb 2012 07:41:27 +0100 (CET) X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.2 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MF-ACE0E1EA [pR: 18.0227] X-CRM114-CacheID: sfid-20120223_07412_F29B03AE X-CRM114-Status: Good ( pR: 18.0227 ) X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Thu Feb 23 07:41:27 2012 X-DSPAM-Confidence: 0.9947 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 4f45df9724281914714480 X-DSPAM-Factors: 27, From*Attila Nagy , 0.00010, >+I, 0.00081, >+I, 0.00081, kernel, 0.00142, kernel, 0.00142, wrote+>, 0.00163, >+>, 0.00261, >+>, 0.00261, =+0, 0.00406, wrote, 0.00475, Is+there, 0.00579, boot, 0.00579, boot, 0.00579, interfaces, 0.00675, interfaces, 0.00675, hint, 0.00675, hint, 0.00675, References*fsn.hu>, 0.00675, References*fsn.hu>, 0.00675, Removing, 0.00675, >+Not, 0.00759, initialization, 0.00866, boot+from, 0.00866, boot+from, 0.00866, this+server, 0.01000, to+boot, 0.01000, X-Spambayes-Classification: ham; 0.00 Received: from japan.t-online.private (japan.t-online.co.hu [195.228.243.99]) by people.fsn.hu (Postfix) with ESMTPSA id 3A142C25AE5; Thu, 23 Feb 2012 07:41:25 +0100 (CET) Message-ID: <4F45DF95.9050309@fsn.hu> Date: Thu, 23 Feb 2012 07:41:25 +0100 From: Attila Nagy User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.23) Gecko/20090817 Thunderbird/2.0.0.23 Mnenhy/0.7.6.0 MIME-Version: 1.0 To: pyunyh@gmail.com References: <4F449E0B.2040909@fsn.hu> <20120223041516.GI6861@michelle.cdnetworks.com> <4F44FF2A.9050505@fsn.hu> <20120223204401.GB13815@michelle.cdnetworks.com> In-Reply-To: <20120223204401.GB13815@michelle.cdnetworks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org Subject: Re: Fatal trap 19, Stopped at bge_init_locked+ and bge booting problems X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 23 Feb 2012 06:41:29 -0000 On 02/23/12 21:44, YongHyeon PYUN wrote: > I have to ask more information for the controller to Broadcom. > Not sure whether I can get some hint at this moment though. :-( Is there anything I can do? I ask this because I have to give back this server very soon. > > Given that you also have USB related errors, could you completely > remove bge(4) in your kernel and see whether it can successfully > boot up? > I think you can add the following entries to /boot/device.hints > without rebuilding kernel. > > hint.bge.0.disabled="1" > hint.bge.1.disabled="1" > hint.bge.2.disabled="1" > hint.bge.3.disabled="1" This does not help. Removing bge makes it stop here: da0 at ciss0 bus 0 scbus0 target 0 lun 0 da0: Fixed Direct Access SCSI-5 device da0: 135.168MB/s transfers da0: Command Queueing enabled da0: 286070MB (585871964 512 byte sectors: 255H 32S/T 65535C) panic: bootpc_init: no eligible interfaces 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 bootpc_init() at bootpc_init+0x1205 mi_startup() at mi_startup+0x77 btext() at btext+0x2c KDB: enter: panic [ thread pid 0 tid 100000 ] Stopped at kdb_enter+0x3b: movq $0,0x976972(%rip) db> Which is completely OK, because there are really no interfaces to boot from. Note that there is no NMI either (maybe because it would happen later in the initialization process). Sadly, I can't boot from disk, but I assume it would work. From owner-freebsd-stable@FreeBSD.ORG Thu Feb 23 06:54: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 74522106564A; Thu, 23 Feb 2012 06:54:37 +0000 (UTC) (envelope-from zbeeble@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 9D4718FC15; Thu, 23 Feb 2012 06:54:36 +0000 (UTC) Received: by bkcjg1 with SMTP id jg1so1022340bkc.13 for ; Wed, 22 Feb 2012 22:54:35 -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=js53BQ1MdzOwPD4HrTs5EtfOvOMXCud7gkl4qPic+ig=; b=tsMSZPgUrZXzYvV1rfUyxUHFc+8uP6hJZ2Ye8O0Pp001+U94BIg8+L0pic84y7vGaF LTGoJoO/fW8PucqfLGg9bTwAAuBUgHmyCduSCIX4e9JjrNhJO12TLuqGbF1ZOC4ncmlO VYIUwI2E4/CqXTSbfxkcM5/IztoeNKiTePrIU= MIME-Version: 1.0 Received: by 10.204.145.145 with SMTP id d17mr8899bkv.77.1329978449153; Wed, 22 Feb 2012 22:27:29 -0800 (PST) Received: by 10.204.152.86 with HTTP; Wed, 22 Feb 2012 22:27:29 -0800 (PST) In-Reply-To: References: <20120222205231.GA81949@onelab2.iet.unipi.it> <1329944986.2621.46.camel@bwh-desktop> <20120222214433.GA82582@onelab2.iet.unipi.it> Date: Thu, 23 Feb 2012 01:27:29 -0500 Message-ID: From: Zaphod Beeblebrox To: Jack Vogel Content-Type: text/plain; charset=ISO-8859-1 Cc: Ben Hutchings , FreeBSD Net , Luigi Rizzo , re , FreeBSD stable Subject: Re: nmbclusters: how do we want to fix this for 8.3 ? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 23 Feb 2012 06:54:37 -0000 It could do some good to think of the scale of the problem and maybe the driver can tune to the hardware. First, is 8k packet buffers a reasonable default on a GigE port? Well... on a GigE port, you could have from 100k pps (packets per second) at 1500 bytes to 500k pps at around 300 bytes to truly pathological rates of packets (2M pps at the Ethernet-minimum of 64 bytes). 8k buffers vanish in 1/10th of a second in the 1500 byte case and that doesn't even really speak to the buffers getting emptied by other software. Do you maybe want to have a switch whereby the GigE port is in performance or non-performance mode? Do you want to assume that systems with GigE ports are also not pathologically low in memory? Perhaps in 10 or 100 megabit mode, the driver should make smaller rings? For that matter, if mbufs come in a page's worth at a time, what's the drawback of scaling them up and down with network vs. memory vs. cache pressure? From owner-freebsd-stable@FreeBSD.ORG Thu Feb 23 08:37: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 B648B106564A; Thu, 23 Feb 2012 08:37:19 +0000 (UTC) (envelope-from fabien.thomas@netasq.com) Received: from work.netasq.com (mars.netasq.com [91.212.116.3]) by mx1.freebsd.org (Postfix) with ESMTP id C18E58FC08; Thu, 23 Feb 2012 08:37:18 +0000 (UTC) Received: from [10.2.1.1] (unknown [10.2.1.1]) by work.netasq.com (Postfix) with ESMTPSA id AE232744006; Thu, 23 Feb 2012 09:18:12 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/signed; boundary="Apple-Mail=_D789DF06-0C84-453C-AD51-1C13DBE43289"; protocol="application/pkcs7-signature"; micalg=sha1 From: Fabien Thomas In-Reply-To: Date: Thu, 23 Feb 2012 09:19:13 +0100 Message-Id: <134564BB-676B-49BB-8BDA-6B8EB8965969@netasq.com> References: <20120222205231.GA81949@onelab2.iet.unipi.it> <1329944986.2621.46.camel@bwh-desktop> <20120222214433.GA82582@onelab2.iet.unipi.it> To: Jack Vogel X-Mailer: Apple Mail (2.1257) X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Ben Hutchings , FreeBSD Net , Luigi Rizzo , re , FreeBSD stable Subject: Re: nmbclusters: how do we want to fix this for 8.3 ? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 23 Feb 2012 08:37:19 -0000 --Apple-Mail=_D789DF06-0C84-453C-AD51-1C13DBE43289 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Le 22 f=E9vr. 2012 =E0 22:51, Jack Vogel a =E9crit : > On Wed, Feb 22, 2012 at 1:44 PM, Luigi Rizzo = wrote: >=20 >> On Wed, Feb 22, 2012 at 09:09:46PM +0000, Ben Hutchings wrote: >>> On Wed, 2012-02-22 at 21:52 +0100, Luigi Rizzo wrote: >> ... >>>> I have hit this problem recently, too. >>>> Maybe the issue mostly/only exists on 32-bit systems. >>>=20 >>> No, we kept hitting mbuf pool limits on 64-bit systems when we = started >>> working on FreeBSD support. >>=20 >> ok never mind then, the mechanism would be the same, though >> the limits (especially VM_LIMIT) would be different. >>=20 >>>> Here is a possible approach: >>>>=20 >>>> 1. nmbclusters consume the kernel virtual address space so there >>>> must be some upper limit, say >>>>=20 >>>> VM_LIMIT =3D 256000 (translates to 512MB of address space) >>>>=20 >>>> 2. also you don't want the clusters to take up too much of the >> available >>>> memory. This one would only trigger for minimal-memory systems, >>>> or virtual machines, but still... >>>>=20 >>>> MEM_LIMIT =3D (physical_ram / 2) / 2048 >>>>=20 >>>> 3. one may try to set a suitably large, desirable number of buffers >>>>=20 >>>> TARGET_CLUSTERS =3D 128000 >>>>=20 >>>> 4. and finally we could use the current default as the absolute = minimum >>>>=20 >>>> MIN_CLUSTERS =3D 1024 + maxusers*64 >>>>=20 >>>> Then at boot the system could say >>>>=20 >>>> nmbclusters =3D min(TARGET_CLUSTERS, VM_LIMIT, MEM_LIMIT) >>>>=20 >>>> nmbclusters =3D max(nmbclusters, MIN_CLUSTERS) >>>>=20 >>>>=20 >>>> In turn, i believe interfaces should do their part and by default >>>> never try to allocate more than a fraction of the total number >>>> of buffers, >>>=20 >>> Well what fraction should that be? It surely depends on how many >>> interfaces are in the system and how many queues the other = interfaces >>> have. >>=20 >>>> if necessary reducing the number of active queues. >>>=20 >>> So now I have too few queues on my interface even after I increase = the >>> limit. >>>=20 >>> There ought to be a standard way to configure numbers of queues and >>> default queue lengths. >>=20 >> Jack raised the problem that there is a poorly chosen default for >> nmbclusters, causing one interface to consume all the buffers. >> If the user explicitly overrides the value then >> the number of cluster should be what the user asks (memory = permitting). >> The next step is on devices: if there are no overrides, the default >> for a driver is to be lean. I would say that topping the request = between >> 1/4 and 1/8 of the total buffers is surely better than the current >> situation. Of course if there is an explicit override, then use >> it whatever happens to the others. >>=20 >> cheers >> luigi >>=20 >=20 > Hmmm, well, I could make the default use only 1 queue or something = like > that, > was thinking more of what actual users of the hardware would want. >=20 I think this is more reasonable to setup interface with one queue. Even if the cluster does not hit the max you will end up with unbalanced = setting that let very low mbuf count for other uses. > After the installed kernel is booted and the admin would do whatever = post > install > modifications they wish it could be changed, along with nmbclusters. >=20 > This was why i sought opinions, of the algorithm itself, but also = anyone > using > ixgbe and igb in heavy use, what would you find most convenient? >=20 > Jack > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" --Apple-Mail=_D789DF06-0C84-453C-AD51-1C13DBE43289-- From owner-freebsd-stable@FreeBSD.ORG Thu Feb 23 08:48: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 280F4106564A for ; Thu, 23 Feb 2012 08:48:47 +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 5F36C8FC1A for ; Thu, 23 Feb 2012 08:48:45 +0000 (UTC) Received: by bkcjg1 with SMTP id jg1so1088994bkc.13 for ; Thu, 23 Feb 2012 00:48: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; bh=2ripg7T6A7DLWtyIpGMKkvqqGEYOLVv49MMSPHikGy4=; b=pZX3t6SaXzZF90EzlP0jK6lCy/9Nn4oqeS+c41F1galOImdLwl+pCBbgb5T8KTOa7Y y8O0h2VL58NW0P5AiH7kjdjobGNAAQ2Gh2B2DS5V4AVJMaRIKkM2SwgrCxFJckr1DeOD WmtvXPS4L6WuX7qWKWJ7j++hypuCg7OGj93qE= MIME-Version: 1.0 Received: by 10.204.157.17 with SMTP id z17mr195468bkw.37.1329986924860; Thu, 23 Feb 2012 00:48:44 -0800 (PST) Received: by 10.204.51.212 with HTTP; Thu, 23 Feb 2012 00:48:44 -0800 (PST) In-Reply-To: <134564BB-676B-49BB-8BDA-6B8EB8965969@netasq.com> References: <20120222205231.GA81949@onelab2.iet.unipi.it> <1329944986.2621.46.camel@bwh-desktop> <20120222214433.GA82582@onelab2.iet.unipi.it> <134564BB-676B-49BB-8BDA-6B8EB8965969@netasq.com> Date: Thu, 23 Feb 2012 09:48:44 +0100 Message-ID: From: Andreas Nilsson To: Fabien Thomas 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 Net , Jack Vogel , Ben Hutchings , re , Luigi Rizzo Subject: Re: nmbclusters: how do we want to fix this for 8.3 ? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 23 Feb 2012 08:48:47 -0000 On Thu, Feb 23, 2012 at 9:19 AM, Fabien Thomas wr= ote: > > Le 22 f=E9vr. 2012 =E0 22:51, Jack Vogel a =E9crit : > > > On Wed, Feb 22, 2012 at 1:44 PM, Luigi Rizzo wrote= : > > > >> On Wed, Feb 22, 2012 at 09:09:46PM +0000, Ben Hutchings wrote: > >>> On Wed, 2012-02-22 at 21:52 +0100, Luigi Rizzo wrote: > >> ... > >>>> I have hit this problem recently, too. > >>>> Maybe the issue mostly/only exists on 32-bit systems. > >>> > >>> No, we kept hitting mbuf pool limits on 64-bit systems when we starte= d > >>> working on FreeBSD support. > >> > >> ok never mind then, the mechanism would be the same, though > >> the limits (especially VM_LIMIT) would be different. > >> > >>>> Here is a possible approach: > >>>> > >>>> 1. nmbclusters consume the kernel virtual address space so there > >>>> must be some upper limit, say > >>>> > >>>> VM_LIMIT =3D 256000 (translates to 512MB of address space) > >>>> > >>>> 2. also you don't want the clusters to take up too much of the > >> available > >>>> memory. This one would only trigger for minimal-memory systems, > >>>> or virtual machines, but still... > >>>> > >>>> MEM_LIMIT =3D (physical_ram / 2) / 2048 > >>>> > >>>> 3. one may try to set a suitably large, desirable number of buffers > >>>> > >>>> TARGET_CLUSTERS =3D 128000 > >>>> > >>>> 4. and finally we could use the current default as the absolute > minimum > >>>> > >>>> MIN_CLUSTERS =3D 1024 + maxusers*64 > >>>> > >>>> Then at boot the system could say > >>>> > >>>> nmbclusters =3D min(TARGET_CLUSTERS, VM_LIMIT, MEM_LIMIT) > >>>> > >>>> nmbclusters =3D max(nmbclusters, MIN_CLUSTERS) > >>>> > >>>> > >>>> In turn, i believe interfaces should do their part and by default > >>>> never try to allocate more than a fraction of the total number > >>>> of buffers, > >>> > >>> Well what fraction should that be? It surely depends on how many > >>> interfaces are in the system and how many queues the other interfaces > >>> have. > >> > >>>> if necessary reducing the number of active queues. > >>> > >>> So now I have too few queues on my interface even after I increase th= e > >>> limit. > >>> > >>> There ought to be a standard way to configure numbers of queues and > >>> default queue lengths. > >> > >> Jack raised the problem that there is a poorly chosen default for > >> nmbclusters, causing one interface to consume all the buffers. > >> If the user explicitly overrides the value then > >> the number of cluster should be what the user asks (memory permitting)= . > >> The next step is on devices: if there are no overrides, the default > >> for a driver is to be lean. I would say that topping the request betwe= en > >> 1/4 and 1/8 of the total buffers is surely better than the current > >> situation. Of course if there is an explicit override, then use > >> it whatever happens to the others. > >> > >> cheers > >> luigi > >> > > > > Hmmm, well, I could make the default use only 1 queue or something like > > that, > > was thinking more of what actual users of the hardware would want. > > > > I think this is more reasonable to setup interface with one queue. > Even if the cluster does not hit the max you will end up with unbalanced > setting that > let very low mbuf count for other uses. > If interfaces have the possibility to use more queues, they should, imo so I'm all for rasing the default size. For those systems with very limited memory it's easily changed. > > > After the installed kernel is booted and the admin would do whatever po= st > > install > > modifications they wish it could be changed, along with nmbclusters. > > > > This was why i sought opinions, of the algorithm itself, but also anyon= e > > using > > ixgbe and igb in heavy use, what would you find most convenient? > > > > Jack > > _______________________________________________ > > freebsd-net@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-net > > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > From owner-freebsd-stable@FreeBSD.ORG Thu Feb 23 08:52: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 C68BA106566B; Thu, 23 Feb 2012 08:52:01 +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 4DB048FC15; Thu, 23 Feb 2012 08:52:01 +0000 (UTC) Received: from mail.0x20.net (mail.0x20.net [217.69.76.211]) by mail.0x20.net (Postfix) with ESMTP id 1E5C46A6012; Thu, 23 Feb 2012 09:52:00 +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 b8Ty3ylRFztF; Thu, 23 Feb 2012 09:51:59 +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 C44266A6011; Thu, 23 Feb 2012 09:51:59 +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 q1N8pxka056660; Thu, 23 Feb 2012 09:51:59 +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 q1N8pxJY055275; Thu, 23 Feb 2012 09:51:59 +0100 (CET) (envelope-from lars) Date: Thu, 23 Feb 2012 09:51:59 +0100 From: Lars Engels To: Alexander Leidinger Message-ID: <20120223085159.GU14469@e-new.0x20.net> References: <20120221143537.Horde.deyFDZjmRSRPQ52pxBIpnLA@webmail.leidinger.net> <20120223091808.Horde.iJJvNZjmRSRPRfZAlqnPsrA@webmail.leidinger.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="95xjieIIiUQImiTX" Content-Disposition: inline In-Reply-To: <20120223091808.Horde.iJJvNZjmRSRPRfZAlqnPsrA@webmail.leidinger.net> 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: "Bjoern A. Zeeb" , stable@FreeBSD.org, current@FreeBSD.org Subject: Re: [CFT] modular kernel config X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 23 Feb 2012 08:52:01 -0000 --95xjieIIiUQImiTX Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Feb 23, 2012 at 09:18:08AM +0100, Alexander Leidinger wrote: > Quoting "Bjoern A. Zeeb" (from Wed, =20 > 22 Feb 2012 22:31:36 +0000): >=20 > > On 21. Feb 2012, at 13:35 , Alexander Leidinger wrote: > > > >> You can download from > >> http://www.Leidinger.net/FreeBSD/current-patches/ > >> The files are > >> - i386_SMALL > >> - i386_SMALL_loader.conf > >> - amd64_SMALL > >> - amd64_SMALL_loader.conf > > > > I only looked at the laoder.conf for amd64 and the only comment I =20 > > have is that I do not have the time to wait minutes for all =20 > > individual modules to be loaded. This is going to be really bad for = =20 > > boot time. >=20 > Well, nobody forces you to use it. And as can be seen on the lists, =20 > there are patches floating around to improve the loading speed of the =20 > loader. You can also put most of the modules in rc.conf: kld_list=3D"umass u3g" ... That speeds up loading the modules a lot. >=20 > This is also just an example to be on par as much as possible with =20 > GENERIC. People which want to use this kernel most probably want to =20 > cut the loader.conf down and maybe even want to use the rc.conf =20 > setting to load modules which are not needed to boot. One additional advantage is that you have a bigger chance of a working suspend / resume. Just unload all problematic modules before suspending and re-load them after resuming. --95xjieIIiUQImiTX Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk9F/i8ACgkQKc512sD3afhlRQCgtWN7Du1OYN0UqzTC0dpbqewM C2wAoJ+/4e5PES5mAG0G/SjpMxRlMmpm =x9fI -----END PGP SIGNATURE----- --95xjieIIiUQImiTX-- From owner-freebsd-stable@FreeBSD.ORG Thu Feb 23 08:56: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 28FAF1065670 for ; Thu, 23 Feb 2012 08:56:31 +0000 (UTC) (envelope-from ask@develooper.com) Received: from mbox1.develooper.com (mbox1.develooper.com [207.171.7.178]) by mx1.freebsd.org (Postfix) with ESMTP id 0ABDE8FC0C for ; Thu, 23 Feb 2012 08:56:30 +0000 (UTC) Received: (qmail 3670 invoked from network); 23 Feb 2012 08:56:26 -0000 Received: from cpe-76-172-28-38.socal.res.rr.com (HELO embla.bn.dev) (ask@mail.dev@76.172.28.38) by smtp.develooper.com with ESMTPA; 23 Feb 2012 08:56:26 -0000 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Ask_Bj=F8rn_Hansen?= In-Reply-To: Date: Thu, 23 Feb 2012 00:56:24 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <1E0D6546-49DE-478C-9759-FE496B1F0DB8@develooper.com> References: <770EEEFF-B41D-4851-AD74-C3F96FFB1683@develooper.com> To: Artem Belevich X-Mailer: Apple Mail (2.1257) Cc: freebsd-stable@freebsd.org, freebsd-zfs@freebsd.org Subject: Re: Can't read a full block, only got 8193 bytes. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 23 Feb 2012 08:56:31 -0000 On Feb 19, 2012, at 12:10, Artem Belevich wrote: [...] >> "Can't read a full block, only got 8193 bytes." >=20 > That's probably just a side effect of ZFS checksum errors. ZFS will > happily read the file until it hits a record with checksum. If > redundant info is available (raidz or mirror), ZFS will attempt to > recover your data. If there's no redundancy you will get read error. > If you do "zpool status -v" you should see list of files affected by > corruption. Hi Artem, Thank you for the reply and the tips! =20 That makes sense and explains why we'd just get checksum errors on a = raidz1 test (but bonnie++ was happy except things were slow), but had = the weird errors on a single disk pool. >> This seems to only be when testing a single ZFS disk or a UFS = partition. Testing a raidz1 we just get checksum errors noted in zpool = status, but no errors reading (though read speeds are ~10MB/second = across four disks -- writing sequentially was ~230MB/second). >>=20 >> Any ideas where to start look? >=20 > You need to figure out why you're getting checksum errors. Alas > there's probably no easy way to troubleshoot it. The issue could be > hardware related and possible culprits may include bad RAM, bad SATA > cables, quirks of particular firmware revision on disk controller > and/or hard drive. Replacing the 3ware controller with a basic LSI controller fixed the = problems and improved performance, so I guess the 3ware controller = doesn't play nice with the Seagate 3TB disks (they're not on their = compatibility list). Ask From owner-freebsd-stable@FreeBSD.ORG Thu Feb 23 09:03: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 609F81065673; Thu, 23 Feb 2012 09:03: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 CB6B78FC08; Thu, 23 Feb 2012 09:03: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 q1N93BgA027397; Thu, 23 Feb 2012 11:03:14 +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 q1N93Boj044762; Thu, 23 Feb 2012 11:03:11 +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 q1N93Bhq044761; Thu, 23 Feb 2012 11:03:11 +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, 23 Feb 2012 11:03:11 +0200 From: Konstantin Belousov To: Rick Macklem Message-ID: <20120223090311.GA55074@deviant.kiev.zoral.com.ua> References: <201202221633.02170.jhb@freebsd.org> <476361430.1773817.1329954835308.JavaMail.root@erie.cs.uoguelph.ca> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="72pTQ1Q5L511SwPT" Content-Disposition: inline In-Reply-To: <476361430.1773817.1329954835308.JavaMail.root@erie.cs.uoguelph.ca> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: stable@freebsd.org, John Baldwin Subject: Re: panic in 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, 23 Feb 2012 09:03:37 -0000 --72pTQ1Q5L511SwPT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 22, 2012 at 06:53:55PM -0500, Rick Macklem wrote: > John Baldwin wrote: > > On Wednesday, February 22, 2012 2:24:14 pm Konstantin Belousov wrote: > > > On Wed, Feb 22, 2012 at 11:29:40AM -0500, Rick Macklem wrote: > > > > Hiroki Sato wrote: > > > > > Hi, > > > > > > > > > > Just a report, but I got the following panic on an NFS server > > > > > running > > > > > 8.3-PRERELEASE: > > > > > > > > > > ----(from here)---- > > > > > pool.allbsd.org dumped core - see /var/crash/vmcore.0 > > > > > > > > > > Tue Feb 21 10:59:44 JST 2012 > > > > > > > > > > FreeBSD pool.allbsd.org 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE > > > > > #7: Thu > > > > > Feb 16 19:29:19 JST 2012 > > > > > hrs@pool.allbsd.org:/usr/obj/usr/src/sys/POOL > > > > > amd64 > > > > > > > > > > panic: Assertion lock =3D=3D sq->sq_lock failed at > > > > > /usr/src/sys/kern/subr_sleepqueue.c:335 > > > > > > > > > Oops, I didn't know that mixing msleep() and tsleep() calls on the > > > > same > > > > event wasn't allowed. > > > > There are two places in the code where it did a: > > > > mtx_unlock(); > > > > tsleep(); > > > > left over from the days when it was written for OpenBSD. > > > This sequence allows to lost the wakeup which is happen right after > > > cache unlock (together with clearing the RC_WANTED flag) but before > > > the thread enters sleep state. The tsleep has a timeout so thread > > > should > > > recover in 10 seconds, but still. > > > > > > Anyway, you should use consistent outer lock for the same wchan, > > > i.e. > > > no lock (tsleep) or mtx (msleep), but not mix them. > >=20 > > Correct. > >=20 > > > > I don't think the mix would actually break anything, except that > > > > the > > > > MPASS() assertion fails, but I've cc'd jhb@ since he seems to have > > > > been > > > > the author of the sleep() stuff. > > > > > > > > Anyhow, please try the attached patch which replaces the > > > > mtx_unlock(); > > tsleep(); with > > > > msleep()s using PDROP. If the attachment gets lost, the patch is > > > > also > > here: > > > > http://people.freebsd.org/~rmacklem/tsleep.patch > > > > > > > > Thanks for reporting this, rick > > > > ps: Is mtx_lock() now preferred over msleep()? > > > What do you mean ? > >=20 > > mtx_sleep() is preferred over msleep(), but I doubt I will remove > > msleep() > > anytime soon. > >=20 > Ok, I'll redo the patch with mtx_sleep() and get one of you guys to > review it. I do not see a need in the changing to mtx_sleep, esp. if other places in nfsd use msleep(). There are more then 570 uses of msleep(9) in the kernel, and undefined number of them in third-party modules. >=20 > One question. Do you think this is serious enough to worry about for > 8.3? (Just wondering if I need to rush a patch into head with a 1 week > MFC. I realize it would still be up to re@, even if I rush it.) I think it is usual routine bugfix, which is as good to have in release as any other bugfix. 8.3 is in the stabilization period, made exactly for pushing bugfixes. --72pTQ1Q5L511SwPT Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk9GAM8ACgkQC3+MBN1Mb4h+CQCfSo1K540I0l3aa2Lqub5e0pzI XzYAoKbnJbm/qNi7MRMWVSyWWpGrUUOn =yDow -----END PGP SIGNATURE----- --72pTQ1Q5L511SwPT-- From owner-freebsd-stable@FreeBSD.ORG Thu Feb 23 09:25: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 9C60E106566B; Thu, 23 Feb 2012 09:25: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 294788FC16; Thu, 23 Feb 2012 09:25: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 q1N9OwaE036298; Thu, 23 Feb 2012 11:24:58 +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 q1N9OwRM044834; Thu, 23 Feb 2012 11:24:58 +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 q1N9OvTG044833; Thu, 23 Feb 2012 11:24:57 +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, 23 Feb 2012 11:24:57 +0200 From: Konstantin Belousov To: "Desai, Kashyap" Message-ID: <20120223092457.GB55074@deviant.kiev.zoral.com.ua> References: <20120222191519.GT55074@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ATYltwmfWCpDp8Ax" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: "freebsd-scsi@freebsd.org" , "Kenneth D. Merry" , "Justin T. Gibbs" , freebsd-stable , "McConnell, Stephen" Subject: Re: mpslsi0 : Trying sleep, but thread marked as sleeping prohibited X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 23 Feb 2012 09:25:18 -0000 --ATYltwmfWCpDp8Ax Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Feb 23, 2012 at 05:52:12AM +0530, Desai, Kashyap wrote: >=20 >=20 > > -----Original Message----- > > From: Konstantin Belousov [mailto:kostikbel@gmail.com] > > Sent: Thursday, February 23, 2012 12:45 AM > > To: Desai, Kashyap > > Cc: freebsd-scsi@freebsd.org; freebsd-stable; Justin T. Gibbs; Kenneth > > D. Merry; McConnell, Stephen > > Subject: Re: mpslsi0 : Trying sleep, but thread marked as sleeping > > prohibited > >=20 > > On Wed, Feb 22, 2012 at 07:36:42PM +0530, Desai, Kashyap wrote: > > > Hi, > > > > > > I am doing some code changes in mps dirver. While working on those > > changes, I come to know about something which is new to me. > > > Some expert help is required to clarify my doubt. > > > > > > 1. When any irq is register with FreeBSD OS, it sets " TDP_NOSLEEPING" > > > pflag. It means though irq in freebsd is treated as thread, We cannot > > sleep in IRQ because of " "TDP_NOSLEEPING " set. > > > 2. In mps driver we have below code snippet in ISR routine. > > > > > > > > > mps_dprint(sc, MPS_TRACE, "%s\n", __func__); > > > mps_lock(sc); > > > mps_intr_locked(data); > > > mps_unlock(sc); > > > > > > I wonder why there is no issue with above code ? Theoretical we cannot > > > sleep in ISR. (as explained in #1) Any thoughts ? > > > > > > > > > 3. I recently added few place msleep() instead of DELAY in ISR context > > > and I see " Trying sleep, but thread marked as sleeping prohibited". > > > > > FreeBSD has several basic ways to prevent a thread from executing on > > CPU. > > They mostly fall into two categories: bounded sleep, sometimes called > > blocking, and unbounded sleep, usually abbreviated as sleep. The bounded > > there refers to amount of code executed by other thread that hold > > resource preventing blocked thread from making a progress. > >=20 > > Examples of the blocking primitives are mutexes, rw locks and rm locks. > > The blocking is not counted as sleeping, so interrupt threads, which are > > designated as non-sleeping, still can lock mutexes. > Thanks for the tech help. .=20 >=20 > As per you comment, So now I understood as "TDP_NOSLEEPING" is only > for unbounded sleep restriction. Just curious to know, What is a > reason that thread can do blocking sleep but can't do unbounded sleep > ? Since technically we introduced sleeping restriction on interrupt > thread is to avoid starvation and that can be fit with either of the > sleep type. Is this not true ? No, not to avoid starvation. The intent of the blocking primitives is to acquire resources for limited amount of time. In other words, you never take a mutex for undefinitely long computation process. On the other hand, msleep sleep usually has no limitations. You do not want the interrupt thread to be put off the processor for undefined time, so sleep is prohibited. Another issue is that sleeping locks do not do priority propagation to the resource owners, while turnstiles used for blocking do. This way, interrupt thread waiting for mutex donates its priority to the current mutex owner, or at least it shall do. >=20 > I will be able to progress on my work based on your comment. A much thank= s for correcting my doubt. >=20 > ~ Kashyap >=20 > >=20 > > Examples of the sleeping primitives are msleep(), sx locks, lockmgr > > locks and conditional variables. > >=20 > > In essence, the locking facilities are split into several classes that > > form the hierarchy, and you cannot legally obtain the lock of higher > > class while holding a lock of lower class: > > spin mutexes -> blocking locks -> sleeping locks. > > It establishes some meta-order on the all locks. > >=20 > > Does this make sense ? >=20 --ATYltwmfWCpDp8Ax Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk9GBekACgkQC3+MBN1Mb4gWYACdF0VYEz9/Zlgfb3xdfANWWZar j6IAoPD8FnxUrm+aokl/YQqtevqYMLrU =4uF7 -----END PGP SIGNATURE----- --ATYltwmfWCpDp8Ax-- From owner-freebsd-stable@FreeBSD.ORG Thu Feb 23 09:46: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 2733D106564A; Thu, 23 Feb 2012 09:46:14 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from mx0.hoeg.nl (mx0.hoeg.nl [IPv6:2a01:4f8:101:5343::aa]) by mx1.freebsd.org (Postfix) with ESMTP id D7AF08FC0A; Thu, 23 Feb 2012 09:46:13 +0000 (UTC) Received: by mx0.hoeg.nl (Postfix, from userid 1000) id BCC462A28CB7; Thu, 23 Feb 2012 10:46:11 +0100 (CET) Date: Thu, 23 Feb 2012 10:46:11 +0100 From: Ed Schouten To: "Desai, Kashyap" Message-ID: <20120223094611.GC32748@hoeg.nl> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="KN5l+BnMqAQyZLvT" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable , "joerg@FreeBSD.org" , "Kenneth D. Merry" , "freebsd-scsi@freebsd.org" , "Justin T. Gibbs" , "McConnell, Stephen" Subject: Re: mpslsi0 : Trying sleep, but thread marked as sleeping prohibited X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 23 Feb 2012 09:46:14 -0000 --KN5l+BnMqAQyZLvT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Kashyap, * Desai, Kashyap , 20120222 18:51: > Adding Ed Schouten and Jorg Wunsch as I see there are author of > msleep/mtx related APIs. Am I? :-) > 1. When any irq is register with FreeBSD OS, it sets " TDP_NOSLEEPING" > pflag. It means though irq in freebsd is treated as thread, > We cannot sleep in IRQ because of " "TDP_NOSLEEPING " set. > 2. In mps driver we have below code snippet in ISR routine. >=20 >=20 > mps_dprint(sc, MPS_TRACE, "%s\n", __func__); > mps_lock(sc); > mps_intr_locked(data); > mps_unlock(sc); >=20 > I wonder why there is no issue with above code ? Theoretical we cannot > sleep in ISR. (as explained in #1) > Any thoughts ? The TDP_NOSLEEPING flag only disallows sleeping of an indeterminate amount of time. Locking a mutex is allowed, as it can only cause the thread to be blocked for a small amount of time, waiting for another thread to unlock it. > 3. I recently added few place msleep() instead of DELAY in ISR context > and I see > " Trying sleep, but thread marked as sleeping prohibited". Which makes sense, as msleep() can be used to sleep for indefinitely. --=20 Ed Schouten WWW: http://80386.nl/ --KN5l+BnMqAQyZLvT Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iQIcBAEBAgAGBQJPRgrjAAoJEG5e2P40kaK7Wk4P/RSI//kT8DyA0dSBCZbSyA74 CA94Gxdd6NE+O5BVcgqdylN9v8Zp4eQ0QWhg/jYOWZR0VqH0o8hLbF9rICj1k9TV S6i7xNT+9weMo45fQaWJM4iyEW5J+S+mhm2qvxMEx2Goy0nMSS9vfQ/oU/ouZ6Nh Hz5lSjTefG7Bv6YIbKMeNder+RhbKl82yxbMGlfvLQwbPcQD+VRzD0sY/vD9neuB UneFt41BWytryGsh5jc3qNlWq3aP0xb/QGOmMwQKXBfrhgDCDWO1X4h5JmrUoLG0 UwGa1ForcdEVGoNSbFqkHThq0pPqEgUWaP+kCrsr565d6wh/dTuBzf+l2+788oT7 8XxNVtPfmcKevFJISMmFT/YyvNoYIIkzVdSN/kNf3LZHX/iawptbeFylwd0FB0GM ITw15B4oGp6zUi9oZMR5hTayUW5UZM88jIxlSEgXsqN/ipLZeWl5JNVSjQDbH2tK A+AsDtqGybM5YZoDVoHFkl3LhoRBkxMiPdowl9geAD7rZxdK/EA6znUa6ojpsaGw nNBIUPFAW/dogxNMky461hhb1D77BzwY6fObPY9B71wiXV/cyEAUeVLP1dQ9Fn2Y 2xL3Mei7fVS101OgARK854bddQc8schDoETQk+O54o//JkDypSpjC9nUd6DWXjHN Zt7ZGjMJOjOfAHsksMl5 =+cMB -----END PGP SIGNATURE----- --KN5l+BnMqAQyZLvT-- From owner-freebsd-stable@FreeBSD.ORG Thu Feb 23 08:00: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 BDF23106566B for ; Thu, 23 Feb 2012 08:00:19 +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 404D38FC17 for ; Thu, 23 Feb 2012 08:00:18 +0000 (UTC) Received: from outgoing.leidinger.net (p5796DADA.dip.t-dialin.net [87.150.218.218]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id E6E208443F4; Thu, 23 Feb 2012 08:59:47 +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 3BF145871; Thu, 23 Feb 2012 08:59:45 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=leidinger.net; s=outgoing-alex; t=1329983985; bh=YCF7G4ZLHS9tq1VERKM4am9vBQ1njHa7MckaXDNZYNk=; h=Date:Message-ID:From:To:Cc:Subject:References:In-Reply-To: Content-Type:MIME-Version; b=N/jRXGmk9qlNTCzFy5TNAxtkf73JHMfovy/4AiZ00QzsUBeXUKXrA2efwbL7LTqox 904lUu4BJrJxDOa7w+BufpOdR2cFgf8xMFUfCaFU0YNAfasNnf5ET6NdHV7H3/jyzN SLLbKxCCxmpRPAECY7JBEZITl0Ig6wkfUKiT76Slor1cRrFZPm9aFXwOL6L9GrWJ9H ua/tTMRGrCJiXoBlNBPyh2KhjtrnBnjjlKBGlv86Zowh06K7gMnXDhSzCdiH/Zhu35 lUwkwLXJqtjOi2wlMAN2LWNmgdUZLDxKB2ZRgvziZfkLQkPCrMWqt90Kcvz1Xh3Hhw dRlDU5QaGFTHA== Received: (from www@localhost) by webmail.leidinger.net (8.14.5/8.14.4/Submit) id q1N7xiiT064354; Thu, 23 Feb 2012 08:59:44 +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; Thu, 23 Feb 2012 08:59:44 +0100 Date: Thu, 23 Feb 2012 08:59:44 +0100 Message-ID: <20120223085944.Horde.s19XAJjmRSRPRfHwZpOPszA@webmail.leidinger.net> From: Alexander Leidinger To: ~Lst References: <20120221143537.Horde.deyFDZjmRSRPQ52pxBIpnLA@webmail.leidinger.net> <1329890164178-5504219.post@n5.nabble.com> <20120222140308.Horde.RjSecpjmRSRPROeM24KCgsA@webmail.leidinger.net> In-Reply-To: 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: E6E208443F4.A4530 X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=0.828, required 6, autolearn=disabled, AWL -1.92, DKIM_SIGNED 0.10, DKIM_VALID -0.10, DKIM_VALID_AU -0.10, RCVD_IN_BL_SPAMCOP_NET 1.25, RCVD_IN_SORBS 1.00, RCVD_IN_SORBS_WEB 0.61, T_RP_MATCHES_RCVD -0.01) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1330588789.26881@2D2/ee+6y+rP4vz2xce00g X-EBL-Spam-Status: No X-Mailman-Approved-At: Thu, 23 Feb 2012 12:36:09 +0000 Cc: freebsd-stable@freebsd.org Subject: Re: [CFT] modular kernel config X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 23 Feb 2012 08:00:19 -0000 Quoting ~Lst (from Wed, 22 Feb 2012 21:53:56 +0700): > It's typo too .. > > net.inet.ip.stealth: IP stealth mode, no TTL decrementation on forwarding > > In your file's (i386|amd64)__SMALL_loader.conf : > > # Disable stealth forwarding and flowtable. > net.inet.ip.stealt=0 > net.inet6.ip6.stealt=0 Fixed. Thanks, Alexander. -- Anoint, v.: To grease a king or other great functionary already sufficiently slippery. -- Ambrose Bierce, "The Devil's Dictionary" 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 Thu Feb 23 08:18:28 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 09CD9106566C; Thu, 23 Feb 2012 08:18:28 +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 5C9BC8FC12; Thu, 23 Feb 2012 08:18:27 +0000 (UTC) Received: from outgoing.leidinger.net (p5796DADA.dip.t-dialin.net [87.150.218.218]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id E00A48443F4; Thu, 23 Feb 2012 09:18:11 +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 3B5FA5874; Thu, 23 Feb 2012 09:18:09 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=leidinger.net; s=outgoing-alex; t=1329985089; bh=n/8tqMAMV0zvAeAUKkq7aOssJFpINvxzCNlvS2KQ/fc=; h=Date:Message-ID:From:To:Cc:Subject:References:In-Reply-To: Content-Type:MIME-Version; b=CWVOlZvZuLGgsMzNVmGZx+PkckR+ChxhwhR7xzYa6SwIpUkUfgy6NEXP3fyz3BlZ2 bPvDYnRdElI/kphIruLKJrrRuTRV201R/3b6j1WUojDDkZM8Agm5o3IxJuYiQhVnBb d9LYLxqw/T9+iduWxtPOp3/pvEHOYQkFjJ6h/FHT7bl22HpgI30w/BSe2C+/HKSxzN 8OW2d3WuS8gXX9+Hq1SHEpINTqHquVHzpwoqsIYVVanrtALKFvBduiBO7GrQLaSc8z 9v0UUIhBiWgCDfajGxNJzOebjLijYHim+ToOkSGZahuMR3LqAZXRPZOWlcDVIMVTJm eOQDnRdywWiUg== Received: (from www@localhost) by webmail.leidinger.net (8.14.5/8.14.4/Submit) id q1N8I8IE065619; Thu, 23 Feb 2012 09:18:08 +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; Thu, 23 Feb 2012 09:18:08 +0100 Date: Thu, 23 Feb 2012 09:18:08 +0100 Message-ID: <20120223091808.Horde.iJJvNZjmRSRPRfZAlqnPsrA@webmail.leidinger.net> From: Alexander Leidinger To: "Bjoern A. Zeeb" References: <20120221143537.Horde.deyFDZjmRSRPQ52pxBIpnLA@webmail.leidinger.net> In-Reply-To: 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: E00A48443F4.A24BA X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=0.851, required 6, autolearn=disabled, AWL -1.90, DKIM_SIGNED 0.10, DKIM_VALID -0.10, DKIM_VALID_AU -0.10, RCVD_IN_BL_SPAMCOP_NET 1.25, RCVD_IN_SORBS 1.00, RCVD_IN_SORBS_WEB 0.61, T_RP_MATCHES_RCVD -0.01) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1330589894.31449@8v3cMtv6G7/X0Puk9DUvDg X-EBL-Spam-Status: No X-Mailman-Approved-At: Thu, 23 Feb 2012 12:36:24 +0000 Cc: stable@FreeBSD.org, current@FreeBSD.org Subject: Re: [CFT] modular kernel config X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 23 Feb 2012 08:18:28 -0000 Quoting "Bjoern A. Zeeb" (from Wed, 22 Feb 2012 22:31:36 +0000): > On 21. Feb 2012, at 13:35 , Alexander Leidinger wrote: > >> You can download from >> http://www.Leidinger.net/FreeBSD/current-patches/ >> The files are >> - i386_SMALL >> - i386_SMALL_loader.conf >> - amd64_SMALL >> - amd64_SMALL_loader.conf > > I only looked at the laoder.conf for amd64 and the only comment I > have is that I do not have the time to wait minutes for all > individual modules to be loaded. This is going to be really bad for > boot time. Well, nobody forces you to use it. And as can be seen on the lists, there are patches floating around to improve the loading speed of the loader. This is also just an example to be on par as much as possible with GENERIC. People which want to use this kernel most probably want to cut the loader.conf down and maybe even want to use the rc.conf setting to load modules which are not needed to boot. >> The new stuff in the kernel config compared to GENERIC is (in order >> of number of requests from users): >> - IPSEC (+ device enc + IPSEC_NAT_T) > > You cannot ship that on by default for non-tecnical reasons in a > kernel. Please do not commit a kernel config that can be booted (no > LINT cannot be booted) with these on without consulting appropriate > hats upfront. I planned to contact core to ask if there are some US export restrictions to take into account before committing. Do you have a different hat in mind? >> - ALTQ >> - SW_WATCHDOG >> - QUOTA >> - IPSTEALTH (disabled in loader.conf) >> - IPFIREWALL_FORWARD (touches every packet, power users which need >> a bigger PPS but not this feature can recompile the kernel, >> discussed with julian@) >> - FLOWTABLE (disabled in loader.conf) > > Which is not the same as it's not 100% disabled and will still > allocate memory. I assume this means that the sideeffects are only some conditionals more for the packets which pass the corresponding kernel places (to check if the feature is enabled, I had a look for the IPFIREWALL_FORWARD and IPSTEALTH options regarding this). Regarding the memory usage I assume this means that if someone removes the loading of modules he does not use from the loader.conf, he will use less memory with those things enabled, than would be used by a GENERIC kernel. Both of those things where taken into account before providing this config here. As I wrote above, people which need the last few PPS more can compile a kernel without those features (they are power-users), while people which do not want to compile kernels at all (and there are a lot of such people, just have a look at how many people use freebsd-update and you will get an idea about the target audience) get more features to play with. This is also not supposed to replace GENERIC, but it coud be offered as an option to install this kernel instead of GENERIC (or we can install in in parallel and the user can chose which kernel he wants to boot, or ...). 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 Thu Feb 23 13:15: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 7AEC2106566B; Thu, 23 Feb 2012 13:15:36 +0000 (UTC) (envelope-from Kashyap.Desai@lsi.com) Received: from na3sys009aog105.obsmtp.com (na3sys009aog105.obsmtp.com [74.125.149.75]) by mx1.freebsd.org (Postfix) with ESMTP id 768248FC13; Thu, 23 Feb 2012 13:15:35 +0000 (UTC) Received: from paledge01.lsi.com ([192.19.193.42]) (using TLSv1) by na3sys009aob105.postini.com ([74.125.148.12]) with SMTP ID DSNKT0Y79jrMvJtxitf75DYklripRivWpX58@postini.com; Thu, 23 Feb 2012 05:15:36 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; Thu, 23 Feb 2012 08:20:19 -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; Thu, 23 Feb 2012 08:15:33 -0500 Received: from inbmail01.lsi.com ([135.36.98.64]) by inbexch01.lsi.com ([135.36.98.37]) with mapi; Thu, 23 Feb 2012 18:45:30 +0530 From: "Desai, Kashyap" To: Ed Schouten Date: Thu, 23 Feb 2012 18:45:29 +0530 Thread-Topic: mpslsi0 : Trying sleep, but thread marked as sleeping prohibited Thread-Index: AczyD/02FbCI9SrkQyKSb+ipNDdQzAAHNqbg Message-ID: References: <20120223094611.GC32748@hoeg.nl> In-Reply-To: <20120223094611.GC32748@hoeg.nl> 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 , "joerg@FreeBSD.org" , "Kenneth D. Merry" , "freebsd-scsi@freebsd.org" , "Justin T. Gibbs" , "McConnell, Stephen" Subject: RE: mpslsi0 : Trying sleep, but thread marked as sleeping prohibited X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 23 Feb 2012 13:15:36 -0000 > -----Original Message----- > From: Ed Schouten [mailto:ed@80386.nl] > Sent: Thursday, February 23, 2012 3:16 PM > To: Desai, Kashyap > Cc: freebsd-scsi@freebsd.org; freebsd-stable; joerg@FreeBSD.org; Kenneth > D. Merry; McConnell, Stephen; Justin T. Gibbs > Subject: Re: mpslsi0 : Trying sleep, but thread marked as sleeping > prohibited >=20 > Hi Kashyap, >=20 > * Desai, Kashyap , 20120222 18:51: > > Adding Ed Schouten and Jorg Wunsch as I see there are author of > > msleep/mtx related APIs. >=20 > Am I? :-) I am new to FreeBSD and desperate to know the answer. :-). Thanks for your = help. >=20 > > 1. When any irq is register with FreeBSD OS, it sets " TDP_NOSLEEPING" > > pflag. It means though irq in freebsd is treated as thread, We cannot > > sleep in IRQ because of " "TDP_NOSLEEPING " set. > > 2. In mps driver we have below code snippet in ISR routine. > > > > > > mps_dprint(sc, MPS_TRACE, "%s\n", __func__); > > mps_lock(sc); > > mps_intr_locked(data); > > mps_unlock(sc); > > > > I wonder why there is no issue with above code ? Theoretical we cannot > > sleep in ISR. (as explained in #1) Any thoughts ? >=20 > The TDP_NOSLEEPING flag only disallows sleeping of an indeterminate > amount of time. Locking a mutex is allowed, as it can only cause the > thread to be blocked for a small amount of time, waiting for another > thread to unlock it. So does this assumption that another thread will release mutex fast enough = ? Same as msleep() this can be applicable here as well. I mean another thread= _can_ (if some bad drivers) take long time to release mutex. >=20 > > 3. I recently added few place msleep() instead of DELAY in ISR context > > and I see " Trying sleep, but thread marked as sleeping prohibited". >=20 > Which makes sense, as msleep() can be used to sleep for indefinitely. This part is clear. ! I agree with all experts view.=20 >=20 > -- > Ed Schouten > WWW: http://80386.nl/ From owner-freebsd-stable@FreeBSD.ORG Thu Feb 23 13:22: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 B36C71065670; Thu, 23 Feb 2012 13:22:15 +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 B7C358FC13; Thu, 23 Feb 2012 13:22:14 +0000 (UTC) Received: from paledge01.lsi.com ([192.19.193.42]) (using TLSv1) by na3sys009aob110.postini.com ([74.125.148.12]) with SMTP ID DSNKT0Y9hlkV3GddnhIt39PwVHD848jt0Sma@postini.com; Thu, 23 Feb 2012 05:22:15 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; Thu, 23 Feb 2012 08:26:57 -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; Thu, 23 Feb 2012 08:22:11 -0500 Received: from inbmail01.lsi.com ([135.36.98.64]) by inbexch01.lsi.com ([135.36.98.37]) with mapi; Thu, 23 Feb 2012 18:52:08 +0530 From: "Desai, Kashyap" To: Konstantin Belousov Date: Thu, 23 Feb 2012 18:52:07 +0530 Thread-Topic: mpslsi0 : Trying sleep, but thread marked as sleeping prohibited Thread-Index: AczyDROYsJKb9H2BQMOCoaNj4iTZKAAIFAPA Message-ID: References: <20120222191519.GT55074@deviant.kiev.zoral.com.ua> <20120223092457.GB55074@deviant.kiev.zoral.com.ua> In-Reply-To: <20120223092457.GB55074@deviant.kiev.zoral.com.ua> 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-scsi@freebsd.org" , "Kenneth D. Merry" , "Justin T. Gibbs" , freebsd-stable , "McConnell, Stephen" Subject: RE: mpslsi0 : Trying sleep, but thread marked as sleeping prohibited X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 23 Feb 2012 13:22:15 -0000 > -----Original Message----- > From: Konstantin Belousov [mailto:kostikbel@gmail.com] > Sent: Thursday, February 23, 2012 2:55 PM > To: Desai, Kashyap > Cc: freebsd-scsi@freebsd.org; freebsd-stable; Justin T. Gibbs; Kenneth > D. Merry; McConnell, Stephen > Subject: Re: mpslsi0 : Trying sleep, but thread marked as sleeping > prohibited >=20 > On Thu, Feb 23, 2012 at 05:52:12AM +0530, Desai, Kashyap wrote: > > > > > > > -----Original Message----- > > > From: Konstantin Belousov [mailto:kostikbel@gmail.com] > > > Sent: Thursday, February 23, 2012 12:45 AM > > > To: Desai, Kashyap > > > Cc: freebsd-scsi@freebsd.org; freebsd-stable; Justin T. Gibbs; > > > Kenneth D. Merry; McConnell, Stephen > > > Subject: Re: mpslsi0 : Trying sleep, but thread marked as sleeping > > > prohibited > > > > > > On Wed, Feb 22, 2012 at 07:36:42PM +0530, Desai, Kashyap wrote: > > > > Hi, > > > > > > > > I am doing some code changes in mps dirver. While working on those > > > changes, I come to know about something which is new to me. > > > > Some expert help is required to clarify my doubt. > > > > > > > > 1. When any irq is register with FreeBSD OS, it sets " > TDP_NOSLEEPING" > > > > pflag. It means though irq in freebsd is treated as thread, We > > > > cannot > > > sleep in IRQ because of " "TDP_NOSLEEPING " set. > > > > 2. In mps driver we have below code snippet in ISR routine. > > > > > > > > > > > > mps_dprint(sc, MPS_TRACE, "%s\n", __func__); > > > > mps_lock(sc); > > > > mps_intr_locked(data); > > > > mps_unlock(sc); > > > > > > > > I wonder why there is no issue with above code ? Theoretical we > > > > cannot sleep in ISR. (as explained in #1) Any thoughts ? > > > > > > > > > > > > 3. I recently added few place msleep() instead of DELAY in ISR > > > > context and I see " Trying sleep, but thread marked as sleeping > prohibited". > > > > > > > FreeBSD has several basic ways to prevent a thread from executing on > > > CPU. > > > They mostly fall into two categories: bounded sleep, sometimes > > > called blocking, and unbounded sleep, usually abbreviated as sleep. > > > The bounded there refers to amount of code executed by other thread > > > that hold resource preventing blocked thread from making a progress. > > > > > > Examples of the blocking primitives are mutexes, rw locks and rm > locks. > > > The blocking is not counted as sleeping, so interrupt threads, which > > > are designated as non-sleeping, still can lock mutexes. > > Thanks for the tech help. . > > > > As per you comment, So now I understood as "TDP_NOSLEEPING" is only > > for unbounded sleep restriction. Just curious to know, What is a > > reason that thread can do blocking sleep but can't do unbounded sleep > > ? Since technically we introduced sleeping restriction on interrupt > > thread is to avoid starvation and that can be fit with either of the > > sleep type. Is this not true ? > No, not to avoid starvation. >=20 > The intent of the blocking primitives is to acquire resources for > limited amount of time. In other words, you never take a mutex for > undefinitely long computation process. On the other hand, msleep sleep > usually has no limitations. I got same reply from Ed Schouten. I agree and understood your note. Thanks= for poring knowledge on this area. _but_ only query is when thread take mutex, we don't know when it will rele= ase. So holding time of mutex is really not known. In case of some bad code, where thread took mutex and not release within sh= ort time. This can eventually match upto msleep restriction as well. Do we have any checks that thread took long time holding mutext ? Similar = to linux where spinlock has been not release in some specific time, they du= mp warnings with backtrace. ~ Kashyap >=20 > You do not want the interrupt thread to be put off the processor for > undefined time, so sleep is prohibited. >=20 > Another issue is that sleeping locks do not do priority propagation to > the resource owners, while turnstiles used for blocking do. This way, > interrupt thread waiting for mutex donates its priority to the current > mutex owner, or at least it shall do. >=20 > > > > I will be able to progress on my work based on your comment. A much > thanks for correcting my doubt. > > > > ~ Kashyap > > > > > > > > Examples of the sleeping primitives are msleep(), sx locks, lockmgr > > > locks and conditional variables. > > > > > > In essence, the locking facilities are split into several classes > > > that form the hierarchy, and you cannot legally obtain the lock of > > > higher class while holding a lock of lower class: > > > spin mutexes -> blocking locks -> sleeping locks. > > > It establishes some meta-order on the all locks. > > > > > > Does this make sense ? > > From owner-freebsd-stable@FreeBSD.ORG Thu Feb 23 13:22: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 32000106566C for ; Thu, 23 Feb 2012 13:22:59 +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 E334F8FC08 for ; Thu, 23 Feb 2012 13:22:58 +0000 (UTC) Received: by gilb.zs64.net (Postfix, from stb@lassitu.de) id B26082408C; Thu, 23 Feb 2012 13:22:57 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Stefan Bethke In-Reply-To: <201202221334.36484.erich@alogreentechnologies.com> Date: Thu, 23 Feb 2012 14:22:57 +0100 Content-Transfer-Encoding: 7bit Message-Id: <64FF3DF7-6EEA-480D-85AA-5784AF013EA8@lassitu.de> References: <201202221334.36484.erich@alogreentechnologies.com> To: Erich Dollansky X-Mailer: Apple Mail (2.1084) Cc: freebsd-stable@freebsd.org Subject: Re: random problem with 8.3 from yesterday X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 23 Feb 2012 13:22:59 -0000 Am 22.02.2012 um 07:34 schrieb Erich Dollansky: > > tunefs -L NewDeviceName /dev/da0a > > Either this call or the mount command does not work randomly. > > When I then try to mount the device on /dev/da0a it does not work always. > > I do not know what this causes, I am only randomly able to reproduce it. > > It might be affected by removing the device or keeping it plugged in. You need to be more specific: what "does not work" mean? Output, results? Stefan -- Stefan Bethke Fon +49 151 14070811 From owner-freebsd-stable@FreeBSD.ORG Thu Feb 23 14:15: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 E65F01065674; Thu, 23 Feb 2012 14:15:25 +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 2BA748FC16; Thu, 23 Feb 2012 14:15:24 +0000 (UTC) Received: from alph.allbsd.org (p1012-ipbf2105funabasi.chiba.ocn.ne.jp [114.148.160.12]) (authenticated bits=128) by mail.allbsd.org (8.14.4/8.14.4) with ESMTP id q1NEF3Fu045867; Thu, 23 Feb 2012 23:15:13 +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 q1NEF0Tp069073; Thu, 23 Feb 2012 23:15:02 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Thu, 23 Feb 2012 23:14:52 +0900 (JST) Message-Id: <20120223.231452.2197780863243078154.hrs@allbsd.org> To: rmacklem@uoguelph.ca From: Hiroki Sato In-Reply-To: <476361430.1773817.1329954835308.JavaMail.root@erie.cs.uoguelph.ca> References: <201202221633.02170.jhb@freebsd.org> <476361430.1773817.1329954835308.JavaMail.root@erie.cs.uoguelph.ca> 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(Thu_Feb_23_23_14_52_2012_010)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.allbsd.org [133.31.130.32]); Thu, 23 Feb 2012 23:15:17 +0900 (JST) X-Spam-Status: No, score=-100.8 required=13.0 tests=BAYES_00, CONTENT_TYPE_PRESENT,RCVD_IN_PBL,RCVD_IN_RP_RNBL,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: kostikbel@gmail.com, stable@FreeBSD.org, jhb@FreeBSD.org Subject: Re: panic in 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, 23 Feb 2012 14:15:26 -0000 ----Security_Multipart(Thu_Feb_23_23_14_52_2012_010)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Rick Macklem wrote in <476361430.1773817.1329954835308.JavaMail.root@erie.cs.uoguelph.ca>: rm> John Baldwin wrote: rm> > On Wednesday, February 22, 2012 2:24:14 pm Konstantin Belousov wrote: rm> > > On Wed, Feb 22, 2012 at 11:29:40AM -0500, Rick Macklem wrote: rm> > > > Hiroki Sato wrote: rm> > > > > Hi, rm> > > > > rm> > > > > Just a report, but I got the following panic on an NFS server rm> > > > > running rm> > > > > 8.3-PRERELEASE: rm> > > > > rm> > > > > ----(from here)---- rm> > > > > pool.allbsd.org dumped core - see /var/crash/vmcore.0 rm> > > > > rm> > > > > Tue Feb 21 10:59:44 JST 2012 rm> > > > > rm> > > > > FreeBSD pool.allbsd.org 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE rm> > > > > #7: Thu rm> > > > > Feb 16 19:29:19 JST 2012 rm> > > > > hrs@pool.allbsd.org:/usr/obj/usr/src/sys/POOL rm> > > > > amd64 rm> > > > > rm> > > > > panic: Assertion lock == sq->sq_lock failed at rm> > > > > /usr/src/sys/kern/subr_sleepqueue.c:335 rm> > > > > rm> > > > Oops, I didn't know that mixing msleep() and tsleep() calls on the rm> > > > same rm> > > > event wasn't allowed. rm> > > > There are two places in the code where it did a: rm> > > > mtx_unlock(); rm> > > > tsleep(); rm> > > > left over from the days when it was written for OpenBSD. rm> > > This sequence allows to lost the wakeup which is happen right after rm> > > cache unlock (together with clearing the RC_WANTED flag) but before rm> > > the thread enters sleep state. The tsleep has a timeout so thread rm> > > should rm> > > recover in 10 seconds, but still. rm> > > rm> > > Anyway, you should use consistent outer lock for the same wchan, rm> > > i.e. rm> > > no lock (tsleep) or mtx (msleep), but not mix them. rm> > rm> > Correct. rm> > rm> > > > I don't think the mix would actually break anything, except that rm> > > > the rm> > > > MPASS() assertion fails, but I've cc'd jhb@ since he seems to have rm> > > > been rm> > > > the author of the sleep() stuff. rm> > > > rm> > > > Anyhow, please try the attached patch which replaces the rm> > > > mtx_unlock(); rm> > tsleep(); with rm> > > > msleep()s using PDROP. If the attachment gets lost, the patch is rm> > > > also rm> > here: rm> > > > http://people.freebsd.org/~rmacklem/tsleep.patch rm> > > > rm> > > > Thanks for reporting this, rick rm> > > > ps: Is mtx_lock() now preferred over msleep()? rm> > > What do you mean ? rm> > rm> > mtx_sleep() is preferred over msleep(), but I doubt I will remove rm> > msleep() rm> > anytime soon. rm> > rm> Ok, I'll redo the patch with mtx_sleep() and get one of you guys to rm> review it. Thank you for the patch! I applied it and put the box under a stress testing again. -- Hiroki ----Security_Multipart(Thu_Feb_23_23_14_52_2012_010)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEABECAAYFAk9GSdwACgkQTyzT2CeTzy3WywCglyyNDeby0X3s1i551DJfB0Nj yjoAn2OzyCU3KdCK1b2ra/88RHXfhem2 =dUUz -----END PGP SIGNATURE----- ----Security_Multipart(Thu_Feb_23_23_14_52_2012_010)---- From owner-freebsd-stable@FreeBSD.ORG Thu Feb 23 14:44: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 8EF6E106566C for ; Thu, 23 Feb 2012 14:44:57 +0000 (UTC) (envelope-from timp87@gmail.com) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) by mx1.freebsd.org (Postfix) with ESMTP id 66CE28FC18 for ; Thu, 23 Feb 2012 14:44:57 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1S0Zui-0006Ao-IF for freebsd-stable@freebsd.org; Thu, 23 Feb 2012 06:44:56 -0800 Date: Thu, 23 Feb 2012 06:44:56 -0800 (PST) From: timp To: freebsd-stable@freebsd.org Message-ID: <1330008296493-5508227.post@n5.nabble.com> In-Reply-To: <20120221143537.Horde.deyFDZjmRSRPQ52pxBIpnLA@webmail.leidinger.net> References: <20120221143537.Horde.deyFDZjmRSRPQ52pxBIpnLA@webmail.leidinger.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [CFT] modular kernel config X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 23 Feb 2012 14:44:57 -0000 missing in loader.conf geom_part_gpt_load="YES" geom_label_load="YES" -- View this message in context: http://freebsd.1045724.n5.nabble.com/CFT-modular-kernel-config-tp5502195p5508227.html Sent from the freebsd-stable mailing list archive at Nabble.com. From owner-freebsd-stable@FreeBSD.ORG Thu Feb 23 14:47:24 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 930A8106564A for ; Thu, 23 Feb 2012 14:47:24 +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 2C1EA8FC13 for ; Thu, 23 Feb 2012 14:47:22 +0000 (UTC) Received: from alph.allbsd.org (p1012-ipbf2105funabasi.chiba.ocn.ne.jp [114.148.160.12]) (authenticated bits=128) by mail.allbsd.org (8.14.4/8.14.4) with ESMTP id q1NEl1lr053891 for ; Thu, 23 Feb 2012 23:47:12 +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 q1NEl0T5069510 for ; Thu, 23 Feb 2012 23:47:01 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Thu, 23 Feb 2012 23:45:58 +0900 (JST) Message-Id: <20120223.234558.1101656075598772176.hrs@allbsd.org> To: stable@FreeBSD.org From: Hiroki Sato 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(Thu_Feb_23_23_45_58_2012_702)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.allbsd.org [133.31.130.32]); Thu, 23 Feb 2012 23:47:17 +0900 (JST) X-Spam-Status: No, score=-99.6 required=13.0 tests=BAYES_00, CONTENT_TYPE_PRESENT,FAKEDWORD_ONE,FAKEDWORD_VERTICALLINE,QENCPTR1, RCVD_IN_PBL, RCVD_IN_RP_RNBL, 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: Subject: another panic in 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, 23 Feb 2012 14:47:24 -0000 ----Security_Multipart(Thu_Feb_23_23_45_58_2012_702)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, This is another reproducible panic. This seems to happen only when top(1) is running for a long time (a sysctl() call for CTL_KERN.KERN_PROC.KERN_PROC_PROC MIB triggered it). ---- pool.allbsd.org dumped core - see /var/crash/vmcore.0 Thu Feb 23 23:21:52 JST 2012 FreeBSD pool.allbsd.org 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #8: Thu Feb 23 04:40:54 JST 2012 hrs@pool.allbsd.org:/usr/obj/usr/src/sys/POOL amd64 panic: 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"... Unread portion of the kernel message buffer: Fatal trap 12: page fault while in kernel mode cpuid = 4; apic id = 04 fault virtual address = 0x800e96000 fault code = supervisor write data, protection violation instruction pointer = 0x20:0xffffffff809440cb stack pointer = 0x28:0xffffff86c63890b0 frame pointer = 0x28:0xffffff86c6389100 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 = 47211 (top) lock order reversal: (Giant after non-sleepable) 1st 0xffffff0244b85568 process lock (process lock) @ /usr/src/sys/kern/kern_proc.c:1211 2nd 0xffffffff80d74c80 Giant (Giant) @ /usr/src/sys/dev/usb/input/ukbd.c:2018 KDB: stack backtrace: Dumping 23903 out of 24550 MB:..1%..11%..21%..31% (CTRL-C to abort) (CTRL-C to abort) ..41%..51%..61%..71%..81%..91% Reading symbols from /boot/kernel/geom_mirror.ko...Reading symbols from /boot/kernel/geom_mirror.ko.symbols...done. done. Loaded symbols for /boot/kernel/geom_mirror.ko Reading symbols from /boot/kernel/zfs.ko...Reading symbols from /boot/kernel/zfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/zfs.ko Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols from /boot/kernel/opensolaris.ko.symbols...done. done. Loaded symbols for /boot/kernel/opensolaris.ko Reading symbols from /boot/kernel/ipfw.ko...Reading symbols from /boot/kernel/ipfw.ko.symbols...done. done. Loaded symbols for /boot/kernel/ipfw.ko #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:263 263 if (textdump_pending) (kgdb) #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:263 #1 0xffffffff801f8cfc in db_fncall (dummy1=Variable "dummy1" is not available. ) at /usr/src/sys/ddb/db_command.c:548 #2 0xffffffff801f9031 in db_command (last_cmdp=0xffffffff80d37f40, cmd_table=Variable "cmd_table" is not available. ) at /usr/src/sys/ddb/db_command.c:445 #3 0xffffffff801f9280 in db_command_loop () at /usr/src/sys/ddb/db_command.c:498 #4 0xffffffff801fb369 in db_trap (type=Variable "type" is not available. ) at /usr/src/sys/ddb/db_main.c:229 #5 0xffffffff8069dff1 in kdb_trap (type=12, code=0, tf=0xffffff86c6389000) at /usr/src/sys/kern/subr_kdb.c:548 #6 0xffffffff809461ed in trap_fatal (frame=0xffffff86c6389000, eva=Variable "eva" is not available. ) at /usr/src/sys/amd64/amd64/trap.c:820 #7 0xffffffff809468b5 in trap (frame=0xffffff86c6389000) at /usr/src/sys/amd64/amd64/trap.c:326 #8 0xffffffff8092d2f4 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:228 #9 0xffffffff809440cb in copyout () at /usr/src/sys/amd64/amd64/support.S:258 #10 0xffffffff80675f1f in sysctl_old_user (req=0xffffff86c63899c0, p=0xffffff86c6389470, l=1088) at /usr/src/sys/kern/kern_sysctl.c:1276 #11 0xffffffff8065f6a6 in sysctl_out_proc_copyout (ki=0xffffff86c6389470, req=0xffffff86c63899c0) at /usr/src/sys/kern/kern_proc.c:1085 #12 0xffffffff8065ff6c in sysctl_out_proc (p=0xffffff0244b85470, req=0xffffff86c63899c0, flags=Variable "flags" is not available. ) at /usr/src/sys/kern/kern_proc.c:1114 #13 0xffffffff8066245e in sysctl_kern_proc (oidp=Variable "oidp" is not available. ) at /usr/src/sys/kern/kern_proc.c:1302 #14 0xffffffff806756e8 in sysctl_root (oidp=Variable "oidp" is not available. ) at /usr/src/sys/kern/kern_sysctl.c:1455 #15 0xffffffff8067598e in userland_sysctl (td=0x0, name=0xffffff86c6389a80, namelen=3, old=0x800e96000, oldlenp=Variable "oldlenp" is not available. ) at /usr/src/sys/kern/kern_sysctl.c:1565 #16 0xffffffff80675e3a in __sysctl (td=0xffffff0396ec5460, uap=0xffffff86c6389bc0) at /usr/src/sys/kern/kern_sysctl.c:1491 #17 0xffffffff80945809 in amd64_syscall (td=0xffffff0396ec5460, traced=0) at subr_syscall.c:114 #18 0xffffffff8092d5ec in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:387 #19 0x0000000800abecfc in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) ---- db> show alllocks Process 1169 (sshd) thread 0xffffff0022cfa460 (100715) exclusive sx so_rcv_sx (so_rcv_sx) r = 0 (0xffffff0022d358f0) locked @ /usr/src/sys/kern/uipc_sockbuf.c:148 Process 865 (nfsd) thread 0xffffff00221b8000 (100611) exclusive lockmgr zfs (zfs) r = 0 (0xffffff02430e7d80) locked @ /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c:1700 Process 865 (nfsd) thread 0xffffff00221b28c0 (100595) shared lockmgr zfs (zfs) r = 0 (0xffffff053a49fd80) locked @ /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c:1700 Process 865 (nfsd) thread 0xffffff00221b3460 (100593) exclusive lockmgr zfs (zfs) r = 0 (0xffffff01e3aa87f8) locked @ /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c:1700 Process 865 (nfsd) thread 0xffffff002219a8c0 (100590) exclusive lockmgr zfs (zfs) r = 0 (0xffffff0570d1f620) locked @ /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c:1700 Process 865 (nfsd) thread 0xffffff00221a2460 (100579) shared lockmgr zfs (zfs) r = 0 (0xffffff0566a86d80) locked @ /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c:1700 Process 865 (nfsd) thread 0xffffff0022193460 (100574) exclusive lockmgr zfs (zfs) r = 0 (0xffffff05cbbc4ba8) locked @ /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c:1700 Process 865 (nfsd) thread 0xffffff0022194000 (100572) shared lockmgr zfs (zfs) r = 0 (0xffffff001d4137f8) locked @ /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c:1700 Process 865 (nfsd) thread 0xffffff0022195000 (100569) exclusive lockmgr zfs (zfs) r = 0 (0xffffff056d8cb620) locked @ /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c:1700 Process 865 (nfsd) thread 0xffffff002218f000 (100549) shared lockmgr zfs (zfs) r = 0 (0xffffff02a8fcbd80) locked @ /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c:1700 Process 865 (nfsd) thread 0xffffff002218f8c0 (100547) exclusive lockmgr zfs (zfs) r = 0 (0xffffff0482a7d7f8) locked @ /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c:1700 Process 865 (nfsd) thread 0xffffff0022188460 (100534) exclusive lockmgr zfs (zfs) r = 0 (0xffffff01d13d0ba8) locked @ /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c:1700 Process 865 (nfsd) thread 0xffffff002218a000 (100532) shared lockmgr zfs (zfs) r = 0 (0xffffff0071c7e620) locked @ /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c:1700 Process 865 (nfsd) thread 0xffffff002218a8c0 (100530) shared lockmgr zfs (zfs) r = 0 (0xffffff017cc947f8) locked @ /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c:1700 Process 865 (nfsd) thread 0xffffff00222fa8c0 (100525) exclusive lockmgr zfs (zfs) r = 0 (0xffffff014757aba8) locked @ /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c:1700 exclusive lockmgr zfs (zfs) r = 0 (0xffffff0366c7f9d0) locked @ /usr/src/sys/kern/vfs_lookup.c:504 Process 865 (nfsd) thread 0xffffff00222fb000 (100524) exclusive lockmgr zfs (zfs) r = 0 (0xffffff01b735b448) locked @ /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c:1700 Process 865 (nfsd) thread 0xffffff0022183000 (100515) shared lockmgr zfs (zfs) r = 0 (0xffffff058c41c098) locked @ /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c:1700 Process 865 (nfsd) thread 0xffffff0022183460 (100514) exclusive lockmgr zfs (zfs) r = 0 (0xffffff01dc0ebd80) locked @ /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c:1700 Process 865 (nfsd) thread 0xffffff00222f28c0 (100505) exclusive lockmgr zfs (zfs) r = 0 (0xffffff04b1503098) locked @ /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c:1700 Process 865 (nfsd) thread 0xffffff00222f5460 (100500) shared lockmgr zfs (zfs) r = 0 (0xffffff05d7345620) locked @ /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c:1700 Process 865 (nfsd) thread 0xffffff00222f6000 (100498) exclusive lockmgr zfs (zfs) r = 0 (0xffffff02db1fb448) locked @ /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c:1700 Process 865 (nfsd) thread 0xffffff00222e88c0 (100494) shared lockmgr zfs (zfs) r = 0 (0xffffff02f6ccf620) locked @ /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c:1700 Process 865 (nfsd) thread 0xffffff00222ea460 (100489) exclusive sleep mutex mbuf (UMA zone) r = 0 (0xffffff063ffdf010) locked @ /usr/src/sys/vm/uma_core.c:2549 Process 865 (nfsd) thread 0xffffff00222ec460 (100483) exclusive lockmgr zfs (zfs) r = 0 (0xffffff05f6827448) locked @ /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c:1700 Process 865 (nfsd) thread 0xffffff00222e28c0 (100477) exclusive sleep mutex nfs_cache_mutex (nfs_cache_mutex) r = 0 (0xffffffff80d6af00) locked @ /usr/src/sys/fs/nfsserver/nfs_nfsdcache.c:710 Process 865 (nfsd) thread 0xffffff00222e4460 (100472) exclusive lockmgr zfs (zfs) r = 0 (0xffffff06102dc9d0) locked @ /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c:1700 Process 865 (nfsd) thread 0xffffff00222e78c0 (100465) shared lockmgr zfs (zfs) r = 0 (0xffffff00314249d0) locked @ /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c:1700 Process 865 (nfsd) thread 0xffffff00222d88c0 (100460) shared lockmgr zfs (zfs) r = 0 (0xffffff05f94be448) locked @ /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c:1700 Process 865 (nfsd) thread 0xffffff00222d9460 (100458) exclusive lockmgr zfs (zfs) r = 0 (0xffffff03901d19d0) locked @ /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c:1700 Process 865 (nfsd) thread 0xffffff00222dc460 (100449) shared lockmgr zfs (zfs) r = 0 (0xffffff013b57d9d0) locked @ /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c:1700 Process 865 (nfsd) thread 0xffffff00222ce8c0 (100443) exclusive lockmgr zfs (zfs) r = 0 (0xffffff0392ed5270) locked @ /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c:1700 Process 865 (nfsd) thread 0xffffff00222d3000 (100433) exclusive lockmgr zfs (zfs) r = 0 (0xffffff0034744ba8) locked @ /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c:1700 Process 865 (nfsd) thread 0xffffff002203c000 (100425) shared lockmgr zfs (zfs) r = 0 (0xffffff05c3947620) locked @ /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c:1700 Process 865 (nfsd) thread 0xffffff00222c1000 (100416) exclusive lockmgr zfs (zfs) r = 0 (0xffffff05102cf620) locked @ /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c:1700 Process 865 (nfsd) thread 0xffffff00222728c0 (100412) shared lockmgr zfs (zfs) r = 0 (0xffffff025c88a620) locked @ /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c:1700 Process 865 (nfsd) thread 0xffffff000cfb0460 (100407) exclusive lockmgr zfs (zfs) r = 0 (0xffffff01b121f448) locked @ /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c:1700 Process 865 (nfsd) thread 0xffffff00222b78c0 (100386) shared lockmgr zfs (zfs) r = 0 (0xffffff0199eaad80) locked @ /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c:1700 Process 865 (nfsd) thread 0xffffff00222b3000 (100368) exclusive lockmgr zfs (zfs) r = 0 (0xffffff0493abad80) locked @ /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c:1700 Process 18 (syncer) thread 0xffffff000c81d000 (100108) exclusive lockmgr syncer (syncer) r = 0 (0xffffff000e0b1ba8) locked @ /usr/src/sys/kern/vfs_subr.c:1770 --- ------------------------------------------------------------------------ ps -axl UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME COMMAND 0 0 0 0 -8 0 0 0 - DLs ?? 237844023158:14.90 [kernel] 0 1 0 0 52 0 3200 0 wait DLs ?? 2999235:54.00 [init] 0 2 0 0 -8 0 0 0 - DL ?? 2583291:48.00 [g_event] 0 3 0 0 -8 0 0 0 - RL ?? 8333529047:38.00 [g_up] 0 4 0 0 -8 0 0 0 - DL ?? 15508645836:58.00 [g_down] 0 5 0 0 -16 0 0 0 mps_sc DL ?? 6921236:34.00 [mps_scan0] 0 6 0 0 -16 0 0 0 waitin DL ?? 1851:28.00 [sctp_itera 0 7 0 0 -16 0 0 0 ccb_sc DL ?? 0:00.00 [xpt_thrd] 0 8 0 0 -16 0 0 0 psleep DL ?? 1117119713:56.00 [pagedaemon 0 9 0 0 -16 0 0 0 psleep DL ?? 398139:12.00 [vmdaemon] 0 10 0 0 -16 0 0 0 audit_ DL ?? 0:00.00 [audit] 0 11 0 0 171 0 0 0 - RL ?? 184151273702:09.87 [idle] 0 12 0 0 -60 0 0 0 - WL ?? 30539688189:18.00 [intr] 0 13 0 0 -16 0 0 0 - DL ?? 3943794171:44.00 [yarrow] 0 14 0 0 -40 0 0 0 - DL ?? 126924074:38.00 [usb] 0 15 0 0 76 0 0 0 pgzero DL ?? 24451:52.00 [pagezero] 0 16 0 0 -16 0 0 0 psleep DL ?? 8680471:14.00 [bufdaemon] 0 17 0 0 47 0 0 0 vlruwt DL ?? 1621276224:34.00 [vnlru] 0 18 0 0 20 0 0 0 syncer DL ?? 6868829552:00.00 [syncer] 0 19 0 0 -16 0 0 0 sdflus DL ?? 23321024:10.00 [softdepflu 0 20 0 0 -8 0 0 0 m:w1 DL ?? 46710556:18.00 [g_mirror g 0 60 0 0 -8 0 0 0 tx->tx DL ?? 59193927259:42.00 [zfskern] 0 113 0 0 -8 0 0 0 mdwait DL ?? 60546:18.00 [md0] 0 153 1 0 76 0 5832 508 pause DWs ?? 0:00.00 [adjkerntz] 0 732 1 0 44 0 6920 0 swread DLs ?? 4569221:32.00 [syslogd] 0 747 1 0 44 0 7976 0 select Ds ?? 5012299:26.00 [rpcbind] 0 782 1 0 76 0 6920 0 select Ds ?? 82364:00.00 [mountd] 0 800 1 0 76 0 5832 572 pause DWs ?? 0:00.00 [nfsuserd] 0 801 800 0 44 0 5832 0 select D ?? 1295896:48.00 [nfsuserd] 0 802 800 0 44 0 5832 0 select D ?? 1461188:16.00 [nfsuserd] 0 803 800 0 44 0 5832 0 select D ?? 1316882:20.00 [nfsuserd] 0 804 800 0 44 0 5832 0 select D ?? 1298376:06.00 [nfsuserd] 0 806 1 0 44 0 5828 0 select Ds ?? 1779972:34.00 [nfsd] 0 807 806 0 44 0 5828 0 rpcsvc D ?? 283962954521:04.24 [nfsd] 0 810 1 0 44 0 269036 0 select Ds ?? 1865349:46.00 [rpc.statd] 0 813 1 0 44 0 7976 0 rpcsvc Ds ?? 1741008680:34.00 [rpc.lockd] 0 852 1 0 44 0 11804 0 select Ds ?? 110532173:34.00 [ntpd] 1 860 1 0 44 0 5828 612 sbwait Ds ?? 29900093:08.00 [rwhod] 0 871 1 0 44 0 20908 0 select Ds ?? 110118584:36.00 [perl5.10.1 0 975 1 0 46 0 26172 0 select Ds ?? 1189785:06.00 [sshd] 0 1011 1 0 44 0 12024 0 select Ds ?? 33266547:42.00 [sendmail] 25 1029 1 0 44 0 12024 1040 pause DWs ?? 0:00.00 [sendmail] 0 1043 1 0 44 0 7976 732 nanslp Ds ?? 5102323:00.00 [cron] 0 1110 1 0 76 0 6916 0 ttyin Ds+ ?? 85587:56.00 [getty] 0 1111 1 0 76 0 6916 0 ttyin Ds+ ?? 84443:56.00 [getty] 0 1112 1 0 44 0 6916 0 ttyin Ds+ ?? 92258:54.00 [getty] 0 1113 975 0 50 0 29808 1988 sbwait DWs ?? 0:00.00 [sshd] 20001 1115 1113 0 44 0 29808 0 select D ?? 71721983:56.00 [sshd] 20001 1116 1115 0 44 0 10336 812 pause DWs ?? 0:00.00 [tcsh] 20001 3161 1116 0 46 0 8344 892 wait D ?? 76296945:54.00 [sh] 20001 11908 3161 0 46 0 2764 0 nanslp D ?? 42611:20.00 [sleep] 20001 47211 1116 0 44 0 9372 0 - R+ ?? 576339426:06.00 [top] ---- ----Security_Multipart(Thu_Feb_23_23_45_58_2012_702)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEABECAAYFAk9GUSYACgkQTyzT2CeTzy2efQCggbkW4UgWgQ3LE3RUIYyRz4CD xyQAn1N7SXKNgbwd14NRFyvwXI7F4PAB =kjs7 -----END PGP SIGNATURE----- ----Security_Multipart(Thu_Feb_23_23_45_58_2012_702)---- From owner-freebsd-stable@FreeBSD.ORG Thu Feb 23 15:13: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 79846106564A for ; Thu, 23 Feb 2012 15:13:20 +0000 (UTC) (envelope-from contact@m.smartymee.org) Received: from mo-p00-ob6.rzone.de (mo-p00-ob6.rzone.de [IPv6:2a01:238:20a:202:53f0::1]) by mx1.freebsd.org (Postfix) with ESMTP id D730D8FC18 for ; Thu, 23 Feb 2012 15:13:18 +0000 (UTC) X-RZG-AUTH: :L2MKYUGrb9+qposg/DDGaHuB759Vkr4S0H4aPyzMu2ZTcgELkNf3zAu/C2dN0hWUO9Q= X-RZG-CLASS-ID: mo00 Received: from b_desk (p57AA6DE2.dip.t-dialin.net [87.170.109.226]) by post.strato.de (mrclete mo1) (RZmta 27.7 DYNA|AUTH) with ESMTPA id e04c55o1NEi6oE for ; Thu, 23 Feb 2012 16:13:12 +0100 (MET) Message-ID: <50f11d55037f4d9f9c4818eb52c3fd93> From: SmartyMee To: freebsd-stable@freebsd.org Date: Thu, 23 Feb 2012 15:12:24 GMT MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_72a78ec2_5fa5_41c5_bc54_c5e107aa87dc" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: SmartyMee X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 23 Feb 2012 15:13:20 -0000 This is a multi-part message in MIME format. ------=_NextPart_72a78ec2_5fa5_41c5_bc54_c5e107aa87dc Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UFJFU1MgUkVMRUFTRSAtIEZPUiBJTU1FRElBVEUgUkVMRUFTRQ0KDQpTbWFydHltZWUuY29tIOKA kyB0aGUgcGVyZmVjdCBzb2x1dGlvbiBmb3IgbW9uZXRpemluZyB5b3VyIGNvdXJzZXdhcmUgYW5k IHR1dG9yaWFscw0KDQpCZXJsaW4sIEdlcm1hbnkg4oCUIEphbnVhcnkgMjQsIDIwMTIg4oCUIHRo ZSBndXlzIGZyb20gaHR0cDovL3NjaWVuY2VzdGFnZS5jb20sIHRoZSBsZWFkaW5nIGludGVybmF0 aW9uYWwgY29tbXVuaXR5IGZvciBhY2FkZW1pYyB2aWRlbyBzdHJlYW1pbmcsIGFyZSBsYXVuY2hp bmcgYSBuZXcgcHJvZHVjdCBjYWxsZWQgaHR0cDovL3NtYXJ0eW1lZS5jb20uDQoNClNtYXJ0eW1l ZS5jb20gaXMgYnVpbHQgb24gdG9wIG9mIGh0dHA6Ly9zY2llbmNlc3RhZ2UuY29tIGJ1dCBuZXZl cnRoZWxlc3MgYW4gaW5kaXZpZHVhbCBicmFuZC4gSXQgaXMgYSBtYXJrZXRwbGFjZSBmb3IgZGln aXRhbCBjb3Vyc2V3YXJlIHByb2R1Y3RzIGFuZCBmb3IgdHV0b3JpYWxzLg0KDQpTbWFydHltZWUu Y29tIGlzIHRoZSBpZGVhbCBwbGFjZSBmb3IgcHJvZHVjZXJzIG9mIGZyZXNoIGFuZCBoaWdoLXF1 YWxpdHkgY29udGVudCB0byBtb25ldGl6ZSB0aGVpciB3b3JrLiBBbGwgaW4gdGhyZWUgc2ltcGxl IHN0ZXBzOiAxLiBDcmVhdGUgYSBjb3Vyc2UgYW5kIHNldCBhIHByaWNlLCAyLiBVcGxvYWQgYW5k IGNvbXBpbGUgZmlsZXMsIDMuIFB1Ymxpc2guDQoNClVubGlrZSBTY2llbmNlc3RhZ2UuY29tLCBT bWFydHltZWUuY29tIGRvZXMgbm90IGp1c3QgY292ZXIgYWNhZGVtaWMgdG9waWNzLiBJdCBhbHNv IGZvY3VzZXMgb24gYSBicm9hZCByYW5nZSBvZiBvdGhlciB0b3BpY3MsIHN1Y2ggYXMgYnVzaW5l c3MsIGhlYWx0aCwgbGlmZXN0eWxlLCBob2JieSwgbGFuZ3VhZ2UsIG11c2ljLCB0ZWNobm9sb2d5 IGFuZCBJbnRlcm5ldC4gU21hcnR5bWVlLmNvbSBjYW4gYmUgdXNlZCB0byBwdWJsaXNoIGZyZWUg Y291cnNld2FyZS4gQnV0IHRoZSBvcGVyYXRvcnMgYWxzbyBzcGVjaWZpY2FsbHkgYXBwZWFsIHRv IGFsbCBleHBlcnRzIHdobyBoYXZlIGFsd2F5cyBmaXJtbHkgYmVsaWV2ZWQgdGhhdCB0b3AtcXVh bGl0eSBjb250ZW50IGNhbiBvbmx5IGNvbWUgYXQgYSBwcmljZSwgZXZlbiBvbiB0aGUgd2ViLg0K DQpJZiB5b3Ugd291bGQgbGlrZSBtb3JlIGluZm9ybWF0aW9uIGFib3V0IHNtYXJ0eW1lZS5jb20s IG9yIHRvIHNjaGVkdWxlIGFuIGludGVydmlldyB3aXRoICBEci4gS3J1ZWdlciwgcGxlYXNlIGNv bnRhY3QgaGltIGRpcmVjdGx5IGF0ICs0OS0oMCkzMCDigJMgNDAgNTAgMDQgNjUgb3Igc2VuZCBh biBlbWFpbCB0byBjb250YWN0QHNtYXJ0eW1lZS5jb20NCg0KVVJMOiBodHRwOi8vc21hcnR5bWVl LmNvbQ0KUHJlc3MgUGFnZSAoSW5jbHVkaW5nIExvZ28gYW5kIFZpZGVvKTogaHR0cDovL3NtYXJ0 eW1lZS5jb20vcHJlc3MtcmVsZWFzZS1iZXJsaW4tZ2VybWFueS0lRTIlODAlOTQtamFuLTI0LTIw MTIgDQpGYWNlYm9vazogaHR0cDovL3d3dy5mYWNlYm9vay5jb20vcHJvZmlsZS5waHA/aWQ9MTAw MDAzMjY5MjAzMDU3DQpZb3V0dWJlOiBodHRwOi8vd3d3LnlvdXR1YmUuY29tL3VzZXIvc21hcnR5 bWVlY29tDQoNCkFkcmVzczogU21hcnR5TWVlLmNvbSwgMTAxNzggQmVybGluLCBHZXJtYW55LCBL YXJsLUxpZWJrbmVjaHQtU3RyLiAxMyANCg== ------=_NextPart_72a78ec2_5fa5_41c5_bc54_c5e107aa87dc-- From owner-freebsd-stable@FreeBSD.ORG Thu Feb 23 15:25: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 0B3A5106564A for ; Thu, 23 Feb 2012 15:25:09 +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 AE4F08FC22 for ; Thu, 23 Feb 2012 15:25:07 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1S0aXa-0002Uf-1C for freebsd-stable@freebsd.org; Thu, 23 Feb 2012 16:25:06 +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 ; Thu, 23 Feb 2012 16:25:06 +0100 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 23 Feb 2012 16:25:06 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Ivan Voras Date: Thu, 23 Feb 2012 16:19:12 +0100 Lines: 36 Message-ID: References: <20120222205231.GA81949@onelab2.iet.unipi.it> <1329944986.2621.46.camel@bwh-desktop> <20120222214433.GA82582@onelab2.iet.unipi.it> <134564BB-676B-49BB-8BDA-6B8EB8965969@netasq.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig9EFFE8653DC66D2067705633" 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: <134564BB-676B-49BB-8BDA-6B8EB8965969@netasq.com> X-Enigmail-Version: 1.3.5 Cc: freebsd-net@freebsd.org Subject: Re: nmbclusters: how do we want to fix this for 8.3 ? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 23 Feb 2012 15:25:09 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig9EFFE8653DC66D2067705633 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 23/02/2012 09:19, Fabien Thomas wrote: > I think this is more reasonable to setup interface with one queue. Unfortunately, the moment you do that, two things will happen: 1) users will start complaining again how FreeBSD is slow 2) the setting will be come a "sacred cow" and nobody will change this default for the next 10 years. If it really comes down to enabling only one queue, something needs to complain extremely loudly that this isn't an optimal setting. Only printing it out at boot may not be enough - what's needed is possibly a script in periodic/daily which checks "system sanity" every day and e-mails the operator. --------------enig9EFFE8653DC66D2067705633 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/ iEYEARECAAYFAk9GWPAACgkQldnAQVacBch8MwCeJ2ae+iyi0z5b7a0BwyHH7fS+ S6UAoJQ4qclF6egfL2K5OU/HOzu4YB4R =pQF+ -----END PGP SIGNATURE----- --------------enig9EFFE8653DC66D2067705633-- From owner-freebsd-stable@FreeBSD.ORG Thu Feb 23 15:35: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 B34C9106564A; Thu, 23 Feb 2012 15:35:17 +0000 (UTC) (envelope-from kabaev@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 00F6E8FC0C; Thu, 23 Feb 2012 15:35:16 +0000 (UTC) Received: by qaea17 with SMTP id a17so1742461qae.13 for ; Thu, 23 Feb 2012 07:35:16 -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:in-reply-to:references:x-mailer :mime-version:content-type; bh=1JcHY4k6ay+mYANyL30n7YXDZ+xOB/KZWwJTjBXfofY=; b=IzTW6qH7YvZt5EqlKFM1i3Y4XtH7Ee9rC4KhrdYQQ7pjv/1SWPIEsbpOY8crv/G/6e xlilM+81heuaENOblUgLUGLBWt1VD9oLdePNuNZfRrVbncvcZJslwH3rEGw9Wxt/avQe txAJtlbUzjGG3spZfi+Dnn4XwfP9+7mM8zU/0= Received: by 10.229.106.17 with SMTP id v17mr1068518qco.145.1330009924984; Thu, 23 Feb 2012 07:12:04 -0800 (PST) Received: from kan.dyndns.org (c-24-63-226-98.hsd1.ma.comcast.net. [24.63.226.98]) by mx.google.com with ESMTPS id el3sm4595452qab.8.2012.02.23.07.12.03 (version=SSLv3 cipher=OTHER); Thu, 23 Feb 2012 07:12:03 -0800 (PST) Date: Thu, 23 Feb 2012 10:11:57 -0500 From: Alexander Kabaev To: "Desai, Kashyap" Message-ID: <20120223101157.0bb3f2ee@kan.dyndns.org> In-Reply-To: References: <20120223094611.GC32748@hoeg.nl> X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.6; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/950qJ=4tk1nASHapQ0CY+jC"; protocol="application/pgp-signature" Cc: Ed Schouten , freebsd-stable , "joerg@FreeBSD.org" , "Kenneth D. Merry" , "freebsd-scsi@freebsd.org" , "Justin T. Gibbs" , "McConnell, Stephen" Subject: Re: mpslsi0 : Trying sleep, but thread marked as sleeping prohibited X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 23 Feb 2012 15:35:17 -0000 --Sig_/950qJ=4tk1nASHapQ0CY+jC Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Thu, 23 Feb 2012 18:45:29 +0530 "Desai, Kashyap" wrote: >=20 >=20 > > -----Original Message----- > > From: Ed Schouten [mailto:ed@80386.nl] > > Sent: Thursday, February 23, 2012 3:16 PM > > To: Desai, Kashyap > > Cc: freebsd-scsi@freebsd.org; freebsd-stable; joerg@FreeBSD.org; > > Kenneth D. Merry; McConnell, Stephen; Justin T. Gibbs > > Subject: Re: mpslsi0 : Trying sleep, but thread marked as sleeping > > prohibited > >=20 > > Hi Kashyap, > >=20 > > * Desai, Kashyap , 20120222 18:51: > > > Adding Ed Schouten and Jorg Wunsch as I see there are author of > > > msleep/mtx related APIs. > >=20 > > Am I? :-) > I am new to FreeBSD and desperate to know the answer. :-). Thanks for > your help. > >=20 > > > 1. When any irq is register with FreeBSD OS, it sets " > > > TDP_NOSLEEPING" pflag. It means though irq in freebsd is treated > > > as thread, We cannot sleep in IRQ because of " "TDP_NOSLEEPING " > > > set. 2. In mps driver we have below code snippet in ISR routine. > > > > > > > > > mps_dprint(sc, MPS_TRACE, "%s\n", __func__); > > > mps_lock(sc); > > > mps_intr_locked(data); > > > mps_unlock(sc); > > > > > > I wonder why there is no issue with above code ? Theoretical we > > > cannot sleep in ISR. (as explained in #1) Any thoughts ? > >=20 > > The TDP_NOSLEEPING flag only disallows sleeping of an indeterminate > > amount of time. Locking a mutex is allowed, as it can only cause the > > thread to be blocked for a small amount of time, waiting for another > > thread to unlock it. > So does this assumption that another thread will release mutex fast > enough ? Same as msleep() this can be applicable here as well. I mean > another thread _can_ (if some bad drivers) take long time to release > mutex. >=20 > Bad drivers can just defererence wild pointer to satisfy their need for wrongdoing. For that reason let us keep them out of conversation. mtx locks were designed to protect small sections of code where thread is only allowed to block waiting for other thread to release the lock of similar class. While threads are blocked, they get benefit of adaptive sleep and priority propagation and should take precaution of never taking the path of code that can cause them to sleep. Assertions are there to help code authors with that. sleep locks are by definition unbound. There is no spinning, no priority propagation. Holders are free to take, say, page faults and go to long journey to disk and back, etc. Hardly the stuff _anyone_ would want to do from interrupt handler, thread or otherwise.=20 =20 > > > 3. I recently added few place msleep() instead of DELAY in ISR > > > context and I see " Trying sleep, but thread marked as sleeping > > > prohibited". > >=20 > > Which makes sense, as msleep() can be used to sleep for > > indefinitely. > This part is clear. ! I agree with all experts view.=20 > >=20 > > -- > > Ed Schouten > > WWW: http://80386.nl/ > _______________________________________________ > freebsd-scsi@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-scsi > To unsubscribe, send any mail to > "freebsd-scsi-unsubscribe@freebsd.org" --=20 Alexander Kabaev --Sig_/950qJ=4tk1nASHapQ0CY+jC Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iD8DBQFPRldCQ6z1jMm+XZYRAhIbAKDOazJ5UXmFRvE7uTT33ev2At+N0wCgymJR 5k9bxKRjkXtb4o5H6isoJVM= =1ndl -----END PGP SIGNATURE----- --Sig_/950qJ=4tk1nASHapQ0CY+jC-- From owner-freebsd-stable@FreeBSD.ORG Thu Feb 23 16:13: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 6D1081065673 for ; Thu, 23 Feb 2012 16:13:37 +0000 (UTC) (envelope-from jpaetzel@freebsd.org) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by mx1.freebsd.org (Postfix) with ESMTP id 2DE1C8FC1D for ; Thu, 23 Feb 2012 16:13:36 +0000 (UTC) Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 013FA20CB6 for ; Thu, 23 Feb 2012 10:58:00 -0500 (EST) Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160]) by compute4.internal (MEProxy); Thu, 23 Feb 2012 10:58:00 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=tFkUZ/ElGuDGrBOZqjoavv 40lsY=; b=DY3oQHs1Cbn4WXkbPATbEl77PlStQWD/qVbZvRL/fUHXmxsnPCszlD QukJqoY0fo5t43cVAyyzZgS/UGbOTMmnbS7i2/wzF68aay9kZnMY3WQBgHmT7BmR oliZraaYxKtaXLjAPIdzGsufDH3Zt6EzsKxfe6IhwqtIsBlLEAOgA= X-Sasl-enc: NgZYrRyPr9ZafP2kPqzyYYMZBtlcYUpodeM+AECAKSBE 1330012680 Received: from roadrash.tcbug.org (drawbridge.ixsystems.com [206.40.55.65]) by mail.messagingengine.com (Postfix) with ESMTPSA id C56DE8E0096; Thu, 23 Feb 2012 10:57:59 -0500 (EST) Message-ID: <4F466206.2000100@freebsd.org> Date: Thu, 23 Feb 2012 07:57:58 -0800 From: Josh Paetzel Organization: FreeBSS User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0) Gecko/20120209 Thunderbird/10.0 MIME-Version: 1.0 To: Jack Vogel References: <20120222205231.GA81949@onelab2.iet.unipi.it> <1329944986.2621.46.camel@bwh-desktop> <20120222214433.GA82582@onelab2.iet.unipi.it> In-Reply-To: X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Ben Hutchings , FreeBSD Net , Luigi Rizzo , re , FreeBSD stable Subject: Re: nmbclusters: how do we want to fix this for 8.3 ? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 23 Feb 2012 16:13:37 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02/22/2012 13:51, Jack Vogel wrote: > > > On Wed, Feb 22, 2012 at 1:44 PM, Luigi Rizzo > wrote: > > On Wed, Feb 22, 2012 at 09:09:46PM +0000, Ben Hutchings wrote: >> On Wed, 2012-02-22 at 21:52 +0100, Luigi Rizzo wrote: > ... >>> I have hit this problem recently, too. Maybe the issue >>> mostly/only exists on 32-bit systems. >> >> No, we kept hitting mbuf pool limits on 64-bit systems when we >> started working on FreeBSD support. > > ok never mind then, the mechanism would be the same, though the > limits (especially VM_LIMIT) would be different. > >>> Here is a possible approach: >>> >>> 1. nmbclusters consume the kernel virtual address space so >>> there must be some upper limit, say >>> >>> VM_LIMIT = 256000 (translates to 512MB of address space) >>> >>> 2. also you don't want the clusters to take up too much of the > available >>> memory. This one would only trigger for minimal-memory >>> systems, or virtual machines, but still... >>> >>> MEM_LIMIT = (physical_ram / 2) / 2048 >>> >>> 3. one may try to set a suitably large, desirable number of >>> buffers >>> >>> TARGET_CLUSTERS = 128000 >>> >>> 4. and finally we could use the current default as the >>> absolute > minimum >>> >>> MIN_CLUSTERS = 1024 + maxusers*64 >>> >>> Then at boot the system could say >>> >>> nmbclusters = min(TARGET_CLUSTERS, VM_LIMIT, MEM_LIMIT) >>> >>> nmbclusters = max(nmbclusters, MIN_CLUSTERS) >>> >>> >>> In turn, i believe interfaces should do their part and by >>> default never try to allocate more than a fraction of the total >>> number of buffers, >> >> Well what fraction should that be? It surely depends on how >> many interfaces are in the system and how many queues the other >> interfaces have. > >>> if necessary reducing the number of active queues. >> >> So now I have too few queues on my interface even after I >> increase the limit. >> >> There ought to be a standard way to configure numbers of queues >> and default queue lengths. > > Jack raised the problem that there is a poorly chosen default for > nmbclusters, causing one interface to consume all the buffers. If > the user explicitly overrides the value then the number of cluster > should be what the user asks (memory permitting). The next step is > on devices: if there are no overrides, the default for a driver is > to be lean. I would say that topping the request between 1/4 and > 1/8 of the total buffers is surely better than the current > situation. Of course if there is an explicit override, then use it > whatever happens to the others. > > cheers luigi > > > Hmmm, well, I could make the default use only 1 queue or something > like that, was thinking more of what actual users of the hardware > would want. > > After the installed kernel is booted and the admin would do > whatever post install modifications they wish it could be changed, > along with nmbclusters. > > This was why i sought opinions, of the algorithm itself, but also > anyone using ixgbe and igb in heavy use, what would you find most > convenient? > > Jack > The default setting is a thorn in our (with my ixsystems servers for freebsd hat on) side. A system with a quad port igb card and two onboard igb NICs won't boot stable/8 or 8.x-R to multiuser. Ditto for a dual port chelsio or ixgbe alongside dual onboard igb interfaces. My vote would be having systems over some minimum threshold of system ram to come up with a higher default for nmbclusters. You don't see too many 10gbe NICs in systems with 2GB of RAM.... - -- Thanks, Josh Paetzel FreeBSD -- The power to serve -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPRmIGAAoJEKFq1/n1feG229gIAIciDDKnc/K6/dgBA2YFGuuV V9cYD6+Zm4bVT9nvFhxJCUj+3CTGQFvNwi2sQx6pVMUWQC7Cpb323CShc8BBNjV3 vCzTmvqVshO+LWhx6J8lq4rqTU+PIKajF3GnwIWt4xmZ6WhrjCUySORYSAINQjKr iXJg/HBA7z/tsPUqOvzU0esZ4moUECapoldEOe0EF2jidARuM4q6MD1+QLMs+JSO JUS5yMPV022NVYS79NsUfvJ1cuwd6/I7CPvsJsW0E+zMMF2BjKZesU89zyFDST80 0WptoEqR9cuyApwu0OfDDzKyL7Z6G9yaAr0zkCAHATxkK0KArMJP/j2eT5uzZkE= =b44v -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Thu Feb 23 16:33: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 97953106566B; Thu, 23 Feb 2012 16:33:01 +0000 (UTC) (envelope-from juli@clockworksquid.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 EE74C8FC17; Thu, 23 Feb 2012 16:33:00 +0000 (UTC) Received: by werm13 with SMTP id m13so1339087wer.13 for ; Thu, 23 Feb 2012 08:32:59 -0800 (PST) Received: by 10.180.101.37 with SMTP id fd5mr3996239wib.1.1330013002223; Thu, 23 Feb 2012 08:03:22 -0800 (PST) MIME-Version: 1.0 Sender: juli@clockworksquid.com Received: by 10.227.209.78 with HTTP; Thu, 23 Feb 2012 08:03:02 -0800 (PST) In-Reply-To: References: <20120222205231.GA81949@onelab2.iet.unipi.it> <1329944986.2621.46.camel@bwh-desktop> <20120222214433.GA82582@onelab2.iet.unipi.it> <134564BB-676B-49BB-8BDA-6B8EB8965969@netasq.com> From: Juli Mallett Date: Thu, 23 Feb 2012 08:03:02 -0800 X-Google-Sender-Auth: Y1jA9RtMAKTklj7ACtaB2RdWag8 Message-ID: To: Ivan Voras Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQkIoUUFlR5tuu51SGixtrKHEZg+qNAHuq+lX5T5N3Zh9PMD4wvwdREbGDSdPStGTi8k7hK0 Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org Subject: Re: nmbclusters: how do we want to fix this for 8.3 ? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 23 Feb 2012 16:33:01 -0000 On Thu, Feb 23, 2012 at 07:19, Ivan Voras wrote: > On 23/02/2012 09:19, Fabien Thomas wrote: >> I think this is more reasonable to setup interface with one queue. > > Unfortunately, the moment you do that, two things will happen: > 1) users will start complaining again how FreeBSD is slow > 2) the setting will be come a "sacred cow" and nobody will change this > default for the next 10 years. Is this any better than making queue-per-core a sacred cow? Even very small systems with comparatively-low memory these days have an increasing number of cores. They also usually have more RAM to go with those cores, but not always. Queue-per-core isn't even optimal for some kinds of workloads, and is harmful to overall performance at higher levels. It also assumes that every core should be utilized for the exciting task of receiving packets. This makes sense on some systems, but not all. Plus more queues doesn't necessarily equal better performance even on systems where you have the memory and cores to spare. On systems with non-uniform memory architectures, routinely processing queues on different physical packages can make networking performance worse. More queues is not a magic wand, it can be roughly the equivalent of go-faster stripes. Queue-per-core has a sort of logic to it, but is not necessarily sensible, like the funroll-all-loops school of system optimization. Which sounds slightly off-topic, except that dedicating loads of mbufs to receive queues that will sit empty on the vast majority of systems and receive a few packets per second in the service of some kind of magical thinking or excitement about multiqueue reception may be a little ill-advised. On my desktop with hardware supporting multiple queues, do I really want to use the maximum number of them just to handle a few thousand packets per second? One core can do that just fine. FreeBSD's great to drop-in on forwarding systems that will have moderate load, but it seems the best justification for this default is so users need fewer reboots to get more queues to spread what is assumed to be an evenly-distributed load over other cores. In practice, isn't the real problem that we have no facility for changing the number of queues at runtime? If the number of queues weren't fixed at boot, users could actually find the number that suits them best with a plausible amount of work, and the point about FreeBSD being "slow" goes away since it's perhaps one more sysctl to set (or one per-interface) or one (or one-per) ifconfig line to run, along with enabling forwarding, etc. The big commitment that multi-queue drivers ask for when they use the maximum number of queues on boot and then demand to fill those queues up with mbufs is unreasonable, even if it can be met on a growing number of systems without much in the way of pain. It's unreasonable, but perhaps it feels good to see all those interrupts bouncing around, all those threads running from time to time in top. Maybe it makes FreeBSD seem more serious, or perhaps it's something that gets people excited. It gives the appearance of doing quite a bit behind the scenes, and perhaps that's beneficial in and of itself, and will keep users from imagining that FreeBSD is slow, to your point. We should be clear, though, whether we are motivated by technical or psychological constraints and benefits. Thanks, Juli. From owner-freebsd-stable@FreeBSD.ORG Thu Feb 23 17:05:02 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 BC3AA106566B for ; Thu, 23 Feb 2012 17:05:02 +0000 (UTC) (envelope-from bengta@P142.sics.se) Received: from sink.sics.se (sink.sics.se [193.10.64.88]) by mx1.freebsd.org (Postfix) with ESMTP id 4C3048FC08 for ; Thu, 23 Feb 2012 17:05:01 +0000 (UTC) Received: from P142.sics.se (P142.sics.se [193.10.66.253]) by sink.sics.se (8.14.4/8.14.4) with ESMTP id q1NGQUq4060739 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 23 Feb 2012 17:26:30 +0100 (CET) (envelope-from bengta@P142.sics.se) Received: from P142.sics.se (localhost [127.0.0.1]) by P142.sics.se (8.14.5/8.14.4) with ESMTP id q1NGQW7N002003; Thu, 23 Feb 2012 17:26:32 +0100 (CET) (envelope-from bengta@P142.sics.se) Received: (from bengta@localhost) by P142.sics.se (8.14.5/8.14.5/Submit) id q1NGQWUV002002; Thu, 23 Feb 2012 17:26:32 +0100 (CET) (envelope-from bengta@P142.sics.se) From: Bengt Ahlgren To: stable@freebsd.org User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (berkeley-unix) Date: Thu, 23 Feb 2012 17:26:32 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Subject: 8.3-PRERELEASE panic in linux emulation X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 23 Feb 2012 17:05:02 -0000 Hi! I get a consistent panic when starting acroread after updating to 8.3-PRERELEASE. An 8.2-STABLE from Feb 4th was OK. Can provide more info if needed. Bengt FreeBSD xx.yy.zz 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #13 r231999: Wed Feb 22 21:01:38 CET 2012 bengta@P142.sics.se:/usr/obj/usr/src/sys/P142-82 i386 Fatal trap 12: page fault while in kernel mode fault virtual address = 0xbfbfdffc fault code = supervisor write, page not present instruction pointer = 0x20:0xc50b396c stack pointer = 0x28:0xe7481a6c frame pointer = 0x28:0xe7481a90 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 1997 (bash) trap number = 12 panic: page fault KDB: stack backtrace: db_trace_self_wrapper(c091af2a,70797420,78302065,a0d6231,c5d6b600,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c0919061,c09b49a0,c0900251,e7481910,e7481910,...) at kdb_backtrace+0x2a panic(c0900251,c0941cab,c5c246e8,1,1,...) at panic+0xaf trap_fatal(c0670d02,0,e7481964,80400,c5c24580,...) at trap_fatal+0x353 trap_pfault(e74819cc,bfbfe190,c5c24580,202,c5cecac0,...) at trap_pfault+0x87 trap(e7481a2c) at trap+0x453 calltrap() at calltrap+0x6 --- trap 0xc, eip = 0xc50b396c, esp = 0xe7481a6c, ebp = 0xe7481a90 --- elf_linux_fixup(e7481c0c,e7481b98,c065ca92,c60ffce8,100000,...) at elf_linux_fixup+0x33c kern_execve(c5c24580,e7481c3c,0,8112710,8116cd8,...) at kern_execve+0x7d6 linux_execve(c5c24580,e7481cec,c,c,c,...) at linux_execve+0xa7 syscall(e7481d28) at syscall+0x372 Xint0x80_syscall() at Xint0x80_syscall+0x21 --- syscall (11, Linux ELF, linux_execve), eip = 0x281e0d4a, esp = 0xbfbfd644, ebp = 0xbfbfd7e8 --- #0 doadump () at pcpu.h:244 #1 0xc05de609 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:441 #2 0xc05de84f in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:614 #3 0xc08b22c3 in trap_fatal (frame=0xe7481a2c, eva=3217022972) at /usr/src/sys/i386/i386/trap.c:981 #4 0xc08b2357 in trap_pfault (frame=0xe7481a2c, usermode=0, eva=3217022972) at /usr/src/sys/i386/i386/trap.c:843 #5 0xc08b3133 in trap (frame=0xe7481a2c) at /usr/src/sys/i386/i386/trap.c:562 #6 0xc089bedc in calltrap () at /usr/src/sys/i386/i386/exception.s:168 #7 0xc50b396c in elf_linux_fixup (stack_base=0xe7481c0c, imgp=0xe7481b98) at /usr/src/sys/modules/linux/../../i386/linux/linux_sysvec.c:288 #8 0xc05ac636 in kern_execve (td=0xc5c24580, args=0xe7481c3c, mac_p=0x0) at /usr/src/sys/kern/kern_exec.c:551 #9 0xc50ab387 in linux_execve (td=0xc5c24580, args=0xe7481cec) at /usr/src/sys/modules/linux/../../i386/linux/linux_machdep.c:143 #10 0xc08b2902 in syscall (frame=0xe7481d28) at subr_syscall.c:114 #11 0xc089bf41 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:266 #12 0x00000033 in ?? () From owner-freebsd-stable@FreeBSD.ORG Thu Feb 23 17:22: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 8D5021065674 for ; Thu, 23 Feb 2012 17:22:41 +0000 (UTC) (envelope-from dudu@dudu.ro) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 44E538FC14 for ; Thu, 23 Feb 2012 17:22:40 +0000 (UTC) Received: by yenl12 with SMTP id l12so835346yen.13 for ; Thu, 23 Feb 2012 09:22:40 -0800 (PST) Received-SPF: pass (google.com: domain of dudu@dudu.ro designates 10.50.87.201 as permitted sender) client-ip=10.50.87.201; Authentication-Results: mr.google.com; spf=pass (google.com: domain of dudu@dudu.ro designates 10.50.87.201 as permitted sender) smtp.mail=dudu@dudu.ro; dkim=pass header.i=dudu@dudu.ro Received: from mr.google.com ([10.50.87.201]) by 10.50.87.201 with SMTP id ba9mr3423840igb.30.1330017760437 (num_hops = 1); Thu, 23 Feb 2012 09:22:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dudu.ro; s=google; h=mime-version:from:date:message-id:subject:to:content-type; bh=D+Qnh49TmMOAyddCSXivV7V0+crHdXshxEezasNaYIs=; b=jXPgG/DJzI/qC9TxTwhn1g4dRVi8Gxe5YEiXRds7cxioAIDVB6PtDnCx/bvykivu9e S6UVo87/McCoCw0kY4rnA40tbNHQaZAMHKp+9UEA93IWaaYC6jAEOI0zrjxvindhOhfW QiZfTGbSlp1Gfwr4Y7ASpJHj9mwJlrGXsinmU= Received: by 10.50.87.201 with SMTP id ba9mr2866984igb.30.1330017760170; Thu, 23 Feb 2012 09:22:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.42.223.69 with HTTP; Thu, 23 Feb 2012 09:22:00 -0800 (PST) From: Vlad Galu Date: Thu, 23 Feb 2012 17:22:00 +0000 Message-ID: To: "freebsd-stable@FreeBSD.org" X-Gm-Message-State: ALoCoQlL9otJ+Z/L1y/LGWUdI0CXmpdLEcwam2Cbm0WzrS2v35axNOmqJnYhc7zLtCwS8pq3olGv Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Inconsistent utx.active? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 23 Feb 2012 17:22:41 -0000 Hi, Has anyone else noticed erratic bookkeeping by utmpx in RELENG_9? Thanks, Vlad -- Good, fast & cheap. Pick any two. From owner-freebsd-stable@FreeBSD.ORG Thu Feb 23 18:25: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 221B21065673 for ; Thu, 23 Feb 2012 18:25:05 +0000 (UTC) (envelope-from ml@my.gd) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id A33658FC1B for ; Thu, 23 Feb 2012 18:25:04 +0000 (UTC) Received: by wibhn14 with SMTP id hn14so1454654wib.13 for ; Thu, 23 Feb 2012 10:25:03 -0800 (PST) Received-SPF: pass (google.com: domain of ml@my.gd designates 10.180.80.35 as permitted sender) client-ip=10.180.80.35; Authentication-Results: mr.google.com; spf=pass (google.com: domain of ml@my.gd designates 10.180.80.35 as permitted sender) smtp.mail=ml@my.gd Received: from mr.google.com ([10.180.80.35]) by 10.180.80.35 with SMTP id o3mr5346855wix.5.1330021503704 (num_hops = 1); Thu, 23 Feb 2012 10:25:03 -0800 (PST) Received: by 10.180.80.35 with SMTP id o3mr4359807wix.5.1330021503609; Thu, 23 Feb 2012 10:25:03 -0800 (PST) Received: from dfleuriot-at-hi-media.com ([83.167.62.196]) by mx.google.com with ESMTPS id ga1sm10099751wib.5.2012.02.23.10.25.02 (version=SSLv3 cipher=OTHER); Thu, 23 Feb 2012 10:25:02 -0800 (PST) Message-ID: <4F46847D.4010908@my.gd> Date: Thu, 23 Feb 2012 19:25:01 +0100 From: Damien Fleuriot User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "freebsd-stable@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQmg33HUvTCdVfQa6fnejB2oSJIInS/trdJHJxD/EAEqu4BqajfE8tq6xOL3thKTOCnwlQCq Subject: FreeBSD9 and the sheer number of problem reports X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 23 Feb 2012 18:25:05 -0000 Hello list, This is NOT a troll. This is NOT a flame. Do NOT hijack this thread to troll/flame. I'm writing this in light of the *many* problem reports I see on the lists with 9.0-RELEASE. I'm getting extremely worried here. Short introduction in order: See, we use FreeBSD at work for our firewall boxes, running: - PF + CARP + PFsync - nagios-nrpe - munin-node - bacula client and either - nginx and/or haproxy - relayd These boxes serve as frontend firewalls for all our projects/products, including a few high traffic ones. For example our most traffic intense project has 4 firewalls, 2 each on 2 different datacenters, sharing 4 CARP IPs with automagic failover. These firewalls total ~200mb/s , serving only minifi'ed javascript pages. Now, I find the number of problem reports regarding 9.0-RELEASE alarming and I'm growing more and more fearful towards it. In the current state of things, I have *absolutely* no wish to run it in production :( I'd love to hear feedback. From owner-freebsd-stable@FreeBSD.ORG Thu Feb 23 19:08: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 EA415106564A for ; Thu, 23 Feb 2012 19:08:08 +0000 (UTC) (envelope-from kurt.buff@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 7424D8FC0A for ; Thu, 23 Feb 2012 19:08:08 +0000 (UTC) Received: by werm13 with SMTP id m13so1479934wer.13 for ; Thu, 23 Feb 2012 11:08:07 -0800 (PST) Received-SPF: pass (google.com: domain of kurt.buff@gmail.com designates 10.180.94.68 as permitted sender) client-ip=10.180.94.68; Authentication-Results: mr.google.com; spf=pass (google.com: domain of kurt.buff@gmail.com designates 10.180.94.68 as permitted sender) smtp.mail=kurt.buff@gmail.com; dkim=pass header.i=kurt.buff@gmail.com Received: from mr.google.com ([10.180.94.68]) by 10.180.94.68 with SMTP id da4mr5443658wib.22.1330024087610 (num_hops = 1); Thu, 23 Feb 2012 11:08:07 -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=bjfI9vfMWnISj4hiQsyucIrRX/FyhME15fMuD4cTWUY=; b=Zq0A5nHDEqmyCspmPEG3S1OqtJ/1qqqIhq+7+bDxQJP9ICATDZMMlpbVpWPAaE/1p1 Vrf+nNi+29153K3JYv3EW3HTYXMEJHtipM3lWa+EEajeYleTZntbny0F484Tl9oi04GM H775M/Zs/uzHfvnmTrex7xG0MASSqWp+IMLv8= MIME-Version: 1.0 Received: by 10.180.94.68 with SMTP id da4mr4303463wib.22.1330022385480; Thu, 23 Feb 2012 10:39:45 -0800 (PST) Received: by 10.216.175.209 with HTTP; Thu, 23 Feb 2012 10:39:45 -0800 (PST) In-Reply-To: <4F46847D.4010908@my.gd> References: <4F46847D.4010908@my.gd> Date: Thu, 23 Feb 2012 10:39:45 -0800 Message-ID: From: Kurt Buff To: "freebsd-stable@freebsd.org" Content-Type: text/plain; charset=UTF-8 Subject: Re: FreeBSD9 and the sheer number of problem reports X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 23 Feb 2012 19:08:09 -0000 On Thu, Feb 23, 2012 at 10:25, Damien Fleuriot wrote: > Now, I find the number of problem reports regarding 9.0-RELEASE alarming > and I'm growing more and more fearful towards it. > > In the current state of things, I have *absolutely* no wish to run it in > production :( > > I'd love to hear feedback. Feedback: If you're worried, wait until you aren't. Kurt From owner-freebsd-stable@FreeBSD.ORG Thu Feb 23 19:14: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 EBCD0106566C for ; Thu, 23 Feb 2012 19:14:52 +0000 (UTC) (envelope-from adams-freebsd@ateamsystems.com) Received: from fss.sandiego.ateamservers.com (fss.sandiego.ateamservers.com [69.55.229.149]) by mx1.freebsd.org (Postfix) with ESMTP id CBDB78FC1D for ; Thu, 23 Feb 2012 19:14:52 +0000 (UTC) Received: from [192.168.15.220] (unknown [118.175.84.92]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by fss.sandiego.ateamservers.com (Postfix) with ESMTPSA id CB99CBCBB0; Thu, 23 Feb 2012 14:14:51 -0500 (EST) Message-ID: <4F46902E.9030500@ateamsystems.com> Date: Fri, 24 Feb 2012 02:14:54 +0700 From: Adam Strohl Organization: A-Team Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Kurt Buff References: <4F46847D.4010908@my.gd> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-stable@freebsd.org" Subject: Re: FreeBSD9 and the sheer number of problem reports X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 23 Feb 2012 19:14:53 -0000 On 2/24/2012 1:39, Kurt Buff wrote: > On Thu, Feb 23, 2012 at 10:25, Damien Fleuriot wrote: > >> Now, I find the number of problem reports regarding 9.0-RELEASE alarming >> and I'm growing more and more fearful towards it. >> >> In the current state of things, I have *absolutely* no wish to run it in >> production :( >> >> I'd love to hear feedback. > Feedback: If you're worried, wait until you aren't. Thorough testing ahead of time will either make you confident or give you the option to report issues which affect you directly (and help improve FreeBSD). I say that having run into one issue with 9.0 (and reported it). I am still using and deploying more 9.0 servers into production. My .02. From owner-freebsd-stable@FreeBSD.ORG Thu Feb 23 19:32: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 461C01065670 for ; Thu, 23 Feb 2012 19:32:06 +0000 (UTC) (envelope-from adam.strohl@ateamsystems.com) Received: from fss.sandiego.ateamservers.com (fss.sandiego.ateamservers.com [69.55.229.149]) by mx1.freebsd.org (Postfix) with ESMTP id 243048FC1B for ; Thu, 23 Feb 2012 19:32:05 +0000 (UTC) Received: from [192.168.15.220] (unknown [118.175.84.92]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by fss.sandiego.ateamservers.com (Postfix) with ESMTPSA id 34BDCBCBA9; Thu, 23 Feb 2012 14:13:52 -0500 (EST) Message-ID: <4F468FF3.8070004@ateamsystems.com> Date: Fri, 24 Feb 2012 02:13:55 +0700 From: Adam Strohl Organization: A-Team Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Kurt Buff References: <4F46847D.4010908@my.gd> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030800080503090607030902" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "freebsd-stable@freebsd.org" Subject: Re: FreeBSD9 and the sheer number of problem reports X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 23 Feb 2012 19:32:06 -0000 This is a cryptographically signed message in MIME format. --------------ms030800080503090607030902 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 2/24/2012 1:39, Kurt Buff wrote: > On Thu, Feb 23, 2012 at 10:25, Damien Fleuriot wrote: > >> Now, I find the number of problem reports regarding 9.0-RELEASE alarmi= ng >> and I'm growing more and more fearful towards it. >> >> In the current state of things, I have *absolutely* no wish to run it = in >> production :( >> >> I'd love to hear feedback. > Feedback: If you're worried, wait until you aren't. Thorough testing ahead of time will either make you confident or give=20 you the option to report issues which affect you directly (and help=20 improve FreeBSD). I say that having run into one issue with 9.0 (and reported it). I am=20 still using and deploying more 9.0 servers into production. My .02. --------------ms030800080503090607030902-- From owner-freebsd-stable@FreeBSD.ORG Thu Feb 23 19: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 EC9E31065675 for ; Thu, 23 Feb 2012 19:53:43 +0000 (UTC) (envelope-from torfinn.ingolfsen@broadpark.no) Received: from thalia-smout.broadpark.no (thalia-smout.broadpark.no [80.202.8.21]) by mx1.freebsd.org (Postfix) with ESMTP id A6D428FC08 for ; Thu, 23 Feb 2012 19:53:41 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from terra-smin.broadpark.no ([80.202.8.13]) by thalia-smout.broadpark.no (Sun Java(tm) System Messaging Server 7u3-15.01 64bit (built Feb 12 2010)) with ESMTP id <0LZV00AJ639G6L90@thalia-smout.broadpark.no> for freebsd-stable@freebsd.org; Thu, 23 Feb 2012 20:53:40 +0100 (CET) Received: from kg-v2.kg4.no ([84.215.134.159]) by terra-smin.broadpark.no (Sun Java(tm) System Messaging Server 7u3-15.01 64bit (built Feb 12 2010)) with ESMTPA id <0LZV0088D39G3K20@terra-smin.broadpark.no> for freebsd-stable@freebsd.org; Thu, 23 Feb 2012 20:53:40 +0100 (CET) Date: Thu, 23 Feb 2012 20:53:39 +0100 From: Torfinn Ingolfsen To: freebsd-stable@freebsd.org Message-id: <20120223205339.5a1f7fdb.torfinn.ingolfsen@broadpark.no> In-reply-to: <4F46847D.4010908@my.gd> References: <4F46847D.4010908@my.gd> X-Mailer: Sylpheed 3.1.2 (GTK+ 2.24.6; amd64-portbld-freebsd8.2) X-Face: "t9w2,-X@O^I`jVW\sonI3.,36KBLZE*AL[y9lL[PyFD*r_S:dIL9c[8Y>V42R0"!"yb_zN,f#%.[PYYNq; m"_0v; ~rUM2Yy!zmkh)3&U|u!=T(zyv,MHJv"nDH>OJ`t(@mil461d_B'Uo|'nMwlKe0Mv=kvV?Nh@>Hb<3s_z2jYgZhPb@?Wi^x1a~Hplz1.zH Subject: Re: FreeBSD9 and the sheer number of problem reports X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 23 Feb 2012 19:53:44 -0000 On Thu, 23 Feb 2012 19:25:01 +0100 Damien Fleuriot wrote: > > In the current state of things, I have *absolutely* no wish to run it in > production :( Nobody forces you to jump onto the 9.0-release bandwagon. You can choose to skip it. If you skip 9.0 - will you be better prepared and less fearful when 9.1-release comes? You decide. -- Torfinn From owner-freebsd-stable@FreeBSD.ORG Thu Feb 23 20:15: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 DD5891065672 for ; Thu, 23 Feb 2012 20:15:16 +0000 (UTC) (envelope-from feld@feld.me) Received: from mwi1.coffeenet.org (unknown [IPv6:2607:f4e0:100:300::2]) by mx1.freebsd.org (Postfix) with ESMTP id 8E7998FC08 for ; Thu, 23 Feb 2012 20:15:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=feld.me; s=blargle; h=In-Reply-To:Message-Id:From:Mime-Version:Date:References:Subject:To:Content-Type; bh=U1yiWUXQ2wXDOXAUlIZofDU1Eqc32S5ZXsw4HVIKzAE=; b=SqN6SsnwITFUVXrsfytag3th46Hrdt3V9aaoq3qyZXiafFnVHwLpQonJFEuqE2Irpwt+qlpPOutkZwuWb+jv4+QaODWvsOygHIa7o1BgXl9xm+EHimrebWG8Laj1Eyd+; Received: from localhost ([127.0.0.1] helo=mwi1.coffeenet.org) by mwi1.coffeenet.org with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1S0f4M-000NE1-GD for freebsd-stable@freebsd.org; Thu, 23 Feb 2012 14:15:15 -0600 Received: from feld@feld.me by mwi1.coffeenet.org (Archiveopteryx 3.1.4) with esmtpsa id 1330028108-13047-13046/5/24; Thu, 23 Feb 2012 20:15:08 +0000 Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: freebsd-stable@freebsd.org References: <4F46847D.4010908@my.gd> Date: Thu, 23 Feb 2012 14:15:08 -0600 Mime-Version: 1.0 From: Mark Felder Message-Id: In-Reply-To: <4F46847D.4010908@my.gd> User-Agent: Opera Mail/11.62 (FreeBSD) X-SA-Score: -1.5 Subject: Re: FreeBSD9 and the sheer number of problem reports X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 23 Feb 2012 20:15:16 -0000 On Thu, 23 Feb 2012 12:25:01 -0600, Damien Fleuriot wrote: > > Now, I find the number of problem reports regarding 9.0-RELEASE alarming > and I'm growing more and more fearful towards it. Then stick with the 8.x train until it's no longer supported. Also, don't you know the rule about running .0 releases in production? :) 9.0 had LOTS of changes. They were very important. It's going to take a while for the community to fully absorb them and bugs to be worked out. We don't have enough testers of -CURRENT to prevent this. Everything seemed stable (ie, no release blockers) for the people running -CURRENT and -PRERELEASE, BETAs, and RCs, so it was released. But as always, TEST TEST TEST and please have a proper staging/test environment before you throw your production into 9.x. Only YOU can prevent forest fires^W^W unplanned outages. From owner-freebsd-stable@FreeBSD.ORG Thu Feb 23 20:41: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 95AA71065677 for ; Thu, 23 Feb 2012 20:41:40 +0000 (UTC) (envelope-from jeremie@le-hen.org) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [IPv6:2a01:e0c:1:1599::14]) by mx1.freebsd.org (Postfix) with ESMTP id E71F68FC16 for ; Thu, 23 Feb 2012 20:41:38 +0000 (UTC) Received: from endor.tataz.chchile.org (unknown [82.233.239.98]) by smtp5-g21.free.fr (Postfix) with ESMTP id 4D0F9D48176; Thu, 23 Feb 2012 21:41:31 +0100 (CET) Received: from felucia.tataz.chchile.org (felucia.tataz.chchile.org [192.168.1.9]) by endor.tataz.chchile.org (Postfix) with ESMTP id 0B38528CF; Thu, 23 Feb 2012 20:41:30 +0000 (UTC) Received: by felucia.tataz.chchile.org (Postfix, from userid 1000) id EB6E134BD; Thu, 23 Feb 2012 20:41:29 +0000 (UTC) Date: Thu, 23 Feb 2012 21:41:29 +0100 From: Jeremie Le Hen To: Rick Macklem Message-ID: <20120223204129.GC90681@felucia.tataz.chchile.org> References: <20120220202517.GC37684@felucia.tataz.chchile.org> <501878740.1651247.1329779116977.JavaMail.root@erie.cs.uoguelph.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <501878740.1651247.1329779116977.JavaMail.root@erie.cs.uoguelph.ca> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@FreeBSD.org, Jeremie Le Hen Subject: Re: "File too large" error when appending to a file of 130 MB X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 23 Feb 2012 20:41:40 -0000 On Mon, Feb 20, 2012 at 06:05:16PM -0500, Rick Macklem wrote: > > > Sorry, I have no idea. Maybe one of the ZFS folks knows when ACLs > are generated. (It might happen as a side effect of a "chmod". You > could experiment with that?) Interestingly, such ACLs only appear on my nullfs mounted ZFS dataset. If I look directly at the underlying ZFS dataset, there is no ACL. -- Jeremie Le Hen Men are born free and equal. Later on, they're on their own. Jean Yanne From owner-freebsd-stable@FreeBSD.ORG Thu Feb 23 21:21: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 4CABF106564A for ; Thu, 23 Feb 2012 21:21:37 +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 AB78B8FC12 for ; Thu, 23 Feb 2012 21:21:36 +0000 (UTC) X-RZG-AUTH: :LWIKdA2leu0bPbLmhzXgqn0MTG6qiKEwQRWfNxSw4HzYIwjsnvdDt2QV8d370mSsWeYMAjg= X-RZG-CLASS-ID: mo05 Received: from [192.168.179.39] (hmbg-4d068593.pool.mediaWays.net [77.6.133.147]) by smtp.strato.de (fruni mo14) (RZmta 27.7 DYNA|AUTH) with (DHE-RSA-AES128-SHA encrypted) ESMTPA id d0179fo1NK0oPm for ; Thu, 23 Feb 2012 22:21:13 +0100 (MET) Message-ID: <4F46ADC8.2080408@brockmann-consult.de> Date: Thu, 23 Feb 2012 22:21:12 +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: <4F46847D.4010908@my.gd> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: FreeBSD9 and the sheer number of problem reports X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 23 Feb 2012 21:21:37 -0000 Am 23.02.2012 21:15, schrieb Mark Felder: > On Thu, 23 Feb 2012 12:25:01 -0600, Damien Fleuriot wrote: > >> >> Now, I find the number of problem reports regarding 9.0-RELEASE alarming >> and I'm growing more and more fearful towards it. > > Then stick with the 8.x train until it's no longer supported. Also, > don't you know the rule about running .0 releases in production? :) > > 9.0 had LOTS of changes. They were very important. It's going to take > a while for the community to fully absorb them and bugs to be worked > out. We don't have enough testers of -CURRENT to prevent this. > Everything seemed stable (ie, no release blockers) for the people > running -CURRENT and -PRERELEASE, BETAs, and RCs, so it was released. This is quite a good explanation, but what can be done in the future, so either people are testing, or more report problems? I suggest these concepts should be tested: Perhaps the testers tested beta1 and beta2, but there were so many changes after beta2, that bugs appeared in release that did not exist in beta2. Test this by reproducing things reported in release also in beta1 or 2. Perhaps the people who know the rule about running .0 releases (such as myself) never bothered to test beta1, beta2, or even release .0 (true in my case). If so, then this rule is a very bad one. Test this with a poll. Perhaps people are more interested in a preview of what new features they can expect, rather than actually planning on testing and submitting PRs. Test this also with a poll. To fix this problem, you could add an automatic bug reporting system like crash handlers in many applications (Mozilla had this long ago; KDE has this, etc.).When dealing with drivers, hard disks, removable devices, etc., the devs can't test every case, but the users can, so until the FreeBSD Foundation can afford a huge test lab with every combination of hardware, strengthening user feedback is more important than internal testing. > > But as always, TEST TEST TEST and please have a proper staging/test > environment before you throw your production into 9.x. > > Only YOU can prevent forest fires^W^W unplanned outages. > _______________________________________________ > 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 23 22:06: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 33604106564A; Thu, 23 Feb 2012 22:06:17 +0000 (UTC) (envelope-from Kashyap.Desai@lsi.com) Received: from na3sys009aog117.obsmtp.com (na3sys009aog117.obsmtp.com [74.125.149.242]) by mx1.freebsd.org (Postfix) with ESMTP id 138A28FC13; Thu, 23 Feb 2012 22:06:15 +0000 (UTC) Received: from paledge01.lsi.com ([192.19.193.42]) (using TLSv1) by na3sys009aob117.postini.com ([74.125.148.12]) with SMTP ID DSNKT0a4V3VAo29DQp3KV4QFetvZ/vWwmzT5@postini.com; Thu, 23 Feb 2012 14:06:16 PST Received: from PALHUB01.lsi.com (128.94.213.114) by PALEDGE01.lsi.com (192.19.193.42) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 23 Feb 2012 17:10:52 -0500 Received: from inbexch01.lsi.com (135.36.98.37) by PALHUB01.lsi.com (128.94.213.114) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 23 Feb 2012 17:06:06 -0500 Received: from inbmail01.lsi.com ([135.36.98.64]) by inbexch01.lsi.com ([135.36.98.37]) with mapi; Fri, 24 Feb 2012 03:36:03 +0530 From: "Desai, Kashyap" To: Alexander Kabaev Date: Fri, 24 Feb 2012 03:35:58 +0530 Thread-Topic: mpslsi0 : Trying sleep, but thread marked as sleeping prohibited Thread-Index: AczyPYPQhFXJc1z1RkuTykhWCQNRMwAOR/ZA Message-ID: References: <20120223094611.GC32748@hoeg.nl> <20120223101157.0bb3f2ee@kan.dyndns.org> In-Reply-To: <20120223101157.0bb3f2ee@kan.dyndns.org> 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: Ed Schouten , freebsd-stable , "joerg@FreeBSD.org" , "Kenneth D. Merry" , "freebsd-scsi@freebsd.org" , "Justin T. Gibbs" , "McConnell, Stephen" Subject: RE: mpslsi0 : Trying sleep, but thread marked as sleeping prohibited X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 23 Feb 2012 22:06:17 -0000 > -----Original Message----- > From: Alexander Kabaev [mailto:kabaev@gmail.com] > Sent: Thursday, February 23, 2012 8:42 PM > To: Desai, Kashyap > Cc: Ed Schouten; freebsd-stable; joerg@FreeBSD.org; Kenneth D. Merry; > freebsd-scsi@freebsd.org; Justin T. Gibbs; McConnell, Stephen > Subject: Re: mpslsi0 : Trying sleep, but thread marked as sleeping > prohibited >=20 > On Thu, 23 Feb 2012 18:45:29 +0530 > "Desai, Kashyap" wrote: >=20 > > > > > > > -----Original Message----- > > > From: Ed Schouten [mailto:ed@80386.nl] > > > Sent: Thursday, February 23, 2012 3:16 PM > > > To: Desai, Kashyap > > > Cc: freebsd-scsi@freebsd.org; freebsd-stable; joerg@FreeBSD.org; > > > Kenneth D. Merry; McConnell, Stephen; Justin T. Gibbs > > > Subject: Re: mpslsi0 : Trying sleep, but thread marked as sleeping > > > prohibited > > > > > > Hi Kashyap, > > > > > > * Desai, Kashyap , 20120222 18:51: > > > > Adding Ed Schouten and Jorg Wunsch as I see there are author of > > > > msleep/mtx related APIs. > > > > > > Am I? :-) > > I am new to FreeBSD and desperate to know the answer. :-). Thanks for > > your help. > > > > > > > 1. When any irq is register with FreeBSD OS, it sets " > > > > TDP_NOSLEEPING" pflag. It means though irq in freebsd is treated > > > > as thread, We cannot sleep in IRQ because of " "TDP_NOSLEEPING " > > > > set. 2. In mps driver we have below code snippet in ISR routine. > > > > > > > > > > > > mps_dprint(sc, MPS_TRACE, "%s\n", __func__); > > > > mps_lock(sc); > > > > mps_intr_locked(data); > > > > mps_unlock(sc); > > > > > > > > I wonder why there is no issue with above code ? Theoretical we > > > > cannot sleep in ISR. (as explained in #1) Any thoughts ? > > > > > > The TDP_NOSLEEPING flag only disallows sleeping of an indeterminate > > > amount of time. Locking a mutex is allowed, as it can only cause the > > > thread to be blocked for a small amount of time, waiting for another > > > thread to unlock it. > > So does this assumption that another thread will release mutex fast > > enough ? Same as msleep() this can be applicable here as well. I mean > > another thread _can_ (if some bad drivers) take long time to release > > mutex. > > > > > Bad drivers can just defererence wild pointer to satisfy their need for > wrongdoing. For that reason let us keep them out of conversation. OK.=20 >=20 > mtx locks were designed to protect small sections of code where thread > is only allowed to block waiting for other thread to release the lock of > similar class. While threads are blocked, they get benefit of adaptive > sleep and priority propagation and should take precaution of never > taking the path of code that can cause them to sleep. Assertions are > there to help code authors with that. >=20 > sleep locks are by definition unbound. There is no spinning, no priority > propagation. Holders are free to take, say, page faults and go to long > journey to disk and back, etc. I understood your above lines. > Hardly the stuff _anyone_ would want to > do from interrupt handler, thread or otherwise. So the way mps driver does in interrupt handler is as below. mps_lock(sc); mps_intr_locked(data); mps_unlock(sc); We hold the mtx lock in Interrupt handler and do whole bunch of work(this i= s bit lengthy work) under that.=20 It looks mps driver is miss using mtx_lock. Are we ? ~ Kashyap >=20 >=20 > > > > 3. I recently added few place msleep() instead of DELAY in ISR > > > > context and I see " Trying sleep, but thread marked as sleeping > > > > prohibited". > > > > > > Which makes sense, as msleep() can be used to sleep for > > > indefinitely. > > This part is clear. ! I agree with all experts view. > > > > > > -- > > > Ed Schouten > > > WWW: http://80386.nl/ > > _______________________________________________ > > freebsd-scsi@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-scsi > > To unsubscribe, send any mail to > > "freebsd-scsi-unsubscribe@freebsd.org" >=20 >=20 > -- > Alexander Kabaev From owner-freebsd-stable@FreeBSD.ORG Fri Feb 24 00:16: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 5C3B6106564A for ; Fri, 24 Feb 2012 00:16:01 +0000 (UTC) (envelope-from gkontos.mail@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 12C998FC0A for ; Fri, 24 Feb 2012 00:16:00 +0000 (UTC) Received: by vcmm1 with SMTP id m1so1781572vcm.13 for ; Thu, 23 Feb 2012 16:16:00 -0800 (PST) Received-SPF: pass (google.com: domain of gkontos.mail@gmail.com designates 10.52.36.2 as permitted sender) client-ip=10.52.36.2; Authentication-Results: mr.google.com; spf=pass (google.com: domain of gkontos.mail@gmail.com designates 10.52.36.2 as permitted sender) smtp.mail=gkontos.mail@gmail.com; dkim=pass header.i=gkontos.mail@gmail.com Received: from mr.google.com ([10.52.36.2]) by 10.52.36.2 with SMTP id m2mr2021980vdj.102.1330042560523 (num_hops = 1); Thu, 23 Feb 2012 16:16: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 :content-type; bh=l7C6sIbCqe8bqtuqNrI5Z1dZ7G2Uxn3X7opDovqfp+s=; b=j7ZMtjb4PGghvzJp6ETe5gcN497/vgpSJDNUy2LHvNtWt/9nWrDzyqih93A0xAoYij UCYkG/P1T+Ml3BTjCAP76bccIdbDpL2TZ1kRPAKElUv2chyWf5hNGSFugdBcsPX1s3tZ +avpJzh59xhXI2CNiHdiSygEauNYZS9PlCRJ8= MIME-Version: 1.0 Received: by 10.52.36.2 with SMTP id m2mr1677810vdj.102.1330042560457; Thu, 23 Feb 2012 16:16:00 -0800 (PST) Received: by 10.220.38.67 with HTTP; Thu, 23 Feb 2012 16:16:00 -0800 (PST) In-Reply-To: <4F46847D.4010908@my.gd> References: <4F46847D.4010908@my.gd> Date: Fri, 24 Feb 2012 02:16:00 +0200 Message-ID: From: George Kontostanos To: Damien Fleuriot , "freebsd-stable@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: Re: FreeBSD9 and the sheer number of problem reports X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 24 Feb 2012 00:16:01 -0000 > Short introduction in order: > > See, we use FreeBSD at work for our firewall boxes, running: > - PF + CARP + PFsync > - nagios-nrpe > - munin-node > - bacula client > > and either > - nginx and/or haproxy > - relayd > > These boxes serve as frontend firewalls for all our projects/products, > including a few high traffic ones. > > > For example our most traffic intense project has 4 firewalls, 2 each on > 2 different datacenters, sharing 4 CARP IPs with automagic failover. > > These firewalls total ~200mb/s , serving only minifi'ed javascript pages. > In the current state of things, I have *absolutely* no wish to run it in > production :( > > > > I'd love to hear feedback. This is really a bad example and we shouldn't jump into the .0 releases comparison. Firewalls are supposed to be super stable. The last thing you need in a firewall is trying to troubleshoot OS related issues. Most major brands use well patched long tested OS to build their firewall software. So, no you shouldn't jump to 9 before it has been thoroughly tested. That doesn't mean of course that you should let others do the testing for you. If you plan on moving your environment to 9 at some point in the future then you have to start your own testing now. Best Regards, -- George Kontostanos Aicom telecoms ltd http://www.aisecure.net From owner-freebsd-stable@FreeBSD.ORG Fri Feb 24 01:12:02 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 D001A1065675 for ; Fri, 24 Feb 2012 01:12:02 +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 624DE8FC1C for ; Fri, 24 Feb 2012 01:12:02 +0000 (UTC) Received: by pbcxa7 with SMTP id xa7so2227817pbc.13 for ; Thu, 23 Feb 2012 17:12:02 -0800 (PST) Received-SPF: pass (google.com: domain of pyunyh@gmail.com designates 10.68.232.230 as permitted sender) client-ip=10.68.232.230; Authentication-Results: mr.google.com; spf=pass (google.com: domain of pyunyh@gmail.com designates 10.68.232.230 as permitted sender) smtp.mail=pyunyh@gmail.com; dkim=pass header.i=pyunyh@gmail.com Received: from mr.google.com ([10.68.232.230]) by 10.68.232.230 with SMTP id tr6mr922531pbc.165.1330045922013 (num_hops = 1); Thu, 23 Feb 2012 17:12: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=/EDSg/PgCtucCP1aICwMEHmwHvO4DiwWpxVDFjFTVZo=; b=UjuOZoJ4HFf6IjTeMczvCqvEg3t87fv64clGRwLHSpDVWVIScCARx0qvHxvTtSfs3o IWcZ0v4/f+kCPMs/gXQUQ1vT1Sv93sC92Jqf7DiPqN1seBuUD7GeFmpAP6ly+KYMwAfx 79tZcmdYgTnQEBes3BeQrlAvoeiZsSxqBlIv8= Received: by 10.68.232.230 with SMTP id tr6mr767753pbc.165.1330045921983; Thu, 23 Feb 2012 17:12:01 -0800 (PST) Received: from pyunyh@gmail.com ([114.111.62.249]) by mx.google.com with ESMTPS id x3sm2871926pbg.35.2012.02.23.17.11.59 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 23 Feb 2012 17:12:01 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Fri, 24 Feb 2012 10:11:55 -0800 From: YongHyeon PYUN Date: Fri, 24 Feb 2012 10:11:55 -0800 To: Attila Nagy Message-ID: <20120224181155.GB18456@michelle.cdnetworks.com> References: <4F449E0B.2040909@fsn.hu> <20120223041516.GI6861@michelle.cdnetworks.com> <4F44FF2A.9050505@fsn.hu> <20120223204401.GB13815@michelle.cdnetworks.com> <4F45DF95.9050309@fsn.hu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F45DF95.9050309@fsn.hu> User-Agent: Mutt/1.4.2.3i Cc: stable@freebsd.org Subject: Re: Fatal trap 19, Stopped at bge_init_locked+ and bge booting problems 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: Fri, 24 Feb 2012 01:12:03 -0000 On Thu, Feb 23, 2012 at 07:41:25AM +0100, Attila Nagy wrote: > On 02/23/12 21:44, YongHyeon PYUN wrote: > >I have to ask more information for the controller to Broadcom. > >Not sure whether I can get some hint at this moment though. :-( > Is there anything I can do? I ask this because I have to give back this > server very soon. > > > >Given that you also have USB related errors, could you completely > >remove bge(4) in your kernel and see whether it can successfully > >boot up? > >I think you can add the following entries to /boot/device.hints > >without rebuilding kernel. > > > >hint.bge.0.disabled="1" > >hint.bge.1.disabled="1" > >hint.bge.2.disabled="1" > >hint.bge.3.disabled="1" > This does not help. > Removing bge makes it stop here: > da0 at ciss0 bus 0 scbus0 target 0 lun 0 > da0: Fixed Direct Access SCSI-5 device > da0: 135.168MB/s transfers > da0: Command Queueing enabled > da0: 286070MB (585871964 512 byte sectors: 255H 32S/T 65535C) > panic: bootpc_init: no eligible interfaces > 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 > bootpc_init() at bootpc_init+0x1205 > mi_startup() at mi_startup+0x77 > btext() at btext+0x2c > KDB: enter: panic > [ thread pid 0 tid 100000 ] > Stopped at kdb_enter+0x3b: movq $0,0x976972(%rip) > db> > > Which is completely OK, because there are really no interfaces to boot > from. Note that there is no NMI either (maybe because it would happen > later in the initialization process). > Sadly, I can't boot from disk, but I assume it would work. Ok, I guess you're seeing similar issue that Sean reported. I'll let you when I have experimental patch. From owner-freebsd-stable@FreeBSD.ORG Fri Feb 24 02:01: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 3B62E1065672 for ; Fri, 24 Feb 2012 02:01:15 +0000 (UTC) (envelope-from erichfreebsdlist@ovitrap.com) Received: from alogreentechnologies.com (alogreentechnologies.com [67.212.226.44]) by mx1.freebsd.org (Postfix) with ESMTP id 8CECA8FC12 for ; Fri, 24 Feb 2012 02:00:53 +0000 (UTC) Received: from amd620.ovitrap.com ([49.128.188.2]) (authenticated bits=0) by alogreentechnologies.com (8.13.1/8.13.1) with ESMTP id q1O1ZZAp024852; Thu, 23 Feb 2012 18:35:37 -0700 From: Erich Dollansky To: freebsd-stable@freebsd.org Date: Fri, 24 Feb 2012 08:35:31 +0700 User-Agent: KMail/1.13.7 (FreeBSD/8.3-PRERELEASE; KDE/4.7.4; amd64; ; ) References: <4F46847D.4010908@my.gd> In-Reply-To: <4F46847D.4010908@my.gd> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201202240835.32041.erichfreebsdlist@ovitrap.com> Cc: Subject: Re: FreeBSD9 and the sheer number of problem reports X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 24 Feb 2012 02:01:15 -0000 Hi, On Friday 24 February 2012 01:25:01 Damien Fleuriot wrote: > > This is NOT a troll. > This is NOT a flame. > Do NOT hijack this thread to troll/flame. > allow them some fun too. > > > Now, I find the number of problem reports regarding 9.0-RELEASE alarming > and I'm growing more and more fearful towards it. > > In the current state of things, I have *absolutely* no wish to run it in > production :( > Did you read deeply into the strategy behind the releases? If I remember right, the odd numbers are a little bit more experimental compared to the even numbers. For myself, I try to stick with even numbers whenever possible. If I install FreeBSD on a serious machine, I never use x.0. It must be at least x.1. So, I have the same wish as you and did not expect much more. Never forget, if the people behind the scene never put a release out, we never have the chance to iron out the problems. And now the fun. I even run 8.3 beta on my personal workstation. But I still would not put 9.0 on any machine I work with or give it to somebody else for this purpose. Erich From owner-freebsd-stable@FreeBSD.ORG Fri Feb 24 02:17: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 9A9BB106566C for ; Fri, 24 Feb 2012 02:17:33 +0000 (UTC) (envelope-from petro.rossini@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 534398FC13 for ; Fri, 24 Feb 2012 02:17:33 +0000 (UTC) Received: by vcmm1 with SMTP id m1so1854871vcm.13 for ; Thu, 23 Feb 2012 18:17:32 -0800 (PST) Received-SPF: pass (google.com: domain of petro.rossini@gmail.com designates 10.220.107.212 as permitted sender) client-ip=10.220.107.212; Authentication-Results: mr.google.com; spf=pass (google.com: domain of petro.rossini@gmail.com designates 10.220.107.212 as permitted sender) smtp.mail=petro.rossini@gmail.com; dkim=pass header.i=petro.rossini@gmail.com Received: from mr.google.com ([10.220.107.212]) by 10.220.107.212 with SMTP id c20mr198088vcp.26.1330049852887 (num_hops = 1); Thu, 23 Feb 2012 18:17:32 -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=4nW/wRlIfA68/Z7fkbTtOMT6yIFl1jQxhZh/Nv9bRMg=; b=QFm+w1nIV/VS875GYAbm/OUeNL9wU3f2G7lNW8m6TjZr86JOLFQUO91fy6XfTL/NRY JKxnoAglUuh9+XAORvr6DzINZ1bgtmU7dd5H8xKFWvqLkDfyVT+UxzioJj8gzQV5lRWx UlJ0EAiv8FSDVIqb5LIeNV1CJf5RMnI5pViSE= MIME-Version: 1.0 Received: by 10.220.107.212 with SMTP id c20mr159777vcp.26.1330049852742; Thu, 23 Feb 2012 18:17:32 -0800 (PST) Received: by 10.220.203.67 with HTTP; Thu, 23 Feb 2012 18:17:32 -0800 (PST) In-Reply-To: <4F46847D.4010908@my.gd> References: <4F46847D.4010908@my.gd> Date: Fri, 24 Feb 2012 13:17:32 +1100 Message-ID: From: Petro Rossini To: Damien Fleuriot Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-stable@freebsd.org" Subject: Re: FreeBSD9 and the sheer number of problem reports X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 24 Feb 2012 02:17:33 -0000 Hi Damien, On Fri, Feb 24, 2012 at 5:25 AM, Damien Fleuriot wrote: > I'm writing this in light of the *many* problem reports I see on the > lists with 9.0-RELEASE. > > I'm getting extremely worried here. > .. > See, we use FreeBSD at work for our firewall boxes, running: > .. > These boxes serve as frontend firewalls for all our projects/products, > including a few high traffic ones. > Hi Damien, I guess you wouldn't roll out a new release on all FreeBSD servers in one go. For most environments there is room to staging it, from test and developer boxes upwards to production. At the moment I am running FreeBSD 9 on some developer boxes, Nagios monitoring and others. It works without problems even if I am using VIMAGE which is still an experimental feature. Sooner or later I will install it on other more relevant production machines. Don't worry, it isn't that bad;-) If I can have one wish from the engineering team: please keep the schedule up to date. http://www.freebsd.org/releases/9.0R/schedule.html isn't showing the release yet, http://wiki.freebsd.org/Releng/9.0TODO was also quite behind. Maybe one web page is enough.. Thanks Peter From owner-freebsd-stable@FreeBSD.ORG Fri Feb 24 06:46: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 16FDA106566C for ; Fri, 24 Feb 2012 06:46:28 +0000 (UTC) (envelope-from erichfreebsdlist@ovitrap.com) Received: from alogreentechnologies.com (alogreentechnologies.com [67.212.226.44]) by mx1.freebsd.org (Postfix) with ESMTP id C3D388FC08 for ; Fri, 24 Feb 2012 06:46:27 +0000 (UTC) Received: from amd620.ovitrap.com ([49.128.188.2]) (authenticated bits=0) by alogreentechnologies.com (8.13.1/8.13.1) with ESMTP id q1O6kK9x031165; Thu, 23 Feb 2012 23:46:23 -0700 From: Erich Dollansky To: freebsd-stable@freebsd.org Date: Fri, 24 Feb 2012 13:46:14 +0700 User-Agent: KMail/1.13.7 (FreeBSD/8.3-PRERELEASE; KDE/4.7.4; amd64; ; ) References: <4F46847D.4010908@my.gd> <4F46ADC8.2080408@brockmann-consult.de> In-Reply-To: <4F46ADC8.2080408@brockmann-consult.de> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201202241346.15160.erichfreebsdlist@ovitrap.com> Cc: Peter Maloney Subject: Re: FreeBSD9 and the sheer number of problem reports X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 24 Feb 2012 06:46:28 -0000 Hi, On Friday 24 February 2012 04:21:12 Peter Maloney wrote: > Am 23.02.2012 21:15, schrieb Mark Felder: > > On Thu, 23 Feb 2012 12:25:01 -0600, Damien Fleuriot wrote: > > > >> > >> Now, I find the number of problem reports regarding 9.0-RELEASE alarming > >> and I'm growing more and more fearful towards it. > > > I suggest these concepts should be tested: > I can tell you what in practical terms stops me from testing very often. The switch back to the running version. Let me suggest this. Currently, we have on the disk normally two kernels. The current one and the last one. Why not add a third one called testing? Add then an entry into the boot menu that users can switch between the current kernel and a kernel they just installed for testing. I know that I can do this manually. But this is the point where it becomes difficult for the majority of people. As FreeBSD needs a large amount of testing on unknown hardware, this could increase the number of actual testers without much effort. Ok, the developers must then be ready to deal with reports which miss many things. Erich From owner-freebsd-stable@FreeBSD.ORG Fri Feb 24 06:51: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 302B6106564A for ; Fri, 24 Feb 2012 06:51:05 +0000 (UTC) (envelope-from erichfreebsdlist@ovitrap.com) Received: from alogreentechnologies.com (alogreentechnologies.com [67.212.226.44]) by mx1.freebsd.org (Postfix) with ESMTP id DDF868FC08 for ; Fri, 24 Feb 2012 06:51:04 +0000 (UTC) Received: from amd620.ovitrap.com ([49.128.188.2]) (authenticated bits=0) by alogreentechnologies.com (8.13.1/8.13.1) with ESMTP id q1O6p0UK032122; Thu, 23 Feb 2012 23:51:03 -0700 From: Erich Dollansky To: freebsd-stable@freebsd.org Date: Fri, 24 Feb 2012 13:50:56 +0700 User-Agent: KMail/1.13.7 (FreeBSD/8.3-PRERELEASE; KDE/4.7.4; amd64; ; ) References: <201202221334.36484.erich@alogreentechnologies.com> <64FF3DF7-6EEA-480D-85AA-5784AF013EA8@lassitu.de> In-Reply-To: <64FF3DF7-6EEA-480D-85AA-5784AF013EA8@lassitu.de> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201202241350.56933.erichfreebsdlist@ovitrap.com> Cc: Stefan Bethke Subject: Re: random problem with 8.3 from yesterday X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 24 Feb 2012 06:51:05 -0000 Hi, On Thursday 23 February 2012 20:22:57 Stefan Bethke wrote: > Am 22.02.2012 um 07:34 schrieb Erich Dollansky: > > > > > tunefs -L NewDeviceName /dev/da0a > > > > Either this call or the mount command does not work randomly. > > > > When I then try to mount the device on /dev/da0a it does not work always. > > > > I do not know what this causes, I am only randomly able to reproduce it. > > > > It might be affected by removing the device or keeping it plugged in. > > You need to be more specific: what "does not work" mean? Output, results? > it seems that I forgot to copy the console output for this. Ok, as far as I remember, tunefs said something like it does not recognise the slice. Mount has had two different messages. One also said that it could not find/recognise the slice. The other one said that the file system was unknown despite just running a newfs on it. I am very much aware that this kind of errors are very hard to find especially if they are not reproduceable. Erich > > Stefan > > -- > Stefan Bethke Fon +49 151 14070811 > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > > From owner-freebsd-stable@FreeBSD.ORG Fri Feb 24 08:34: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 4D26F106566B for ; Fri, 24 Feb 2012 08:34:08 +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 C38BC8FC14 for ; Fri, 24 Feb 2012 08:34:07 +0000 (UTC) Received: by bkcjg1 with SMTP id jg1so2367056bkc.13 for ; Fri, 24 Feb 2012 00:34:06 -0800 (PST) Received-SPF: pass (google.com: domain of andrnils@gmail.com designates 10.204.129.71 as permitted sender) client-ip=10.204.129.71; Authentication-Results: mr.google.com; spf=pass (google.com: domain of andrnils@gmail.com designates 10.204.129.71 as permitted sender) smtp.mail=andrnils@gmail.com; dkim=pass header.i=andrnils@gmail.com Received: from mr.google.com ([10.204.129.71]) by 10.204.129.71 with SMTP id n7mr582286bks.91.1330072446682 (num_hops = 1); Fri, 24 Feb 2012 00:34: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=0RhwGtiukJhXcfW4ANnD1X2Bhx7LTzFaSVjOdJoF6Aw=; b=csk8LXyLXjrk6wvHFZQ4vfLzRsTl8r48atCSUgyTO7xyPyhouYyo8Iuh4GZ4JKAaCg napV2M+stXsOU5s17c4StZ7cgvXBSl6MgqpdIyULNAcCze4dP3RJvjzrV+t3xOwQ2wsg 40YGcHe/Cli4s10dD0gqlLuMNid1oqhzzBbz0= MIME-Version: 1.0 Received: by 10.204.129.71 with SMTP id n7mr482544bks.91.1330072446591; Fri, 24 Feb 2012 00:34:06 -0800 (PST) Received: by 10.204.163.140 with HTTP; Fri, 24 Feb 2012 00:34:06 -0800 (PST) In-Reply-To: <201202241346.15160.erichfreebsdlist@ovitrap.com> References: <4F46847D.4010908@my.gd> <4F46ADC8.2080408@brockmann-consult.de> <201202241346.15160.erichfreebsdlist@ovitrap.com> Date: Fri, 24 Feb 2012 09:34:06 +0100 Message-ID: From: Andreas Nilsson To: Erich Dollansky Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Peter Maloney , freebsd-stable@freebsd.org Subject: Re: FreeBSD9 and the sheer number of problem reports X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 24 Feb 2012 08:34:08 -0000 On Fri, Feb 24, 2012 at 7:46 AM, Erich Dollansky < erichfreebsdlist@ovitrap.com> wrote: > Hi, > > On Friday 24 February 2012 04:21:12 Peter Maloney wrote: > > Am 23.02.2012 21:15, schrieb Mark Felder: > > > On Thu, 23 Feb 2012 12:25:01 -0600, Damien Fleuriot wrote: > > > > > >> > > >> Now, I find the number of problem reports regarding 9.0-RELEASE > alarming > > >> and I'm growing more and more fearful towards it. > > > > > I suggest these concepts should be tested: > > > I can tell you what in practical terms stops me from testing very often. > The switch back to the running version. > > Let me suggest this. > > Currently, we have on the disk normally two kernels. The current one and > the last one. Why not add a third one called testing? > > Add then an entry into the boot menu that users can switch between the > current kernel and a kernel they just installed for testing. > Well, as you would want to test both kernel + userland its get a bit tricky on ufs based system, as you have to setup several slices/partitions. For ZFS its easier, as the only thing required would be a snapshot of clean install, which the user then can just zfs recv, modify vfs.root.mountfrom and so on. Just my thoughts. Andreas > > I know that I can do this manually. But this is the point where it becomes > difficult for the majority of people. > > As FreeBSD needs a large amount of testing on unknown hardware, this could > increase the number of actual testers without much effort. > > Ok, the developers must then be ready to deal with reports which miss many > things. > > Erich > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Fri Feb 24 10: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 8CCC1106564A for ; Fri, 24 Feb 2012 10:26:02 +0000 (UTC) (envelope-from erichfreebsdlist@ovitrap.com) Received: from alogreentechnologies.com (alogreentechnologies.com [67.212.226.44]) by mx1.freebsd.org (Postfix) with ESMTP id 3BF928FC15 for ; Fri, 24 Feb 2012 10:26:01 +0000 (UTC) Received: from amd620.ovitrap.com ([49.128.188.2]) (authenticated bits=0) by alogreentechnologies.com (8.13.1/8.13.1) with ESMTP id q1OAPq3X014619; Fri, 24 Feb 2012 03:25:56 -0700 From: Erich Dollansky To: freebsd-stable@freebsd.org Date: Fri, 24 Feb 2012 17:25:34 +0700 User-Agent: KMail/1.13.7 (FreeBSD/8.3-PRERELEASE; KDE/4.7.4; amd64; ; ) References: <4F46847D.4010908@my.gd> <201202241346.15160.erichfreebsdlist@ovitrap.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201202241725.35198.erichfreebsdlist@ovitrap.com> Cc: Peter Maloney , Andreas Nilsson Subject: Re: FreeBSD9 and the sheer number of problem reports X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 24 Feb 2012 10:26:02 -0000 Hi, On Friday 24 February 2012 15:34:06 Andreas Nilsson wrote: > On Fri, Feb 24, 2012 at 7:46 AM, Erich Dollansky < > erichfreebsdlist@ovitrap.com> wrote: > > > On Friday 24 February 2012 04:21:12 Peter Maloney wrote: > > > Am 23.02.2012 21:15, schrieb Mark Felder: > > > > On Thu, 23 Feb 2012 12:25:01 -0600, Damien Fleuriot wrote: > > Let me suggest this. > > > > Currently, we have on the disk normally two kernels. The current one and > > the last one. Why not add a third one called testing? > > > > Add then an entry into the boot menu that users can switch between the > > current kernel and a kernel they just installed for testing. > > > > Well, as you would want to test both kernel + userland its get a bit tricky > on ufs based system, as you have to setup several slices/partitions. For > ZFS its easier, as the only thing required would be a snapshot of clean > install, which the user then can just zfs recv, modify vfs.root.mountfrom > and so on. > /usr/local for the current system and /usr/localtest for the other system. Of course, the same for /bin, /etc ... It is not that difficult. Or a script which renames the directories for the next start. Erich From owner-freebsd-stable@FreeBSD.ORG Fri Feb 24 10:33: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 22E11106566C for ; Fri, 24 Feb 2012 10:33:00 +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 C673A8FC14 for ; Fri, 24 Feb 2012 10:32:59 +0000 (UTC) Received: by vcmm1 with SMTP id m1so2126675vcm.13 for ; Fri, 24 Feb 2012 02:32:59 -0800 (PST) Received-SPF: pass (google.com: domain of tevans.uk@googlemail.com designates 10.220.209.200 as permitted sender) client-ip=10.220.209.200; Authentication-Results: mr.google.com; spf=pass (google.com: domain of tevans.uk@googlemail.com designates 10.220.209.200 as permitted sender) smtp.mail=tevans.uk@googlemail.com; dkim=pass header.i=tevans.uk@googlemail.com Received: from mr.google.com ([10.220.209.200]) by 10.220.209.200 with SMTP id gh8mr965850vcb.55.1330079579092 (num_hops = 1); Fri, 24 Feb 2012 02:32:59 -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=uUFP7I4QnKV2PD4vZ7nyDugRINg3MSdxxy4qIE6alJU=; b=K9cd3w08c7rHC+9u5TvqfBPI2gVGw6FgtMDepKYodRLKFShLn1VE84L6k3ssNO6ngM +Sh2SEaUfe7+17j9GwWkp1A8E1SHMFDCNRYaBXd/7nA2F0QCYwXqi+pvwERuitR0VMfi qB8SAK/TBcFoS0nZbQ8Kx9VxDatA8YgFWRqKc= MIME-Version: 1.0 Received: by 10.220.209.200 with SMTP id gh8mr739557vcb.55.1330079578884; Fri, 24 Feb 2012 02:32:58 -0800 (PST) Received: by 10.52.91.210 with HTTP; Fri, 24 Feb 2012 02:32:58 -0800 (PST) In-Reply-To: <4F46ADC8.2080408@brockmann-consult.de> References: <4F46847D.4010908@my.gd> <4F46ADC8.2080408@brockmann-consult.de> Date: Fri, 24 Feb 2012 10:32:58 +0000 Message-ID: From: Tom Evans To: Peter Maloney Content-Type: text/plain; charset=UTF-8 Cc: freebsd-stable@freebsd.org Subject: Re: FreeBSD9 and the sheer number of problem reports X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 24 Feb 2012 10:33:00 -0000 On Thu, Feb 23, 2012 at 9:21 PM, Peter Maloney wrote: > I suggest these concepts should be tested: > > Perhaps the testers tested beta1 and beta2, but there were so many > changes after beta2, that bugs appeared in release that did not exist in > beta2. Test this by reproducing things reported in release also in beta1 > or 2. > > Perhaps the people who know the rule about running .0 releases (such as > myself) never bothered to test beta1, beta2, or even release .0 (true in > my case). If so, then this rule is a very bad one. Test this with a poll. > At $JOB, we never install a N.0 release either, but only because the .0 release has such a brief life. The N.1 and N.3 releases have extended lifetimes, and so we tend to only use those versions. Cheers Tom From owner-freebsd-stable@FreeBSD.ORG Fri Feb 24 11:42: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 76853106566B; Fri, 24 Feb 2012 11:42:11 +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 3DEF98FC0A; Fri, 24 Feb 2012 11:42:10 +0000 (UTC) Received: from [127.0.0.1] (helo=youse) by hybrid-sites.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1S0szG-000EeU-ET; Fri, 24 Feb 2012 11:07:00 +0000 From: Luke Marsden To: "freebsd-stable@freebsd.org" Content-Type: text/plain; charset="UTF-8" Date: Fri, 24 Feb 2012 11:06:52 +0000 Message-ID: <1330081612.13430.39.camel@pow> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 Content-Transfer-Encoding: 7bit X-Spam-bar: / Cc: freebsd-fs@freebsd.org, team@hybrid-logic.co.uk Subject: Another ZFS ARC memory question X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 24 Feb 2012 11:42:11 -0000 Hi all, Just wanted to get your opinion on best practices for ZFS. We're running 8.2-RELEASE v15 in production on 24GB RAM amd64 machines but have been having trouble with short spikes in application memory usage resulting in huge amounts of swapping, bringing the whole machine to its knees and crashing it hard. I suspect this is because when there is a sudden spike in memory usage the zfs arc reclaim thread is unable to free system memory fast enough. This most recently happened yesterday as you can see from the following munin graphs: E.g. http://hybrid-logic.co.uk/memory-day.png http://hybrid-logic.co.uk/swap-day.png Our response has been to start limiting the ZFS ARC cache to 4GB on our production machines - trading performance for stability is fine with me (and we have L2ARC on SSD so we still get good levels of caching). My questions are: * is this a known problem? * what is the community's advice for production machines running ZFS on FreeBSD, is manually limiting the ARC cache (to ensure that there's enough actually free memory to handle a spike in application memory usage) the best solution to this spike-in-memory-means-crash problem? * has FreeBSD 9.0 / ZFS v28 solved this problem? * rather than setting a hard limit on the ARC cache size, is it possible to adjust the auto-tuning variables to leave more free memory for spiky memory situations? e.g. set the auto-tuning to make arc eat 80% of memory instead of ~95% like it is at present? * could the arc reclaim thread be made to drop ARC pages with higher priority before the system starts swapping out application pages? Thank you for any/all answers, and thank you for making FreeBSD awesome :-) Best Regards, Luke Marsden -- CTO, Hybrid Logic +447791750420 | +1-415-449-1165 | www.hybrid-cluster.com From owner-freebsd-stable@FreeBSD.ORG Fri Feb 24 14:33: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 25CDC106566B; Fri, 24 Feb 2012 14:33: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 55BC68FC0C; Fri, 24 Feb 2012 14:33:53 +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 q1OEXbpq004876; Fri, 24 Feb 2012 16:33:37 +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 q1OEXbOb002119; Fri, 24 Feb 2012 16:33:37 +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 q1OEXbAi002118; Fri, 24 Feb 2012 16:33:37 +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: Fri, 24 Feb 2012 16:33:36 +0200 From: Konstantin Belousov To: Hiroki Sato Message-ID: <20120224143336.GS55074@deviant.kiev.zoral.com.ua> References: <20120223.234558.1101656075598772176.hrs@allbsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="GohmpbibSJzDFTQZ" Content-Disposition: inline In-Reply-To: <20120223.234558.1101656075598772176.hrs@allbsd.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: stable@freebsd.org Subject: Re: another panic in 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: Fri, 24 Feb 2012 14:33:55 -0000 --GohmpbibSJzDFTQZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Feb 23, 2012 at 11:45:58PM +0900, Hiroki Sato wrote: > Hi, >=20 > This is another reproducible panic. This seems to happen only when > top(1) is running for a long time (a sysctl() call for > CTL_KERN.KERN_PROC.KERN_PROC_PROC MIB triggered it). >=20 > ---- > pool.allbsd.org dumped core - see /var/crash/vmcore.0 >=20 > Thu Feb 23 23:21:52 JST 2012 >=20 > FreeBSD pool.allbsd.org 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #8: Thu Feb= 23 04:40:54 JST 2012 hrs@pool.allbsd.org:/usr/obj/usr/src/sys/POOL am= d64 >=20 > panic: >=20 > 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"... >=20 > Unread portion of the kernel message buffer: >=20 >=20 > Fatal trap 12: page fault while in kernel mode > cpuid =3D 4; apic id =3D 04 > fault virtual address =3D 0x800e96000 > fault code =3D supervisor write data, protection violation > instruction pointer =3D 0x20:0xffffffff809440cb > stack pointer =3D 0x28:0xffffff86c63890b0 > frame pointer =3D 0x28:0xffffff86c6389100 > 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 47211 (top) > lock order reversal: (Giant after non-sleepable) > 1st 0xffffff0244b85568 process lock (process lock) @ /usr/src/sys/kern/k= ern_proc.c:1211 > 2nd 0xffffffff80d74c80 Giant (Giant) @ /usr/src/sys/dev/usb/input/ukbd.c= :2018 > KDB: stack backtrace: > Dumping 23903 out of 24550 MB:..1%..11%..21%..31% (CTRL-C to abort) (CTR= L-C to abort) ..41%..51%..61%..71%..81%..91% >=20 > Reading symbols from /boot/kernel/geom_mirror.ko...Reading symbols from /= boot/kernel/geom_mirror.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/geom_mirror.ko > Reading symbols from /boot/kernel/zfs.ko...Reading symbols from /boot/ker= nel/zfs.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/zfs.ko > Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols from /= boot/kernel/opensolaris.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/opensolaris.ko > Reading symbols from /boot/kernel/ipfw.ko...Reading symbols from /boot/ke= rnel/ipfw.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/ipfw.ko > #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:263 > 263 if (textdump_pending) > (kgdb) #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:263 > #1 0xffffffff801f8cfc in db_fncall (dummy1=3DVariable "dummy1" is not av= ailable. > ) > at /usr/src/sys/ddb/db_command.c:548 > #2 0xffffffff801f9031 in db_command (last_cmdp=3D0xffffffff80d37f40, cmd= _table=3DVariable "cmd_table" is not available. >=20 > ) at /usr/src/sys/ddb/db_command.c:445 > #3 0xffffffff801f9280 in db_command_loop () > at /usr/src/sys/ddb/db_command.c:498 > #4 0xffffffff801fb369 in db_trap (type=3DVariable "type" is not availabl= e. > ) at /usr/src/sys/ddb/db_main.c:229 > #5 0xffffffff8069dff1 in kdb_trap (type=3D12, code=3D0, tf=3D0xffffff86c= 6389000) > at /usr/src/sys/kern/subr_kdb.c:548 > #6 0xffffffff809461ed in trap_fatal (frame=3D0xffffff86c6389000, eva=3DV= ariable "eva" is not available. > ) > at /usr/src/sys/amd64/amd64/trap.c:820 > #7 0xffffffff809468b5 in trap (frame=3D0xffffff86c6389000) > at /usr/src/sys/amd64/amd64/trap.c:326 > #8 0xffffffff8092d2f4 in calltrap () > at /usr/src/sys/amd64/amd64/exception.S:228 > #9 0xffffffff809440cb in copyout () at /usr/src/sys/amd64/amd64/support.= S:258 > #10 0xffffffff80675f1f in sysctl_old_user (req=3D0xffffff86c63899c0, > p=3D0xffffff86c6389470, l=3D1088) at /usr/src/sys/kern/kern_sysctl.c:= 1276 > #11 0xffffffff8065f6a6 in sysctl_out_proc_copyout (ki=3D0xffffff86c638947= 0, > req=3D0xffffff86c63899c0) at /usr/src/sys/kern/kern_proc.c:1085 > #12 0xffffffff8065ff6c in sysctl_out_proc (p=3D0xffffff0244b85470, > req=3D0xffffff86c63899c0, flags=3DVariable "flags" is not available. > ) at /usr/src/sys/kern/kern_proc.c:1114 > #13 0xffffffff8066245e in sysctl_kern_proc (oidp=3DVariable "oidp" is not= available. > ) > at /usr/src/sys/kern/kern_proc.c:1302 > #14 0xffffffff806756e8 in sysctl_root (oidp=3DVariable "oidp" is not avai= lable. > ) > at /usr/src/sys/kern/kern_sysctl.c:1455 > #15 0xffffffff8067598e in userland_sysctl (td=3D0x0, name=3D0xffffff86c63= 89a80, > namelen=3D3, old=3D0x800e96000, oldlenp=3DVariable "oldlenp" is not a= vailable. > ) > at /usr/src/sys/kern/kern_sysctl.c:1565 > #16 0xffffffff80675e3a in __sysctl (td=3D0xffffff0396ec5460, > uap=3D0xffffff86c6389bc0) at /usr/src/sys/kern/kern_sysctl.c:1491 > #17 0xffffffff80945809 in amd64_syscall (td=3D0xffffff0396ec5460, traced= =3D0) > at subr_syscall.c:114 > #18 0xffffffff8092d5ec in Xfast_syscall () > at /usr/src/sys/amd64/amd64/exception.S:387 > #19 0x0000000800abecfc in ?? () > Previous frame inner to this frame (corrupt stack?) > (kgdb) Can you, please, print out the content of *td, e.g. from the frame 16 ? --GohmpbibSJzDFTQZ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk9Hn8AACgkQC3+MBN1Mb4hQzACghLihs0BQA/smos2jj7Qm4Lyb GysAoMp3tt+TojUmGmINw3sppJHaW4sK =cMO5 -----END PGP SIGNATURE----- --GohmpbibSJzDFTQZ-- From owner-freebsd-stable@FreeBSD.ORG Fri Feb 24 15:03:11 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 E9D67106564A; Fri, 24 Feb 2012 15:03:11 +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 2A6228FC08; Fri, 24 Feb 2012 15:03:10 +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 q1OF30lE002671; Fri, 24 Feb 2012 17:03:00 +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 q1OF2xmS002372; Fri, 24 Feb 2012 17:02:59 +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 q1OF2xb2002371; Fri, 24 Feb 2012 17:02:59 +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: Fri, 24 Feb 2012 17:02:59 +0200 From: Konstantin Belousov To: Hiroki Sato Message-ID: <20120224150259.GV55074@deviant.kiev.zoral.com.ua> References: <20120223.234558.1101656075598772176.hrs@allbsd.org> <20120224143336.GS55074@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7aLy7NWYeEog7w9O" Content-Disposition: inline In-Reply-To: <20120224143336.GS55074@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: stable@freebsd.org Subject: Re: another panic in 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: Fri, 24 Feb 2012 15:03:12 -0000 --7aLy7NWYeEog7w9O Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Feb 24, 2012 at 04:33:36PM +0200, Konstantin Belousov wrote: > On Thu, Feb 23, 2012 at 11:45:58PM +0900, Hiroki Sato wrote: > > Hi, > >=20 > > This is another reproducible panic. This seems to happen only when > > top(1) is running for a long time (a sysctl() call for > > CTL_KERN.KERN_PROC.KERN_PROC_PROC MIB triggered it). > >=20 > > ---- > > pool.allbsd.org dumped core - see /var/crash/vmcore.0 > >=20 > > Thu Feb 23 23:21:52 JST 2012 > >=20 > > FreeBSD pool.allbsd.org 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #8: Thu F= eb 23 04:40:54 JST 2012 hrs@pool.allbsd.org:/usr/obj/usr/src/sys/POOL = amd64 > >=20 > > panic: > >=20 > > GNU gdb 6.1.1 [FreeBSD] > > Copyright 2004 Free Software Foundation, Inc. > > GDB is free software, covered by the GNU General Public License, and yo= u are > > welcome to change it and/or distribute copies of it under certain condi= tions. > > Type "show copying" to see the conditions. > > There is absolutely no warranty for GDB. Type "show warranty" for deta= ils. > > This GDB was configured as "amd64-marcel-freebsd"... > >=20 > > Unread portion of the kernel message buffer: > >=20 > >=20 > > Fatal trap 12: page fault while in kernel mode > > cpuid =3D 4; apic id =3D 04 > > fault virtual address =3D 0x800e96000 > > fault code =3D supervisor write data, protection violation > > instruction pointer =3D 0x20:0xffffffff809440cb > > stack pointer =3D 0x28:0xffffff86c63890b0 > > frame pointer =3D 0x28:0xffffff86c6389100 > > 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 47211 (top) > > lock order reversal: (Giant after non-sleepable) > > 1st 0xffffff0244b85568 process lock (process lock) @ /usr/src/sys/kern= /kern_proc.c:1211 > > 2nd 0xffffffff80d74c80 Giant (Giant) @ /usr/src/sys/dev/usb/input/ukbd= .c:2018 > > KDB: stack backtrace: > > Dumping 23903 out of 24550 MB:..1%..11%..21%..31% (CTRL-C to abort) (C= TRL-C to abort) ..41%..51%..61%..71%..81%..91% > >=20 > > Reading symbols from /boot/kernel/geom_mirror.ko...Reading symbols from= /boot/kernel/geom_mirror.ko.symbols...done. > > done. > > Loaded symbols for /boot/kernel/geom_mirror.ko > > Reading symbols from /boot/kernel/zfs.ko...Reading symbols from /boot/k= ernel/zfs.ko.symbols...done. > > done. > > Loaded symbols for /boot/kernel/zfs.ko > > Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols from= /boot/kernel/opensolaris.ko.symbols...done. > > done. > > Loaded symbols for /boot/kernel/opensolaris.ko > > Reading symbols from /boot/kernel/ipfw.ko...Reading symbols from /boot/= kernel/ipfw.ko.symbols...done. > > done. > > Loaded symbols for /boot/kernel/ipfw.ko > > #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:263 > > 263 if (textdump_pending) > > (kgdb) #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:263 > > #1 0xffffffff801f8cfc in db_fncall (dummy1=3DVariable "dummy1" is not = available. > > ) > > at /usr/src/sys/ddb/db_command.c:548 > > #2 0xffffffff801f9031 in db_command (last_cmdp=3D0xffffffff80d37f40, c= md_table=3DVariable "cmd_table" is not available. > >=20 > > ) at /usr/src/sys/ddb/db_command.c:445 > > #3 0xffffffff801f9280 in db_command_loop () > > at /usr/src/sys/ddb/db_command.c:498 > > #4 0xffffffff801fb369 in db_trap (type=3DVariable "type" is not availa= ble. > > ) at /usr/src/sys/ddb/db_main.c:229 > > #5 0xffffffff8069dff1 in kdb_trap (type=3D12, code=3D0, tf=3D0xffffff8= 6c6389000) > > at /usr/src/sys/kern/subr_kdb.c:548 > > #6 0xffffffff809461ed in trap_fatal (frame=3D0xffffff86c6389000, eva= =3DVariable "eva" is not available. > > ) > > at /usr/src/sys/amd64/amd64/trap.c:820 > > #7 0xffffffff809468b5 in trap (frame=3D0xffffff86c6389000) > > at /usr/src/sys/amd64/amd64/trap.c:326 > > #8 0xffffffff8092d2f4 in calltrap () > > at /usr/src/sys/amd64/amd64/exception.S:228 > > #9 0xffffffff809440cb in copyout () at /usr/src/sys/amd64/amd64/suppor= t.S:258 > > #10 0xffffffff80675f1f in sysctl_old_user (req=3D0xffffff86c63899c0, > > p=3D0xffffff86c6389470, l=3D1088) at /usr/src/sys/kern/kern_sysctl.= c:1276 > > #11 0xffffffff8065f6a6 in sysctl_out_proc_copyout (ki=3D0xffffff86c6389= 470, > > req=3D0xffffff86c63899c0) at /usr/src/sys/kern/kern_proc.c:1085 > > #12 0xffffffff8065ff6c in sysctl_out_proc (p=3D0xffffff0244b85470, > > req=3D0xffffff86c63899c0, flags=3DVariable "flags" is not available. > > ) at /usr/src/sys/kern/kern_proc.c:1114 > > #13 0xffffffff8066245e in sysctl_kern_proc (oidp=3DVariable "oidp" is n= ot available. > > ) > > at /usr/src/sys/kern/kern_proc.c:1302 > > #14 0xffffffff806756e8 in sysctl_root (oidp=3DVariable "oidp" is not av= ailable. > > ) > > at /usr/src/sys/kern/kern_sysctl.c:1455 > > #15 0xffffffff8067598e in userland_sysctl (td=3D0x0, name=3D0xffffff86c= 6389a80, > > namelen=3D3, old=3D0x800e96000, oldlenp=3DVariable "oldlenp" is not= available. > > ) > > at /usr/src/sys/kern/kern_sysctl.c:1565 > > #16 0xffffffff80675e3a in __sysctl (td=3D0xffffff0396ec5460, > > uap=3D0xffffff86c6389bc0) at /usr/src/sys/kern/kern_sysctl.c:1491 > > #17 0xffffffff80945809 in amd64_syscall (td=3D0xffffff0396ec5460, trace= d=3D0) > > at subr_syscall.c:114 > > #18 0xffffffff8092d5ec in Xfast_syscall () > > at /usr/src/sys/amd64/amd64/exception.S:387 > > #19 0x0000000800abecfc in ?? () > > Previous frame inner to this frame (corrupt stack?) > > (kgdb) > Can you, please, print out the content of *td, e.g. from the frame 16 ? And *req from the frame 11, please. --7aLy7NWYeEog7w9O Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk9HpqMACgkQC3+MBN1Mb4haPACg1OMlMG3fL2nMLI1hPRaXK+GG ai8An0yAPnel+UGbTTltcYmCUdDQaGZZ =6UyI -----END PGP SIGNATURE----- --7aLy7NWYeEog7w9O-- From owner-freebsd-stable@FreeBSD.ORG Fri Feb 24 16:23: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 684C0106566B for ; Fri, 24 Feb 2012 16:23:58 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from qmta09.emeryville.ca.mail.comcast.net (qmta09.emeryville.ca.mail.comcast.net [76.96.30.96]) by mx1.freebsd.org (Postfix) with ESMTP id 46C388FC0C for ; Fri, 24 Feb 2012 16:23:57 +0000 (UTC) Received: from omta21.emeryville.ca.mail.comcast.net ([76.96.30.88]) by qmta09.emeryville.ca.mail.comcast.net with comcast id dpoF1i0081u4NiLA9sPxW8; Fri, 24 Feb 2012 16:23:57 +0000 Received: from damnhippie.dyndns.org ([24.8.232.202]) by omta21.emeryville.ca.mail.comcast.net with comcast id dsPv1i02U4NgCEG8hsPwVC; Fri, 24 Feb 2012 16:23:57 +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 q1OGNrha001763; Fri, 24 Feb 2012 09:23:53 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) From: Ian Lepore To: Erich Dollansky In-Reply-To: <201202241350.56933.erichfreebsdlist@ovitrap.com> References: <201202221334.36484.erich@alogreentechnologies.com> <64FF3DF7-6EEA-480D-85AA-5784AF013EA8@lassitu.de> <201202241350.56933.erichfreebsdlist@ovitrap.com> Content-Type: text/plain; charset="us-ascii" Date: Fri, 24 Feb 2012 09:23:53 -0700 Message-ID: <1330100633.7317.41.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, Stefan Bethke Subject: Re: random problem with 8.3 from yesterday X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 24 Feb 2012 16:23:58 -0000 On Fri, 2012-02-24 at 13:50 +0700, Erich Dollansky wrote: > Hi, > > On Thursday 23 February 2012 20:22:57 Stefan Bethke wrote: > > Am 22.02.2012 um 07:34 schrieb Erich Dollansky: > > > > > > > > tunefs -L NewDeviceName /dev/da0a > > > > > > Either this call or the mount command does not work randomly. > > > > > > When I then try to mount the device on /dev/da0a it does not work always. > > > > > > I do not know what this causes, I am only randomly able to reproduce it. > > > > > > It might be affected by removing the device or keeping it plugged in. > > > > You need to be more specific: what "does not work" mean? Output, results? > > > it seems that I forgot to copy the console output for this. > > Ok, as far as I remember, tunefs said something like it does not recognise the slice. > > Mount has had two different messages. One also said that it could not find/recognise the slice. The other one said that the file system was unknown despite just running a newfs on it. > > I am very much aware that this kind of errors are very hard to find especially if they are not reproduceable. > > Erich > > > > > Stefan > > > > -- > > Stefan Bethke Fon +49 151 14070811 I've been putting up with problems like this since first upgrading to 8.2. I guess I haven't dug deeper into them because it's actually a huge improvement from what I was used to in 6.x and 7.x where complete system lockups were more common with removable usb drives. Here's an example sequence that just happened to me with a compact flash card in a usb multi-card reader... revolution # ll /dev/da* crw-r----- 1 root operator 0, 246 Feb 24 08:21 /dev/da0 crw-r----- 1 root operator 1, 26 Feb 24 08:21 /dev/da0s1 crw-r----- 1 root operator 1, 39 Feb 24 08:21 /dev/da0s1a crw-r----- 1 root operator 1, 40 Feb 24 08:21 /dev/da0s1e crw-r----- 1 root operator 1, 27 Feb 24 08:21 /dev/da0s2 crw-r----- 1 root operator 1, 29 Feb 24 08:21 /dev/da0s2a crw-r----- 1 root operator 1, 30 Feb 24 08:21 /dev/da0s2e crw-r----- 1 root operator 1, 28 Feb 24 08:21 /dev/da0s3 crw-r----- 1 root operator 1, 32 Feb 24 08:21 /dev/da0s3a crw-r----- 1 root operator 0, 248 Feb 23 12:01 /dev/da1 crw-r----- 1 root operator 0, 249 Feb 23 12:01 /dev/da2 crw-r----- 1 root operator 0, 250 Feb 23 12:01 /dev/da3 crw-r----- 1 root operator 1, 44 Feb 24 08:54 /dev/da4 revolution # mount /dev/da0s1a /mnt mount: /dev/da0s1a : Invalid argument revolution # fsck -y /dev/da0s1a fsck: Could not determine filesystem type revolution # fsck -t ufs -y /dev/da0s1a ** /dev/da0s1a Cannot find file system superblock ioctl (GCINFO): Inappropriate ioctl for device fsck_ufs: /dev/da0s1a: can't read disk label At this point I unplug the multi-card reader and plug it back in. revolution # fsck -y /dev/da0s1a fsck: Could not determine filesystem type revolution # fsck -t ufs -y /dev/da0s1a ** /dev/da0s1a ** Last Mounted on / ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups 1932 files, 45569 used, 385214 free (54 frags, 48145 blocks, 0.0% fragmentation) ***** FILE SYSTEM IS CLEAN ***** revolution # mount /dev/da0s1a /mnt At this point everything is fine and I can access the card. Sometimes I have to do the unplug/replug dance and sometimes I don't. I've always suspected something in the geom layer isn't noticing that a CF or SD card in the reader got removed/inserted/reformatted, and un-/re-plugging the whole reader (making the cam layer destroy and recreate the devices) makes geom aware of the change. Oh, a datapoint... notice how the timestamps on the /dev/da0* files above are all 08:21? I had just inserted that card at 08:57 when I ran the command sequence above, but apparently the geom layer was still reporting on a different card that was used and removed earlier this morning. I'm not sure whether or not this is related to the problem Erich originally reported, but there are some similarities in symptoms such as the inability to recognize the filesystem type, so I thought I'd mention it. This happens to me several times a week (often several times a day) so if anyone has suggestions on information-gathering I'll probably have lots of opportunities. -- Ian From owner-freebsd-stable@FreeBSD.ORG Fri Feb 24 17:54: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 BCAD81065670 for ; Fri, 24 Feb 2012 17:54:37 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 904108FC08 for ; Fri, 24 Feb 2012 17:54:37 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id 47EB246B09; Fri, 24 Feb 2012 12:54:37 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id CF847B967; Fri, 24 Feb 2012 12:54:36 -0500 (EST) From: John Baldwin To: freebsd-stable@freebsd.org, pyunyh@gmail.com Date: Thu, 23 Feb 2012 09:46:20 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p10; KDE/4.5.5; amd64; ; ) References: <20120215005600.GB1336@michelle.cdnetworks.com> In-Reply-To: <20120215005600.GB1336@michelle.cdnetworks.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201202230946.20471.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 24 Feb 2012 12:54:36 -0500 (EST) Cc: 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 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 17:54:37 -0000 On Tuesday, February 14, 2012 7:56:00 pm YongHyeon PYUN wrote: > 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. Eh, please don't do the thing where you walk all pcib devices. Instead, walk up the tree like so: static int bge_mbox_reorder(struct bge_softc *sc) { devclass_t pcib, pci; device_t dev, bus; pci = devclass_find("pci"); pcib = devclass_find("pcib"); dev = sc->dev; bus = device_get_parent(dev); for (;;) { dev = device_get_parent(bus); bus = device_get_parent(dev); if (device_get_devclass(dev) != pcib_devclass || device_get_devclass(bus) != pci_devclass) break; /* Probe device ID. */ } return (0); } It is not safe to use pci_get_vendor() with non-PCI devices (you may get random junk, and Host-PCI bridges are not PCI devices). Also, this will only apply the quirk if a relevant bridge is in the bge device's path. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Fri Feb 24 17: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 26920106566B; Fri, 24 Feb 2012 17:54:39 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id DC1B58FC15; Fri, 24 Feb 2012 17:54:38 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id 78B2E46B23; Fri, 24 Feb 2012 12:54:38 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 06E54B96E; Fri, 24 Feb 2012 12:54:38 -0500 (EST) From: John Baldwin To: freebsd-stable@freebsd.org Date: Thu, 23 Feb 2012 09:58:05 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p10; KDE/4.5.5; amd64; ; ) References: <20120223092457.GB55074@deviant.kiev.zoral.com.ua> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201202230958.05667.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 24 Feb 2012 12:54:38 -0500 (EST) Cc: "Desai, Kashyap" , "Kenneth D. Merry" , Konstantin Belousov , "freebsd-scsi@freebsd.org" , "Justin T. Gibbs" , "McConnell, Stephen" Subject: Re: mpslsi0 : Trying sleep, but thread marked as sleeping prohibited X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 24 Feb 2012 17:54:39 -0000 On Thursday, February 23, 2012 8:22:07 am Desai, Kashyap wrote: > > > -----Original Message----- > > From: Konstantin Belousov [mailto:kostikbel@gmail.com] > > Sent: Thursday, February 23, 2012 2:55 PM > > To: Desai, Kashyap > > Cc: freebsd-scsi@freebsd.org; freebsd-stable; Justin T. Gibbs; Kenneth > > D. Merry; McConnell, Stephen > > Subject: Re: mpslsi0 : Trying sleep, but thread marked as sleeping > > prohibited > > > > On Thu, Feb 23, 2012 at 05:52:12AM +0530, Desai, Kashyap wrote: > > > > > > > > > > -----Original Message----- > > > > From: Konstantin Belousov [mailto:kostikbel@gmail.com] > > > > Sent: Thursday, February 23, 2012 12:45 AM > > > > To: Desai, Kashyap > > > > Cc: freebsd-scsi@freebsd.org; freebsd-stable; Justin T. Gibbs; > > > > Kenneth D. Merry; McConnell, Stephen > > > > Subject: Re: mpslsi0 : Trying sleep, but thread marked as sleeping > > > > prohibited > > > > > > > > On Wed, Feb 22, 2012 at 07:36:42PM +0530, Desai, Kashyap wrote: > > > > > Hi, > > > > > > > > > > I am doing some code changes in mps dirver. While working on those > > > > changes, I come to know about something which is new to me. > > > > > Some expert help is required to clarify my doubt. > > > > > > > > > > 1. When any irq is register with FreeBSD OS, it sets " > > TDP_NOSLEEPING" > > > > > pflag. It means though irq in freebsd is treated as thread, We > > > > > cannot > > > > sleep in IRQ because of " "TDP_NOSLEEPING " set. > > > > > 2. In mps driver we have below code snippet in ISR routine. > > > > > > > > > > > > > > > mps_dprint(sc, MPS_TRACE, "%s\n", __func__); > > > > > mps_lock(sc); > > > > > mps_intr_locked(data); > > > > > mps_unlock(sc); > > > > > > > > > > I wonder why there is no issue with above code ? Theoretical we > > > > > cannot sleep in ISR. (as explained in #1) Any thoughts ? > > > > > > > > > > > > > > > 3. I recently added few place msleep() instead of DELAY in ISR > > > > > context and I see " Trying sleep, but thread marked as sleeping > > prohibited". > > > > > > > > > FreeBSD has several basic ways to prevent a thread from executing on > > > > CPU. > > > > They mostly fall into two categories: bounded sleep, sometimes > > > > called blocking, and unbounded sleep, usually abbreviated as sleep. > > > > The bounded there refers to amount of code executed by other thread > > > > that hold resource preventing blocked thread from making a progress. > > > > > > > > Examples of the blocking primitives are mutexes, rw locks and rm > > locks. > > > > The blocking is not counted as sleeping, so interrupt threads, which > > > > are designated as non-sleeping, still can lock mutexes. > > > Thanks for the tech help. . > > > > > > As per you comment, So now I understood as "TDP_NOSLEEPING" is only > > > for unbounded sleep restriction. Just curious to know, What is a > > > reason that thread can do blocking sleep but can't do unbounded sleep > > > ? Since technically we introduced sleeping restriction on interrupt > > > thread is to avoid starvation and that can be fit with either of the > > > sleep type. Is this not true ? > > No, not to avoid starvation. > > > > The intent of the blocking primitives is to acquire resources for > > limited amount of time. In other words, you never take a mutex for > > undefinitely long computation process. On the other hand, msleep sleep > > usually has no limitations. > > I got same reply from Ed Schouten. I agree and understood your note. Thanks for poring knowledge on this area. > _but_ only query is when thread take mutex, we don't know when it will release. So holding time of mutex is really not known. > In case of some bad code, where thread took mutex and not release within short time. This can eventually match upto msleep restriction as well. > Do we have any checks that thread took long time holding mutext ? Similar to linux where spinlock has been not release in some specific time, they dump warnings with backtrace. We don't allow code to do unbounded sleeps while holding mutexes either, and WITNESS warns about doing so. That ensures that barring an infinite loop-type bug, mutexes should be held for a bounded amount of time. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Fri Feb 24 17:59: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 9F4121065676 for ; Fri, 24 Feb 2012 17:59:58 +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 008DF8FC17 for ; Fri, 24 Feb 2012 17:59:57 +0000 (UTC) Received: from alph.allbsd.org (p1012-ipbf2105funabasi.chiba.ocn.ne.jp [114.148.160.12]) (authenticated bits=128) by mail.allbsd.org (8.14.4/8.14.4) with ESMTP id q1OHxa8e033120; Sat, 25 Feb 2012 02:59:46 +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 q1OHxZwA084062; Sat, 25 Feb 2012 02:59:35 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Sat, 25 Feb 2012 02:58:28 +0900 (JST) Message-Id: <20120225.025828.128418237042325597.hrs@allbsd.org> To: kostikbel@gmail.com From: Hiroki Sato In-Reply-To: <20120224150259.GV55074@deviant.kiev.zoral.com.ua> References: <20120223.234558.1101656075598772176.hrs@allbsd.org> <20120224143336.GS55074@deviant.kiev.zoral.com.ua> <20120224150259.GV55074@deviant.kiev.zoral.com.ua> 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(Sat_Feb_25_02_58_28_2012_477)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.allbsd.org [133.31.130.32]); Sat, 25 Feb 2012 02:59:50 +0900 (JST) X-Spam-Status: No, score=-100.2 required=13.0 tests=BAYES_00, CONTENT_TYPE_PRESENT, MIMEQENC, QENCPTR1, QENCPTR2, RCVD_IN_PBL, RCVD_IN_RP_RNBL, 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: stable@FreeBSD.org Subject: Re: another panic in 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: Fri, 24 Feb 2012 17:59:58 -0000 ----Security_Multipart(Sat_Feb_25_02_58_28_2012_477)-- Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Konstantin Belousov wrote in <20120224150259.GV55074@deviant.kiev.zoral.com.ua>: ko> > > #19 0x0000000800abecfc in ?? () ko> > > Previous frame inner to this frame (corrupt stack?) ko> > > (kgdb) ko> > Can you, please, print out the content of *td, e.g. from the fram= e 16 ? ko> = ko> And *req from the frame 11, please. Here: (kgdb) f 16 #16 0xffffffff80675e3a in __sysctl (td=3D0xffffff0396ec5460, = uap=3D0xffffff86c6389bc0) at /usr/src/sys/kern/kern_sysctl.c:1491 1491 error =3D userland_sysctl(td, name, uap->namelen, (kgdb) print *td $2 =3D {td_lock =3D 0xffffffff80d7f540, td_proc =3D 0xffffff03969bf470,= td_plist =3D { tqe_next =3D 0x0, tqe_prev =3D 0xffffff03969bf480}, td_runq =3D {tq= e_next =3D 0x0, = tqe_prev =3D 0xffffffff80d7f788}, td_slpq =3D {tqe_next =3D 0x0, = tqe_prev =3D 0xffffff0396ebe800}, td_lockq =3D {tqe_next =3D 0x0, = tqe_prev =3D 0xffffff86c57b48a0}, td_cpuset =3D 0xffffff0005789dc8,= = td_sel =3D 0xffffff01b5dd0500, td_sleepqueue =3D 0xffffff0396ebe800, = td_turnstile =3D 0xffffff01334cf600, td_umtxq =3D 0xffffff0396ec3a80,= = td_tid =3D 100763, td_sigqueue =3D {sq_signals =3D {__bits =3D {0, 0,= 0, 0}}, = sq_kill =3D {__bits =3D {0, 0, 0, 0}}, sq_list =3D {tqh_first =3D 0= x0, = tqh_last =3D 0xffffff0396ec5500}, sq_proc =3D 0xffffff03969bf470,= = sq_flags =3D 1}, td_flags =3D 65540, td_inhibitors =3D 0, td_pflags= =3D 0, = td_dupfd =3D 0, td_sqqueue =3D 0, td_wchan =3D 0x0, td_wmesg =3D 0x0,= = td_lastcpu =3D 4 '\004', td_oncpu =3D 4 '\004', td_owepreempt =3D 0 '= \0', = td_tsqueue =3D 255 '=FF', td_locks =3D 4, td_rw_rlocks =3D 0, td_lk_s= locks =3D 0, = td_blocked =3D 0x0, td_lockname =3D 0x0, td_contested =3D {lh_first =3D= 0x0}, = td_sleeplocks =3D 0xffffffff80ecebf0, td_intr_nesting_level =3D 0, = td_pinned =3D 0, td_ucred =3D 0xffffff007d537b00, td_estcpu =3D 0, td= _slptick =3D 0, = td_blktick =3D 0, td_ru =3D {ru_utime =3D {tv_sec =3D 0, tv_usec =3D = 0}, ru_stime =3D { tv_sec =3D 0, tv_usec =3D 0}, ru_maxrss =3D 1864, ru_ixrss =3D 66= 288, = ru_idrss =3D 1347856, ru_isrss =3D 176768, ru_minflt =3D 263901, ru= _majflt =3D 10, = ru_nswap =3D 0, ru_inblock =3D 0, ru_oublock =3D 0, ru_msgsnd =3D 0= , = ru_msgrcv =3D 0, ru_nsignals =3D 0, ru_nvcsw =3D 14937, ru_nivcsw =3D= 3286}, = td_incruntime =3D 0, td_runtime =3D 15204044088, td_pticks =3D 15, td= _sticks =3D 15, = td_iticks =3D 0, td_uticks =3D 0, td_intrval =3D 0, td_oldsigmask =3D= {__bits =3D {0, = 0, 0, 0}}, td_sigmask =3D {__bits =3D {0, 0, 0, 0}}, td_generatio= n =3D 18223, = td_sigstk =3D {ss_sp =3D 0x0, ss_size =3D 0, ss_flags =3D 4}, td_xsig= =3D 0, = td_profil_addr =3D 0, td_profil_ticks =3D 0, = td_name =3D "top", '\0' , td_fpop =3D 0x0, td_dbgfl= ags =3D 0, = td_dbgksi =3D {ksi_link =3D {tqe_next =3D 0x0, tqe_prev =3D 0x0}, ksi= _info =3D { si_signo =3D 0, si_errno =3D 0, si_code =3D 0, si_pid =3D 0, si_u= id =3D 0, = si_status =3D 0, si_addr =3D 0x0, si_value =3D {sival_int =3D 0, = sival_ptr =3D 0x0, sigval_int =3D 0, sigval_ptr =3D 0x0}, _reas= on =3D { _fault =3D {_trapno =3D 0}, _timer =3D {_timerid =3D 0, _overru= n =3D 0}, = _mesgq =3D {_mqd =3D 0}, _poll =3D {_band =3D 0}, __spare__ =3D= {__spare1__ =3D 0, = __spare2__ =3D {0, 0, 0, 0, 0, 0, 0}}}}, ksi_flags =3D 0, = ksi_sigq =3D 0x0}, td_ng_outbound =3D 0, td_osd =3D {osd_nslots =3D= 0, = osd_slots =3D 0x0, osd_next =3D {le_next =3D 0x0, le_prev =3D 0x0}}= , = td_rqindex =3D 32 ' ', td_base_pri =3D 128 '\200', td_priority =3D 12= 8 '\200', = td_pri_class =3D 3 '\003', td_user_pri =3D 129 '\201', = td_base_user_pri =3D 129 '\201', td_pcb =3D 0xffffff86c6389d10, = td_state =3D TDS_RUNNING, td_retval =3D {0, 34375032832}, td_slpcallo= ut =3D { c_links =3D {sle =3D {sle_next =3D 0x0}, tqe =3D {tqe_next =3D 0x0,= = tqe_prev =3D 0xffffff800042ccd0}}, c_time =3D 51568077, = c_arg =3D 0xffffff0396ec5460, c_func =3D 0xffffffff806a84c0 , = c_lock =3D 0x0, c_flags =3D 18, c_cpu =3D 4}, td_frame =3D 0xffffff= 86c6389c50, = td_kstack_obj =3D 0xffffff03410b20d8, td_kstack =3D 18446743553049124= 864, = td_kstack_pages =3D 4, td_unused1 =3D 0x0, td_unused2 =3D 0, td_unuse= d3 =3D 0, = td_critnest =3D 0, td_md =3D {md_spinlock_count =3D 0, md_saved_flags= =3D 70}, = td_sched =3D 0xffffff0396ec5890, td_ar =3D 0x0, td_syscalls =3D 46992= 6, = td_lprof =3D {{lh_first =3D 0x0}, {lh_first =3D 0x0}}, td_dtrace =3D = 0x0, = td_errno =3D 0, td_vnet =3D 0x0, td_vnet_lpush =3D 0x0, td_rux =3D { rux_runtime =3D 15204044088, rux_uticks =3D 226, rux_sticks =3D 114= 0, = rux_iticks =3D 0, rux_uu =3D 0, rux_su =3D 0, rux_tu =3D 0}, = td_map_def_user =3D 0x0, td_dbg_forked =3D 0} (kgdb) f 11 #11 0xffffffff8065f6a6 in sysctl_out_proc_copyout (ki=3D0xffffff86c6389= 470, = req=3D0xffffff86c63899c0) at /usr/src/sys/kern/kern_proc.c:1085 1085 error =3D SYSCTL_OUT(req, ki, sizeof(struct kinfo_proc)); (kgdb) print *req $3 =3D {td =3D 0xffffff0396ec5460, lock =3D 2, oldptr =3D 0x800e96000, = oldlen =3D 68217, = oldidx =3D 1088, oldfunc =3D 0xffffffff80675e80 , ne= wptr =3D 0x0, = newlen =3D 0, newidx =3D 0, newfunc =3D 0xffffffff80675d10 , = validlen =3D 68217, flags =3D 0} (kgdb) quit -- Hiroki ----Security_Multipart(Sat_Feb_25_02_58_28_2012_477)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEABECAAYFAk9Hz8QACgkQTyzT2CeTzy0ABQCgmGDJRGpVCIk97KRxqEkwmh2i mYoAoLNcqUUgfvK94HOmCJVgK+3mwhfm =l2eB -----END PGP SIGNATURE----- ----Security_Multipart(Sat_Feb_25_02_58_28_2012_477)---- From owner-freebsd-stable@FreeBSD.ORG Fri Feb 24 19:18:30 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A8DFD106566B for ; Fri, 24 Feb 2012 19:18:30 +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 25FCA8FC0C for ; Fri, 24 Feb 2012 19:18:29 +0000 (UTC) Received: by bkcjg1 with SMTP id jg1so3106291bkc.13 for ; Fri, 24 Feb 2012 11:18:29 -0800 (PST) Received-SPF: pass (google.com: domain of edwinlculp@gmail.com designates 10.204.155.69 as permitted sender) client-ip=10.204.155.69; Authentication-Results: mr.google.com; spf=pass (google.com: domain of edwinlculp@gmail.com designates 10.204.155.69 as permitted sender) smtp.mail=edwinlculp@gmail.com; dkim=pass header.i=edwinlculp@gmail.com Received: from mr.google.com ([10.204.155.69]) by 10.204.155.69 with SMTP id r5mr1780842bkw.118.1330111109134 (num_hops = 1); Fri, 24 Feb 2012 11:18: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; bh=C+6Q4LbdnWIge/bJdvyXjIgrMC1wj9MP7fAyP/gRscM=; b=mESW3+zGx42jCbmSz1EhAQjoHkiywvNFVX03qGvLWRaWNlpvKUWNLqTpz1M0vCsV3K NPLLT7qDyakiEt+oalhqO4C5xZ6fVHHgM3uusdhcePYf1iKpPmbuotUSSc+mf/ScAdXx FNzRDB5sts867M4n5Qpyzx9tYThmUwclne5ug= MIME-Version: 1.0 Received: by 10.204.155.69 with SMTP id r5mr1470177bkw.118.1330111108970; Fri, 24 Feb 2012 11:18:28 -0800 (PST) Received: by 10.204.22.17 with HTTP; Fri, 24 Feb 2012 11:18:28 -0800 (PST) In-Reply-To: <4F425523.9060709@brockmann-consult.de> References: <4F425523.9060709@brockmann-consult.de> Date: Fri, 24 Feb 2012 13:18:28 -0600 Message-ID: From: "Edwin L. Culp W." To: Peter Maloney Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: 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, 24 Feb 2012 19:18:30 -0000 2012/2/20 Peter Maloney > Am 17.02.2012 21:08, schrieb Edwin L. Culp W.: > > 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. > To create a full document from scratch explaining everything is likely > beyond the capabilites of any individual. If you had more specific > questions or topics, it would help us to help you more efficiently. What > are you looking for? A gpart howto? Mirroring and other types of > devices? mbr vs gpt? Whether or not to have separate partitions for /usr > and /var, etc.? > > And then when you get your answers, submit a PR including the details of > what you expected in the handbook, and what you learned elsewhere that > should be added, and then in the PR, ask them to add what you wrote in > the PR to the handbook. > > Personally, I can tell you a bunch about gpart, zfs, and explain or > elaborate on technical jargon, but I don't know too much about > sysinstall, bsdlabel, UFS, different boot options or FreeBSD software > raid configuration files. All my FreeBSD machines are running pure ZFS, > and I've only created temporary gpart, gstripe, etc. for tests so far. > If I needed to put together a real software raid UFS system, I would > need to look through documentation. > > > 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. > > I think he means something like this, but I don't know how to use > bsdlabel, so here is gpart (one of the new things you should learn > anyway). And also I don't know if the result of my code below would even > boot, which bootcode to use, or what to put in /boot/loader.conf to make > it boot. > > # create a gpt table (rather than MBR) > gpart create -s gpt da0 > #(not sure... boot loader needed outside the mirror?) > gpart add -s 64k -l boot1 -t freebsd-boot da0 > # add a slice for your mirror (aka. partition). > # from quote: "But even with one mirror," > gpart add -s 80g -l mirrorslice1 -t mbr da0 > > # set up the second disk > gpart create -s gpt da1 > #(not sure... boot loader needed outside the mirror?) > gpart add -s 64k -l boot2 -t freebsd-boot da1 > # from quote: "you can mirror *a big partiton* covering the whole drive" > gpart add -s 80g -l mirrorslice2 -t mbr da1 > > # Not sure if "mbr" is the right choice for the type above... I also > tried guessing "gpt" which didn't work and is not in the manual. > > # create the mirror device (I don't know the proper way to do this... I > just tried this and don't know if it persists on boot, etc.) > # from quote: "*you can mirror* a big partiton covering the whole drive" > gmirror load > gmirror label mymirror gpt/mirrorslice1 gpt/mirrorslice2 > > # slice the mirror device as if it was a regular disk > # from quote: "and then carve that up with bsdlabel" (but I used gpart > instead of bsdlabel) > gpart create -s gpt gmirror/mymirror > gpart add -s 1g -l root -t freebsd-ufs gmirror/mymirror > gpart add -s 1g -l usr -t freebsd-ufs gmirror/mymirror > > newfs gpt/root > newfs gpt/usr > > > > Further explanation of other things he said not involved in the above: > > "wasn't suggesting that you should always mirror the individual > partititons" > gpart create -s gpt da0 > gpart create -s gpt da1 > gpart add -s 1g -l root1 -t freebsd-ufs da0 > gpart add -s 1g -l root2 -t freebsd-ufs da1 > gpart add -s 1g -l usr1 -t freebsd-ufs da0 > gpart add -s 1g -l usr2 -t freebsd-ufs da1 > ... > gmirror label rootmirror gpt/root1 gpt/root2 > gmirror label mymirror gpt/usr1 gpt/usr2 > ... > > #and an example of what he said you don't need to do: > # from quote: "No need to ever mirror actual raw discs" > gmirror label mymirror da0 da1 > > raw disk = da0 > > gpt slice/partition = da0p1 where 1 is the index seen in "gpart show" > or > gpt slice/partition = gpt/root1 where root1 is the label seen in "gpart > show -l" and set in "gpart add ... -l labelhere" > > mirror device = mirror/mymirror > > etc. > > Be sure to align properly. I didn't do any aligning above. Use the "-a > ..." option. Units in gpart are sectors unless you specify another, and > sizes are in base-2 (eg. "-s 5g" would be a size of 5 GiB not 5GB) > > And you would also need a boot slice separate from the mirror unless the > bootloader understands the mirror, and install the bootloader on both > disks. I don't know if it does support this, or if it will work at all > this way. You need to find this out somewhere other than from me. > > I will try several options and configurations on the new machine and will > hopefully learn to send my results in a howto type format for raw beginners > in all the new options. The most confusing part for me, now, is how to mix > and match the options for better results. > Thanks so much for your reply. ed > > > _______________________________________________ > > 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 Fri Feb 24 20:48: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 998AA106566C; Fri, 24 Feb 2012 20:48:41 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from fallbackmx06.syd.optusnet.com.au (fallbackmx06.syd.optusnet.com.au [211.29.132.8]) by mx1.freebsd.org (Postfix) with ESMTP id 9EB438FC12; Fri, 24 Feb 2012 20:48:40 +0000 (UTC) Received: from mail09.syd.optusnet.com.au (mail09.syd.optusnet.com.au [211.29.132.190]) by fallbackmx06.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id q1OIKZeS022862; Sat, 25 Feb 2012 05:20:35 +1100 Received: from c211-30-171-136.carlnfd1.nsw.optusnet.com.au (c211-30-171-136.carlnfd1.nsw.optusnet.com.au [211.30.171.136]) by mail09.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id q1OIKPkh026371 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 25 Feb 2012 05:20:26 +1100 Date: Sat, 25 Feb 2012 05:20:25 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: "Desai, Kashyap" In-Reply-To: Message-ID: <20120225045730.D2319@besplex.bde.org> References: <20120223094611.GC32748@hoeg.nl> <20120223101157.0bb3f2ee@kan.dyndns.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Ed Schouten , freebsd-stable , "joerg@FreeBSD.org" , "Kenneth D. Merry" , "freebsd-scsi@freebsd.org" , "Justin T. Gibbs" , "McConnell, Stephen" Subject: RE: mpslsi0 : Trying sleep, but thread marked as sleeping prohibited X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 24 Feb 2012 20:48:41 -0000 On Fri, 24 Feb 2012, Desai, Kashyap wrote: >> From: Alexander Kabaev [mailto:kabaev@gmail.com] >> ... >> sleep locks are by definition unbound. There is no spinning, no priority >> propagation. Holders are free to take, say, page faults and go to long >> journey to disk and back, etc. > > I understood your above lines. >> Hardly the stuff _anyone_ would want to >> do from interrupt handler, thread or otherwise. > > So the way mps driver does in interrupt handler is as below. > > mps_lock(sc); > mps_intr_locked(data); > mps_unlock(sc); > > We hold the mtx lock in Interrupt handler and do whole bunch of work(this is bit lengthy work) under that. > It looks mps driver is miss using mtx_lock. Are we ? No. Most NIC drivers do this. Lengthy work isn't as long as it used to be, and here the lock only locks out other accesses to a single piece of hardware (provided sc is for a single piece of hardware as it should be). Worry instead about more global locks, either in your driver or in upper layers. You might need one to lock your whole driver, and upper layers might need one to lock things globally too. Giant locking is an example of the latter. I don't trust the upper layers much, but for interrupt handling they can be trusted to not have anything locked when the interrupt handler is called (except for Giant locking when the driver requests this). Also worry about your interrupt handler taking too long -- although nothing except interrupt thread priority prevents other code running, it is possible that other code doesn't get enough (or any) cycles if an interrupt handler is too hoggish. This problem is smaller than when there was a single ~1 MHz CPU doing PIO. With multiple ~2GHz CPUs doing DMA, the interrupt handler can often be 100 times sloppier without anyone noticing. But not 1000 times, and not 100 times with certain hardware. Bruce From owner-freebsd-stable@FreeBSD.ORG Fri Feb 24 22:15:29 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 59AC31065675 for ; Fri, 24 Feb 2012 22:15:29 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from mx0.hoeg.nl (mx0.hoeg.nl [IPv6:2a01:4f8:101:5343::aa]) by mx1.freebsd.org (Postfix) with ESMTP id E84E98FC15 for ; Fri, 24 Feb 2012 22:15:28 +0000 (UTC) Received: by mx0.hoeg.nl (Postfix, from userid 1000) id D78172A28CCF; Fri, 24 Feb 2012 23:15:26 +0100 (CET) Date: Fri, 24 Feb 2012 23:15:26 +0100 From: Ed Schouten To: dudu@dudu.ro Message-ID: <20120224221526.GH32748@hoeg.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+Z7/5fzWRHDJ0o7Q" Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Cc: stable@FreeBSD.org Subject: Re: Inconsistent utx.active? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 24 Feb 2012 22:15:29 -0000 --+Z7/5fzWRHDJ0o7Q Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Vlad, > Has anyone else noticed erratic bookkeeping by utmpx in RELENG_9? Would you mind explaining to me what you're seeing? It's hard for me to fix bugs if I don't get proper reports. --=20 Ed Schouten WWW: http://80386.nl/ --+Z7/5fzWRHDJ0o7Q Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iQIcBAEBAgAGBQJPSAv+AAoJEG5e2P40kaK7YSIQAIPidm5J8UZTlrvvR2SkIIXA 2JhKmh998mtAn1j8Jzz2CPqg47KBwhWjnPJBq38AixBhjqxvbU4GoWv2DWNsDolB SQ9pjCI2XQ90Bk30Yjl0/f1fURwGZ/n4uvNCvGXwSHsc1tU3aMyLa4h2c43FEST/ L3/WeBDHutmGg3vJKOTCQMBazeLIX/QLgcdFvyukIwurOo53zh3KVldUbL6AI229 usyHXr2KdXI590uGLXEPEazxBjqp5ffLYy/bynAxJn3qJG6wSJtBzJSjfe/QN6j5 7rrKme2Wg3yRA9KrUib/WWKK184QCTiQG4Wh7n7/DG4OciGzUy32cFMC6adtcght W4uiooVx4m/p6/fr+iQYKjZL5chlrPdXkUY2wfVkxHADarfVDRuNG944AgYuGDr3 sM5yXMEtiI6wlcEIFuijyycAEzEj1il2LWf7AQSP6famg2a/+owIPodslXhIhuUv 8+kBrOqTNYS9qss3rirGGmWG/ftH4eq7VFlWSF1wGCJ7drIxgd2SBUw+b0MZxnb6 8hi66znIUX4tEPxuCpn/MMKTFWL6MgFoeZA8xikE9wnnoB+foDWo5JE+IevtNtaf Yy4/BRg5GEI/5B+v0U1ikPm6z1hFUoG4N/oukQK4s5kQ97PLCBiFbkV4AMOc9PZM LX1WZ9tdf4dJmCWWy64q =Ia0Q -----END PGP SIGNATURE----- --+Z7/5fzWRHDJ0o7Q-- From owner-freebsd-stable@FreeBSD.ORG Fri Feb 24 22:40: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 95DF4106566C for ; Fri, 24 Feb 2012 22:40:01 +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 D491C8FC0C for ; Fri, 24 Feb 2012 22:40:00 +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 AAA07560; Sat, 25 Feb 2012 00:39:51 +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 1S13nq-0006gt-RQ; Sat, 25 Feb 2012 00:39:50 +0200 Message-ID: <4F4811B4.4000701@FreeBSD.org> Date: Sat, 25 Feb 2012 00:39:48 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.2) Gecko/20120218 Thunderbird/10.0.2 MIME-Version: 1.0 To: Ian Lepore References: <201202221334.36484.erich@alogreentechnologies.com> <64FF3DF7-6EEA-480D-85AA-5784AF013EA8@lassitu.de> <201202241350.56933.erichfreebsdlist@ovitrap.com> <1330100633.7317.41.camel@revolution.hippie.lan> In-Reply-To: <1330100633.7317.41.camel@revolution.hippie.lan> X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Erich Dollansky , freebsd-stable@FreeBSD.org, Stefan Bethke Subject: Re: random problem with 8.3 from yesterday X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 24 Feb 2012 22:40:01 -0000 on 24/02/2012 18:23 Ian Lepore said the following: > I've always > suspected something in the geom layer isn't noticing that a CF or SD > card in the reader got removed/inserted/reformatted, and un-/re-plugging > the whole reader (making the cam layer destroy and recreate the devices) > makes geom aware of the change. This is a fact, actually. Nothing in GEOM layer (and below it) notices a silent card change, since most hardware doesn't have any notification for the change and FreeBSD disk stack doesn't do any polling for changes. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Fri Feb 24 22:40: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 6BE331065678 for ; Fri, 24 Feb 2012 22:40:17 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from mx0.hoeg.nl (mx0.hoeg.nl [IPv6:2a01:4f8:101:5343::aa]) by mx1.freebsd.org (Postfix) with ESMTP id 2D2A08FC0C for ; Fri, 24 Feb 2012 22:40:17 +0000 (UTC) Received: by mx0.hoeg.nl (Postfix, from userid 1000) id 537992A28CBC; Fri, 24 Feb 2012 23:40:16 +0100 (CET) Date: Fri, 24 Feb 2012 23:40:16 +0100 From: Ed Schouten To: Vlad Galu Message-ID: <20120224224016.GI32748@hoeg.nl> References: <20120224221526.GH32748@hoeg.nl> <350DE43596674E608581BB2536231611@dudu.ro> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="IR1Y5IvQhrKgS4e6" Content-Disposition: inline In-Reply-To: <350DE43596674E608581BB2536231611@dudu.ro> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: stable@freebsd.org Subject: Re: Inconsistent utx.active? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 24 Feb 2012 22:40:17 -0000 --IR1Y5IvQhrKgS4e6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Vlad, * Vlad Galu , 20120224 23:35: > Yes, sorry about that. I'm seeing stale (which sometimes turn into > duplicate) entries when I log off and on again. The symptom seems to > be exacerbated by unclean logouts (such as when my stateful corporate > firewall kills my SSH sessions - I don't have keepalives active at > either end). >=20 > In the example below, I'm actually logged on from IP address X.Y.Z.T, > the first two entries belong to earlier sessions that have been long > gone. The pts is the same, and the command displayed under WHAT is > mirrored for all 3 entries. Would you mind pasting the output of `getent utmpx active'? Thanks, --=20 Ed Schouten WWW: http://80386.nl/ --IR1Y5IvQhrKgS4e6 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iQIcBAEBAgAGBQJPSBHQAAoJEG5e2P40kaK73cMP/jywnKACPRBFJqzbOJhurB07 zG1IMx2QwUP7z9/n8vYz69PIk85VIN4HRY742JKBjBysMDUfL+cDE2Rg0O8v8Txh KtxVu9Zzoy11B70vAXXLq7OCDle5zkjH3YzGNlmwFW/pFswtI62G77hDO0nkop4P /vw2PT0rFJhmjYuLx0FUtH78q6Ur1rdyRAVIXcwNe2AlS11RmS/syPKDmG/zZLK3 2nQM0LD62l6rdB3nmBUhHrG1BJJav8v3+u3+tzoisuZzsdbdRzeC32eJ0GQqK7zO yXnB/jD+U6KLV+ONQr2rGoJOf5oN9nnDdjut7kThzHv3O5ZXuV3GSbN/VphvMRnp dxxOyC8mTEmqLalbGvXXq/QNnRvzMH14bd6keRZ4iFZ380sOjHptCtD2yUS+wwMg 8pQnVRNXk/7TIJCLR62IDnUP6GyTwangffOo0edOmWgbB8lIZ2U86BI745RTQctz fAJfYT7c4Y0nUGguzEjiABdlvjKaqf5eiT2tU2+ak+bHPMVBo3tgxVnNXxTHN+Fx o+fb51ww0gIpxnH2RXRy4YeBV7KGCMEKhog+tGZLTMFc8FFryeyQRFnVBBFwyVWO 3AFUc3Zik6rW018PKkG/1b2NF03pVJUX+IOYs7Hp9hAY2I+wy5dnnyoectswRPAc bUKijePBeGuwNDXCS4Js =eiqU -----END PGP SIGNATURE----- --IR1Y5IvQhrKgS4e6-- From owner-freebsd-stable@FreeBSD.ORG Fri Feb 24 22:54:36 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 0F31F106564A for ; Fri, 24 Feb 2012 22:54:36 +0000 (UTC) (envelope-from dudu@dudu.ro) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 8161F8FC0C for ; Fri, 24 Feb 2012 22:54:35 +0000 (UTC) Received: by eekd17 with SMTP id d17so460912eek.13 for ; Fri, 24 Feb 2012 14:54:34 -0800 (PST) Received-SPF: pass (google.com: domain of dudu@dudu.ro designates 10.213.33.145 as permitted sender) client-ip=10.213.33.145; Authentication-Results: mr.google.com; spf=pass (google.com: domain of dudu@dudu.ro designates 10.213.33.145 as permitted sender) smtp.mail=dudu@dudu.ro; dkim=pass header.i=dudu@dudu.ro Received: from mr.google.com ([10.213.33.145]) by 10.213.33.145 with SMTP id h17mr1316564ebd.89.1330124074469 (num_hops = 1); Fri, 24 Feb 2012 14:54:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dudu.ro; s=google; h=date:from:to:cc:message-id:in-reply-to:references:subject:x-mailer :mime-version:content-type:content-transfer-encoding :content-disposition; bh=eg9pagqXri4nGNa1s9ZzM2otDw+MoebszyzMITf6scA=; b=kemME1CqYTqDLHIQGUUwdS0pWXQVOw6KVHD6JO6lP4zGNcV5Hx0njOJ51twNvkxYB9 QkjOFnjF48AFGL2ssch2e7siTgVhrtp4Axf1Oqa/RxJJ/9U8XevEc1zy1OH3rMECW2qp +h4RIw5DbfMggQRTXNj10yig52dhjrXc13QMw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=gamma; h=date:from:to:cc:message-id:in-reply-to:references:subject:x-mailer :mime-version:content-type:content-transfer-encoding :content-disposition:x-gm-message-state; bh=eg9pagqXri4nGNa1s9ZzM2otDw+MoebszyzMITf6scA=; b=oT8kUrKhnx9+M3GEg8J124pva0v9GhOWI454Z3h2nSSK6MvwNXRcjMqIm3Uy6Sl+Ue sYg2b4jqYF/yaY3MuepdqAABXSgX97N1CKMMtlHhTPxbrTROjaxLJj+ugYOFFQ59tsFk m73ZayNyCWMDF2yaFLitziCKA9XWF6R+MDH4U= Received: by 10.213.33.145 with SMTP id h17mr976390ebd.89.1330124074276; Fri, 24 Feb 2012 14:54:34 -0800 (PST) Received: from LesPaul.local ([82.76.253.74]) by mx.google.com with ESMTPS id y14sm23467623eef.10.2012.02.24.14.54.32 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 24 Feb 2012 14:54:33 -0800 (PST) Date: Fri, 24 Feb 2012 22:54:29 +0000 From: Vlad Galu To: Ed Schouten Message-ID: <9DAEF77AE05F4151AD561D26DF5D69F1@dudu.ro> In-Reply-To: <20120224224016.GI32748@hoeg.nl> References: <20120224221526.GH32748@hoeg.nl> <350DE43596674E608581BB2536231611@dudu.ro> <20120224224016.GI32748@hoeg.nl> X-Mailer: sparrow 1.5 (build 1043.1) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Gm-Message-State: ALoCoQm0IIS3mA8rpC119LIubVvPpJOE3Z5G05IFRYM6ymy0Vq+/xO/GUnbhmkM6XTIplplwGPwR Cc: stable@freebsd.org Subject: Re: Inconsistent utx.active? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 24 Feb 2012 22:54:36 -0000 On Friday, February 24, 2012 at 10:40 PM, Ed Schouten wrote: > Hi Vlad, > > * Vlad Galu , 20120224 23:35: > > Yes, sorry about that. I'm seeing stale (which sometimes turn into > > duplicate) entries when I log off and on again. The symptom seems to > > be exacerbated by unclean logouts (such as when my stateful corporate > > firewall kills my SSH sessions - I don't have keepalives active at > > either end). > > > > In the example below, I'm actually logged on from IP address X.Y.Z.T, > > the first two entries belong to earlier sessions that have been long > > gone. The pts is the same, and the command displayed under WHAT is > > mirrored for all 3 entries. > > > > Would you mind pasting the output of `getent utmpx active'? > Not at all, here it is: -- cut here -- [1330014380.652067 -- Thu Feb 23 17:26:20 2012] user process: id="4f86d023f250d3c9" pid="39012" user="dudu" line="pts/0" host="A.B.C.D" [1330014398.177818 -- Thu Feb 23 17:26:38 2012] user process: id="269d75b37f295346" pid="39221" user="dudu" line="pts/1" host="A.B.C.D" [1330085459.796787 -- Fri Feb 24 13:10:59 2012] user process: id="d026e8e5c0648ec2" pid="38093" user="dudu" line="pts/0" host="A.B.C.D" [1330122640.813570 -- Fri Feb 24 23:30:40 2012] user process: id="dd8d3dff2f3002a0" pid="82959" user="dudu" line="pts/0" host="X.Y.Z.T" [1330122493.638088 -- Fri Feb 24 23:28:13 2012] user process: id="92b73279a543d99f" pid="73085" user="dudu" line="pts/1" host="X.Y.Z.T" [1330122498.444614 -- Fri Feb 24 23:28:18 2012] user process: id="c0f3c404a3ca8565" pid="73573" user="dudu" line="pts/2" host="X.Y.Z.T" [1330122634.538515 -- Fri Feb 24 23:30:34 2012] dead process: id="fea56df5dde26e4d" pid="76338" -- and here -- The local time is UTC+1. The current (and only) bash PID (82986) is not even on that list. From owner-freebsd-stable@FreeBSD.ORG Fri Feb 24 23:00: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 83FA11065670 for ; Fri, 24 Feb 2012 23:00:23 +0000 (UTC) (envelope-from dudu@dudu.ro) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id CE1E68FC08 for ; Fri, 24 Feb 2012 23:00:22 +0000 (UTC) Received: by eekd17 with SMTP id d17so461839eek.13 for ; Fri, 24 Feb 2012 15:00:21 -0800 (PST) Received-SPF: pass (google.com: domain of dudu@dudu.ro designates 10.14.182.134 as permitted sender) client-ip=10.14.182.134; Authentication-Results: mr.google.com; spf=pass (google.com: domain of dudu@dudu.ro designates 10.14.182.134 as permitted sender) smtp.mail=dudu@dudu.ro; dkim=pass header.i=dudu@dudu.ro Received: from mr.google.com ([10.14.182.134]) by 10.14.182.134 with SMTP id o6mr2557965eem.40.1330124421813 (num_hops = 1); Fri, 24 Feb 2012 15:00:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dudu.ro; s=google; h=date:from:to:cc:message-id:in-reply-to:references:subject:x-mailer :mime-version:content-type:content-transfer-encoding :content-disposition; bh=934YBOhBtpEFG3aa+mRIt+bg4ik9cc/1ToF+ulxg7E8=; b=YKma1tCetwtVeyJX3ZqriHwZ272g14ROwuPp0NkefkXlUg2SW8r9tLspUzBr053YYf 8fezMTlapOf9poPd6Ggokgdt2JhjoPfdMfXcB27m1K8KnLb/WumP9VXaiIXGoYQuKeAQ amhAsrZ9LQUn0vzJkQorLj1WM7dG+KKtdVbcQ= Received: by 10.14.182.134 with SMTP id o6mr1877900eem.40.1330122929618; Fri, 24 Feb 2012 14:35:29 -0800 (PST) Received: from LesPaul.local ([82.76.253.74]) by mx.google.com with ESMTPS id z47sm23300217eeh.9.2012.02.24.14.35.27 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 24 Feb 2012 14:35:28 -0800 (PST) Date: Fri, 24 Feb 2012 22:35:25 +0000 From: Vlad Galu To: Ed Schouten Message-ID: <350DE43596674E608581BB2536231611@dudu.ro> In-Reply-To: <20120224221526.GH32748@hoeg.nl> References: <20120224221526.GH32748@hoeg.nl> X-Mailer: sparrow 1.5 (build 1043.1) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Gm-Message-State: ALoCoQlytfCEUQrGPHjWXLKdxdjR1mDbt/I6YolKGRJ5GMuNIRr6tOzFARzpH42Y0S6ohAYy4NE3 Cc: stable@freebsd.org Subject: Re: Inconsistent utx.active? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 24 Feb 2012 23:00:23 -0000 On Friday, February 24, 2012 at 10:15 PM, Ed Schouten wrote: > Hi Vlad, > > > Has anyone else noticed erratic bookkeeping by utmpx in RELENG_9? > > Would you mind explaining to me what you're seeing? It's hard for me to > fix bugs if I don't get proper reports. > > -- > Ed Schouten > WWW: http://80386.nl/ Hi Ed, Yes, sorry about that. I'm seeing stale (which sometimes turn into duplicate) entries when I log off and on again. The symptom seems to be exacerbated by unclean logouts (such as when my stateful corporate firewall kills my SSH sessions - I don't have keepalives active at either end). In the example below, I'm actually logged on from IP address X.Y.Z.T, the first two entries belong to earlier sessions that have been long gone. The pts is the same, and the command displayed under WHAT is mirrored for all 3 entries. -- cut here -- dudu@joint ~ $ w 11:30PM up 2 days, 6:17, 3 users, load averages: 0.00, 0.00, 0.00 USER TTY FROM LOGIN@ IDLE WHAT dudu pts/0 A.B.C.D Thu05PM - w dudu pts/0 A.B.C.D 1:10PM - w dudu pts/0 X.Y.Z.T 11:30PM - w dudu@joint ~ $ ps ax PID TT STAT TIME COMMAND 82986 0 SJ 0:00.00 -bash (bash) 83323 0 R+J 0:00.00 ps ax dudu@joint ~ $ -- and here -- From owner-freebsd-stable@FreeBSD.ORG Fri Feb 24 23:00:28 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 D666F106564A for ; Fri, 24 Feb 2012 23:00:28 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from mx0.hoeg.nl (mx0.hoeg.nl [178.63.0.170]) by mx1.freebsd.org (Postfix) with ESMTP id 973418FC0C for ; Fri, 24 Feb 2012 23:00:28 +0000 (UTC) Received: by mx0.hoeg.nl (Postfix, from userid 1000) id DCFB72A28CCF; Sat, 25 Feb 2012 00:00:27 +0100 (CET) Date: Sat, 25 Feb 2012 00:00:27 +0100 From: Ed Schouten To: Vlad Galu Message-ID: <20120224230027.GJ32748@hoeg.nl> References: <20120224221526.GH32748@hoeg.nl> <350DE43596674E608581BB2536231611@dudu.ro> <20120224224016.GI32748@hoeg.nl> <9DAEF77AE05F4151AD561D26DF5D69F1@dudu.ro> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Do4IU1xF/9sod/r6" Content-Disposition: inline In-Reply-To: <9DAEF77AE05F4151AD561D26DF5D69F1@dudu.ro> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: stable@freebsd.org Subject: Re: Inconsistent utx.active? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 24 Feb 2012 23:00:28 -0000 --Do4IU1xF/9sod/r6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Vlad, * Vlad Galu , 20120224 23:54: > [1330014380.652067 -- Thu Feb 23 17:26:20 2012] user process: id=3D"4f86d= 023f250d3c9" pid=3D"39012" user=3D"dudu" line=3D"pts/0" host=3D"A.B.C.D" > [1330014398.177818 -- Thu Feb 23 17:26:38 2012] user process: id=3D"269d7= 5b37f295346" pid=3D"39221" user=3D"dudu" line=3D"pts/1" host=3D"A.B.C.D" > [1330085459.796787 -- Fri Feb 24 13:10:59 2012] user process: id=3D"d026e= 8e5c0648ec2" pid=3D"38093" user=3D"dudu" line=3D"pts/0" host=3D"A.B.C.D" > [1330122640.813570 -- Fri Feb 24 23:30:40 2012] user process: id=3D"dd8d3= dff2f3002a0" pid=3D"82959" user=3D"dudu" line=3D"pts/0" host=3D"X.Y.Z.T" > [1330122493.638088 -- Fri Feb 24 23:28:13 2012] user process: id=3D"92b73= 279a543d99f" pid=3D"73085" user=3D"dudu" line=3D"pts/1" host=3D"X.Y.Z.T" > [1330122498.444614 -- Fri Feb 24 23:28:18 2012] user process: id=3D"c0f3c= 404a3ca8565" pid=3D"73573" user=3D"dudu" line=3D"pts/2" host=3D"X.Y.Z.T" > [1330122634.538515 -- Fri Feb 24 23:30:34 2012] dead process: id=3D"fea56= df5dde26e4d" pid=3D"76338" You mentioned in a previous email that these entries belong to SSH sessions. Are you sure about this? The identifiers seem to contain randomly generated data, just like pam_lastlog(8) does. OpenSSH uses identifiers based on the TTY name, like so: > [1330124273.955165 -- Fri Feb 24 23:57:53 2012] user process: id=3D"70747= 32f30000000" pid=3D"15880" user=3D"ed" line=3D"pts/0" host=3D"m.fxq.nl" 0x7074732f30 is equal to "pts/0". Maybe they're generated by some different login service or you've configured PAM/OpenSSH/etc. in a non-default way? Thanks so far, --=20 Ed Schouten WWW: http://80386.nl/ --Do4IU1xF/9sod/r6 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iQIcBAEBAgAGBQJPSBaLAAoJEG5e2P40kaK7TyAP/jbNzaOo6NqnuvBE9DeO0zpa /2d0fmtFNbPkTWTSIlgSBZAnnsgo//bUM0eB304a2+nQh+XRrw+QdXDmmhLClBt6 4KYuHKsr+8XUFbUHgo/jQ9fqOL8AseLf5EN7tF3bJ4zI0lpwVrGH149y82yIbB0+ HQOmZFUBNZS0ABXBkX38604Grp2o3U+/kUEogMA14Rk+p50gXLapzbV+94b8AA6/ UnxUD6fym0SkXTh8ghP0eDEkfQFpu51Y6lg1CJw1XolR/hG35jTIfrp82XKdjP1j UOAjThbCv/Tg+kRDcIc54Hkxwa3Cd+pwb/F2N0WGJgJ9c8rko4+bzR9U0+fG9PSZ EK7Nh9XKC2KgI0VK8BXVuddJ8Nwv4mtHTFNn42pVicGeoOQliSntlwPrpk0PRD6G rVFi1CQ+SFqRMIh83im0OayLlla/3Tyadd43a0mqj0bMfAit5CfJRmBtHEv9NDhi M0rNjDPHW2z1tobSTmmIJpWF0zXWa+5ytWzaqlBT+vZn5xPx4/kEg66fl5zRq4sq BzIU/czEr8JiC/Aj+7EoM9iJDlD2HuSBFXZTbx6WSH2G0jyJN0cHM/xVrffecTNn 1cXXgKnEJXN5BAfmIbR1/Mrd/6ZUJqgqO9EZYj9vhV6Zk84sqHuM+v4VG/c0TDpT QU+ro01/NAQEf4N6Hqpj =XDWx -----END PGP SIGNATURE----- --Do4IU1xF/9sod/r6-- From owner-freebsd-stable@FreeBSD.ORG Fri Feb 24 23:24: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 58CC61065672 for ; Fri, 24 Feb 2012 23:24:26 +0000 (UTC) (envelope-from dudu@dudu.ro) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id CD93E8FC0A for ; Fri, 24 Feb 2012 23:24:25 +0000 (UTC) Received: by eekd17 with SMTP id d17so465583eek.13 for ; Fri, 24 Feb 2012 15:24:25 -0800 (PST) Received-SPF: pass (google.com: domain of dudu@dudu.ro designates 10.14.47.8 as permitted sender) client-ip=10.14.47.8; Authentication-Results: mr.google.com; spf=pass (google.com: domain of dudu@dudu.ro designates 10.14.47.8 as permitted sender) smtp.mail=dudu@dudu.ro; dkim=pass header.i=dudu@dudu.ro Received: from mr.google.com ([10.14.47.8]) by 10.14.47.8 with SMTP id s8mr2642076eeb.91.1330125864995 (num_hops = 1); Fri, 24 Feb 2012 15:24:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dudu.ro; s=google; h=date:from:to:cc:message-id:in-reply-to:references:subject:x-mailer :mime-version:content-type:content-transfer-encoding :content-disposition; bh=1L6bxMoVOXloylnpId7w5lHOgIrhTzQsrrSu19bpBDs=; b=h1a1AKEvR305LITCYyeBz7uloZQnxV3VbMRIHCjLbJVgorMlc0e1GAo9Qkcdk0bF3t RLBt0kTSAu6HsrgXxgfN6aYZb6/iIZ3Nw2lLWgx5cZRtklNPwAVyL/iQdk843QE9Y6nf sfZok6S9I1P1CttJBvqd7dyr/HaieUTznmUGA= Received: by 10.14.47.8 with SMTP id s8mr1962785eeb.91.1330125864788; Fri, 24 Feb 2012 15:24:24 -0800 (PST) Received: from LesPaul.local ([82.76.253.74]) by mx.google.com with ESMTPS id u9sm23733811eem.11.2012.02.24.15.24.22 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 24 Feb 2012 15:24:23 -0800 (PST) Date: Fri, 24 Feb 2012 23:24:20 +0000 From: Vlad Galu To: Ed Schouten Message-ID: <74553B7DA41D44179CAC5A937E6322E6@dudu.ro> In-Reply-To: <20120224230027.GJ32748@hoeg.nl> References: <20120224221526.GH32748@hoeg.nl> <350DE43596674E608581BB2536231611@dudu.ro> <20120224224016.GI32748@hoeg.nl> <9DAEF77AE05F4151AD561D26DF5D69F1@dudu.ro> <20120224230027.GJ32748@hoeg.nl> X-Mailer: sparrow 1.5 (build 1043.1) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Gm-Message-State: ALoCoQnpdQZR0XYrBDK+yYInWZ/bpEMLjE+AAlGXmrAUJR5I1w2oss3wO9yTuHUnnOmU1f6lOYnv Cc: stable@freebsd.org Subject: Re: Inconsistent utx.active? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 24 Feb 2012 23:24:26 -0000 On Friday, February 24, 2012 at 11:00 PM, Ed Schouten wrote: > Hello Vlad, > > * Vlad Galu , 20120224 23:54: > > [1330014380.652067 -- Thu Feb 23 17:26:20 2012] user process: id="4f86d023f250d3c9" pid="39012" user="dudu" line="pts/0" host="A.B.C.D" > > [1330014398.177818 -- Thu Feb 23 17:26:38 2012] user process: id="269d75b37f295346" pid="39221" user="dudu" line="pts/1" host="A.B.C.D" > > [1330085459.796787 -- Fri Feb 24 13:10:59 2012] user process: id="d026e8e5c0648ec2" pid="38093" user="dudu" line="pts/0" host="A.B.C.D" > > [1330122640.813570 -- Fri Feb 24 23:30:40 2012] user process: id="dd8d3dff2f3002a0" pid="82959" user="dudu" line="pts/0" host="X.Y.Z.T" > > [1330122493.638088 -- Fri Feb 24 23:28:13 2012] user process: id="92b73279a543d99f" pid="73085" user="dudu" line="pts/1" host="X.Y.Z.T" > > [1330122498.444614 -- Fri Feb 24 23:28:18 2012] user process: id="c0f3c404a3ca8565" pid="73573" user="dudu" line="pts/2" host="X.Y.Z.T" > > [1330122634.538515 -- Fri Feb 24 23:30:34 2012] dead process: id="fea56df5dde26e4d" pid="76338" > > > > You mentioned in a previous email that these entries belong to SSH > sessions. Are you sure about this? The identifiers seem to contain > randomly generated data, just like pam_lastlog(8) does. OpenSSH uses > identifiers based on the TTY name, like so: > > > [1330124273.955165 -- Fri Feb 24 23:57:53 2012] user process: id="7074732f30000000" pid="15880" user="ed" line="pts/0" host="m.fxq.nl (http://m.fxq.nl)" > > 0x7074732f30 is equal to "pts/0". > > Maybe they're generated by some different login service or you've > configured PAM/OpenSSH/etc. in a non-default way? > Sigh, you are right. I had UseLogin set to yes in sshd_config. Sorry for the noise and thanks! From owner-freebsd-stable@FreeBSD.ORG Fri Feb 24 23:38: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 57712106566C for ; Fri, 24 Feb 2012 23:38:05 +0000 (UTC) (envelope-from erichfreebsdlist@ovitrap.com) Received: from alogreentechnologies.com (alogreentechnologies.com [67.212.226.44]) by mx1.freebsd.org (Postfix) with ESMTP id 2C6998FC08 for ; Fri, 24 Feb 2012 23:38:04 +0000 (UTC) Received: from amd620.ovitrap.com ([49.128.188.2]) (authenticated bits=0) by alogreentechnologies.com (8.13.1/8.13.1) with ESMTP id q1ONbvn0022483; Fri, 24 Feb 2012 16:38:00 -0700 From: Erich Dollansky To: freebsd-stable@freebsd.org Date: Sat, 25 Feb 2012 06:37:20 +0700 User-Agent: KMail/1.13.7 (FreeBSD/8.3-PRERELEASE; KDE/4.7.4; amd64; ; ) References: <201202221334.36484.erich@alogreentechnologies.com> <201202241350.56933.erichfreebsdlist@ovitrap.com> <1330100633.7317.41.camel@revolution.hippie.lan> In-Reply-To: <1330100633.7317.41.camel@revolution.hippie.lan> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201202250637.21276.erichfreebsdlist@ovitrap.com> Cc: Ian Lepore , Stefan Bethke Subject: Re: random problem with 8.3 from yesterday X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 24 Feb 2012 23:38:05 -0000 On Friday 24 February 2012 23:23:53 Ian Lepore wrote: > On Fri, 2012-02-24 at 13:50 +0700, Erich Dollansky wrote: > > Hi, > > Hi, > > On Thursday 23 February 2012 20:22:57 Stefan Bethke wrote: > > > Am 22.02.2012 um 07:34 schrieb Erich Dollansky: > > > > tunefs -L NewDeviceName /dev/da0a > > > > > > > > Either this call or the mount command does not work randomly. > > > > > > > > When I then try to mount the device on /dev/da0a it does not work always. > > > > > > > -- > > > Stefan Bethke Fon +49 151 14070811 > > I've been putting up with problems like this since first upgrading to > 8.2. I guess I haven't dug deeper into them because it's actually a > huge improvement from what I was used to in 6.x and 7.x where complete > system lockups were more common with removable usb drives. Here's an > example sequence that just happened to me with a compact flash card in a > usb multi-card reader... > I was lucky then. Since 8.0, these problems disappeared for me and came back only with 8.3. > revolution # mount /dev/da0s1a /mnt > mount: /dev/da0s1a : Invalid argument > revolution # fsck -y /dev/da0s1a > fsck: Could not determine filesystem type > revolution # fsck -t ufs -y /dev/da0s1a > ** /dev/da0s1a > Cannot find file system superblock > ioctl (GCINFO): Inappropriate ioctl for device > fsck_ufs: /dev/da0s1a: can't read disk label > > At this point I unplug the multi-card reader and plug it back in. > > revolution # fsck -y /dev/da0s1a > fsck: Could not determine filesystem type Yes, this are some of the messages. They changed randomly for me. > > I'm not sure whether or not this is related to the problem Erich > originally reported, but there are some similarities in symptoms such as > the inability to recognize the filesystem type, so I thought I'd mention It is the same what happened to me. Erich From owner-freebsd-stable@FreeBSD.ORG Fri Feb 24 23:40: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 2E451106564A for ; Fri, 24 Feb 2012 23:40:43 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from qmta09.emeryville.ca.mail.comcast.net (qmta09.emeryville.ca.mail.comcast.net [76.96.30.96]) by mx1.freebsd.org (Postfix) with ESMTP id 1282B8FC15 for ; Fri, 24 Feb 2012 23:40:42 +0000 (UTC) Received: from omta21.emeryville.ca.mail.comcast.net ([76.96.30.88]) by qmta09.emeryville.ca.mail.comcast.net with comcast id dzMB1i0021u4NiLA9zgigq; Fri, 24 Feb 2012 23:40:42 +0000 Received: from damnhippie.dyndns.org ([24.8.232.202]) by omta21.emeryville.ca.mail.comcast.net with comcast id dzgh1i01j4NgCEG8hzgimP; Fri, 24 Feb 2012 23:40:42 +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 q1ONeeE6002126; Fri, 24 Feb 2012 16:40:40 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) From: Ian Lepore To: Andriy Gapon In-Reply-To: <4F4811B4.4000701@FreeBSD.org> References: <201202221334.36484.erich@alogreentechnologies.com> <64FF3DF7-6EEA-480D-85AA-5784AF013EA8@lassitu.de> <201202241350.56933.erichfreebsdlist@ovitrap.com> <1330100633.7317.41.camel@revolution.hippie.lan> <4F4811B4.4000701@FreeBSD.org> Content-Type: text/plain; charset="us-ascii" Date: Fri, 24 Feb 2012 16:40:40 -0700 Message-ID: <1330126840.7317.60.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: random problem with 8.3 from yesterday X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 24 Feb 2012 23:40:43 -0000 On Sat, 2012-02-25 at 00:39 +0200, Andriy Gapon wrote: > on 24/02/2012 18:23 Ian Lepore said the following: > > I've always > > suspected something in the geom layer isn't noticing that a CF or SD > > card in the reader got removed/inserted/reformatted, and un-/re-plugging > > the whole reader (making the cam layer destroy and recreate the devices) > > makes geom aware of the change. > > This is a fact, actually. Nothing in GEOM layer (and below it) notices a silent > card change, since most hardware doesn't have any notification for the change > and FreeBSD disk stack doesn't do any polling for changes. > If the hardware did have change notification, is there a mechanism that would communicate that to geom? That's a precursor question to my real question: is there a way to manually kick geom when necessary? If the api exists but there's no userland app to make the needed calls, I'll write some code -- just point me at a manpage or header file. -- Ian From owner-freebsd-stable@FreeBSD.ORG Sat Feb 25 05:13: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 BA165106566B; Sat, 25 Feb 2012 05:13:08 +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 4AC5B8FC12; Sat, 25 Feb 2012 05:13:08 +0000 (UTC) Received: by pbcxa7 with SMTP id xa7so3657514pbc.13 for ; Fri, 24 Feb 2012 21:13:07 -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=dExz/vcbsQZzpFXTT5dMRXkt8EBgK6ZNtRhQhq1kYzQ=; b=vAZDoqd+hNqnMwYIWG8kPnJ0fPC9YI5acxjpUaPx2LTzrEsocUbSfnKH9gzgR400zZ /BzUSQ6iyMtXcO8SpZJoOrkP2FoAGq33eOrkjhsyhRL5k+JqhN1+oOJMtiNgch1n60vq R4ppx4ZBqVB7MnruQXQiTB3JS0FxitpTNs2wg= Received: by 10.68.232.170 with SMTP id tp10mr11504731pbc.72.1330146787858; Fri, 24 Feb 2012 21:13:07 -0800 (PST) Received: from pyunyh@gmail.com ([114.111.62.249]) by mx.google.com with ESMTPS id m3sm6247844pbg.44.2012.02.24.21.13.04 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 24 Feb 2012 21:13:06 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Sat, 25 Feb 2012 14:13:01 -0800 From: YongHyeon PYUN Date: Sat, 25 Feb 2012 14:13:01 -0800 To: John Baldwin Message-ID: <20120225221301.GA3718@michelle.cdnetworks.com> References: <20120215005600.GB1336@michelle.cdnetworks.com> <201202230946.20471.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="IS0zKkzwUGydFO0o" Content-Disposition: inline In-Reply-To: <201202230946.20471.jhb@freebsd.org> 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: Sat, 25 Feb 2012 05:13:08 -0000 --IS0zKkzwUGydFO0o Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Feb 23, 2012 at 09:46:20AM -0500, John Baldwin wrote: > On Tuesday, February 14, 2012 7:56:00 pm YongHyeon PYUN wrote: > > 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. > > Eh, please don't do the thing where you walk all pcib devices. Instead, walk > up the tree like so: > > static int > bge_mbox_reorder(struct bge_softc *sc) > { > devclass_t pcib, pci; > device_t dev, bus; > > pci = devclass_find("pci"); > pcib = devclass_find("pcib"); > dev = sc->dev; > bus = device_get_parent(dev); > for (;;) { > dev = device_get_parent(bus); > bus = device_get_parent(dev); > if (device_get_devclass(dev) != pcib_devclass || > device_get_devclass(bus) != pci_devclass) > break; > /* Probe device ID. */ > } > return (0); > } > > It is not safe to use pci_get_vendor() with non-PCI devices (you may get > random junk, and Host-PCI bridges are not PCI devices). Also, this will only > apply the quirk if a relevant bridge is in the bge device's path. > Thanks for reviewing and suggestion. Would you review updated one? --IS0zKkzwUGydFO0o Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="bge.mbox.reorder.diff2" Index: sys/dev/bge/if_bgereg.h =================================================================== --- sys/dev/bge/if_bgereg.h (revision 232144) +++ 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 232144) +++ 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,47 @@ } 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 pci, pcib; + device_t bus, dev; + int count, i; + + count = sizeof(mbox_reorder_lists) / sizeof(mbox_reorder_lists[0]); + pci = devclass_find("pci"); + pcib = devclass_find("pcib"); + dev = sc->bge_dev; + bus = device_get_parent(dev); + for (;;) { + dev = device_get_parent(bus); + bus = device_get_parent(dev); + if (device_get_devclass(dev) != pcib || + device_get_devclass(bus) != pci) + break; + 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 +3139,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. --IS0zKkzwUGydFO0o-- From owner-freebsd-stable@FreeBSD.ORG Sat Feb 25 07: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 D1C231065673; Sat, 25 Feb 2012 07:13:50 +0000 (UTC) (envelope-from nox@jelal.kn-bremen.de) Received: from smtp.kn-bremen.de (gelbbaer.kn-bremen.de [78.46.108.116]) by mx1.freebsd.org (Postfix) with ESMTP id 8FC9E8FC08; Sat, 25 Feb 2012 07:13:50 +0000 (UTC) Received: by smtp.kn-bremen.de (Postfix, from userid 10) id 04A5D1E0024B; Sat, 25 Feb 2012 07:57:15 +0100 (CET) Received: from triton8.kn-bremen.de (noident@localhost [127.0.0.1]) by triton8.kn-bremen.de (8.14.4/8.14.4) with ESMTP id q1P6tiht015360; Sat, 25 Feb 2012 07:55:44 +0100 (CET) (envelope-from nox@triton8.kn-bremen.de) Received: (from nox@localhost) by triton8.kn-bremen.de (8.14.4/8.14.3/Submit) id q1P6tiSU015359; Sat, 25 Feb 2012 07:55:44 +0100 (CET) (envelope-from nox) Date: Sat, 25 Feb 2012 07:55:44 +0100 (CET) From: Juergen Lock Message-Id: <201202250655.q1P6tiSU015359@triton8.kn-bremen.de> To: freebsd@damnhippie.dyndns.org X-Newsgroups: local.list.freebsd.stable In-Reply-To: <1330126840.7317.60.camel@revolution.hippie.lan> References: <201202221334.36484.erich@alogreentechnologies.com> <64FF3DF7-6EEA-480D-85AA-5784AF013EA8@lassitu.de> <201202241350.56933.erichfreebsdlist@ovitrap.com> <1330100633.7317.41.camel@revolution.hippie.lan> <4F4811B4.4000701@FreeBSD.org> Organization: Cc: freebsd-stable@freebsd.org, Andriy Gapon Subject: geom vs. removable disks/cards (was: Re: random problem with 8.3 from yesterday) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Feb 2012 07:13:50 -0000 In article <1330126840.7317.60.camel@revolution.hippie.lan> you write: >On Sat, 2012-02-25 at 00:39 +0200, Andriy Gapon wrote: >> on 24/02/2012 18:23 Ian Lepore said the following: >> > I've always >> > suspected something in the geom layer isn't noticing that a CF or SD >> > card in the reader got removed/inserted/reformatted, and un-/re-plugging >> > the whole reader (making the cam layer destroy and recreate the devices) >> > makes geom aware of the change. >> >> This is a fact, actually. Nothing in GEOM layer (and below it) notices a silent >> card change, since most hardware doesn't have any notification for the change >> and FreeBSD disk stack doesn't do any polling for changes. >> > >If the hardware did have change notification, is there a mechanism that >would communicate that to geom? That's a precursor question to my real >question: is there a way to manually kick geom when necessary? If the >api exists but there's no userland app to make the needed calls, I'll >write some code -- just point me at a manpage or header file. scsi has a mechanism called unit attention to report things like media changes, not sure usb devices use that tho since the host can only poll them... Anyway, the usual workaround is to force a geom retaste by opening the device for writing without actually writing anything, e.g.: # : >/dev/da0 Btw this can't be Erich's problem I'd say since he said he's plugging in a thumbdrive not a card into a reader (and also writing /dev/zero to it) so geom _should_ already taste it. (Unless the write fails since the thumbdrive is too slow initializing or something like that...) HTH, Juergen From owner-freebsd-stable@FreeBSD.ORG Sat Feb 25 08:01:11 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 02ECA106564A for ; Sat, 25 Feb 2012 08:01:11 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from mx0.hoeg.nl (mx0.hoeg.nl [178.63.0.170]) by mx1.freebsd.org (Postfix) with ESMTP id B95548FC12 for ; Sat, 25 Feb 2012 08:01:10 +0000 (UTC) Received: by mx0.hoeg.nl (Postfix, from userid 1000) id D26F42A28CCF; Sat, 25 Feb 2012 09:01:09 +0100 (CET) Date: Sat, 25 Feb 2012 09:01:09 +0100 From: Ed Schouten To: Vlad Galu Message-ID: <20120225080109.GK32748@hoeg.nl> References: <20120224221526.GH32748@hoeg.nl> <350DE43596674E608581BB2536231611@dudu.ro> <20120224224016.GI32748@hoeg.nl> <9DAEF77AE05F4151AD561D26DF5D69F1@dudu.ro> <20120224230027.GJ32748@hoeg.nl> <74553B7DA41D44179CAC5A937E6322E6@dudu.ro> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="SCOJXUq1iwCn05li" Content-Disposition: inline In-Reply-To: <74553B7DA41D44179CAC5A937E6322E6@dudu.ro> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: stable@freebsd.org Subject: Re: Inconsistent utx.active? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Feb 2012 08:01:11 -0000 --SCOJXUq1iwCn05li Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Vlad, * Vlad Galu , 20120225 00:24: > Sigh, you are right. I had UseLogin set to yes in sshd_config. Sorry > for the noise and thanks! Even with UseLogin I fail to reproduce it on my system. Even with UseLogin enabled it shouldn't cause utmpx entries to be `leaked'. I'll keep UseLogin enabled on one of my systems from now on to see whether it occurs sporadically. Thanks for reporting the issue. --=20 Ed Schouten WWW: http://80386.nl/ --SCOJXUq1iwCn05li Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iQIcBAEBAgAGBQJPSJVFAAoJEG5e2P40kaK7RsAP/3qZrb0AmHfKsR4l8V1Vux3Y A/3bnW1oYRNhPk64/5dEwT+E3E6wjbjjHS/XxKlt05ypH+TfruF4f8lb0jChcLm9 y8IqcWMEIUCh3FU8qISLIXl5eQ+aLhWtQiphOrfLpcZb/TqtICVpGbUF1kvL37/F Vlqq/WaOKc7T9zPc5LJF/ZBwL4ELmLgm3LjPOHiPxrdmu3vZlIsd8xHNU4uhQ4Fw QqL5BmEVESvsOE9XvXZYjgRwaAWuDS5sSlKCpyU/C2BkYWezpodbVKglzgbe6EyK 9k9N7RDJMExEQJ30Ydq6iUsfTRn9gyafgwdrD/h81y46k8vIlqF5fq6ZNupHCL0k UWmRJKaeXLApLmMiiRp7vTbaVLFo95kCrSB1owdkeR4wm5P5oGLGENz7QWqYwCBq MTxTOrZh67hjOwGVrXwyS93XLumFba+BNhsVZB1UtjTrqpGFOtPqr04sBDpo1aYE 8A1/XksaxvKnsDxtUIJmsKRoKVYfreAe9Dpfoaq02yvOJdAakd4cf+i5pIcOiEsG HT7uYHpxkLdAK3PJkMVdEtg08IDm0mzWPqCbE5OUl10Wf9T/g1EhujsIYuHfpQtR MwQ5jqyBSDy9HkSpAUM+uUtNNYBj710RvDqGNX6KAJHDJzXl/l0OYU7nWj09rbt/ xBXA6qpwiNYuPj79vrW2 =6FbE -----END PGP SIGNATURE----- --SCOJXUq1iwCn05li-- From owner-freebsd-stable@FreeBSD.ORG Sat Feb 25 11:28: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 77A1F106564A for ; Sat, 25 Feb 2012 11:28:22 +0000 (UTC) (envelope-from bennett@cs.niu.edu) Received: from mp.cs.niu.edu (mp.cs.niu.edu [131.156.145.41]) by mx1.freebsd.org (Postfix) with ESMTP id 3FE188FC16 for ; Sat, 25 Feb 2012 11:28:21 +0000 (UTC) Received: from mp.cs.niu.edu (bennett@localhost [127.0.0.1]) by mp.cs.niu.edu (8.14.3/8.14.3) with ESMTP id q1PARUEB021976; Sat, 25 Feb 2012 04:27:30 -0600 (CST) Date: Sat, 25 Feb 2012 04:27:30 -0600 (CST) From: Scott Bennett Message-Id: <201202251027.q1PARURH021975@mp.cs.niu.edu> To: Erich Dollansky Cc: freebsd-stable@freebsd.org Subject: random problem with 8.3 from yesterday X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Feb 2012 11:28:22 -0000 On Wed, 22 Feb 2012 13:34:36 +0700 Erich Dollansky wrote: >I got a new thumb drive which was FAT formatted. I use this script to change this: > >!/bin/tcsh ># ># This script format a thumb drive connected to USB as da0. ># >printf "You have to run this script as 'root' to succeed.\n" >printf "Warning this script will delete all your data from /dev/da0. Continue? > " >set Eingabe = $< >if ("$Eingabe" == "y") then > printf "\nDeleting the device " > dd if=/dev/zero of=/dev/da0 bs=1k count=1 > printf "\nWriting the BSD label " > bsdlabel -Bw da0 auto Hmmm...so no MBR and no GPT either? Just the bare device? I guess I haven't tried that, so I don't know what that would do. > printf "\nEditing the BSD label " > bsdlabel -e da0 > newfs /dev/da0a > printf "\nThe device /dev/da0 was formated to be used with FreeBSD.\n" >else > printf "\nScript aborted!\n" >endif > >I then call manually > >tunefs -L NewDeviceName /dev/da0a Just out of curiosity, I'd like to know why you run tunefs manually, rather than using "-L NewDeviceName" on the newfs command, given that your script is clearing the physical device and then creating an empty file system. > >Either this call or the mount command does not work randomly. > >When I then try to mount the device on /dev/da0a it does not work always. What do you mean when you write "mount the device on /dev/da0a"? Normally one mounts a filesystem onto a "device", e.g., mount /dev/ad0s1d /var or some similar thing. Also, why do you refer to /dev/da0a at all if you labeled the file system? The whole point of labeling the file system is supposed to be so that you can mount it independently of the physical device name, e.g., mount /dev/ufs/NewDeviceName /thumbfs which allows you to have an entry in /etc/fstab for mounting the file system that doesn't need to be edited every time you reboot the system or move devices around. > >I do not know what this causes, I am only randomly able to reproduce it. > >It might be affected by removing the device or keeping it plugged in. Well, yes, that's what you label partitions/devices to avoid having to deal with manually, right? > >uname says: > >FreeBSD AMD620.ovitrap.com 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #28: Tue Feb 21 17:15:07 WIT 2012 erich@AMD620.ovitrap.com:/usr/obj/usr/src/sys/AsusAMD620 amd64 > >dmesg says: > >ugen1.2: at usbus1 >umass0: on usbus1 >umass0: SCSI over Bulk-Only; quirks = 0x4001 >umass0:2:0:-1: Attached to scbus2 >da0 at umass-sim0 bus 0 scbus2 target 0 lun 0 >da0: < USB FLASH DRIVE PMAP> Removable Direct Access SCSI-0 device >da0: 40.000MB/s transfers >da0: 15272MB (31277056 512 byte sectors: 255H 63S/T 1946C) > >It is not an urgent problem. > It most likely is not a problem at all. See http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/geom-glabel.html#AEN27470 With best regards, Scott Bennett, Comm. ASMELG, CFIAG ********************************************************************** * Internet: bennett at cs.niu.edu * *--------------------------------------------------------------------* * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * * -- Gov. John Hancock, New York Journal, 28 January 1790 * ********************************************************************** From owner-freebsd-stable@FreeBSD.ORG Sat Feb 25 16:56: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 5E1D3106564A for ; Sat, 25 Feb 2012 16:56:26 +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 DF1188FC08 for ; Sat, 25 Feb 2012 16:56:25 +0000 (UTC) Received: by wgbdq11 with SMTP id dq11so2858895wgb.31 for ; Sat, 25 Feb 2012 08:56:24 -0800 (PST) Received-SPF: pass (google.com: domain of kob6558@gmail.com designates 10.180.80.71 as permitted sender) client-ip=10.180.80.71; Authentication-Results: mr.google.com; spf=pass (google.com: domain of kob6558@gmail.com designates 10.180.80.71 as permitted sender) smtp.mail=kob6558@gmail.com; dkim=pass header.i=kob6558@gmail.com Received: from mr.google.com ([10.180.80.71]) by 10.180.80.71 with SMTP id p7mr14025800wix.10.1330188984976 (num_hops = 1); Sat, 25 Feb 2012 08:56:24 -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=+U8o5V7h2v020CtTkTUtPmamO1mnLKNEIPcfWGxiPdk=; b=T/wY987/vzPX5/7UhfPgbh/ReAt9Ifry+sG5nszJttubPVO17iULc+5isXHqV81RML HxSdWvV6OPcqCdecRF4hciA1cuqexnv0ZTeYqSrXi3JfGqMTH7jNKAY+GdpRbkflqn28 EIj0q4pr4sJYiAvWGTidnsj017SVlfPpH/rcc= MIME-Version: 1.0 Received: by 10.180.80.71 with SMTP id p7mr11202486wix.10.1330188984879; Sat, 25 Feb 2012 08:56:24 -0800 (PST) Received: by 10.223.16.82 with HTTP; Sat, 25 Feb 2012 08:56:24 -0800 (PST) In-Reply-To: <201202251027.q1PARURH021975@mp.cs.niu.edu> References: <201202251027.q1PARURH021975@mp.cs.niu.edu> Date: Sat, 25 Feb 2012 08:56:24 -0800 Message-ID: From: Kevin Oberman To: Scott Bennett Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Erich Dollansky , freebsd-stable@freebsd.org Subject: Re: random problem with 8.3 from yesterday X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Feb 2012 16:56:26 -0000 On Sat, Feb 25, 2012 at 2:27 AM, Scott Bennett wrote: > =A0 =A0 On Wed, 22 Feb 2012 13:34:36 +0700 Erich Dollansky > wrote: > >>I got a new thumb drive which was FAT formatted. I use this script to cha= nge this: >> >>!/bin/tcsh >># >># This script format a thumb drive connected to USB as da0. >># >>printf "You have to run this script as 'root' to succeed.\n" >>printf "Warning this script will delete all your data from /dev/da0. Cont= inue? > " >>set Eingabe =3D $< >>if ("$Eingabe" =3D=3D "y") then >> =A0 printf "\nDeleting the device " >> =A0 dd if=3D/dev/zero of=3D/dev/da0 bs=3D1k count=3D1 >> =A0 printf "\nWriting the BSD label " >> =A0 bsdlabel -Bw da0 auto > > =A0 =A0 Hmmm...so no MBR and no GPT either? =A0Just the bare device? =A0I= guess > I haven't tried that, so I don't know what that would do. Call me a bit confused, but I thought -B did write an MBR. It always has seemed to do so for me, at any rate. From man bsdlabel: "Installing Bootstraps If the -B option is specified, bootstrap code will be read from the fi= le /boot/boot and written to the disk." Or am I not understanding something? --=20 R. Kevin Oberman, Network Engineer E-mail: kob6558@gmail.com From owner-freebsd-stable@FreeBSD.ORG Sat Feb 25 17:19: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 F2557106564A for ; Sat, 25 Feb 2012 17:19:09 +0000 (UTC) (envelope-from bennett@cs.niu.edu) Received: from mp.cs.niu.edu (mp.cs.niu.edu [131.156.145.41]) by mx1.freebsd.org (Postfix) with ESMTP id AC3078FC0C for ; Sat, 25 Feb 2012 17:19:09 +0000 (UTC) Received: from mp.cs.niu.edu (bennett@localhost [127.0.0.1]) by mp.cs.niu.edu (8.14.3/8.14.3) with ESMTP id q1PHHeGC024465; Sat, 25 Feb 2012 11:17:40 -0600 (CST) Date: Sat, 25 Feb 2012 11:17:40 -0600 (CST) From: Scott Bennett Message-Id: <201202251717.q1PHHeXD024464@mp.cs.niu.edu> To: Kevin Oberman Cc: Erich Dollansky , freebsd-stable@freebsd.org Subject: Re: random problem with 8.3 from yesterday X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Feb 2012 17:19:10 -0000 On Sat, 25 Feb 2012 08:56:24 -0800 Kevin Oberman wrote: >On Sat, Feb 25, 2012 at 2:27 AM, Scott Bennett wrote: >> =A0 =A0 On Wed, 22 Feb 2012 13:34:36 +0700 Erich Dollansky >> wrote: >> >>>I got a new thumb drive which was FAT formatted. I use this script to cha= >nge this: >>> >>>!/bin/tcsh >>># >>># This script format a thumb drive connected to USB as da0. >>># >>>printf "You have to run this script as 'root' to succeed.\n" >>>printf "Warning this script will delete all your data from /dev/da0. Cont= >inue? > " >>>set Eingabe =3D $< >>>if ("$Eingabe" =3D=3D "y") then >>> =A0 printf "\nDeleting the device " >>> =A0 dd if=3D/dev/zero of=3D/dev/da0 bs=3D1k count=3D1 >>> =A0 printf "\nWriting the BSD label " >>> =A0 bsdlabel -Bw da0 auto >> >> =A0 =A0 Hmmm...so no MBR and no GPT either? =A0Just the bare device? =A0I= > guess >> I haven't tried that, so I don't know what that would do. > >Call me a bit confused, but I thought -B did write an MBR. It always >has seemed to do so for me, at any rate. From man bsdlabel: >"Installing Bootstraps > If the -B option is specified, bootstrap code will be read from the fi= >le > /boot/boot and written to the disk." >Or am I not understanding something? I guess I understand the part that you quoted above as meaning that the bootstrap code would be copied to the bootstrap sectors. However, as I interpret it, the bsdlabel command does not write a MBR, which would include the slice map for the device. Further, Erich's later commands did not specify a slice number. In short, it looks to me as though he may have ended up with the initial boot code where it belonged at the start of the device, but the boot code looks for the slice map, which isn't there, so it should not be possible to boot a kernel because the bootstrap code would not be able to find it. But as far as simply mounting a file system, I really don't know whether it should work to have a BSD label written to a bare device with neither a MBR nor a GPT to find that label. IOW, would the device node to be used in the mount operation have been created? Note to Erich: did you look in /dev and /dev/ufs to see whether all of the device files that you expected to be there were, in fact, present before you attempted the mount? Scott Bennett, Comm. ASMELG, CFIAG ********************************************************************** * Internet: bennett at cs.niu.edu * *--------------------------------------------------------------------* * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * * -- Gov. John Hancock, New York Journal, 28 January 1790 * ********************************************************************** From owner-freebsd-stable@FreeBSD.ORG Sat Feb 25 17:55: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 F180C106564A for ; Sat, 25 Feb 2012 17:55:47 +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 7E49E8FC15 for ; Sat, 25 Feb 2012 17:55:47 +0000 (UTC) Received: by wgbdq11 with SMTP id dq11so2881108wgb.31 for ; Sat, 25 Feb 2012 09:55:46 -0800 (PST) Received-SPF: pass (google.com: domain of kob6558@gmail.com designates 10.216.137.219 as permitted sender) client-ip=10.216.137.219; Authentication-Results: mr.google.com; spf=pass (google.com: domain of kob6558@gmail.com designates 10.216.137.219 as permitted sender) smtp.mail=kob6558@gmail.com; dkim=pass header.i=kob6558@gmail.com Received: from mr.google.com ([10.216.137.219]) by 10.216.137.219 with SMTP id y69mr3635116wei.51.1330192546538 (num_hops = 1); Sat, 25 Feb 2012 09:55:46 -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=5eTZMr//H/Znk8WeNJuqOD2xTmtSzTQGFqlsgKiXnrg=; b=koWIAPj+94dKbs+16yYQUGMF5mT7SBeFk6nGaJ+YoxLozvez42RvbxjqqQmOr6UgIg M6cA0S4AVHSLR5KKbRkTHWNGAzrroo6RVMsujn8lpcPJ8cyFY0DyTbeVd3P5aPD3rxAq T1bhupEM5402CjClhfdZ7DCr/1aeOyDOvrbFk= MIME-Version: 1.0 Received: by 10.216.137.219 with SMTP id y69mr2897821wei.51.1330192546375; Sat, 25 Feb 2012 09:55:46 -0800 (PST) Received: by 10.223.16.82 with HTTP; Sat, 25 Feb 2012 09:55:46 -0800 (PST) In-Reply-To: <201202251717.q1PHHeXD024464@mp.cs.niu.edu> References: <201202251717.q1PHHeXD024464@mp.cs.niu.edu> Date: Sat, 25 Feb 2012 09:55:46 -0800 Message-ID: From: Kevin Oberman To: Scott Bennett Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Erich Dollansky , freebsd-stable@freebsd.org Subject: Re: random problem with 8.3 from yesterday X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Feb 2012 17:55:48 -0000 On Sat, Feb 25, 2012 at 9:17 AM, Scott Bennett wrote: > =A0 =A0 On Sat, 25 Feb 2012 08:56:24 -0800 Kevin Oberman > wrote: >>On Sat, Feb 25, 2012 at 2:27 AM, Scott Bennett wrote= : >>> =3DA0 =3DA0 On Wed, 22 Feb 2012 13:34:36 +0700 Erich Dollansky >>> wrote: >>> >>>>I got a new thumb drive which was FAT formatted. I use this script to c= ha=3D >>nge this: >>>> >>>>!/bin/tcsh >>>># >>>># This script format a thumb drive connected to USB as da0. >>>># >>>>printf "You have to run this script as 'root' to succeed.\n" >>>>printf "Warning this script will delete all your data from /dev/da0. Co= nt=3D >>inue? > " >>>>set Eingabe =3D3D $< >>>>if ("$Eingabe" =3D3D=3D3D "y") then >>>> =3DA0 printf "\nDeleting the device " >>>> =3DA0 dd if=3D3D/dev/zero of=3D3D/dev/da0 bs=3D3D1k count=3D3D1 >>>> =3DA0 printf "\nWriting the BSD label " >>>> =3DA0 bsdlabel -Bw da0 auto >>> >>> =3DA0 =3DA0 Hmmm...so no MBR and no GPT either? =3DA0Just the bare devi= ce? =3DA0I=3D >> guess >>> I haven't tried that, so I don't know what that would do. >> >>Call me a bit confused, but I thought -B did write an MBR. It always >>has seemed to do so for me, at any rate. From man bsdlabel: >>"Installing Bootstraps >> =A0 =A0 If the -B option is specified, bootstrap code will be read from = the fi=3D >>le >> =A0 =A0 /boot/boot and written to the disk." >>Or am I not understanding something? > > =A0 =A0 I guess I understand the part that you quoted above as meaning th= at > the bootstrap code would be copied to the bootstrap sectors. =A0However, = as > I interpret it, the bsdlabel command does not write a MBR, which would > include the slice map for the device. =A0Further, Erich's later commands = did > not specify a slice number. =A0In short, it looks to me as though he may = have > ended up with the initial boot code where it belonged at the start of the > device, but the boot code looks for the slice map, which isn't there, so > it should not be possible to boot a kernel because the bootstrap code > would not be able to find it. =A0But as far as simply mounting a file sys= tem, > I really don't know whether it should work to have a BSD label written to > a bare device with neither a MBR nor a GPT to find that label. =A0IOW, wo= uld > the device node to be used in the mount operation have been created? > =A0 =A0 Note to Erich: =A0did you look in /dev and /dev/ufs to see whethe= r all > of the device files that you expected to be there were, in fact, present > before you attempted the mount? I thought he was creating a "monolithic" device...what was called "dangerously dedicated". No slices at all. Not only are DD volumes mountable, they are bootable. It's been years since I created a DD disk as the slight space savings are irrelevant on modern hundreds of gigabyte disks, so I may have forgotten how it works. It might still make sense on a small thumb drive, bootable or not. --=20 R. Kevin Oberman, Network Engineer E-mail: kob6558@gmail.com From owner-freebsd-stable@FreeBSD.ORG Sat Feb 25 18:23: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 25C831065673 for ; Sat, 25 Feb 2012 18:23:04 +0000 (UTC) (envelope-from freebsd@damnhippie.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 029418FC0C for ; Sat, 25 Feb 2012 18:23:03 +0000 (UTC) Received: from omta09.emeryville.ca.mail.comcast.net ([76.96.30.20]) by qmta08.emeryville.ca.mail.comcast.net with comcast id eJNJ1i0040S2fkCA8JP3Tc; Sat, 25 Feb 2012 18:23:03 +0000 Received: from damnhippie.dyndns.org ([24.8.232.202]) by omta09.emeryville.ca.mail.comcast.net with comcast id eJP21i00B4NgCEG8VJP24M; Sat, 25 Feb 2012 18:23:03 +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 q1PIN0kK002922; Sat, 25 Feb 2012 11:23:00 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) From: Ian Lepore To: Juergen Lock In-Reply-To: <201202250655.q1P6tiSU015359@triton8.kn-bremen.de> References: <201202221334.36484.erich@alogreentechnologies.com> <64FF3DF7-6EEA-480D-85AA-5784AF013EA8@lassitu.de> <201202241350.56933.erichfreebsdlist@ovitrap.com> <1330100633.7317.41.camel@revolution.hippie.lan> <4F4811B4.4000701@FreeBSD.org> <201202250655.q1P6tiSU015359@triton8.kn-bremen.de> Content-Type: text/plain; charset="us-ascii" Date: Sat, 25 Feb 2012 11:23:00 -0700 Message-ID: <1330194180.7317.64.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: geom vs. removable disks/cards (was: Re: random problem with 8.3 from yesterday) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Feb 2012 18:23:04 -0000 On Sat, 2012-02-25 at 07:55 +0100, Juergen Lock wrote: > In article <1330126840.7317.60.camel@revolution.hippie.lan> you write: > >On Sat, 2012-02-25 at 00:39 +0200, Andriy Gapon wrote: > >> on 24/02/2012 18:23 Ian Lepore said the following: > >> > I've always > >> > suspected something in the geom layer isn't noticing that a CF or SD > >> > card in the reader got removed/inserted/reformatted, and un-/re-plugging > >> > the whole reader (making the cam layer destroy and recreate the devices) > >> > makes geom aware of the change. > >> > >> This is a fact, actually. Nothing in GEOM layer (and below it) notices a silent > >> card change, since most hardware doesn't have any notification for the change > >> and FreeBSD disk stack doesn't do any polling for changes. > >> > > > >If the hardware did have change notification, is there a mechanism that > >would communicate that to geom? That's a precursor question to my real > >question: is there a way to manually kick geom when necessary? If the > >api exists but there's no userland app to make the needed calls, I'll > >write some code -- just point me at a manpage or header file. > > scsi has a mechanism called unit attention to report things like > media changes, not sure usb devices use that tho since the host can > only poll them... > > Anyway, the usual workaround is to force a geom retaste by opening > the device for writing without actually writing anything, e.g.: > > # : >/dev/da0 > > Btw this can't be Erich's problem I'd say since he said he's > plugging in a thumbdrive not a card into a reader (and also writing > /dev/zero to it) so geom _should_ already taste it. (Unless the > write fails since the thumbdrive is too slow initializing or something > like that...) > > HTH, > Juergen I was a bit concerned that the similarities between Erich's symptoms and mine were purely superficial, with different underlying causes. I've never seen the stale geom data problem I described on a thumb drive, except when I've used dd to zero out the beginning of a drive that was gpt-formatted but left the backup partition table at the end of the drive -- that always causes me problems that only get fixed by using gpart destroy -F. Thanks for the tip about forcing a re-taste, I think I'll be using that a bunch. -- Ian