From owner-freebsd-stable@FreeBSD.ORG Sun May 30 02:42:45 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C6F2F1065670 for ; Sun, 30 May 2010 02:42:45 +0000 (UTC) (envelope-from dan@dan.emsphone.com) Received: from email1.allantgroup.com (email1.emsphone.com [199.67.51.115]) by mx1.freebsd.org (Postfix) with ESMTP id 73E848FC0C for ; Sun, 30 May 2010 02:42:45 +0000 (UTC) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by email1.allantgroup.com (8.14.0/8.14.0) with ESMTP id o4U2gfBD018604 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 29 May 2010 21:42:42 -0500 (CDT) (envelope-from dan@dan.emsphone.com) Received: from dan.emsphone.com (smmsp@localhost [127.0.0.1]) by dan.emsphone.com (8.14.4/8.14.4) with ESMTP id o4U2gfdG044134 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 29 May 2010 21:42:41 -0500 (CDT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.14.4/8.14.3/Submit) id o4U2gf33044133; Sat, 29 May 2010 21:42:41 -0500 (CDT) (envelope-from dan) Date: Sat, 29 May 2010 21:42:41 -0500 From: Dan Nelson To: Kirk Strauser Message-ID: <20100530024240.GE8866@dan.emsphone.com> References: <4C017419.9010909@strauser.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C017419.9010909@strauser.com> X-OS: FreeBSD 8.0-STABLE User-Agent: Mutt/1.5.20 (2009-06-14) X-Virus-Scanned: clamav-milter 0.96 at email1.allantgroup.com X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (email1.allantgroup.com [199.67.51.78]); Sat, 29 May 2010 21:42:42 -0500 (CDT) X-Scanned-By: MIMEDefang 2.45 Cc: FreeBSD-STABLE Mailing List Subject: Re: Make ZFS auto-destroy snapshots when the out of space? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 30 May 2010 02:42:45 -0000 In the last episode (May 29), Kirk Strauser said: > I found some nice scripts to regularly snapshot all the filesystems in my > ZFS pool at > http://www.neces.com/blog/technology/integrating-freebsd-zfs-and-periodic-snapshots-and-scrubs > . One thing bothers me, though: I have to intentionally set how many > months' worth of snapshots I want to keep. Too many and I run out of > room. Too few and I lose some of the benefits of easy recovery of > deleted data. My computer is better at bookkeeping than I am, so why not > let it? > > I'd propose standardizing on an attribute like > org.freebsd:allowautodestroy. Modify ZFS's disk full behavior to scan for > snapshots with that attribute set and destroy the oldest one, and continue > until there's enough free space to complete a write requests or until out > of "expendable" snapshots to destroy (at which time the normal disk full > handler would run). Also run a daily periodic script to ensure that the > free space stays below a configurable threshold each day so that ZFS isn't > constantly butting up against completely full drives. If the kernel does the snapshot deleting itself, why not add a pool-level property that sets the amount of free space at which the deletion starts? That way you don't need the cleanup script. Alternatively, make the org.freebsd:allowautodestroy property hold the trigger freespace amount. That way you can have monthly/daily/hourly snapshots but set it so the hourly ones disappear first, then the dailies (by setting the destroy trigger slightly higher for the ones you want to expire first). -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-stable@FreeBSD.ORG Sun May 30 02:58:26 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 254E1106566B for ; Sun, 30 May 2010 02:58:26 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id C52598FC15 for ; Sun, 30 May 2010 02:58:25 +0000 (UTC) Received: by vws12 with SMTP id 12so3495198vws.13 for ; Sat, 29 May 2010 19:58:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=kNRwDKpd9APfZ2r9OFzanGvePzuuHY9rS58GitQNjQw=; b=jk+waaZCqc2Fy9S4ZlAMls0C9Sybpio+/NTRKzVTKKp/RGX0ztYAxr9tB8qz270yaa 5X4SI3DfC0nSXK/8DTNTufM0M/Sl1x/JIXsJeFtI6cYwwL7w6q7ys1ZJwnj9RtRCrJo4 07Njk7H7mtuO4R7Gzgz8kh4oyfLGp/Pmsl+sA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Lya23GRcly8RxgrP1MbV/137p1TQXIdXorNO9nERRmYu8wxxrMnrgvDLhxPSz/IQ/B yWBxfXt8UheVrnbWSoLpek/86ZTISk/11mO51WVzCN0dDXPzx3s7uIZ/CZBHzQZGKNqf GJBmSZh95cOPJXj8AhqUl8v/RZise0Zib1rG8= MIME-Version: 1.0 Received: by 10.229.236.135 with SMTP id kk7mr408429qcb.145.1275188304598; Sat, 29 May 2010 19:58:24 -0700 (PDT) Received: by 10.229.190.83 with HTTP; Sat, 29 May 2010 19:58:24 -0700 (PDT) In-Reply-To: <4C017419.9010909@strauser.com> References: <4C017419.9010909@strauser.com> Date: Sat, 29 May 2010 19:58:24 -0700 Message-ID: From: Garrett Cooper To: Kirk Strauser Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD-STABLE Mailing List Subject: Re: Make ZFS auto-destroy snapshots when the out of space? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 30 May 2010 02:58:26 -0000 On Sat, May 29, 2010 at 1:07 PM, Kirk Strauser wrote: > I found some nice scripts to regularly snapshot all the filesystems in my > ZFS pool at > http://www.neces.com/blog/technology/integrating-freebsd-zfs-and-periodic-snapshots-and-scrubs > . One thing bothers me, though: I have to intentionally set how many months' > worth of snapshots I want to keep. Too many and I run out of room. Too few > and I lose some of the benefits of easy recovery of deleted data. My > computer is better at bookkeeping than I am, so why not let it? > > I'd propose standardizing on an attribute like org.freebsd:allowautodestroy. > Modify ZFS's disk full behavior to scan for snapshots with that attribute > set and destroy the oldest one, and continue until there's enough free space > to complete a write requests or until out of "expendable" snapshots to > destroy (at which time the normal disk full handler would run). Also run a > daily periodic script to ensure that the free space stays below a > configurable threshold each day so that ZFS isn't constantly butting up > against completely full drives. > > This would take all configuration guesswork out of the equation and would > let me keep as many snapshots as I have space to maintain. If I want to > extend my reach back in time, I can add another drive to the pool and the > rest is handled automatically. At the same time, should I suddenly *want* to > store massive amounts of new data, the snapshots can be easily and > automatically cleared out to make room for the stuff I want to hold. > > What do you think? It seems like this should be pretty easy to implement > without requiring any upstream changes or new FreeBSD-only data structures. > The whole thing could possibly be implemented in userspace, but I don't know > that ZFS has any exception handling callbacks that would make it easy. > > An unused resource is a wasted resource, right? So basically you're saying deal with an LRU snapshot deletion when you reach a certain threshold of free space, type scheme? This might get tricky, but it does lend itself to other systems I suppose (I hate to mention it, but the best one I can think of is Windows' system restore... there might be something else available with OSX's Time Machine). What would be more tricky is when the automated system is filling in a bunch of useless snapshots unnecessarily, but as you'd be providing the snapshot criteria, I suppose that you would know what snapshots you want to save and what ones you want to toss... It's an interesting thought though -- just increases the overall complexity of the system and may only meet one need. Cheers, -Garrett From owner-freebsd-stable@FreeBSD.ORG Sun May 30 05:27:26 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D65CA1065677 for ; Sun, 30 May 2010 05:27:26 +0000 (UTC) (envelope-from delphij@gmail.com) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id AC5368FC13 for ; Sun, 30 May 2010 05:27:26 +0000 (UTC) Received: by pvg16 with SMTP id 16so1293784pvg.13 for ; Sat, 29 May 2010 22:27:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=v8UcPD1gmgOBhql/BMI3c8dJDgqiLOW9JvsrPK9HVo8=; b=CyyQY7Xobq7SAIAa7uaO7VJGKplNN8No1XS+6p7oq5iXqwwNdpEfUVKKj+w9LYRLoM x6/fgNZPleKZcve1thrXjSRDBvSMuVO/0h416IYz8fggJnOa0GODDT3jSit43BojAZy3 riMaPYbzY23uAaxk0o+GxqjrpssnYIUStvpMk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=kF8BF3t02TcwzDj4Xf7/jbbgj6odOvXnObrge1R2PM5FH7z3zH9QAhb/3VrhFJ+DuW zLHWehomgCc4YIUgsreIJFRJ0wNCYkZods0rvT/cqBciN2da0TlFTLmk5csy5prTt3gL 3rrvM06t/jW4CW1TgDdIWBhGfJ+hkjybknXnU= MIME-Version: 1.0 Received: by 10.141.101.14 with SMTP id d14mr1935414rvm.232.1275197245157; Sat, 29 May 2010 22:27:25 -0700 (PDT) Received: by 10.140.204.3 with HTTP; Sat, 29 May 2010 22:27:25 -0700 (PDT) In-Reply-To: <4C017419.9010909@strauser.com> References: <4C017419.9010909@strauser.com> Date: Sat, 29 May 2010 22:27:25 -0700 Message-ID: From: Xin LI To: Kirk Strauser Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD-STABLE Mailing List Subject: Re: Make ZFS auto-destroy snapshots when the out of space? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 30 May 2010 05:27:27 -0000 Hi, Kirk, On Sat, May 29, 2010 at 1:07 PM, Kirk Strauser wrote: > I found some nice scripts to regularly snapshot all the filesystems in my > ZFS pool at > http://www.neces.com/blog/technology/integrating-freebsd-zfs-and-periodic-snapshots-and-scrubs > . One thing bothers me, though: I have to intentionally set how many months' > worth of snapshots I want to keep. Too many and I run out of room. Too few > and I lose some of the benefits of easy recovery of deleted data. My > computer is better at bookkeeping than I am, so why not let it? > > I'd propose standardizing on an attribute like org.freebsd:allowautodestroy. > Modify ZFS's disk full behavior to scan for snapshots with that attribute > set and destroy the oldest one, and continue until there's enough free space > to complete a write requests or until out of "expendable" snapshots to > destroy (at which time the normal disk full handler would run). Also run a > daily periodic script to ensure that the free space stays below a > configurable threshold each day so that ZFS isn't constantly butting up > against completely full drives. > > This would take all configuration guesswork out of the equation and would > let me keep as many snapshots as I have space to maintain. If I want to > extend my reach back in time, I can add another drive to the pool and the > rest is handled automatically. At the same time, should I suddenly *want* to > store massive amounts of new data, the snapshots can be easily and > automatically cleared out to make room for the stuff I want to hold. > > What do you think? It seems like this should be pretty easy to implement > without requiring any upstream changes or new FreeBSD-only data structures. > The whole thing could possibly be implemented in userspace, but I don't know > that ZFS has any exception handling callbacks that would make it easy. > > An unused resource is a wasted resource, right? I think this sounds like a good idea but I think we may probably want to explore a more general mechanism, e.g. a daemon that "listen"s system events like file system full, etc. and execute some user defined actions. One thing that we want to avoid is that by making the "automatic recycle" we would open a new race between system and user backup programs, i.e. if you remove an intermediate snapshot, 'zfs send' may fail at receiving side, if incremental send is being used. We would need a way to "notify" that a 'zfs send' is underway. Cheers, -- Xin LI http://www.delphij.net From owner-freebsd-stable@FreeBSD.ORG Sun May 30 06:31:28 2010 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 87DBD1065678; Sun, 30 May 2010 06:31:28 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 194FA8FC08; Sun, 30 May 2010 06:31:27 +0000 (UTC) Received: by vws12 with SMTP id 12so3654209vws.13 for ; Sat, 29 May 2010 23:31:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ndyKhcJ2lul3Zfp5jky5/GoEgoBdaTwD6ZonrY7n0JE=; b=EXfcdnOSXMiYVze73ldUe8Ut8MfAPKQuosdECJD5t9BxLvH8rIIpjfUk23hz/SBf1r ONJdQHRtifR30XkgVUMNzllvGQGAwm+D3Ix71E9QjG0VQYYzNH+g08vZYPWhyRfVn2Tb RQ1yKaN0VCp2tiRKVSKdPYniaj7yO4MDs/U10= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=rMRtHGi40UQKYS8mQCF5p+O4fOl4PHDGdEMy4MSvH/LjBnJAMclc0Mv4WkwmrcD6Bn geR4/xQanRgNNN2oYuEkMESRILXNAwq0p9qVcQegEZBmda0EqJhLPDxWTip/8vl8shju JXbnng3fIHFOQcODCR9SlRAAfgwWnAT8lj7BI= MIME-Version: 1.0 Received: by 10.224.61.69 with SMTP id s5mr1037778qah.189.1275201087082; Sat, 29 May 2010 23:31:27 -0700 (PDT) Received: by 10.229.190.83 with HTTP; Sat, 29 May 2010 23:31:27 -0700 (PDT) In-Reply-To: <4BFD70F5.6070005@mapper.nl> References: <4BF1891F.3040704@mapper.nl> <4BF23029.80104@mapper.nl> <4BFBA130.6060506@mapper.nl> <4BFD70F5.6070005@mapper.nl> Date: Sat, 29 May 2010 23:31:27 -0700 Message-ID: From: Garrett Cooper To: Mark Stapper Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: stable@freebsd.org, multimedia@freebsd.org Subject: Re: Buzzing snd_emu10kx enabled card with r206173 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 30 May 2010 06:31:28 -0000 On Wed, May 26, 2010 at 12:05 PM, Mark Stapper wrote: > On 25/05/2010 20:05, Garrett Cooper wrote: >> On Tue, May 25, 2010 at 3:06 AM, Mark Stapper wrote: >> >>> On 18/05/2010 08:14, Mark Stapper wrote: >>> >>>> On 18/05/2010 00:22, Garrett Cooper wrote: >>>> >>>> >>>>> On Mon, May 17, 2010 at 11:21 AM, Mark Stapper wrot= e: >>>>> >>>>> >>>>> >>>>>> I have the same problem. >>>>>> I'll try compiling the driver in the kernel. >>>>>> >>>>> =A0 =A0 FWIW I've compiled the driver into the kernel for several >>>>> iterations now and it works like a champ, so there's something with >>>>> the sound subsystem that isn't jiving properly when loading from >>>>> modules... >>>>> HTH, >>>>> -Garrett >>>>> >>>>> >>>>> >>>> Thanks for the info. >>>> I've noticed that when I load the kernel module at startup (by adding = it >>>> to loader.conf) chances of it working improve. >>>> If I load it afterwards, the nice huff puff sounds come out of my >>>> speaker again. >>>> Compiling the new and improved kernel today. >>>> Thanks for your help. >>> >>> I compiled the emu10kx driver into the kernel. >>> That seemed to work, but now the hissing and buzzing is back. >>> I really don't know what is going on anymore.. >>> Any thoughts? >>> >> What modules have you compiled and loaded? > > Kernel config and kldstat output pasted below > [...] > Everything I saw there appeared sane (it would have been nice to grab the -v output from kldstat, but that's ok...). Let's try doing the following: 1. Add `options EMU_MTX_DEBUG' to your kernconf. 2. Add set the sysctl: dev.emu10kx.0.debug=3D1 . Let's see if anything changes... Also, if you could provide some more hardware stats (say dmesg.boot and/or devinfo -v) and version stats (I already know that you're running amd64 from your kernel config) for the OS that would be helpful as well. I'm going to try upgrading my kernel and I'll try these steps as well. The locking between this driver and some other sound drivers isn't exactly the same (interestingly enough this driver uses Giant locking for some bits, while the ich one doesn't), and there were some past bugs with other branches of *BSD's drivers related to pci bus commands, etc; the other BSDs have dramatically different soundsystems -- I assume the old school soundsystem, s.t. the issues are probably not the same. Thanks, -Garrett From owner-freebsd-stable@FreeBSD.ORG Sun May 30 14:30:39 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0CE6D1065686; Sun, 30 May 2010 14:30:39 +0000 (UTC) (envelope-from amdmi3@amdmi3.ru) Received: from smtp.timeweb.ru (smtp.timeweb.ru [92.53.116.15]) by mx1.freebsd.org (Postfix) with ESMTP id BA25C8FC08; Sun, 30 May 2010 14:30:38 +0000 (UTC) Received: from [213.148.20.85] (helo=hive.panopticon) by smtp.timeweb.ru with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.71) (envelope-from ) id 1OIjX9-0003AV-RD; Sun, 30 May 2010 18:30:36 +0400 Received: from hades.panopticon (hades.panopticon [192.168.0.32]) by hive.panopticon (Postfix) with ESMTP id 1618CB84D; Sun, 30 May 2010 18:30:35 +0400 (MSD) Received: by hades.panopticon (Postfix, from userid 1000) id 032DCB833; Sun, 30 May 2010 18:30:35 +0400 (MSD) Date: Sun, 30 May 2010 18:30:35 +0400 From: Dmitry Marakasov To: freebsd-stable@FreeBSD.org, freebsd-current@FreeBSD.org Message-ID: <20100530143034.GH43302@hades.panopticon> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Subject: need better POSIX semaphore support X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 30 May 2010 14:30:39 -0000 Hi! Not long ago, POSIX semaphores support was enabled by default as it's becoming more widely used, by e.g. firefox. However, the support for these is still incomplete: we only have systemwide limit of 30 semaphores, and that doesn't seem to be configurable neither online with sysctl, nor at boottime from loader.conf. I only was able to raise semaphore count by changing SEM_MAX in kernel sources. The real appliaction which needs more semaphores is lightspark (graphics/lightspark-devel) flash plugin - it uses ~40 sems for simple clips and ~250 for something like youtube videos. Until there more apps that require proper semaphore support, I guess we need to improve it asap. Given the amount of memory used by ksem, the least can be done is SEM_MAX bumped up to 5120 or so for non-embedded kernels. 5120 semaphores require just 644k of kernel memory (judging by vmstat), and is "ought to be enough for anybody". Another good thing would be to make it configurable at boot-time or even better in runtime. -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D amdmi3@amdmi3.ru ..: jabber: amdmi3@jabber.ru http://www.amdmi3.ru From owner-freebsd-stable@FreeBSD.ORG Sun May 30 15:06:28 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3855110656CB; Sun, 30 May 2010 15:06:28 +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 C46458FC16; Sun, 30 May 2010 15:06:27 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id o4UF6aM4053517 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 30 May 2010 18:06:36 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id o4UF6MY7049447; Sun, 30 May 2010 18:06:22 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id o4UF6MCi049446; Sun, 30 May 2010 18:06:22 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 30 May 2010 18:06:22 +0300 From: Kostik Belousov To: Dmitry Marakasov Message-ID: <20100530150622.GJ83316@deviant.kiev.zoral.com.ua> References: <20100530143034.GH43302@hades.panopticon> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="aJd1ttTPPR7r8b0Q" Content-Disposition: inline In-Reply-To: <20100530143034.GH43302@hades.panopticon> 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=-2.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_50, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: need better POSIX semaphore support X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 30 May 2010 15:06:28 -0000 --aJd1ttTPPR7r8b0Q Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, May 30, 2010 at 06:30:35PM +0400, Dmitry Marakasov wrote: > Hi! >=20 > Not long ago, POSIX semaphores support was enabled by default as it's > becoming more widely used, by e.g. firefox. However, the support > for these is still incomplete: we only have systemwide limit of 30 > semaphores, and that doesn't seem to be configurable neither online with > sysctl, nor at boottime from loader.conf. I only was able to raise > semaphore count by changing SEM_MAX in kernel sources. >=20 > The real appliaction which needs more semaphores is lightspark > (graphics/lightspark-devel) flash plugin - it uses ~40 sems for simple > clips and ~250 for something like youtube videos. >=20 > Until there more apps that require proper semaphore support, I guess > we need to improve it asap. Given the amount of memory used by ksem, > the least can be done is SEM_MAX bumped up to 5120 or so for > non-embedded kernels. 5120 semaphores require just 644k of kernel > memory (judging by vmstat), and is "ought to be enough for anybody". > Another good thing would be to make it configurable at boot-time > or even better in runtime. HEAD contains different implementation. Apparently, it did not made into stable/8 yet, so it will not appear in the 8.1. Try this, I could try to squeeze it into 8.1. diff --git a/sys/kern/posix4_mib.c b/sys/kern/posix4_mib.c index 5242b31..41e28da 100644 --- a/sys/kern/posix4_mib.c +++ b/sys/kern/posix4_mib.c @@ -57,6 +57,9 @@ SYSCTL_DECL(_p1003_1b); #define P1B_SYSCTL(num, name) \ SYSCTL_INT(_p1003_1b, num, \ name, CTLFLAG_RD, facility + num - 1, 0, ""); +#define P1B_SYSCTL_RW(num, name) \ +SYSCTL_INT(_p1003_1b, num, \ + name, CTLFLAG_RW, facility + num - 1, 0, ""); =20 #else =20 @@ -65,6 +68,9 @@ SYSCTL_DECL(_kern_p1003_1b); #define P1B_SYSCTL(num, name) \ SYSCTL_INT(_kern_p1003_1b, OID_AUTO, \ name, CTLFLAG_RD, facility + num - 1, 0, ""); +#define P1B_SYSCTL_RW(num, name) \ +SYSCTL_INT(_kern_p1003_1b, OID_AUTO, \ + name, CTLFLAG_RW, facility + num - 1, 0, ""); SYSCTL_NODE(_kern, OID_AUTO, p1003_1b, CTLFLAG_RW, 0, "P1003.1B"); =20 #endif @@ -91,7 +97,7 @@ P1B_SYSCTL(CTL_P1003_1B_DELAYTIMER_MAX, delaytimer_max); P1B_SYSCTL(CTL_P1003_1B_MQ_OPEN_MAX, mq_open_max); P1B_SYSCTL(CTL_P1003_1B_PAGESIZE, pagesize); P1B_SYSCTL(CTL_P1003_1B_RTSIG_MAX, rtsig_max); -P1B_SYSCTL(CTL_P1003_1B_SEM_NSEMS_MAX, sem_nsems_max); +P1B_SYSCTL_RW(CTL_P1003_1B_SEM_NSEMS_MAX, sem_nsems_max); P1B_SYSCTL(CTL_P1003_1B_SEM_VALUE_MAX, sem_value_max); P1B_SYSCTL(CTL_P1003_1B_SIGQUEUE_MAX, sigqueue_max); P1B_SYSCTL(CTL_P1003_1B_TIMER_MAX, timer_max); --aJd1ttTPPR7r8b0Q Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkwCfu4ACgkQC3+MBN1Mb4inuACgwDhkHfAox2Km+EKeQkUkYQeM QusAmgLSXQKMzuGanmQD8yhBUlqcvDN3 =Irt5 -----END PGP SIGNATURE----- --aJd1ttTPPR7r8b0Q-- From owner-freebsd-stable@FreeBSD.ORG Sun May 30 19:12:21 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 152A9106566B; Sun, 30 May 2010 19:12:21 +0000 (UTC) (envelope-from technews@giallarhorn.org) Received: from mail.giallarhorn.com (giallarhorn.com [204.109.60.83]) by mx1.freebsd.org (Postfix) with ESMTP id EBB718FC13; Sun, 30 May 2010 19:12:20 +0000 (UTC) Received: from [172.16.1.7] (pool-71-179-162-64.bltmmd.fios.verizon.net [71.179.162.64]) by mail.giallarhorn.com (Postfix) with ESMTPSA id AAB271144F; Sun, 30 May 2010 15:12:19 -0400 (EDT) Message-ID: <4C02B91A.6000206@giallarhorn.org> Date: Sun, 30 May 2010 15:14:34 -0400 From: technews User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Alexander Motin References: <4BFDE813.4090201@FreeBSD.org> In-Reply-To: <4BFDE813.4090201@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Stable Subject: Re: gmirror panic with SiI 3726 when array is degraded X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 30 May 2010 19:12:21 -0000 On 5/26/2010 11:33 PM, Alexander Motin wrote: > technews wrote: > >> So I've started using gmirror recently to mirror 2 1.5 TB drives however >> if I reboot the machine or 'gmirror stop -f data1' while the array is >> been rebuilt I get the panic below. >> Rebooting without geom_mirror loaded does not cause a panic >> Rebooting with geom_mirror loaded and the drives disconnected does not >> cause a panic. >> The drives are in an "Rosewill RSV-S4-X 4 Bay SATA to eSATA (Port >> Multiplier) JBOD / RAID 0, 1, 1+0, 5 Enclosure" connected over a SiI >> 3726 (rev=1706) adapter >> Rebooting with the drives mounted normally does not cause a panic >> I'm using the latest and greatest firmware, the panics occurred before >> the update >> > It would be nice if you build kernel with debugger and got a stack > backtrace to show where problem occurred. > > Also, if you like your port multiplier to work much faster and stable - > I would strongly suggest you to update to 8-STABLE (or wait forthcoming > 8.1-RELEASE, if you prefer releases) and use new siis(4) driver for your > SiI3132 SATA controller. Port Multiplier support in ata(4) driver left > in embryo level and won't be improved. > > Thanks Alexander, I'll update to 8-STABLE and give the siis(4) driver a try. Its not really worth wasting time on something that's not going to be touched any more. From owner-freebsd-stable@FreeBSD.ORG Sun May 30 20:09:57 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1EA5B1065670 for ; Sun, 30 May 2010 20:09:57 +0000 (UTC) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.freebsd.org (Postfix) with ESMTP id E75968FC0A for ; Sun, 30 May 2010 20:09:56 +0000 (UTC) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.14.4/8.14.1) with ESMTP id o4UK9u74002478 for ; Sun, 30 May 2010 13:09:56 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.14.4/8.13.4/Submit) id o4UK9u9R002477; Sun, 30 May 2010 13:09:56 -0700 (PDT) Date: Sun, 30 May 2010 13:09:56 -0700 (PDT) From: Matthew Dillon Message-Id: <201005302009.o4UK9u9R002477@apollo.backplane.com> To: FreeBSD-STABLE Mailing List References: <4C017419.9010909@strauser.com> Subject: Re: Make ZFS auto-destroy snapshots when the out of space? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 30 May 2010 20:09:57 -0000 It is actually a security issue to automatically destroy snapshots based on whether a filesystem is full, even automatically generated snapshots. Since one usually implements snapshots to perform a function you wish to rely on, such as to retain backups of historical data for auditing or other purposes, you do not want an attacker to be able to indirectly destroy snapshots simply by filling up the filesystem. Instead what you want to do is to treat both the automatic and the manual snapshots as an integrated part of the filesystem's operation. Just as we have to deal with a nominal non-snapshotted filesystem-full condition today we also want to treat a filesystem with multiple snapshots in the same vein. So, for example, you might administratively desire 60 1-day snapshots plus 10 minute snapshots for the most recent 3 days to be retained at all times. The automatic maintainance of the snapshots would then administratively delete snapshots over 60 days old and prune to a coarser grain past 3 days. The use of snapshots on modern filesystem capable of managing large numbers of snapshots relatively pain-free, particularly on large storage systems and/or on modern multi-terrabyte HDs, requires a bit of a change in thinking. You have to stop thinking of the snapshots as optional and start thinking of them as mandatory. When snapshot availability is an assumed condition and not an exceptional or special-case condition it opens up a whole new arena in how filesystems can be managed, backed-up, audited, and used in every-day work. Once your thinking processes change you'll never go back to non-snapshotted or nontrivially-snapshotted filesystems. And you will certainly not want to allow a filesystem being mistakenly filled up to destroy your precious snapshots :-) -Matt From owner-freebsd-stable@FreeBSD.ORG Sun May 30 21:53:12 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 62DAD1065676 for ; Sun, 30 May 2010 21:53:12 +0000 (UTC) (envelope-from kirk@strauser.com) Received: from kanga.honeypot.net (kanga.honeypot.net [IPv6:2001:470:a80a:1:21f:d0ff:fe22:b8a8]) by mx1.freebsd.org (Postfix) with ESMTP id 240118FC0A for ; Sun, 30 May 2010 21:53:11 +0000 (UTC) Received: from kanga.honeypot.net (localhost [127.0.0.1]) by kanga.honeypot.net (Postfix) with ESMTP id E3B4E7BCDB; Sun, 30 May 2010 16:53:10 -0500 (CDT) X-Virus-Scanned: amavisd-new at honeypot.net Received: from kanga.honeypot.net ([127.0.0.1]) by kanga.honeypot.net (kanga.honeypot.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id cXkvb+QdjXFd; Sun, 30 May 2010 16:53:08 -0500 (CDT) Received: from pooh.honeypot.net (pooh.honeypot.net [IPv6:2001:470:a80a:1:20a:95ff:fed5:10f2]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by kanga.honeypot.net (Postfix) with ESMTPSA id 985357BCD0; Sun, 30 May 2010 16:53:07 -0500 (CDT) Message-Id: <4F444333-C839-4C2F-AA5D-1898192DDE93@strauser.com> From: Kirk Strauser To: Denny Lin In-Reply-To: <20100529234507.GD20695@mail.hs.ntnu.edu.tw> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 30 May 2010 16:53:06 -0500 References: <4C017419.9010909@strauser.com> <20100529234507.GD20695@mail.hs.ntnu.edu.tw> X-Mailer: Apple Mail (2.936) Cc: FreeBSD-STABLE Mailing List Subject: Re: Make ZFS auto-destroy snapshots when the out of space? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 30 May 2010 21:53:12 -0000 On May 29, 2010, at 6:45 PM, Denny Lin wrote: > How about writing a shell script with this functionality? Get the > available disk space using: > $ zfs list -H -o avail tank > > And then compare the figures against a limit. Then delete the oldest > snapshots when the limit is exceeded. That's certainly an option, and easy to implement in a shell script. It just wouldn't work in the case where a bunch of data comes in between runs of that script, and that's why I wanted something lower- level. -- Kirk Strauser From owner-freebsd-stable@FreeBSD.ORG Sun May 30 22:03:47 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7316A106564A for ; Sun, 30 May 2010 22:03:47 +0000 (UTC) (envelope-from kirk@strauser.com) Received: from kanga.honeypot.net (kanga.honeypot.net [IPv6:2001:470:a80a:1:21f:d0ff:fe22:b8a8]) by mx1.freebsd.org (Postfix) with ESMTP id 155E48FC14 for ; Sun, 30 May 2010 22:03:47 +0000 (UTC) Received: from kanga.honeypot.net (localhost [127.0.0.1]) by kanga.honeypot.net (Postfix) with ESMTP id A0BC87BE53; Sun, 30 May 2010 17:03:46 -0500 (CDT) X-Virus-Scanned: amavisd-new at honeypot.net Received: from kanga.honeypot.net ([127.0.0.1]) by kanga.honeypot.net (kanga.honeypot.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id E28xMtiGzgNb; Sun, 30 May 2010 17:03:44 -0500 (CDT) Received: from pooh.honeypot.net (pooh.honeypot.net [IPv6:2001:470:a80a:1:20a:95ff:fed5:10f2]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by kanga.honeypot.net (Postfix) with ESMTPSA id 7CAC07BE4B; Sun, 30 May 2010 17:03:44 -0500 (CDT) Message-Id: From: Kirk Strauser To: Garrett Cooper In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 30 May 2010 17:03:43 -0500 References: <4C017419.9010909@strauser.com> X-Mailer: Apple Mail (2.936) Cc: FreeBSD-STABLE Mailing List Subject: Re: Make ZFS auto-destroy snapshots when the out of space? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 30 May 2010 22:03:47 -0000 On May 29, 2010, at 9:58 PM, Garrett Cooper wrote: > So basically you're saying deal with an LRU snapshot deletion when you > reach a certain threshold of free space, type scheme? This might get > tricky, but it does lend itself to other systems I suppose (I hate to > mention it, but the best one I can think of is Windows' system > restore... there might be something else available with OSX's Time > Machine). Time Machine works almost exactly that way. It stores as far back in history as you have hard drive space to hold it. > What would be more tricky is when the automated system is filling in a > bunch of useless snapshots unnecessarily, but as you'd be providing > the snapshot criteria, I suppose that you would know what snapshots > you want to save and what ones you want to toss... I don't think add any trickery. The snapshots are again analogous to how Time Machine works, where you have hourly snapshots, then a week's worth of daily, then a month's worth of weeklies, then as many monthly snapshots as will fit on your hard drive. If you run out of space, delete November, then December. > It's an interesting thought though -- just increases the overall > complexity of the system and may only meet one need. I think the additional complexity would amount to adding a config option to the code that gets run when a disk is full that executes an arbitrary command, namely a user-space shell script that deletes the oldest automatically-generated snapshot. The "only one need" that it addresses is that now FreeBSD would come with a built-in recovery system. Did a "make installworld" but screwed something up and ended up with a non-bootable system? Pop in a recovery CD and revert to the "4 hours ago" snapshot, then reboot. Voila! It never happened. Accidentally deleted /etc/passwd? Retrieve the version from /.zfs/snapshot/weekly-2010-21/etc/passwd . Just realized that you deleted an important file 3 months ago and only keep 2 weeks worth of backups? No problem, as long as you haven't filled up your hard drive since then. -- Kirk Strauser From owner-freebsd-stable@FreeBSD.ORG Sun May 30 22:06:21 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9874B106564A for ; Sun, 30 May 2010 22:06:21 +0000 (UTC) (envelope-from kirk@strauser.com) Received: from kanga.honeypot.net (kanga.honeypot.net [IPv6:2001:470:a80a:1:21f:d0ff:fe22:b8a8]) by mx1.freebsd.org (Postfix) with ESMTP id 5B9A78FC16 for ; Sun, 30 May 2010 22:06:21 +0000 (UTC) Received: from kanga.honeypot.net (localhost [127.0.0.1]) by kanga.honeypot.net (Postfix) with ESMTP id E1EFC7BEBC; Sun, 30 May 2010 17:06:20 -0500 (CDT) X-Virus-Scanned: amavisd-new at honeypot.net Received: from kanga.honeypot.net ([127.0.0.1]) by kanga.honeypot.net (kanga.honeypot.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Pe9cQhxnJJR7; Sun, 30 May 2010 17:06:18 -0500 (CDT) Received: from pooh.honeypot.net (pooh.honeypot.net [IPv6:2001:470:a80a:1:20a:95ff:fed5:10f2]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by kanga.honeypot.net (Postfix) with ESMTPSA id AAFD57BEB2; Sun, 30 May 2010 17:06:18 -0500 (CDT) Message-Id: <93F986A6-DAEB-47B4-AB8C-5A095E61A7B7@strauser.com> From: Kirk Strauser To: Dan Nelson In-Reply-To: <20100530024240.GE8866@dan.emsphone.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 30 May 2010 17:06:18 -0500 References: <4C017419.9010909@strauser.com> <20100530024240.GE8866@dan.emsphone.com> X-Mailer: Apple Mail (2.936) Cc: FreeBSD-STABLE Mailing List Subject: Re: Make ZFS auto-destroy snapshots when the out of space? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 30 May 2010 22:06:21 -0000 On May 29, 2010, at 9:42 PM, Dan Nelson wrote: > If the kernel does the snapshot deleting itself, why not add a pool- > level > property that sets the amount of free space at which the deletion > starts? > That way you don't need the cleanup script. Alternatively, make the > org.freebsd:allowautodestroy property hold the trigger freespace > amount. > That way you can have monthly/daily/hourly snapshots but set it so the > hourly ones disappear first, then the dailies (by setting the destroy > trigger slightly higher for the ones you want to expire first). That'd definitely work. The idea was to keep as much as possible out of the kernel so that it wouldn't add additional complexity for people who don't use it (but it certainly wouldn't offend me any to find it in there :-) ). -- Kirk Strauser From owner-freebsd-stable@FreeBSD.ORG Sun May 30 22:16:28 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CE68E106566B for ; Sun, 30 May 2010 22:16:28 +0000 (UTC) (envelope-from kirk@strauser.com) Received: from kanga.honeypot.net (kanga.honeypot.net [IPv6:2001:470:a80a:1:21f:d0ff:fe22:b8a8]) by mx1.freebsd.org (Postfix) with ESMTP id 8D2508FC1A for ; Sun, 30 May 2010 22:16:28 +0000 (UTC) Received: from kanga.honeypot.net (localhost [127.0.0.1]) by kanga.honeypot.net (Postfix) with ESMTP id 252064503A; Sun, 30 May 2010 17:16:28 -0500 (CDT) X-Virus-Scanned: amavisd-new at honeypot.net Received: from kanga.honeypot.net ([127.0.0.1]) by kanga.honeypot.net (kanga.honeypot.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id MXZGRIt7hwYr; Sun, 30 May 2010 17:16:26 -0500 (CDT) Received: from pooh.honeypot.net (pooh.honeypot.net [IPv6:2001:470:a80a:1:20a:95ff:fed5:10f2]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by kanga.honeypot.net (Postfix) with ESMTPSA id 3D74045034; Sun, 30 May 2010 17:16:26 -0500 (CDT) Message-Id: From: Kirk Strauser To: Xin LI In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 30 May 2010 17:16:25 -0500 References: <4C017419.9010909@strauser.com> X-Mailer: Apple Mail (2.936) Cc: FreeBSD-STABLE Mailing List Subject: Re: Make ZFS auto-destroy snapshots when the out of space? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 30 May 2010 22:16:28 -0000 On May 30, 2010, at 12:27 AM, Xin LI wrote: > I think this sounds like a good idea but I think we may probably want > to explore a more general mechanism, e.g. a daemon that "listen"s > system events like file system full, etc. and execute some user > defined actions. I could definitely get on board with that, and I think such a mechanism would be generally useful even without my idea. I wouldn't mind having a mechanism to send me an IM whenever I need to respond to something urgently. > One thing that we want to avoid is that by making the "automatic > recycle" we would open a new race between system and user backup > programs, i.e. if you remove an intermediate snapshot, 'zfs send' may > fail at receiving side, if incremental send is being used. We would > need a way to "notify" that a 'zfs send' is underway. Well, two things about that: first, if I were implementing it in a vacuum without any input from anyone else, I'd make it simply delete the oldest snapshot. There's precedence in OS X's Time Machine, and that's probably what most people would want and expect anyway. Second, I'd treat those almost as "property" of the OS. While there's nothing magical about them, they're created (and subject to deletion) at the whim of the system, and you shouldn't be sending or receiving them or doing anything else that assumes their integrity. You could still create and destroy your own snapshots as needed, but the OS would manage these on its own. Again, this is how I would handle it in a vacuum if I didn't know or care how anyone else wanted to use it. Still, I think those might be reasonable assumptions. -- Kirk Strauser From owner-freebsd-stable@FreeBSD.ORG Sun May 30 22:54:14 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 29AEA1065670 for ; Sun, 30 May 2010 22:54:14 +0000 (UTC) (envelope-from kirk@strauser.com) Received: from kanga.honeypot.net (kanga.honeypot.net [IPv6:2001:470:a80a:1:21f:d0ff:fe22:b8a8]) by mx1.freebsd.org (Postfix) with ESMTP id B98B78FC13 for ; Sun, 30 May 2010 22:54:13 +0000 (UTC) Received: from kanga.honeypot.net (localhost [127.0.0.1]) by kanga.honeypot.net (Postfix) with ESMTP id A452B45663 for ; Sun, 30 May 2010 17:54:12 -0500 (CDT) X-Virus-Scanned: amavisd-new at honeypot.net Received: from kanga.honeypot.net ([127.0.0.1]) by kanga.honeypot.net (kanga.honeypot.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id KlG3oA4wjv6h for ; Sun, 30 May 2010 17:54:10 -0500 (CDT) Received: from pooh.honeypot.net (pooh.honeypot.net [IPv6:2001:470:a80a:1:20a:95ff:fed5:10f2]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by kanga.honeypot.net (Postfix) with ESMTPSA id 3E5974565C for ; Sun, 30 May 2010 17:54:09 -0500 (CDT) Message-Id: <96A9A271-9C20-400A-AB2D-360BD3787C40@strauser.com> From: Kirk Strauser To: FreeBSD-STABLE Mailing List In-Reply-To: <201005302009.o4UK9u9R002477@apollo.backplane.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 30 May 2010 17:54:09 -0500 References: <4C017419.9010909@strauser.com> <201005302009.o4UK9u9R002477@apollo.backplane.com> X-Mailer: Apple Mail (2.936) Subject: Re: Make ZFS auto-destroy snapshots when the out of space? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 30 May 2010 22:54:14 -0000 On May 30, 2010, at 3:09 PM, Matthew Dillon wrote: > It is actually a security issue to automatically destroy > snapshots based > on whether a filesystem is full, even automatically generated > snapshots. > Since one usually implements snapshots to perform a function you > wish > to rely on, such as to retain backups of historical data for > auditing > or other purposes, you do not want an attacker to be able to > indirectly > destroy snapshots simply by filling up the filesystem. > > Instead what you want to do is to treat both the automatic and > the manual > snapshots as an integrated part of the filesystem's operation. > Just as > we have to deal with a nominal non-snapshotted filesystem-full > condition > today we also want to treat a filesystem with multiple snapshots > in the > same vein. So, for example, you might administratively desire 60 > 1-day > snapshots plus 10 minute snapshots for the most recent 3 days to be > retained at all times. The automatic maintainance of the snapshots > would then administratively delete snapshots over 60 days old and > prune > to a coarser grain past 3 days. First, I agree wholeheartedly with everything you've said. But in the interest of keeping the low-level stuff as simple as possible, how about a compromise: a cronjob or periodic script that regularly marks snapshots as "expendable" based on user-configurable criteria. For example, you could say "snapshots_keep_hourly=72" and "snapshots_keep_monthly=6", and anything older than those would be marked as *eligible* for automatic deletion, but would not be *actually* destroyed unless necessary. Then you could meet both goals of clearing old data to make room for new content while establishing policies of how much you want to guarantee having on hand (to the extend that a filesystem snapshot is a guarantee). > The use of snapshots on modern filesystem capable of managing large > numbers of snapshots relatively pain-free, particularly on large > storage > systems and/or on modern multi-terrabyte HDs, requires a bit of a > change > in thinking. You have to stop thinking of the snapshots as > optional and > start thinking of them as mandatory. I'll grant you that. But first let's establish them as possible, even for people who don't want to actively monitor their drive space availability or actively, manually prune the old ones. Note: this is exactly what OS X's Time Machine does. If they can do it, and we have all the components in place to have something at least as nice ourselves, then I think we should go for it. > When snapshot availability is an assumed condition and not an > exceptional or special-case condition it opens up a whole new arena > in how filesystems can be managed, backed-up, audited, and used in > every-day work. Once your thinking processes change you'll never > go back to non-snapshotted or nontrivially-snapshotted filesystems. I couldn't agree more. I see it as programming with and without version control. Before you have reliable VC in your arsenal, changes are risky and difficult. What if you screw up? Will you remember everything that you need to revert to get back to a known-working state, or make periodic tarballs before you start on an experimental branch? Once you have VC, you're so... liberated. If you try something and it doesn't work out, it's no big deal - you just go back to the last good version and try again another day. Knowing that, you're much more likely to try those grand experiments because the price of being wrong is drastically reduced. To give a more pragmatic example, I wanted to try a KDE port from area51. I knew it was experimental, so I made a snapshot of /usr/local and /usr/ports, built the new version, and tested it. It wasn't fully working that day and I didn't have time to troubleshoot it, so I just rolled back to the snapshot I'd taken before starting. Voila! Back to a working system. > And you will certainly not want to allow a filesystem being > mistakenly > filled up to destroy your precious snapshots :-) Very true, but I don't mind if it destroys the ones I told it that I don't care about anymore. :-) -- Kirk Strauser From owner-freebsd-stable@FreeBSD.ORG Mon May 31 00:08:26 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 228CA106564A for ; Mon, 31 May 2010 00:08:25 +0000 (UTC) (envelope-from christof.schulze@gmx.com) Received: from mailout-eu.gmx.com (mailout-eu.gmx.com [213.165.64.42]) by mx1.freebsd.org (Postfix) with SMTP id 922698FC15 for ; Mon, 31 May 2010 00:08:24 +0000 (UTC) Received: (qmail invoked by alias); 31 May 2010 00:08:22 -0000 Received: from g228053210.adsl.alicedsl.de (EHLO klausdieter0815.dyndns.org) [92.228.53.210] by mail.gmx.com (mp-eu004) with SMTP; 31 May 2010 02:08:22 +0200 X-Authenticated: #56306756 X-Provags-ID: V01U2FsdGVkX1/AIL4OzV7AmP+LvdvVXGvmdWMjevUNUL2a3hlof4 FoaW6nMDwNIG/V Received: by myhost.mydomain.de (Postfix, from userid 1001) id A0D3A13132; Mon, 31 May 2010 02:08:22 +0200 (CEST) From: Christof Schulze To: freebsd-stable@freebsd.org Date: Mon, 31 May 2010 02:08:21 +0200 User-Agent: KMail/1.13.3 (FreeBSD/8.0-STABLE; KDE/4.4.3; amd64; ; ) References: <4C017419.9010909@strauser.com> <20100529234507.GD20695@mail.hs.ntnu.edu.tw> <4F444333-C839-4C2F-AA5D-1898192DDE93@strauser.com> In-Reply-To: <4F444333-C839-4C2F-AA5D-1898192DDE93@strauser.com> MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_23vAMpwjIYfQ7mv" Message-Id: <201005310208.22387.christof.schulze@gmx.com> X-Y-GMX-Trusted: 0 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: Make ZFS auto-destroy snapshots when the out of space? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 31 May 2010 00:08:26 -0000 --Boundary-00=_23vAMpwjIYfQ7mv Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Am Sonntag 30 Mai 2010 23:53:06 schrieb Kirk Strauser: > On May 29, 2010, at 6:45 PM, Denny Lin wrote: > > How about writing a shell script with this functionality? Get the > > available disk space using: > > $ zfs list -H -o avail tank > > > > And then compare the figures against a limit. Then delete the oldest > > snapshots when the limit is exceeded. > > That's certainly an option, and easy to implement in a shell script. > It just wouldn't work in the case where a bunch of data comes in > between runs of that script, and that's why I wanted something lower- > level. Hello, this is what I use to create daily zfs snapshots. It might provide a base for developing something more sophisticated Regards Christof -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments --Boundary-00=_23vAMpwjIYfQ7mv-- From owner-freebsd-stable@FreeBSD.ORG Mon May 31 00:34:49 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EFD7D106566B for ; Mon, 31 May 2010 00:34:49 +0000 (UTC) (envelope-from christof.schulze@gmx.com) Received: from mailout-eu.gmx.com (mailout-eu.gmx.com [213.165.64.42]) by mx1.freebsd.org (Postfix) with SMTP id 3ADCA8FC0A for ; Mon, 31 May 2010 00:34:49 +0000 (UTC) Received: (qmail invoked by alias); 31 May 2010 00:34:47 -0000 Received: from g228053210.adsl.alicedsl.de (EHLO klausdieter0815.dyndns.org) [92.228.53.210] by mail.gmx.com (mp-eu004) with SMTP; 31 May 2010 02:34:47 +0200 X-Authenticated: #56306756 X-Provags-ID: V01U2FsdGVkX189G2Fbcrs9IyTXZTobZYGDCoq39hEdI/qasC8Cli b2owVCVX3AO34o Received: by myhost.mydomain.de (Postfix, from userid 1001) id 8DFFE13137; Mon, 31 May 2010 02:34:47 +0200 (CEST) From: Christof Schulze To: freebsd-stable@freebsd.org Date: Mon, 31 May 2010 02:34:46 +0200 User-Agent: KMail/1.13.3 (FreeBSD/8.0-STABLE; KDE/4.4.3; amd64; ; ) References: <4C017419.9010909@strauser.com> <4F444333-C839-4C2F-AA5D-1898192DDE93@strauser.com> <201005310208.22387.christof.schulze@gmx.com> In-Reply-To: <201005310208.22387.christof.schulze@gmx.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-6" Content-Transfer-Encoding: 7bit Message-Id: <201005310234.47363.christof.schulze@gmx.com> X-Y-GMX-Trusted: 0 Subject: Re: Make ZFS auto-destroy snapshots when the out of space? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 31 May 2010 00:34:50 -0000 still struggling with the attachment remover. So here is the script: http://paste.pocoo.org/show/220207/ -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments From owner-freebsd-stable@FreeBSD.ORG Mon May 31 00:40:05 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0E595106566B for ; Mon, 31 May 2010 00:40:05 +0000 (UTC) (envelope-from kirk@strauser.com) Received: from kanga.honeypot.net (kanga.honeypot.net [IPv6:2001:470:a80a:1:21f:d0ff:fe22:b8a8]) by mx1.freebsd.org (Postfix) with ESMTP id BB5C58FC08 for ; Mon, 31 May 2010 00:40:04 +0000 (UTC) Received: from kanga.honeypot.net (localhost [127.0.0.1]) by kanga.honeypot.net (Postfix) with ESMTP id 91BF87C5D4; Sun, 30 May 2010 19:40:03 -0500 (CDT) X-Virus-Scanned: amavisd-new at honeypot.net Received: from kanga.honeypot.net ([127.0.0.1]) by kanga.honeypot.net (kanga.honeypot.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id rS1UrRTxwcfk; Sun, 30 May 2010 19:40:01 -0500 (CDT) Received: from pooh.honeypot.net (pooh.honeypot.net [IPv6:2001:470:a80a:1:20a:95ff:fed5:10f2]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by kanga.honeypot.net (Postfix) with ESMTPSA id 04CCB7C5CF; Sun, 30 May 2010 19:40:01 -0500 (CDT) Message-Id: <613D3C80-85F6-4A52-8C33-7F5AF18A3A2E@strauser.com> From: Kirk Strauser To: Christof Schulze In-Reply-To: <201005310234.47363.christof.schulze@gmx.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 30 May 2010 19:40:00 -0500 References: <4C017419.9010909@strauser.com> <4F444333-C839-4C2F-AA5D-1898192DDE93@strauser.com> <201005310208.22387.christof.schulze@gmx.com> <201005310234.47363.christof.schulze@gmx.com> X-Mailer: Apple Mail (2.936) Cc: freebsd-stable@freebsd.org Subject: Re: Make ZFS auto-destroy snapshots when the out of space? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 31 May 2010 00:40:05 -0000 On May 30, 2010, at 7:34 PM, Christof Schulze wrote: > still struggling with the attachment remover. So here is the script: > > http://paste.pocoo.org/show/220207/ That's pretty similar in concept to the scripts I found and am using, but with the difference that those scripts use "zfs snapshot -r" to take a recursive, atomic snapshot of all filesystems in the configured pools. I wrote a separate script to prune all the unwanted filesystems (/tmp, and so on) regularly: #!/bin/sh # If there is a global system configuration file, suck it in. # if [ -r /etc/defaults/periodic.conf ] then . /etc/defaults/periodic.conf source_periodic_confs fi filesystems=$hourly_zfs_snapshot_prune_filesystems case "$hourly_zfs_snapshot_prune_enable" in [Yy][Ee][Ss]) if [ -z "$filesystems" ]; then echo "Hourly snapshot pruning is enabled but not configured." exit 2 fi for filesystem in $filesystems ; do zfs list -H -o name -t snapshot | grep -E "^ $filesystem@(hourly|daily|weekly|monthly)" | xargs -n1 zfs destroy done ;; *) ;; esac -- Kirk Strauser From owner-freebsd-stable@FreeBSD.ORG Mon May 31 00:40:29 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 666AD10656C9 for ; Mon, 31 May 2010 00:40:29 +0000 (UTC) (envelope-from dmagda@ee.ryerson.ca) Received: from eccles.ee.ryerson.ca (ee.ryerson.ca [141.117.1.2]) by mx1.freebsd.org (Postfix) with ESMTP id 226888FC21 for ; Mon, 31 May 2010 00:40:28 +0000 (UTC) Received: from [192.168.1.103] (bas1-toronto09-1279534184.dsl.bell.ca [76.68.36.104]) (authenticated bits=0) by eccles.ee.ryerson.ca (8.14.4/8.14.4) with ESMTP id o4V0eWaZ013441 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 30 May 2010 20:40:33 -0400 (EDT) (envelope-from dmagda@ee.ryerson.ca) Message-Id: <04B42F88-2E60-4B29-BEF9-3AE3AE251CB3@ee.ryerson.ca> From: David Magda To: Kirk Strauser In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 30 May 2010 20:40:19 -0400 References: <4C017419.9010909@strauser.com> X-Mailer: Apple Mail (2.936) Cc: FreeBSD-STABLE Mailing List Subject: Re: Make ZFS auto-destroy snapshots when the out of space? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 31 May 2010 00:40:29 -0000 On May 30, 2010, at 18:03, Kirk Strauser wrote: > The "only one need" that it addresses is that now FreeBSD would come > with a built-in recovery system. Did a "make installworld" but > screwed something up and ended up with a non-bootable system? Pop in > a recovery CD and revert to the "4 hours ago" snapshot, then reboot. > Voila! It never happened. Accidentally deleted /etc/passwd? Retrieve > the version from /.zfs/snapshot/weekly-2010-21/etc/passwd . Just > realized that you deleted an important file 3 months ago and only > keep 2 weeks worth of backups? No problem, as long as you haven't > filled up your hard drive since then. All scriptable. For the case of "make installworld", a make.conf variable can be created to run a "zfs snapshot" before any kind of 'make install'; this could be for both Ports and the base system. Portmanager and/or portupgrade could also be expanded to optionally do this. (Open)Solaris already has this with the Live Upgrade and boot environment idea if you want a comparison: http://docs.sun.com/app/docs/doc/820-5238/ggavn http://docs.sun.com/app/docs/doc/819-2240/bootadm-1m http://docs.sun.com/app/docs/doc/819-2379/gglaj From owner-freebsd-stable@FreeBSD.ORG Mon May 31 00:48:33 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 97763106564A for ; Mon, 31 May 2010 00:48:33 +0000 (UTC) (envelope-from dmagda@ee.ryerson.ca) Received: from eccles.ee.ryerson.ca (eccles.ee.ryerson.ca [141.117.1.2]) by mx1.freebsd.org (Postfix) with ESMTP id 559948FC19 for ; Mon, 31 May 2010 00:48:32 +0000 (UTC) Received: from [192.168.1.103] (bas1-toronto09-1279534184.dsl.bell.ca [76.68.36.104]) (authenticated bits=0) by eccles.ee.ryerson.ca (8.14.4/8.14.4) with ESMTP id o4V0Xqju013232 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 30 May 2010 20:33:55 -0400 (EDT) (envelope-from dmagda@ee.ryerson.ca) Message-Id: <4632C12D-2B1E-4073-B2C9-E9D15C212EF1@ee.ryerson.ca> From: David Magda To: Kirk Strauser In-Reply-To: <4C017419.9010909@strauser.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 30 May 2010 20:33:40 -0400 References: <4C017419.9010909@strauser.com> X-Mailer: Apple Mail (2.936) Cc: FreeBSD-STABLE Mailing List Subject: Re: Make ZFS auto-destroy snapshots when the out of space? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 31 May 2010 00:48:33 -0000 On May 29, 2010, at 16:07, Kirk Strauser wrote: > I'd propose standardizing on an attribute like > org.freebsd:allowautodestroy. Modify ZFS's disk full behavior [...] > Also run a daily periodic script to ensure that the free space stays > below a configurable threshold each day so that ZFS isn't constantly > butting up against completely full drives. Why not simply have a script that runs and checks for pool usage and then deletes snapshots with that attribute if necessary? Why do you need to have have it built into ZFS? > What do you think? It seems like this should be pretty easy to > implement without requiring any upstream changes or new FreeBSD-only > data structures. The whole thing could possibly be implemented in > userspace, but I don't know that ZFS has any exception handling > callbacks that would make it easy. IMHO this shouldn't be built into the file system. You have one script to automatically generate snapshots, and another to monitor usage and delete old ones. This idea was talked about on zfs-discuss in 2006: http://mail.opensolaris.org/pipermail/zfs-discuss/2006-May/thread.html#2266 Good summary in this post: http://mail.opensolaris.org/pipermail/zfs-discuss/2006-May/002313.html Generally I don't think this is the "Unix Way". I don't want my kernel doing stuff behind my back. If I want snapshots I'll create them (scripted or manual); if I want to get rid of them for whatever reason, I'll destroy them (scripted or manual). Either of these behaviours can then be controlled by an rc.conf(5) variable perhaps. There's already an useful creation tool for OpenSolaris: http://src.opensolaris.org/source/xref/jds/zfs-snapshot/ There's also an auto-scrub script: http://blogs.sun.com/constantin/entry/new_opensolaris_zfs_auto_scrub From owner-freebsd-stable@FreeBSD.ORG Mon May 31 00:55:46 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 26619106566C for ; Mon, 31 May 2010 00:55:46 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from noop.in-addr.com (mail.in-addr.com [IPv6:2001:470:8:162::1]) by mx1.freebsd.org (Postfix) with ESMTP id F05C98FC12 for ; Mon, 31 May 2010 00:55:45 +0000 (UTC) Received: from gjp by noop.in-addr.com with local (Exim 4.54 (FreeBSD)) id 1OItI8-0005FV-13; Sun, 30 May 2010 20:55:44 -0400 Date: Sun, 30 May 2010 20:55:43 -0400 From: Gary Palmer To: David Magda Message-ID: <20100531005543.GA77116@in-addr.com> References: <4C017419.9010909@strauser.com> <4632C12D-2B1E-4073-B2C9-E9D15C212EF1@ee.ryerson.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4632C12D-2B1E-4073-B2C9-E9D15C212EF1@ee.ryerson.ca> Cc: FreeBSD-STABLE Mailing List Subject: Re: Make ZFS auto-destroy snapshots when the out of space? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 31 May 2010 00:55:46 -0000 On Sun, May 30, 2010 at 08:33:40PM -0400, David Magda wrote: > On May 29, 2010, at 16:07, Kirk Strauser wrote: > > >I'd propose standardizing on an attribute like > >org.freebsd:allowautodestroy. Modify ZFS's disk full behavior [...] > >Also run a daily periodic script to ensure that the free space stays > >below a configurable threshold each day so that ZFS isn't constantly > >butting up against completely full drives. > > > Why not simply have a script that runs and checks for pool usage and > then deletes snapshots with that attribute if necessary? Why do you > need to have have it built into ZFS? Suggestion: zfs can have settings that trigger an event to be delivered to devd when a filesystem hits a certain percentage full (or under a certain percentage free space left). That way you can have the event triggered at the filesystem level, which I believe is the correct thing to do (so you're not polling), and also delivers the level of control you want. Regards, Gary From owner-freebsd-stable@FreeBSD.ORG Mon May 31 01:15:05 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ECA821065670 for ; Mon, 31 May 2010 01:15:05 +0000 (UTC) (envelope-from christof.schulze@gmx.com) Received: from mailout-eu.gmx.com (mailout-eu.gmx.com [213.165.64.42]) by mx1.freebsd.org (Postfix) with SMTP id 537DF8FC12 for ; Mon, 31 May 2010 01:15:05 +0000 (UTC) Received: (qmail invoked by alias); 31 May 2010 01:15:03 -0000 Received: from g228053210.adsl.alicedsl.de (EHLO klausdieter0815.dyndns.org) [92.228.53.210] by mail.gmx.com (mp-eu001) with SMTP; 31 May 2010 03:15:03 +0200 X-Authenticated: #56306756 X-Provags-ID: V01U2FsdGVkX1/iXatToqfixSthHgHnqxOruAxPzbELtqkA/z5gGN 0KWLT7soTL1YP6 Received: by myhost.mydomain.de (Postfix, from userid 1001) id A07FC1313E; Mon, 31 May 2010 03:15:03 +0200 (CEST) From: Christof Schulze To: freebsd-stable@freebsd.org Date: Mon, 31 May 2010 03:15:02 +0200 User-Agent: KMail/1.13.3 (FreeBSD/8.0-STABLE; KDE/4.4.3; amd64; ; ) References: <4C017419.9010909@strauser.com> <201005310234.47363.christof.schulze@gmx.com> <613D3C80-85F6-4A52-8C33-7F5AF18A3A2E@strauser.com> In-Reply-To: <613D3C80-85F6-4A52-8C33-7F5AF18A3A2E@strauser.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201005310315.03255.christof.schulze@gmx.com> X-Y-GMX-Trusted: 0 Subject: Re: Make ZFS auto-destroy snapshots when the out of space? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 31 May 2010 01:15:06 -0000 Am Montag 31 Mai 2010 02:40:00 schrieben Sie: > On May 30, 2010, at 7:34 PM, Christof Schulze wrote: > > still struggling with the attachment remover. So here is the script: > > > > http://paste.pocoo.org/show/220207/ > > That's pretty similar in concept to the scripts I found and am using, > but with the difference that those scripts use "zfs snapshot -r" to > take a recursive, atomic snapshot of all filesystems in the configured > pools. I wrote a separate script to prune all the unwanted filesystems > (/tmp, and so on) regularly: might be useful to have this a second script. During the last few minutes I put in the size-based removal: http://paste.pocoo.org/show/220213/ using -r would require to remove the unwanted snapshots lateron but it might be worth it because of having it atomic. Regards Christof > > #!/bin/sh > > # If there is a global system configuration file, suck it in. > # > if [ -r /etc/defaults/periodic.conf ] > then > . /etc/defaults/periodic.conf > source_periodic_confs > fi > > filesystems=$hourly_zfs_snapshot_prune_filesystems > > case "$hourly_zfs_snapshot_prune_enable" in > [Yy][Ee][Ss]) > if [ -z "$filesystems" ]; then > echo "Hourly snapshot pruning is enabled but not > configured." > exit 2 > fi > for filesystem in $filesystems ; do > zfs list -H -o name -t snapshot | grep -E "^ > $filesystem@(hourly|daily|weekly|monthly)" | xargs -n1 zfs destroy > done > ;; > *) > ;; > esac -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments From owner-freebsd-stable@FreeBSD.ORG Mon May 31 01:57:01 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DA37F106564A for ; Mon, 31 May 2010 01:57:01 +0000 (UTC) (envelope-from kirk@strauser.com) Received: from kanga.honeypot.net (kanga.honeypot.net [IPv6:2001:470:a80a:1:21f:d0ff:fe22:b8a8]) by mx1.freebsd.org (Postfix) with ESMTP id 9820A8FC18 for ; Mon, 31 May 2010 01:57:01 +0000 (UTC) Received: from kanga.honeypot.net (localhost [127.0.0.1]) by kanga.honeypot.net (Postfix) with ESMTP id 39BAF7CEAC; Sun, 30 May 2010 20:57:00 -0500 (CDT) X-Virus-Scanned: amavisd-new at honeypot.net Received: from kanga.honeypot.net ([127.0.0.1]) by kanga.honeypot.net (kanga.honeypot.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id xK5QZQQ+90zZ; Sun, 30 May 2010 20:56:58 -0500 (CDT) Received: from pooh.honeypot.net (pooh.honeypot.net [IPv6:2001:470:a80a:1:20a:95ff:fed5:10f2]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by kanga.honeypot.net (Postfix) with ESMTPSA id 486387CEA6; Sun, 30 May 2010 20:56:57 -0500 (CDT) Message-Id: <38064784-18E3-43CA-8561-AEFC6CF64024@strauser.com> From: Kirk Strauser To: David Magda In-Reply-To: <04B42F88-2E60-4B29-BEF9-3AE3AE251CB3@ee.ryerson.ca> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 30 May 2010 20:56:57 -0500 References: <4C017419.9010909@strauser.com> <04B42F88-2E60-4B29-BEF9-3AE3AE251CB3@ee.ryerson.ca> X-Mailer: Apple Mail (2.936) Cc: FreeBSD-STABLE Mailing List Subject: Re: Make ZFS auto-destroy snapshots when the out of space? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 31 May 2010 01:57:01 -0000 On May 30, 2010, at 7:40 PM, David Magda wrote: > All scriptable. > > For the case of "make installworld", a make.conf variable can be > created to run a "zfs snapshot" before any kind of 'make install'; > this could be for both Ports and the base system. I understand that it comes down to a philosophical difference, but I dislike the idea of every subsystem implementing similar logic instead of having it done once (and well) as a system-wide feature. -- Kirk Strauser From owner-freebsd-stable@FreeBSD.ORG Mon May 31 02:18:01 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F08591065673 for ; Mon, 31 May 2010 02:18:00 +0000 (UTC) (envelope-from kirk@strauser.com) Received: from kanga.honeypot.net (kanga.honeypot.net [IPv6:2001:470:a80a:1:21f:d0ff:fe22:b8a8]) by mx1.freebsd.org (Postfix) with ESMTP id 8D0C48FC08 for ; Mon, 31 May 2010 02:18:00 +0000 (UTC) Received: from kanga.honeypot.net (localhost [127.0.0.1]) by kanga.honeypot.net (Postfix) with ESMTP id 228737C185; Sun, 30 May 2010 21:18:00 -0500 (CDT) X-Virus-Scanned: amavisd-new at honeypot.net Received: from kanga.honeypot.net ([127.0.0.1]) by kanga.honeypot.net (kanga.honeypot.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id UMMo2IRqVOcE; Sun, 30 May 2010 21:17:57 -0500 (CDT) Received: from pooh.honeypot.net (pooh.honeypot.net [IPv6:2001:470:a80a:1:20a:95ff:fed5:10f2]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by kanga.honeypot.net (Postfix) with ESMTPSA id CBE447C17E; Sun, 30 May 2010 21:17:56 -0500 (CDT) Message-Id: From: Kirk Strauser To: David Magda In-Reply-To: <4632C12D-2B1E-4073-B2C9-E9D15C212EF1@ee.ryerson.ca> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 30 May 2010 21:17:56 -0500 References: <4C017419.9010909@strauser.com> <4632C12D-2B1E-4073-B2C9-E9D15C212EF1@ee.ryerson.ca> X-Mailer: Apple Mail (2.936) Cc: FreeBSD-STABLE Mailing List Subject: Re: Make ZFS auto-destroy snapshots when the out of space? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 31 May 2010 02:18:01 -0000 On May 30, 2010, at 7:33 PM, David Magda wrote: > Why not simply have a script that runs and checks for pool usage and > then deletes snapshots with that attribute if necessary? Why do you > need to have have it built into ZFS? That's certainly possible and I suspect most people here could knock that out in about 20 minutes. The problem is that you get into all kinds of race conditions and manual bookkeeping. For instance, what happens if a disk-full condition occurs 2 minutes before the cron job would have run that would've averted it? At what level do you trigger deletions that would both 1) provide enough of a safety margin that disk-fulls are unlikely, but 2) allow the snapshots to take advantage of as much storage as possible? > IMHO this shouldn't be built into the file system. You have one > script to automatically generate snapshots, and another to monitor > usage and delete old ones. I'm not opposed to that approach at all, with the exception that I'd like for the deletion script to be triggerable from the filesystem. And as I said in another post, I'd like that as a generic cross- filesystem feature. Maybe you'd like a UFS-based /tmp/log directory that a certain daemon fills with rotating logfiles, and you'd like a script to automatically delete the oldest one whenever the filesystem fills. Or maybe it'd be nice to get an email when /var is over 90% full? I can think of a lot of uses for that mechanism other than the specific case of destroying ZFS snapshots. > Good summary in this post: > > http://mail.opensolaris.org/pipermail/zfs-discuss/2006-May/ > 002313.html I disagree with the cons of the summary. It's made to sound like ZFS would be responsible for making tough decisions about what to keep and discard, when that could really be simplified to deleting the snapshot with the lowest integer value of a certain attribute and re-trying failed writes until either the write succeeds or there are no more filesystems to delete. Then have a regular cron job - probably even the one that creates the snapshots in the first place - that assigns priorities appropriates. It would require a small amount of kernel could, but it could be very simple code with no decision-making responsibilities. > Generally I don't think this is the "Unix Way". I don't want my > kernel doing stuff behind my back. But we have all sorts of daemons that do stuff behind our back. I have a nightly Amanda daemon that decides what and how much to back up and when to overwrite old backups. The difference, as I see it, is that in the ZFS case the kernel would have a very small amount of extra work to do. That kernel code would eliminate the need for a lot of potentially-flakey userspace code. > There's already an useful creation tool for OpenSolaris: > > http://src.opensolaris.org/source/xref/jds/zfs-snapshot/ That's actually the easy part. From the scripts I downloaded at the link in the original post, I have that running in production on my system today. > There's also an auto-scrub script: > > http://blogs.sun.com/constantin/entry/new_opensolaris_zfs_auto_scrub > That just scrubs the pools, ie verifies checksums and data consistency. -- Kirk Strauser From owner-freebsd-stable@FreeBSD.ORG Mon May 31 02:27:24 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 59D141065670 for ; Mon, 31 May 2010 02:27:24 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 14FD88FC17 for ; Mon, 31 May 2010 02:27:23 +0000 (UTC) Received: by iwn5 with SMTP id 5so455906iwn.13 for ; Sun, 30 May 2010 19:27:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=MaZ6++HpfZh6CMAMX5lCwS6AOcX2uk+RBS4P0Rx0lHI=; b=xFSDyTgM4hsMsPhCrnUW6YNY8sm99DRtxyk0uwLwLU7+67m1yutmFGIqDk/QFqbCuH P83f9Lj99cQ07OsZapS1mrowMMLkshbkAoVpqWfkVF5PBzF0e5eUHsiy7B7Vy925TbSs uY/cx7yp0Oog1sNIfA0Vm16TjP1qwNzmHtJr0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=oHIT/Q+vx50zJe6X3eZJLQA+UBNrhDR2IRKkdhrjIMmwo3CvZClkcXUxlZ3a/A9Now GBHcTTpBIohK/oZihu15uvi3DDO3xrZ9ljbgNwIuAgAVNcqlBtlJhMM8UjjKqCVPbJR5 HGEcd3yzyG2JZaM0vv63BRIVW3fiqUujNAHsI= Received: by 10.231.157.200 with SMTP id c8mr4925760ibx.53.1275272843386; Sun, 30 May 2010 19:27:23 -0700 (PDT) Received: from centel.dataix.local (adsl-99-19-40-41.dsl.klmzmi.sbcglobal.net [99.19.40.41]) by mx.google.com with ESMTPS id d9sm23930018ibl.10.2010.05.30.19.27.21 (version=SSLv3 cipher=RC4-MD5); Sun, 30 May 2010 19:27:22 -0700 (PDT) Sender: "J. Hellenthal" Message-ID: <4C031E88.9060205@dataix.net> Date: Sun, 30 May 2010 22:27:20 -0400 From: jhell User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.9) Gecko/20100515 Thunderbird MIME-Version: 1.0 To: Kirk Strauser References: <4C017419.9010909@strauser.com> <20100530024240.GE8866@dan.emsphone.com> <93F986A6-DAEB-47B4-AB8C-5A095E61A7B7@strauser.com> In-Reply-To: <93F986A6-DAEB-47B4-AB8C-5A095E61A7B7@strauser.com> X-Enigmail-Version: 1.0.1 OpenPGP: id=89D8547E Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD-STABLE Mailing List , Dan Nelson Subject: Re: Make ZFS auto-destroy snapshots when the out of space? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 31 May 2010 02:27:24 -0000 On 05/30/2010 18:06, Kirk Strauser wrote: > On May 29, 2010, at 9:42 PM, Dan Nelson wrote: > >> If the kernel does the snapshot deleting itself, why not add a pool-level >> property that sets the amount of free space at which the deletion starts? >> That way you don't need the cleanup script. Alternatively, make the >> org.freebsd:allowautodestroy property hold the trigger freespace amount. >> That way you can have monthly/daily/hourly snapshots but set it so the >> hourly ones disappear first, then the dailies (by setting the destroy >> trigger slightly higher for the ones you want to expire first). > > > That'd definitely work. The idea was to keep as much as possible out of > the kernel so that it wouldn't add additional complexity for people who > don't use it (but it certainly wouldn't offend me any to find it in > there :-) ). I think this would probably be best handled by the script that is creating the snapshots. Though this is a nice feature how well would it be received upstream and in what period of time would we have to wait while maintaining are down-level patches. I would propose looking at the creation time of the snapshots while in creation mode and parsing for a time that is older than a use configurable variable so the script can take proper action when destroying snapshots before it tries to create a new one and look at a value comprised of either the quota property or a attribute like the previous one stated. I strongly urge against creating a attribute that the script would look for due to the reason it would take more involvement with the script to be specific to FreeBSD where as now it should be OS independent. # This works good enough to compare with date(1) "+%s" zfs get -o name,value creation | grep @ # This works for seeing exactly how much a snapshot is using zfs get -o name,value used |grep @ Between the above two examples a threshold can be achieved at which older data can expire faster or slower depending on your settings and provide an upper tolerance for space usage. Of course this can be refined and there is a whole lot that is left to be scripted around the above commands. Regards, .02 -- jhell From owner-freebsd-stable@FreeBSD.ORG Mon May 31 02:36:07 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 79F5F1065673 for ; Mon, 31 May 2010 02:36:07 +0000 (UTC) (envelope-from dmagda@ee.ryerson.ca) Received: from eccles.ee.ryerson.ca (eccles.ee.ryerson.ca [141.117.1.2]) by mx1.freebsd.org (Postfix) with ESMTP id 36EDF8FC15 for ; Mon, 31 May 2010 02:36:06 +0000 (UTC) Received: from [192.168.1.103] (bas1-toronto09-1279534184.dsl.bell.ca [76.68.36.104]) (authenticated bits=0) by eccles.ee.ryerson.ca (8.14.4/8.14.4) with ESMTP id o4V2aAfH018156 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 30 May 2010 22:36:11 -0400 (EDT) (envelope-from dmagda@ee.ryerson.ca) Message-Id: <19664824-1B23-4E5F-BC12-BB4D59A9C8AA@ee.ryerson.ca> From: David Magda To: Kirk Strauser In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 30 May 2010 22:35:59 -0400 References: <4C017419.9010909@strauser.com> <4632C12D-2B1E-4073-B2C9-E9D15C212EF1@ee.ryerson.ca> X-Mailer: Apple Mail (2.936) Cc: FreeBSD-STABLE Mailing List Subject: Re: Make ZFS auto-destroy snapshots when the out of space? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 31 May 2010 02:36:07 -0000 On May 30, 2010, at 22:17, Kirk Strauser wrote: > For instance, what happens if a disk-full condition occurs 2 minutes > before the cron job would have run that would've averted it? At what > level do you trigger deletions that would both 1) provide enough of > a safety margin that disk-fulls are unlikely, but 2) allow the > snapshots to take advantage of as much storage as possible? What happens now when your UFS file system gets full? :) The situation is no worse than that in the case of a pool filling up, regardless of whether it's because of an abundance of snapshots or simply lots of "regular" user data. > But we have all sorts of daemons that do stuff behind our back. Yes, but they're daemons, not kernel code. As a general rule I like to be able to do a ps(1) on any one of my systems and be able to describe what every single PID does. If it's Amanda, I know what its purpose is; if it would be something called auto-snap(8) or auto-scrub(8) or auto-snap-clean(8) then I'd have to learn what those are. An event framework would certainly be helpful in a general sense (Linux has event(3) AFAIK), and that could certainly be useful for purging snapshots during resource constrained situations. But even if we don't have it, I doubt a fork(2) from cron(8) and a statfs(2) would be onerous on a system. :) > That just scrubs the pools, ie verifies checksums and data > consistency. Yes, I know, it was the general principle I was going after: if you want something periodic to be checked, you should run it from cron/SMF/ launchd/etc. From owner-freebsd-stable@FreeBSD.ORG Mon May 31 02:42:48 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 77E241065670 for ; Mon, 31 May 2010 02:42:48 +0000 (UTC) (envelope-from dave@jetcafe.org) Received: from hugeraid.jetcafe.org (hugeraid.jetcafe.org [205.147.26.109]) by mx1.freebsd.org (Postfix) with ESMTP id 546898FC12 for ; Mon, 31 May 2010 02:42:47 +0000 (UTC) Received: from hugeraid.jetcafe.org (localhost [127.0.0.1]) by hugeraid.jetcafe.org (8.13.8/8.13.8) with ESMTP id o4V2glZX057087; Sun, 30 May 2010 19:42:47 -0700 (PDT) Message-Id: <201005310242.o4V2glZX057087@hugeraid.jetcafe.org> X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.0.4 To: Garrett Cooper In-reply-to: References: <201005272348.o4RNmgWh014243@hugeraid.jetcafe.org> <20100528043006.GA18560@lava.net> <201005281757.o4SHvTwq020905@hugeraid.jetcafe.org> <20100528191828.GA83371@icarus.home.lan> <201005281926.o4SJQCW3041849@hugeraid.jetcafe.org> <20100528215837.GA86689@icarus.home.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 30 May 2010 19:42:47 -0700 From: Dave Hayes Cc: freebsd-stable@freebsd.org, Clifton Royston , Jeremy Chadwick Subject: Re: Locking a file backed mdconfig into memory X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 31 May 2010 02:42:48 -0000 Garrett Cooper writes: > This is how I do it in my quickie loader.rc: > include /boot/loader.4th > set vfs.root.mountfrom="ufs:/dev/md0" > load /kernel > load -t mfs_root /mfsroot > start I used to do exactly this back at FreeBSD 4.11 to boot off a cdrom. Nice to know it still works this way. Jeremy Chadwick writes: > However, what I'm having trouble understanding is what exactly > preload_search_info() looks for and how all this actually connects > and works. It appears to me that there are specific drivers located in > src/sys/dev that are KLD-supported and others which are expected to be > included in the kernel statically. Maybe this confusion explains why /dev/md0c is giving me random crashes at the moment? Of course, another theory might be the size of my initial ramdisk (300Mb). Would there any known bug where booting off a large ramdisk causes unreadable panics to flash past the console too rapidly to view? -- Dave Hayes - Consultant - Altadena CA, USA - dave@jetcafe.org >>> The opinions expressed above are entirely my own <<< By and large, language is a tool for concealing the truth. -George Carlin From owner-freebsd-stable@FreeBSD.ORG Mon May 31 03:11:05 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E5660106566B for ; Mon, 31 May 2010 03:11:05 +0000 (UTC) (envelope-from peter@simons-rock.edu) Received: from hedwig.simons-rock.edu (hedwig.simons-rock.edu [208.81.88.14]) by mx1.freebsd.org (Postfix) with ESMTP id A62EA8FC0A for ; Mon, 31 May 2010 03:11:05 +0000 (UTC) Received: from cesium.hyperfine.info (c2.8d.5646.static.theplanet.com [70.86.141.194]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hedwig.simons-rock.edu (Postfix) with ESMTP id 701EC2BB341; Sun, 30 May 2010 23:11:04 -0400 (EDT) Date: Sun, 30 May 2010 23:11:02 -0400 From: "Peter C. Lai" To: Dave Hayes Message-ID: <20100531031102.GD63749@cesium.hyperfine.info> References: <201005272348.o4RNmgWh014243@hugeraid.jetcafe.org> <20100528043006.GA18560@lava.net> <201005281757.o4SHvTwq020905@hugeraid.jetcafe.org> <20100528191828.GA83371@icarus.home.lan> <201005281926.o4SJQCW3041849@hugeraid.jetcafe.org> <20100528215837.GA86689@icarus.home.lan> <201005310242.o4V2glZX057087@hugeraid.jetcafe.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201005310242.o4V2glZX057087@hugeraid.jetcafe.org> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: Garrett Cooper , freebsd-stable@freebsd.org, Clifton Royston , Jeremy Chadwick Subject: Re: Locking a file backed mdconfig into memory X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 31 May 2010 03:11:06 -0000 On 2010-05-30 07:42:47PM -0700, Dave Hayes wrote: > Garrett Cooper writes: > > This is how I do it in my quickie loader.rc: > > include /boot/loader.4th > > set vfs.root.mountfrom="ufs:/dev/md0" > > load /kernel > > load -t mfs_root /mfsroot > > start > > I used to do exactly this back at FreeBSD 4.11 to boot off a cdrom. > Nice to know it still works this way. > > Jeremy Chadwick writes: > > However, what I'm having trouble understanding is what exactly > > preload_search_info() looks for and how all this actually connects > > and works. It appears to me that there are specific drivers located in > > src/sys/dev that are KLD-supported and others which are expected to be > > included in the kernel statically. > > Maybe this confusion explains why /dev/md0c is giving me random crashes > at the moment? > > Of course, another theory might be the size of my initial ramdisk > (300Mb). Would there any known bug where booting off a large ramdisk > causes unreadable panics to flash past the console too rapidly to view? Run memtest86 on the first 300mb of ram lately? Does your ramdisk crash at any size? -- =========================================================== Peter C. Lai | Bard College at Simon's Rock Systems Administrator | 84 Alford Rd. Information Technology Svcs. | Gt. Barrington, MA 01230 USA peter AT simons-rock.edu | (413) 528-7428 =========================================================== From owner-freebsd-stable@FreeBSD.ORG Mon May 31 04:18:44 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E9F4F106566B for ; Mon, 31 May 2010 04:18:44 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta15.emeryville.ca.mail.comcast.net (qmta15.emeryville.ca.mail.comcast.net [76.96.27.228]) by mx1.freebsd.org (Postfix) with ESMTP id C54FF8FC16 for ; Mon, 31 May 2010 04:18:44 +0000 (UTC) Received: from omta18.emeryville.ca.mail.comcast.net ([76.96.30.74]) by qmta15.emeryville.ca.mail.comcast.net with comcast id Q3xD1e0011bwxycAF4JkDF; Mon, 31 May 2010 04:18:44 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta18.emeryville.ca.mail.comcast.net with comcast id Q4Jj1e00D3S48mS8e4JjRi; Mon, 31 May 2010 04:18:44 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 99B7A9B418; Sun, 30 May 2010 21:18:43 -0700 (PDT) Date: Sun, 30 May 2010 21:18:43 -0700 From: Jeremy Chadwick To: Dave Hayes Message-ID: <20100531041843.GA66732@icarus.home.lan> References: <201005272348.o4RNmgWh014243@hugeraid.jetcafe.org> <20100528043006.GA18560@lava.net> <201005281757.o4SHvTwq020905@hugeraid.jetcafe.org> <20100528191828.GA83371@icarus.home.lan> <201005281926.o4SJQCW3041849@hugeraid.jetcafe.org> <20100528215837.GA86689@icarus.home.lan> <201005310242.o4V2glZX057087@hugeraid.jetcafe.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201005310242.o4V2glZX057087@hugeraid.jetcafe.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Garrett Cooper , freebsd-stable@freebsd.org, Clifton Royston Subject: Re: Locking a file backed mdconfig into memory X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 31 May 2010 04:18:45 -0000 On Sun, May 30, 2010 at 07:42:47PM -0700, Dave Hayes wrote: > Garrett Cooper writes: > > This is how I do it in my quickie loader.rc: > > include /boot/loader.4th > > set vfs.root.mountfrom="ufs:/dev/md0" > > load /kernel > > load -t mfs_root /mfsroot > > start > > I used to do exactly this back at FreeBSD 4.11 to boot off a cdrom. > Nice to know it still works this way. > > Jeremy Chadwick writes: > > However, what I'm having trouble understanding is what exactly > > preload_search_info() looks for and how all this actually connects > > and works. It appears to me that there are specific drivers located in > > src/sys/dev that are KLD-supported and others which are expected to be > > included in the kernel statically. > > Maybe this confusion explains why /dev/md0c is giving me random crashes > at the moment? > > Of course, another theory might be the size of my initial ramdisk > (300Mb). Would there any known bug where booting off a large ramdisk > causes unreadable panics to flash past the console too rapidly to view? Is the mfsroot file compressed (.gz extension)? Reason I ask is that the OP states he's using RELENG_7... http://jdc.parodius.com/freebsd/pxeboot_serial_install_7.html#step7 -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Mon May 31 06:03:25 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6E1CA106564A; Mon, 31 May 2010 06:03:25 +0000 (UTC) (envelope-from auryn@zirakzigil.org) Received: from mail.zirakzigil.org (mail.zirakzigil.org [82.63.178.63]) by mx1.freebsd.org (Postfix) with ESMTP id F2E498FC12; Mon, 31 May 2010 06:03:24 +0000 (UTC) Received: from localhost (unknown [192.168.1.2]) by mail.zirakzigil.org (Postfix) with ESMTP id 24B7897781; Mon, 31 May 2010 08:03:23 +0200 (CEST) X-Virus-Scanned: amavisd-new at zirakzigil.org Received: from mail.zirakzigil.org ([192.168.1.2]) by localhost (ext.zirakzigil.org [192.168.1.2]) (amavisd-new, port 10024) with ESMTP id 1kCUlKqGrOia; Mon, 31 May 2010 08:03:20 +0200 (CEST) Received: from [192.168.229.30] (unknown [192.168.1.2]) (Authenticated sender: auryn@zirakzigil.org) by mail.zirakzigil.org (Postfix) with ESMTPA id 58ED997776; Mon, 31 May 2010 08:03:20 +0200 (CEST) Message-ID: <4C03511D.6070807@zirakzigil.org> Date: Mon, 31 May 2010 08:03:09 +0200 From: Giulio Ferro User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Max Laier References: <4BFF589F.2050102@zirakzigil.org> <201005281320.51027.max@love2party.net> In-Reply-To: <201005281320.51027.max@love2party.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org Subject: Re: PF + BRIDGE still causes system freezing X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 31 May 2010 06:03:25 -0000 Max Laier wrote: > On Friday 28 May 2010 07:46:07 Giulio Ferro wrote: > >> Months ago I reported a system freezing whenever bridge was used >> with pf. This still happens now in 8.1 prerelease: after several minutes >> to hours >> that the bridge is active the system becomes unresponsive. >> > > as I told you last time your reported this problem: you need to simplify your > setup in order to track down the problem. For all I know, you have created a > routing or ethernet loop that is the cause of your problems. Unless you can > provide a simple setup that can be reproduced, you have to track down the > issue yourself - sorry. > > Max > Ok, I've moved the vpn-bridging service to a server without pf, and now it seems to work correctly. I maintain that this issue would need to look into, anyway... I don't think that a system freezing is acceptable, even when the administrator makes some configuration mistakes: the o.s. should complain about "routing or ethernet loop", without leaving him wondering... (how can I find them, anyway?) Thanks for your help. From owner-freebsd-stable@FreeBSD.ORG Mon May 31 07:01:57 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8E1491065678 for ; Mon, 31 May 2010 07:01:57 +0000 (UTC) (envelope-from phil@amdg.etowns.org) Received: from nskntmtas05p.mx.bigpond.com (nskntmtas05p.mx.bigpond.com [61.9.168.149]) by mx1.freebsd.org (Postfix) with ESMTP id 222AA8FC18 for ; Mon, 31 May 2010 07:01:56 +0000 (UTC) Received: from nskntotgx03p.mx.bigpond.com ([58.172.114.57]) by nskntmtas05p.mx.bigpond.com with ESMTP id <20100531070155.IUDS18865.nskntmtas05p.mx.bigpond.com@nskntotgx03p.mx.bigpond.com> for ; Mon, 31 May 2010 07:01:55 +0000 Received: from mail.heuristicsystems.com.au ([58.172.114.57]) by nskntotgx03p.mx.bigpond.com with ESMTP id <20100531070154.GBSP1978.nskntotgx03p.mx.bigpond.com@mail.heuristicsystems.com.au> for ; Mon, 31 May 2010 07:01:54 +0000 Received: from white (white.hs [10.0.5.2]) (authenticated bits=0) by mail.heuristicsystems.com.au (8.14.3/8.13.6) with ESMTP id o4V71QZh046924 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Mon, 31 May 2010 17:01:26 +1000 (EST) (envelope-from phil@amdg.etowns.org) From: "Phil" To: Date: Mon, 31 May 2010 17:00:57 +1000 Organization: Heuristic Systems Pty Ltd Message-ID: <580CA5B8F8654FC782CC1137614582C3@HS> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Thread-Index: AcsAiKYatqCHIslkRy2GLFHBBFGBewAASoCQ X-RPD-ScanID: Class unknown; VirusThreatLevel unknown, RefID str=0001.0A090207.4C035EE2.00F0,ss=1,fgs=0 X-SIH-MSG-ID: rB43Ftz3TAD0zmQv0WC2O1J3yArnq3Mt8ZoaRdJjqwQZTULdvMbOPpX9Y94QiJ7l1S5MMRCFP2slZ7zmXY7RiA== Subject: 8.1 Pre-release gpart, isn't setting type correctly X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 31 May 2010 07:01:57 -0000 Performing the following gpart commands on either a hard disk or usb memory stick doesn't correctly store the gpart type information. What we're doing, using FreeBSD 8.1-PRERELEASE, csuped as at 30-May-2010 23:59 UTC (*default date=2010.05.30.23.59.59) # gpart create -s GPT da1 # gpart add -s 1G -t freebsd-ufs da1 # gpart show da1 => 34 7827325 da1 GPT (3.7G) 34 2097152 1 !00000000-0000-0000-0000-000000000000 (1.0G) 2097186 5730173 - free - (2.7G) Expected to see something like: 34 2097152 1 freebsd-ufs (1.0G) # gpart list da1 Geom name: da1 fwheads: 255 fwsectors: 63 last: 7827358 first: 34 entries: 128 scheme: GPT Providers: 1. Name: da1p1 Mediasize: 1073741824 (1.0G) Sectorsize: 512 Mode: r0w0e0 rawtype: 00000000-0000-0000-0000-000000000000 label: (null) length: 1073741824 offset: 17408 type: !00000000-0000-0000-0000-000000000000 index: 1 end: 2097185 start: 34 Consumers: 1. Name: da1 Mediasize: 4007624704 (3.7G) Sectorsize: 512 Mode: r0w0e0 If I reboot the machine, only the /dev/da1 devices is recognised, there is no /dev/da1p1. Also "gpart modify -i 1 -t freebsd-ufs da1" did not have any effect on the "gpart list" We have a similar outcome when using the HDD, => 34 976773101 ada0 GPT (466G) 34 128 1 !00000000-0000-0000-0000-000000000000 (64K) 162 8388608 2 !00000000-0000-0000-0000-000000000000 (4.0G) 8388770 4194304 3 !00000000-0000-0000-0000-000000000000 (2.0G) 12583074 25165824 4 !00000000-0000-0000-0000-000000000000 (12G) 37748898 33554432 5 !00000000-0000-0000-0000-000000000000 (16G) 71303330 4096 6 !00000000-0000-0000-0000-000000000000 (2.0M) 71307426 10485760 7 !00000000-0000-0000-0000-000000000000 (5.0G) 81793186 33554432 8 !00000000-0000-0000-0000-000000000000 (16G) 115347618 566231040 9 !00000000-0000-0000-0000-000000000000 (270G) 681578658 16384 10 !00000000-0000-0000-0000-000000000000 (8.0M) 681595042 4194304 11 !00000000-0000-0000-0000-000000000000 (2.0G) 685789346 290983789 12 !00000000-0000-0000-0000-000000000000 (139G) Hardware: Used two different motherboards: Gigabyte (without ahci available) and VIA SN1800 (with ahci available and enabled); two hard disks (WD500AAKS)and one usb memory stick. Initially I thought it was the ahci timeouts, but using different motherboards, and a usb drive disproved that association. If there is anything that I can do, or provide to help resolve this, I'm happy to do so. Regards, Phil Sydney Australia (GMT+10 hours) From owner-freebsd-stable@FreeBSD.ORG Mon May 31 08:05:57 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8F2C2106566B for ; Mon, 31 May 2010 08:05:57 +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 150F68FC15 for ; Mon, 31 May 2010 08:05:56 +0000 (UTC) Received: from alph.d.allbsd.org (p5247-ipbf302funabasi.chiba.ocn.ne.jp [125.170.154.247]) (authenticated bits=128) by mail.allbsd.org (8.14.3/8.14.3) with ESMTP id o4V84pwZ001150; Mon, 31 May 2010 17:05:01 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) (authenticated bits=0) by alph.d.allbsd.org (8.14.4/8.14.4) with ESMTP id o4V84oCd075821; Mon, 31 May 2010 17:04:51 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Mon, 31 May 2010 17:04:17 +0900 (JST) Message-Id: <20100531.170417.202070374.hrs@allbsd.org> To: phil@amdg.etowns.org From: Hiroki Sato In-Reply-To: <580CA5B8F8654FC782CC1137614582C3@HS> References: <580CA5B8F8654FC782CC1137614582C3@HS> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.3 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Mon_May_31_17_04_17_2010_679)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.95.3 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]); Mon, 31 May 2010 17:05:05 +0900 (JST) X-Spam-Status: No, score=-98.5 required=13.0 tests=AWL,CONTENT_TYPE_PRESENT, FAKEDWORD_ONE, FAKEDWORD_VERTICALLINE, QENCPTR1, RCVD_IN_CHINA, RCVD_IN_CHINA_KR, RCVD_IN_PBL, RCVD_IN_TAIWAN, SPF_SOFTFAIL, USER_IN_WHITELIST, X_MAILER_PRESENT autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gatekeeper.allbsd.org Cc: freebsd-stable@FreeBSD.org Subject: Re: 8.1 Pre-release gpart, isn't setting type correctly X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 31 May 2010 08:05:57 -0000 ----Security_Multipart(Mon_May_31_17_04_17_2010_679)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit "Phil" wrote in <580CA5B8F8654FC782CC1137614582C3@HS>: ph> Performing the following gpart commands on either a hard disk or ph> usb memory stick doesn't correctly store the gpart type information. ph> ph> What we're doing, using FreeBSD 8.1-PRERELEASE, csuped as at ph> 30-May-2010 23:59 UTC (*default date=2010.05.30.23.59.59) ph> ph> # gpart create -s GPT da1 ph> # gpart add -s 1G -t freebsd-ufs da1 ph> # gpart show da1 ph> ph> => 34 7827325 da1 GPT (3.7G) ph> 34 2097152 1 !00000000-0000-0000-0000-000000000000 (1.0G) ph> 2097186 5730173 - free - (2.7G) This is probably the same issue reported at http://www.freebsd.org/cgi/query-pr.cgi?pr=kern%2F142174 and already fixed on CURRENT. I guess the fix will be merged to 8.X soon. -- Hiroki ----Security_Multipart(Mon_May_31_17_04_17_2010_679)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEABECAAYFAkwDbYEACgkQTyzT2CeTzy07rgCgmuUXkTTpz2IfPdef/UBzP9Ys 6aMAoLZMhvtuZCMLBngvwzKnJXb0w64j =SmPz -----END PGP SIGNATURE----- ----Security_Multipart(Mon_May_31_17_04_17_2010_679)---- From owner-freebsd-stable@FreeBSD.ORG Mon May 31 08:32:18 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EC9EF106568B for ; Mon, 31 May 2010 08:32:18 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta08.emeryville.ca.mail.comcast.net (qmta08.emeryville.ca.mail.comcast.net [76.96.30.80]) by mx1.freebsd.org (Postfix) with ESMTP id D2B3F8FC19 for ; Mon, 31 May 2010 08:32:18 +0000 (UTC) Received: from omta20.emeryville.ca.mail.comcast.net ([76.96.30.87]) by qmta08.emeryville.ca.mail.comcast.net with comcast id Q8XY1e0011smiN4A88YJrJ; Mon, 31 May 2010 08:32:18 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta20.emeryville.ca.mail.comcast.net with comcast id Q8YH1e0033S48mS8g8YHzB; Mon, 31 May 2010 08:32:18 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 3C54E9B418; Mon, 31 May 2010 01:32:17 -0700 (PDT) Date: Mon, 31 May 2010 01:32:17 -0700 From: Jeremy Chadwick To: Giulio Ferro Message-ID: <20100531083217.GA74108@icarus.home.lan> References: <4BFF589F.2050102@zirakzigil.org> <201005281320.51027.max@love2party.net> <4C03511D.6070807@zirakzigil.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C03511D.6070807@zirakzigil.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Max Laier , freebsd-stable@freebsd.org, freebsd-net@freebsd.org Subject: Re: PF + BRIDGE still causes system freezing X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 31 May 2010 08:32:19 -0000 On Mon, May 31, 2010 at 08:03:09AM +0200, Giulio Ferro wrote: > Max Laier wrote: > >On Friday 28 May 2010 07:46:07 Giulio Ferro wrote: > >>Months ago I reported a system freezing whenever bridge was used > >>with pf. This still happens now in 8.1 prerelease: after several minutes > >>to hours > >>that the bridge is active the system becomes unresponsive. > > > >as I told you last time your reported this problem: you need to > >simplify your setup in order to track down the problem. For all I > >know, you have created a routing or ethernet loop that is the > >cause of your problems. Unless you can provide a simple setup > >that can be reproduced, you have to track down the issue yourself > >- sorry. > > > >Max > > Ok, I've moved the vpn-bridging service to a server without pf, and now > it seems to work correctly. > > I maintain that this issue would need to look into, anyway... > I don't think that a system freezing is acceptable, even when the > administrator > makes some configuration mistakes: the o.s. should complain about > "routing or ethernet loop", without leaving him wondering... We don't know if physical cabling loops are the problem here, but I'll chime in with my two cents regardless. If you're prone to making cabling mistakes that result in layer 2 loops in your network, you should consider using protocols like spanning tree[1] on your switches. Be aware that STP induces a lot of other problems and complexities which very likely *will* be seen as issues within the OS (such as physical Ethernet link not coming up quickly, taking instead maybe 60-120 full seconds). I believe there are extension protocols that address this (such as RSTP). If you're actually using FreeBSD as a "smart switch", then there may be some spanning tree software that works on FreeBSD. I'm not familiar with this setup or what software may be available. The majority of folks connect their FreeBSD machines to a switch, and those switches can handle STP. [1]: http://en.wikipedia.org/wiki/Spanning_tree_protocol -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Mon May 31 11:34:42 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3E8C01065672 for ; Mon, 31 May 2010 11:34:42 +0000 (UTC) (envelope-from sean@gothic.net.au) Received: from visi.gothic.net.au (visi.gothic.net.au [115.64.131.102]) by mx1.freebsd.org (Postfix) with ESMTP id CE6BE8FC19 for ; Mon, 31 May 2010 11:34:41 +0000 (UTC) Received: from visi.gothic.net.au (localhost [127.0.0.1]) by visi.gothic.net.au (Postfix) with ESMTP id AB4144C78D; Mon, 31 May 2010 21:34:39 +1000 (EST) X-Virus-Scanned: amavisd-new at gothic.net.au Received: from localhost ([127.0.0.1]) by visi.gothic.net.au (visi.gothic.net.au [127.0.0.1]) (amavisd-new, port 10026) with SMTP id kPgR4c5Yf1xK; Mon, 31 May 2010 21:34:35 +1000 (EST) Received: from eee904 (dhcp181.gothic.net.au [10.168.1.181]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: sean) by visi.gothic.net.au (Postfix) with ESMTPSA id E4C854C779; Mon, 31 May 2010 21:34:34 +1000 (EST) Date: Mon, 31 May 2010 21:34:34 +1000 From: Sean To: Jeremy Chadwick Message-Id: <20100531213434.5fff3c67.sean@gothic.net.au> In-Reply-To: <20100531083217.GA74108@icarus.home.lan> References: <4BFF589F.2050102@zirakzigil.org> <201005281320.51027.max@love2party.net> <4C03511D.6070807@zirakzigil.org> <20100531083217.GA74108@icarus.home.lan> X-Mailer: Sylpheed 3.0.2 (GTK+ 2.10.14; i686-pc-mingw32) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Max Laier , Giulio Ferro , freebsd-stable@freebsd.org, freebsd-net@freebsd.org Subject: Re: PF + BRIDGE still causes system freezing X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 31 May 2010 11:34:42 -0000 On Mon, 31 May 2010 01:32:17 -0700 Jeremy Chadwick wrote: > If you're actually using FreeBSD as a "smart switch", then there may > be some spanning tree software that works on FreeBSD. I'm not > familiar with this setup or what software may be available. The > majority of folks connect their FreeBSD machines to a switch, and > those switches can handle STP. if_bridge supports RSTP if bridgestp is loaded. man 4 if_bridge -- Sean Winn sean@gothic.net.au From owner-freebsd-stable@FreeBSD.ORG Mon May 31 13:48:55 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D78F4106568A for ; Mon, 31 May 2010 13:48:55 +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 8A51D8FC0A for ; Mon, 31 May 2010 13:48:55 +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 o4VDlINX016851; Mon, 31 May 2010 09:48:18 -0400 Received: from auth3.smtp.vt.edu (EHLO auth3.smtp.vt.edu) ([198.82.161.152]) by dagger.cc.vt.edu (MOS 4.1.8-GA FastPath queued) with ESMTP id JBM58237; Mon, 31 May 2010 09:48:17 -0400 (EDT) Received: from gromit.chumby.lan (c-98-249-7-145.hsd1.va.comcast.net [98.249.7.145]) (authenticated bits=0) by auth3.smtp.vt.edu (8.13.8/8.13.8) with ESMTP id o4VDmGb8006742 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 31 May 2010 09:48:17 -0400 Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Paul Mather In-Reply-To: <19664824-1B23-4E5F-BC12-BB4D59A9C8AA@ee.ryerson.ca> Date: Mon, 31 May 2010 09:48:16 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <7B30E5C6-07F9-4B61-9F09-1615D21F6461@gromit.dlib.vt.edu> References: <4C017419.9010909@strauser.com> <4632C12D-2B1E-4073-B2C9-E9D15C212EF1@ee.ryerson.ca> <19664824-1B23-4E5F-BC12-BB4D59A9C8AA@ee.ryerson.ca> To: David Magda X-Mailer: Apple Mail (2.1078) X-Mirapoint-Received-SPF: 198.82.161.152 auth3.smtp.vt.edu paul@gromit.dlib.vt.edu 5 none X-Mirapoint-IP-Reputation: reputation=neutral-1, source=Fixed, refid=n/a, actions=MAILHURDLE SPF TAG X-Junkmail-Info: (0) X-Junkmail-Status: score=10/50, host=dagger.cc.vt.edu X-Junkmail-SD-Raw: score=unknown, refid=str=0001.0A02020A.4C03BE22.00E9,ss=1,fgs=0, ip=98.249.7.145, so=2009-09-22 00:05:22, dmn=2009-09-10 00:05:08, mode=multiengine X-Junkmail-IWF: false Cc: FreeBSD-STABLE Mailing List Subject: Re: Make ZFS auto-destroy snapshots when the out of space? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 31 May 2010 13:48:55 -0000 On May 30, 2010, at 10:35 PM, David Magda wrote: > An event framework would certainly be helpful in a general sense = (Linux has event(3) AFAIK), and that could certainly be useful for = purging snapshots during resource constrained situations. But even if we = don't have it, I doubt a fork(2) from cron(8) and a statfs(2) would be = onerous on a system. :) Devd already receives several ZFS-based events (failed vdev, I/O error, = checksum mismatch, etc.), so perhaps it would be useful to add another, = e.g., "space" which is set to be triggered when a pool attains a certain = percentage full. This could default to 100%, but be capable of being = set lower by an associated kernel sysctl. You could then have any = auto-pruning/snapshot management script triggered from devd. (You'd = probably also have to figure out some kind of throttling mechanism for = this devd event, too.) Cheers, Paul. From owner-freebsd-stable@FreeBSD.ORG Mon May 31 15:19:05 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 43AD31065670 for ; Mon, 31 May 2010 15:19:05 +0000 (UTC) (envelope-from kdulep@gmail.com) Received: from mail-ww0-f54.google.com (mail-ww0-f54.google.com [74.125.82.54]) by mx1.freebsd.org (Postfix) with ESMTP id C73B58FC1C for ; Mon, 31 May 2010 15:19:04 +0000 (UTC) Received: by wwb22 with SMTP id 22so374596wwb.13 for ; Mon, 31 May 2010 08:19:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=w+IJO6+NEZBrxJGjAIhCsmRfTE71gcDvcHtj6nFL7/A=; b=jxikDOA+ANLvCa0MV+d3j9u6swxBBARuFyqjVM5uf9MqnhAAxHCxs5D0e2vKdA+qLV aHP5UBfFnh8UNhXk7WwX+EHCMwEvrSpxIqReWGHXOX6ek03F887t7tXs83ZN6Bl/U1VS zNvLzsjskJb8Querunm5cmRrcaqmrL8QAHwmw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=HNNxS6jGHC9Q5e3k5LIAkm+AZuAbLbhUCH8uCUjqXq4krAPCUohod2pCdrGK95Olmb oZg0CAjIicgqrTePYH5yp/Bc+IgNBipyXLWO3Eok/E02UyMTlJ3IaiPZ2VBUqmBn4NGm MeiplOnIGwTowyEsmzLgoh+flmr2nQazGX3Ec= MIME-Version: 1.0 Received: by 10.227.154.204 with SMTP id p12mr4353098wbw.141.1275315608958; Mon, 31 May 2010 07:20:08 -0700 (PDT) Received: by 10.216.3.1 with HTTP; Mon, 31 May 2010 07:20:08 -0700 (PDT) Date: Mon, 31 May 2010 20:20:08 +0600 Message-ID: From: Konstantin Doulepov To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: kernel panic: vm_page_unwire X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 31 May 2010 15:19:05 -0000 FreeBSD 8.1-PRERELEASE #0 r208656 i have enabled textdump, if u need i guess i can still recover some info from dedicated dump partition i have enabled some tweaks in loader.conf hint.p4tcc.0.disabled=1 hint.acpi_throttle.0.disabled=1 hint.apic.0.clock=0 kern.hz=100 hint.atrtc.0.clock=0 panic: vm_page_unwire: invalid wire count: 0 cpuid = 3 Uptime: 15h58m27s machine amd64 cpu HAMMER makeoptions NO_MODULES= makeoptions DEBUG=-g options COMPAT_LINUX32 options TMPFS options NULLFS options ACCEPT_FILTER_HTTP options ACCEPT_FILTER_DNS options ACCEPT_FILTER_DATA options ZERO_COPY_SOCKETS options IPDIVERT options IPFIREWALL_VERBOSE_LIMIT=100 options IPFIREWALL_VERBOSE options IPFIREWALL options PANIC_REBOOT_WAIT_TIME=120 options GDB options KDB_UNATTENDED options DDB options KDB options USB_DEBUG options AH_SUPPORT_AR5416 options IEEE80211_SUPPORT_MESH options IEEE80211_AMPDU_AGE options IEEE80211_DEBUG options AHD_REG_PRETTY_PRINT options AHC_REG_PRETTY_PRINT options ATA_STATIC_ID options SMP options INCLUDE_CONFIG_FILE options FLOWTABLE options MAC options AUDIT options HWPMC_HOOKS options KBD_INSTALL_CDEV options PRINTF_BUFR_SIZE=128 options _KPOSIX_PRIORITY_SCHEDULING options P1003_1B_SEMAPHORES options SYSVSEM options SYSVMSG options SYSVSHM options STACK options KTRACE options SCSI_DELAY=5000 options COMPAT_FREEBSD7 options COMPAT_FREEBSD6 options COMPAT_FREEBSD5 options COMPAT_FREEBSD4 options COMPAT_FREEBSD32 options COMPAT_43TTY options GEOM_LABEL options GEOM_PART_GPT options PSEUDOFS options PROCFS options CD9660 options MSDOSFS options NFS_ROOT options NFSLOCKD options NFSSERVER options NFSCLIENT options MD_ROOT options UFS_GJOURNAL options UFS_DIRHASH options UFS_ACL options SOFTUPDATES options FFS options INET options PREEMPTION options SCHED_ULE options GEOM_PART_MBR options GEOM_PART_EBR_COMPAT options GEOM_PART_EBR options GEOM_PART_BSD device isa device mem device io device uart_ns8250 device cpufreq device acpi device pci device ata device atadisk device ataraid device atapicd device scbus device da device cd device pass device atkbdc device atkbd device psm device kbdmux device vga device splash device sc device uart device miibus device ale device msk device re device sge device loop device random device ether device vlan device pty device md device firmware device bpf device uhci device ohci device ehci device usb device uhid device umass device ums device firewire device ahci device coretemp device if_bridge device blank_saver -- konstantin -- All The Best Of All From owner-freebsd-stable@FreeBSD.ORG Mon May 31 15:23:08 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E32D11065674 for ; Mon, 31 May 2010 15:23:08 +0000 (UTC) (envelope-from dudu@dudu.ro) Received: from mail-yw0-f176.google.com (mail-yw0-f176.google.com [209.85.211.176]) by mx1.freebsd.org (Postfix) with ESMTP id AC8238FC15 for ; Mon, 31 May 2010 15:23:08 +0000 (UTC) Received: by ywh6 with SMTP id 6so2823253ywh.16 for ; Mon, 31 May 2010 08:23:08 -0700 (PDT) Received: by 10.90.47.9 with SMTP id u9mr2487119agu.195.1275319387136; Mon, 31 May 2010 08:23:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.90.35.11 with HTTP; Mon, 31 May 2010 08:22:47 -0700 (PDT) In-Reply-To: References: From: Vlad Galu Date: Mon, 31 May 2010 18:22:47 +0300 Message-ID: To: Konstantin Doulepov Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-stable@freebsd.org Subject: Re: kernel panic: vm_page_unwire X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 31 May 2010 15:23:09 -0000 On Mon, May 31, 2010 at 5:20 PM, Konstantin Doulepov wrote: [...] Hello Konstantin, Remove ZERO_COPY_SOCKETS and retry. It's been known to cause VM panics for quite a while. Regards, Vlad -- Good, fast & cheap. Pick any two. From owner-freebsd-stable@FreeBSD.ORG Mon May 31 17:47:18 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1B3121065673 for ; Mon, 31 May 2010 17:47:18 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.10]) by mx1.freebsd.org (Postfix) with ESMTP id 8AA528FC0C for ; Mon, 31 May 2010 17:47:17 +0000 (UTC) Received: from vampire.homelinux.org (dslb-088-066-034-186.pools.arcor-ip.net [88.66.34.186]) by mrelayeu.kundenserver.de (node=mreu0) with ESMTP (Nemesis) id 0Lm8NJ-1Orvrm3EtF-00ZDpc; Mon, 31 May 2010 19:47:15 +0200 Received: (qmail 96386 invoked from network); 31 May 2010 17:47:15 -0000 Received: from f8x64.laiers.local (192.168.4.188) by mx.laiers.local with SMTP; 31 May 2010 17:47:15 -0000 From: Max Laier Organization: FreeBSD To: Giulio Ferro Date: Mon, 31 May 2010 19:47:14 +0200 User-Agent: KMail/1.13.3 (FreeBSD/8.0-RELEASE-p2; KDE/4.4.3; amd64; ; ) References: <4BFF589F.2050102@zirakzigil.org> <201005281320.51027.max@love2party.net> <4C03511D.6070807@zirakzigil.org> In-Reply-To: <4C03511D.6070807@zirakzigil.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201005311947.14984.max@love2party.net> X-Provags-ID: V01U2FsdGVkX1+J20Hh3Vag36QBW++cGEWic58Icuf97XvGcUl ifLoh4Ms7YBn9HheN49nRCIWyL3rC5TwKUktxYSKBqycJz4yQW epK18GFMZ+qj5JfRtHoQg== Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org Subject: Re: PF + BRIDGE still causes system freezing X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 31 May 2010 17:47:18 -0000 On Monday 31 May 2010 08:03:09 Giulio Ferro wrote: > Max Laier wrote: > > On Friday 28 May 2010 07:46:07 Giulio Ferro wrote: > >> Months ago I reported a system freezing whenever bridge was used > >> with pf. This still happens now in 8.1 prerelease: after several minutes > >> to hours > >> that the bridge is active the system becomes unresponsive. > > > > as I told you last time your reported this problem: you need to simplify > > your setup in order to track down the problem. For all I know, you have > > created a routing or ethernet loop that is the cause of your problems. > > Unless you can provide a simple setup that can be reproduced, you have > > to track down the issue yourself - sorry. > > > > Max > > Ok, I've moved the vpn-bridging service to a server without pf, and now > it seems to work correctly. Glad to hear. I would, however, still like to know the *details* of your setup so I can *reproduce* the problem. Without proper configuration details, all I - or anyone - can do is guess. The information you provided so far is not very helpful in this regard. > I maintain that this issue would need to look into, anyway... Yes ... but unless the issue can be reproduced in a controlled environment, it's next to impossible to do so. > I don't think that a system freezing is acceptable, even when the > administrator > makes some configuration mistakes: the o.s. should complain about > "routing or ethernet loop", without leaving him wondering... I'm afraid in this regard we (or any other o.s. for that matter) are just rope vendors. Network configuration is complicated business. The more components you throw in the mix, the easier it gets to hang yourself in the ensuing web. Sorry I can't be of more help, but again: without details about your setup, everything is just guesswork! Max From owner-freebsd-stable@FreeBSD.ORG Mon May 31 18:25:52 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4CB831065677 for ; Mon, 31 May 2010 18:25:52 +0000 (UTC) (envelope-from dave@jetcafe.org) Received: from hugeraid.jetcafe.org (hugeraid.jetcafe.org [205.147.26.109]) by mx1.freebsd.org (Postfix) with ESMTP id 291408FC22 for ; Mon, 31 May 2010 18:25:51 +0000 (UTC) Received: from hugeraid.jetcafe.org (localhost [127.0.0.1]) by hugeraid.jetcafe.org (8.13.8/8.13.8) with ESMTP id o4VIPp5F051573; Mon, 31 May 2010 11:25:51 -0700 (PDT) Message-Id: <201005311825.o4VIPp5F051573@hugeraid.jetcafe.org> X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.0.4 To: Jeremy Chadwick In-reply-to: <20100531041843.GA66732@icarus.home.lan> References: <201005272348.o4RNmgWh014243@hugeraid.jetcafe.org> <20100528043006.GA18560@lava.net> <201005281757.o4SHvTwq020905@hugeraid.jetcafe.org> <20100528191828.GA83371@icarus.home.lan> <201005281926.o4SJQCW3041849@hugeraid.jetcafe.org> <20100528215837.GA86689@icarus.home.lan> <201005310242.o4V2glZX057087@hugeraid.jetcafe.org> <20100531041843.GA66732@icarus.home.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 31 May 2010 11:25:51 -0700 From: Dave Hayes Cc: Garrett Cooper , freebsd-stable@freebsd.org, Clifton Royston Subject: Re: Locking a file backed mdconfig into memory X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 31 May 2010 18:25:52 -0000 Jeremy Chadwick writes: > Is the mfsroot file compressed (.gz extension)? Reason I ask is that > the OP states he's using RELENG_7... Yes it is compressed. > http://jdc.parodius.com/freebsd/pxeboot_serial_install_7.html#step7 Thanks much for this. I did a simple test, I rebuilt a DVD that wasn't booting to use a lower level of compression (gzip -9 to gzip -6) on mfsroot without changing anything else. This caused it to boot normally. I'm not sure it's conclusive evidence, but it certainly looks like a weak datapoint supporting this kernel bug being the source of my problem. Is this problem fixed in 8.0 or by a patch? -- Dave Hayes - Consultant - Altadena CA, USA - dave@jetcafe.org >>> The opinions expressed above are entirely my own <<< Suggested definition of "sin": Trading aliveness for survival. From owner-freebsd-stable@FreeBSD.ORG Mon May 31 18:45:26 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 940BC106566B for ; Mon, 31 May 2010 18:45:26 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta11.emeryville.ca.mail.comcast.net (qmta11.emeryville.ca.mail.comcast.net [76.96.27.211]) by mx1.freebsd.org (Postfix) with ESMTP id 73BD88FC15 for ; Mon, 31 May 2010 18:45:26 +0000 (UTC) Received: from omta02.emeryville.ca.mail.comcast.net ([76.96.30.19]) by qmta11.emeryville.ca.mail.comcast.net with comcast id QHAW1e0030QkzPwABJlRtS; Mon, 31 May 2010 18:45:25 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta02.emeryville.ca.mail.comcast.net with comcast id QJlR1e00L3S48mS8NJlRym; Mon, 31 May 2010 18:45:25 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 6CDF39B418; Mon, 31 May 2010 11:45:25 -0700 (PDT) Date: Mon, 31 May 2010 11:45:25 -0700 From: Jeremy Chadwick To: Dave Hayes Message-ID: <20100531184525.GA89545@icarus.home.lan> References: <201005272348.o4RNmgWh014243@hugeraid.jetcafe.org> <20100528043006.GA18560@lava.net> <201005281757.o4SHvTwq020905@hugeraid.jetcafe.org> <20100528191828.GA83371@icarus.home.lan> <201005281926.o4SJQCW3041849@hugeraid.jetcafe.org> <20100528215837.GA86689@icarus.home.lan> <201005310242.o4V2glZX057087@hugeraid.jetcafe.org> <20100531041843.GA66732@icarus.home.lan> <201005311825.o4VIPp5F051573@hugeraid.jetcafe.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201005311825.o4VIPp5F051573@hugeraid.jetcafe.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Garrett Cooper , freebsd-stable@freebsd.org, Clifton Royston , jhb@freebsd.org Subject: Re: Locking a file backed mdconfig into memory X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 31 May 2010 18:45:26 -0000 On Mon, May 31, 2010 at 11:25:51AM -0700, Dave Hayes wrote: > Jeremy Chadwick writes: > > Is the mfsroot file compressed (.gz extension)? Reason I ask is that > > the OP states he's using RELENG_7... > > Yes it is compressed. > > > http://jdc.parodius.com/freebsd/pxeboot_serial_install_7.html#step7 > > Thanks much for this. I did a simple test, I rebuilt a DVD that wasn't > booting to use a lower level of compression (gzip -9 to gzip -6) on > mfsroot without changing anything else. This caused it to boot normally. > > I'm not sure it's conclusive evidence, but it certainly looks like a > weak datapoint supporting this kernel bug being the source of my > problem. > > Is this problem fixed in 8.0 or by a patch? With regards to said bug, gzip compression seems to work fine on RELENG_8, at least in my experiences: http://jdc.parodius.com/freebsd/pxeboot_serial_install_8.html I'm not sure the level of compression is what triggers the bug though; I haven't tested all levels (1 through 9). CC'ing jhb@ since he last updated PR kern/120127 (which I would say is still a problem on RELENG_7 :-) ). John, are you aware of any gzip decompression / mfsroot changes which might explain the problem on RELENG_7? I haven't done a "thorough" series of tests, but on my testbed boxes RELENG_8 works fine with a gzip'd mfsroot. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Mon May 31 21:24:11 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0BB781065673 for ; Mon, 31 May 2010 21:24:11 +0000 (UTC) (envelope-from dave@jetcafe.org) Received: from hugeraid.jetcafe.org (hugeraid.jetcafe.org [205.147.26.109]) by mx1.freebsd.org (Postfix) with ESMTP id C2E348FC17 for ; Mon, 31 May 2010 21:24:10 +0000 (UTC) Received: from hugeraid.jetcafe.org (localhost [127.0.0.1]) by hugeraid.jetcafe.org (8.13.8/8.13.8) with ESMTP id o4VLO9vW082331; Mon, 31 May 2010 14:24:09 -0700 (PDT) Message-Id: <201005312124.o4VLO9vW082331@hugeraid.jetcafe.org> X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.0.4 To: Jeremy Chadwick In-reply-to: <20100531184525.GA89545@icarus.home.lan> References: <201005272348.o4RNmgWh014243@hugeraid.jetcafe.org> <20100528043006.GA18560@lava.net> <201005281757.o4SHvTwq020905@hugeraid.jetcafe.org> <20100528191828.GA83371@icarus.home.lan> <201005281926.o4SJQCW3041849@hugeraid.jetcafe.org> <20100528215837.GA86689@icarus.home.lan> <201005310242.o4V2glZX057087@hugeraid.jetcafe.org> <20100531041843.GA66732@icarus.home.lan> <201005311825.o4VIPp5F051573@hugeraid.jetcafe.org> <20100531184525.GA89545@icarus.home.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 31 May 2010 14:24:09 -0700 From: Dave Hayes Cc: Garrett Cooper , freebsd-stable@freebsd.org, Clifton Royston , jhb@freebsd.org Subject: Re: Locking a file backed mdconfig into memory X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 31 May 2010 21:24:11 -0000 Jeremy Chadwick writes: > CC'ing jhb@ since he last updated PR kern/120127 (which I would say is > still a problem on RELENG_7 :-) ). John, are you aware of any gzip > decompression / mfsroot changes which might explain the problem on > RELENG_7? I haven't done a "thorough" series of tests, but on my > testbed boxes RELENG_8 works fine with a gzip'd mfsroot. I can get you an iso that crashes when you try to boot it, if that will help? -- Dave Hayes - Consultant - Altadena CA, USA - dave@jetcafe.org >>> The opinions expressed above are entirely my own <<< Your ego is a failed API for a system that doesn't need your input. From owner-freebsd-stable@FreeBSD.ORG Mon May 31 22:15:03 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6D3A61065676; Mon, 31 May 2010 22:15:03 +0000 (UTC) (envelope-from dave@jetcafe.org) Received: from hugeraid.jetcafe.org (hugeraid.jetcafe.org [205.147.26.109]) by mx1.freebsd.org (Postfix) with ESMTP id 463688FC08; Mon, 31 May 2010 22:15:03 +0000 (UTC) Received: from hugeraid.jetcafe.org (localhost [127.0.0.1]) by hugeraid.jetcafe.org (8.13.8/8.13.8) with ESMTP id o4VMF2Gc089418; Mon, 31 May 2010 15:15:02 -0700 (PDT) Message-Id: <201005312215.o4VMF2Gc089418@hugeraid.jetcafe.org> X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.0.4 To: Jeremy Chadwick , Garrett Cooper , freebsd-stable@freebsd.org, Clifton Royston , jhb@freebsd.org In-reply-to: <201005312124.o4VLO9vW082331@hugeraid.jetcafe.org> References: <201005272348.o4RNmgWh014243@hugeraid.jetcafe.org> <20100528043006.GA18560@lava.net> <201005281757.o4SHvTwq020905@hugeraid.jetcafe.org> <20100528191828.GA83371@icarus.home.lan> <201005281926.o4SJQCW3041849@hugeraid.jetcafe.org> <20100528215837.GA86689@icarus.home.lan> <201005310242.o4V2glZX057087@hugeraid.jetcafe.org> <20100531041843.GA66732@icarus.home.lan> <201005311825.o4VIPp5F051573@hugeraid.jetcafe.org> <20100531184525.GA89545@icarus.home.lan> <201005312124.o4VLO9vW082331@hugeraid.jetcafe.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 31 May 2010 15:15:02 -0700 From: Dave Hayes Cc: Subject: Re: Locking a file backed mdconfig into memory X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 31 May 2010 22:15:03 -0000 Dave Hayes writes: > Jeremy Chadwick writes: >> CC'ing jhb@ since he last updated PR kern/120127 (which I would say is >> still a problem on RELENG_7 :-) ). John, are you aware of any gzip >> decompression / mfsroot changes which might explain the problem on >> RELENG_7? I haven't done a "thorough" series of tests, but on my >> testbed boxes RELENG_8 works fine with a gzip'd mfsroot. > I can get you an iso that crashes when you try to boot it, if that > will help? Well this doesn't seem to be the compression issue, since I just tried a test without compressing the ramdisk image. It still crashes. I'm back to thinking it's the size of the ramdisk image itself, but really I've no clue. -- Dave Hayes - Consultant - Altadena CA, USA - dave@jetcafe.org >>> The opinions expressed above are entirely my own <<< "In theory, there is no difference between theory and practice. In practice, there is." -- Jan L. A. Van De Snepscheut From owner-freebsd-stable@FreeBSD.ORG Tue Jun 1 02:53:14 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B979B1065675 for ; Tue, 1 Jun 2010 02:53:14 +0000 (UTC) (envelope-from bounces@nabble.com) Received: from kuber.nabble.com (kuber.nabble.com [216.139.236.158]) by mx1.freebsd.org (Postfix) with ESMTP id 92C268FC19 for ; Tue, 1 Jun 2010 02:53:14 +0000 (UTC) Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1OJHbN-0003nb-Vj for freebsd-stable@freebsd.org; Mon, 31 May 2010 19:53:13 -0700 Message-ID: <28737218.post@talk.nabble.com> Date: Mon, 31 May 2010 19:53:13 -0700 (PDT) From: PaulFr To: freebsd-stable@freebsd.org In-Reply-To: <20080810120156.O1324@borg> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: pfcomptech@gmail.com References: <20080809195935.F4976@borg> <20080809215249.T5563@borg> <20080810082410.X1306@borg> <57BE2631-7AED-443A-88E4-62456C048DD4@tamu.edu> <20080810102225.V1945@borg> <20080810120156.O1324@borg> Subject: Re: IPMI Console: No luck once OS is booted X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 01 Jun 2010 02:53:14 -0000 Larry Rosenman wrote: > > On Sun, 10 Aug 2008, David Duchscher wrote: > >> On Aug 10, 2008, at 10:22 AM, Larry Rosenman wrote: >> >>>> I don't have that IPMI card but I can say we have other cards of theirs >>>> working. I would make sure the card is at the latest version of >>>> firmware. >>>> The AOC-SIMSO(+) card was not detected correctly until we upgraded. I >>>> don't know why the card is going away when freebsd boots since I assume >>>> you are on the dedicated LAN interface with its own IP address. >>> Yes. It's not going away, just doesn't see the key strokes. >> >> Looking through your dmesg file, I don't see a USB keyboard being >> attached. >> On my system, the virtual keyboard is a USB keyboard. >> >> ukbd0: on >> uhub3 >> kbd2 at ukbd0 > Good catch. When I set it to disable USB Mass Storage when no image > is loaded, the ukbd came alive, and I'm typing this on the IPMI Console. > > Thanks! >> >> -- >> DaveD >> > Larry I have a similar problem as you describe in this posting using a SuperMicro X8SIL-F motherboard with onboard IPMI. The console redirection works fine during boot until the OS (pfSense - FreebSD 7.2 Release p5) boots and then I can't enter anything from the keyboard. Screen output is OK. I notice there is also no usb keyboard being detected during boot - instead a usb mass storage device is added. Thus I suspect I am seeing the same issue as you did. When you mentioned "When I set it to disable USB Mass Storage when no image is loaded, the ukbd came alive..." how did you do that? Regards Paul Freeman -- View this message in context: http://old.nabble.com/IPMI-Console%3A-No-luck-once-OS-is-booted-tp18910013p28737218.html Sent from the freebsd-stable mailing list archive at Nabble.com. From owner-freebsd-stable@FreeBSD.ORG Tue Jun 1 02:54:27 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 45070106566C for ; Tue, 1 Jun 2010 02:54:27 +0000 (UTC) (envelope-from ncrogers@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 0B2FD8FC0A for ; Tue, 1 Jun 2010 02:54:26 +0000 (UTC) Received: by iwn5 with SMTP id 5so705962iwn.13 for ; Mon, 31 May 2010 19:54:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=HLBxYSD9zVohYHUQNxrTPCke46Tx5iEk5OcBryVjhJI=; b=r1IcjQMuj5qac1h35Nap77bisCuyuCnDzu7AYfqG90m+4fxa99M5ILJBr3txu9HHPH DpD2Rx2AWZqMaVJrAk2D5Fv7uVqOy9czFlT6saPN3xBb+B12rrBAnExywItRReTv1v9k 2llyoQ7fecxhJpB1/DkGLNFQfXVwhmIofhlaA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=eIOQiiKd5vxDyyYfxlT9vBUoD5h32qvTJgLhkMiPcrOngarFM+fm727eVemAv4BBmt /Ck7s2VWWcSyq5aksAdKgPBx8MsZPAPUrJbxD0cID+HrQdzL0iN0+pT3WHSG1R1O/sFw LqStTS383xjRo78WyWHmqckHD00Pm10K5uBUg= MIME-Version: 1.0 Received: by 10.231.187.6 with SMTP id cu6mr6889735ibb.76.1275360866233; Mon, 31 May 2010 19:54:26 -0700 (PDT) Received: by 10.231.192.144 with HTTP; Mon, 31 May 2010 19:54:26 -0700 (PDT) Date: Mon, 31 May 2010 22:54:26 -0400 Message-ID: From: Nick Rogers To: FreeBSD STABLE Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: arp -na performance w/ many permanent entries X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 01 Jun 2010 02:54:27 -0000 I have an 8.0-RELEASE system with 4000 "permanent" ARP entries due to having a network interface (em(4)) configured with 4000 aliases. The "arp -na" command takes what I consider to be an extremely long time to finish (up to 30s on an otherwise unloaded system). I am able to replicate this in a test environment by installing 8.0-RELEASE-amd64 on a VMWare VM w/ 1GB of RAM and a 2GHz CPU. The 4000 aliases/entries is arbitrary, but nicely illustrates the performance problem. The performance is much worse on a real/loaded system. I realize the 4k aliases on an interface is unusual but I have been effectively using this configuration in my network to try and keep my end-users's each on his/her own broadcast domain. The box is a router and I allocate addresses to each user and put each on his/her own subnet with a netmask of /30. If you would like more info on this I can provide it, but it has worked effectively in FreeBSD 6.0-7.2. The slow performance of "arp -na" is an issue for me because I have a web/CGI tool that runs various reports, many of them relying on acquiring the current "ARP table", and the performance of arp(8) makes the web interface extremely slow. I believe the problem was introduced between 7.2 and 8.0, when, as far as I understand, parts of the ARP subsystem were improved. In 7.2, the aliases configured on an interface were not considered ARP entries (at least according to arp(8)), but as of 8.0 they are marked as "permanent" ARP entries and displayed by arp(8), which seems to attribute to the performance problem. I ran the following perl script to setup my test system. This script was run after installing 8.0-RELEASE and adding the bash, perl, and p5-NetAddr-IP packages via pkg_add -r. #!/usr/bin/perl use strict; use diagnostics; use NetAddr::IP; my $interface = 'em1'; my $cidr = '10.0.0.1/18'; # configure the interface with 4000 or so aliases foreach my $na (@{NetAddr::IP->new($cidr)->splitref(30)}) { my $ip = $na->addr(); my $mask = $na->mask(); my $bcast = $na->broadcast()->addr(); my $cmd = "ifconfig $interface inet alias $ip netmask $mask broadcast $bcast"; print STDERR "$cmd\n"; system($cmd); } The results are as follows: [root@ ~]# uname -a FreeBSD .localdomain 8.0-RELEASE FreeBSD 8.0-RELEASE #0: Sat Nov 21 15:02:08 UTC 2009 root@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 [root@ ~]# ifconfig -a | wc -l 4113 [root@ ~]# ifconfig -a | head -15 em0: flags=8843 metric 0 mtu 1500 options=9b ether 00:0c:29:65:4d:3e inet 172.16.16.244 netmask 0xffffff00 broadcast 172.16.16.255 media: Ethernet autoselect (1000baseT ) status: active em1: flags=8843 metric 0 mtu 1500 options=9b ether 00:0c:29:65:4d:48 inet 10.0.0.0 netmask 0xfffffffc broadcast 10.0.0.3 inet 10.0.0.4 netmask 0xfffffffc broadcast 10.0.0.7 inet 10.0.0.8 netmask 0xfffffffc broadcast 10.0.0.11 inet 10.0.0.12 netmask 0xfffffffc broadcast 10.0.0.15 inet 10.0.0.16 netmask 0xfffffffc broadcast 10.0.0.19 inet 10.0.0.20 netmask 0xfffffffc broadcast 10.0.0.23 [root@ ~]# time ifconfig -a > /dev/null real 0m0.032s user 0m0.023s sys 0m0.008s [root@ ~]# arp -na | wc -l 4100 [root@ ~]# arp -na | tail -15 ? (10.0.5.80) at 00:0c:29:65:4d:48 on em1 permanent [ethernet] ? (10.0.5.48) at 00:0c:29:65:4d:48 on em1 permanent [ethernet] ? (10.0.5.16) at 00:0c:29:65:4d:48 on em1 permanent [ethernet] ? (10.0.1.244) at 00:0c:29:65:4d:48 on em1 permanent [ethernet] ? (10.0.1.212) at 00:0c:29:65:4d:48 on em1 permanent [ethernet] ? (10.0.1.180) at 00:0c:29:65:4d:48 on em1 permanent [ethernet] ? (10.0.1.148) at 00:0c:29:65:4d:48 on em1 permanent [ethernet] ? (10.0.1.116) at 00:0c:29:65:4d:48 on em1 permanent [ethernet] ? (10.0.1.84) at 00:0c:29:65:4d:48 on em1 permanent [ethernet] ? (10.0.1.52) at 00:0c:29:65:4d:48 on em1 permanent [ethernet] ? (10.0.1.20) at 00:0c:29:65:4d:48 on em1 permanent [ethernet] ? (172.16.16.1) at 00:50:56:c0:00:08 on em0 [ethernet] ? (172.16.16.2) at 00:50:56:ea:ea:1a on em0 [ethernet] ? (172.16.16.254) at 00:50:56:f2:75:00 on em0 [ethernet] ? (172.16.16.244) at 00:0c:29:65:4d:3e on em0 permanent [ethernet] [root@ ~]# uptime 7:28PM up 42 mins, 2 users, load averages: 0.00, 0.00, 0.00 [root@ ~]# time arp -na > /dev/null real 0m12.761s user 0m2.959s sys 0m9.753s [root@ ~]# Notice that "arp -na" takes about 13s to execute even though there is no other load. This can get a lot worse by a few orders of magnitude on a loaded machine in a production environment, and seems to scale up linearly when more aliases are added to the interface (permanent ARP entries created). Is this a reasonable problem that can be fixed/improved, or am I stuck with the slow arp -na output? Any help or comments is greatly appreciated. From owner-freebsd-stable@FreeBSD.ORG Tue Jun 1 05:17:34 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 596EC10677A8 for ; Tue, 1 Jun 2010 05:16:59 +0000 (UTC) (envelope-from phil@amdg.etowns.org) Received: from nskntmtas06p.mx.bigpond.com (nskntmtas06p.mx.bigpond.com [61.9.168.152]) by mx1.freebsd.org (Postfix) with ESMTP id DDFF48FC25 for ; Tue, 1 Jun 2010 05:16:58 +0000 (UTC) Received: from nskntotgx03p.mx.bigpond.com ([58.172.114.57]) by nskntmtas06p.mx.bigpond.com with ESMTP id <20100601051657.DIWD24784.nskntmtas06p.mx.bigpond.com@nskntotgx03p.mx.bigpond.com> for ; Tue, 1 Jun 2010 05:16:57 +0000 Received: from mail.heuristicsystems.com.au ([58.172.114.57]) by nskntotgx03p.mx.bigpond.com with ESMTP id <20100601051655.JUHG1978.nskntotgx03p.mx.bigpond.com@mail.heuristicsystems.com.au> for ; Tue, 1 Jun 2010 05:16:55 +0000 Received: from white (white.hs [10.0.5.2]) (authenticated bits=0) by mail.heuristicsystems.com.au (8.14.3/8.13.6) with ESMTP id o515GZ7o073707 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 1 Jun 2010 15:16:37 +1000 (EST) (envelope-from phil@amdg.etowns.org) From: "Phil" To: Date: Tue, 1 Jun 2010 15:15:35 +1000 Organization: Heuristic Systems Pty Ltd Message-ID: <0A94FF873D6B4D83BF778BC13B347065@HS> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Thread-Index: AcsBSXctXqzhnRjDT+Wo7VXnT786qQ== X-RPD-ScanID: Class unknown; VirusThreatLevel unknown, RefID str=0001.0A090209.4C0497C8.012A,ss=1,fgs=0 X-SIH-MSG-ID: ox4zFdf3TAD0zmQv0WC2O1J3yArnq3Mt8ZoaRdJjqwQZTULdvMbOJ4/2Y9kEn5721S5MMxCEOGslZbzmXY7RiA== Subject: AHCI timeouts - 8.1-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: Tue, 01 Jun 2010 05:17:34 -0000 Is it expected behaviour that ahci performs a time-out during boot, even though camcontrol indicates success? This is on 8.1-PRERELEASE csup'ed today. I've enclosed dmesg, camcontrol and pciconf information. The timeout is approximately 12 to 14 seconds for each connected disk-drive. If I run with only usb devices, there are no timeouts. The following dmesg is when I connect two HDD's on a VIA SN18000 motherboard, and the BIOS has ahci selected, i.e. not IDE nor RAID. These machines are personal servers and are permanently running. # dmesg | egrep -i "ahci|ada" ahci0: port 0xdc00-0xdc07,0xd880-0xd883,0xd800-0xd807,0xd480-0xd483,0xd400-0xd40f mem 0xfcfffc00-0xfcffffff irq 21 at device 15.0 on pci0 ahci0: [ITHREAD] ahci0: AHCI v1.00 with 4 3Gbps ports, Port Multiplier supported ahcich0: at channel 0 on ahci0 ahcich0: [ITHREAD] ahcich1: at channel 1 on ahci0 ahcich1: [ITHREAD] ahcich2: at channel 2 on ahci0 ahcich2: [ITHREAD] ahcich3: at channel 3 on ahci0 ahcich3: [ITHREAD] ahcich0: Poll timeout on slot 0 ahcich0: is 00800000 cs 00000001 ss 00000000 rs 00000001 tfd 1d0 serr 00000000 ahcich1: Poll timeout on slot 0 ahcich1: is 00800000 cs 00000001 ss 00000000 rs 00000001 tfd 1d0 serr 00000000 ada0 at ahcich0 bus 0 scbus0 target 0 lun 0da1 at umass-sim1 bus 1 scbus5 target 0 lun 0 ada0: ATA-8 SATA 2.x device ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) ada1 at ahcich1 bus 0 scbus1 target 0 lun 0 ...and ada1 is similar to ada0 above. # camcontrol devlist at scbus0 target 0 lun 0 (ada0,pass0) at scbus1 target 0 lun 0 (ada1,pass1) at scbus4 target 0 lun 0 (da0,pass2) at scbus5 target 0 lun 0 (da1,pass3) # pciconf -lv | grep -A 4 ahci ahci0@pci0:0:15:0: class=0x010601 card=0x62871106 chip=0x62871106 rev=0x20 hdr=0x00 vendor = 'VIA Technologies, Inc.' device = 'VT8251 AHCI Controller' class = mass storage subclass = SATA If there's anything that I can provide to help, please advise. Regards, Phil. From owner-freebsd-stable@FreeBSD.ORG Tue Jun 1 07:16:05 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 077BD1065673 for ; Tue, 1 Jun 2010 07:16:05 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 6AD5D8FC0A for ; Tue, 1 Jun 2010 07:16:04 +0000 (UTC) Received: by fxm5 with SMTP id 5so3266935fxm.13 for ; Tue, 01 Jun 2010 00:16:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=C2BqdDdN29U4+8NI6qtckkBYzHTrxYdp+/uqNrpLlYQ=; b=HhMgA3l8+L5WNm15Hl6u+c3rY+B/kOqn90yI8/ilH3BQ3E3pHx6f1es5TSu2OtzlUf CQ8sw/NYXxfYm1rRXC2qfGAHtEaiOe2RnqK2GW9of7AI5Rs9+pm0uhkZ3a8yHrMN+GPs jM9LHx/RLCMuw9AyLqiw8Q7kKBbT2dp98ogW8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=bWA7FNR5V2MGvLOqoARhkYNw0RB6L82WuH9NMssSLXcneIXBYkYCocPOQyVP3qwxk1 UDfblFarB8SmY0C4C/F6zgp0xQ4NKaLeOb7UOGF2avPkGL1RIn8z6/u006I32QC2jcnO WKRrklWoUQbrJs1xfh6ws+VXIOB8XEU2PzquE= Received: by 10.223.18.67 with SMTP id v3mr6531189faa.93.1275376563263; Tue, 01 Jun 2010 00:16:03 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id 13sm45741389fad.19.2010.06.01.00.16.01 (version=SSLv3 cipher=RC4-MD5); Tue, 01 Jun 2010 00:16:01 -0700 (PDT) Sender: Alexander Motin Message-ID: <4C04B39D.8060503@FreeBSD.org> Date: Tue, 01 Jun 2010 10:15:41 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.24 (X11/20100402) MIME-Version: 1.0 To: Phil , FreeBSD Stable References: In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: Re: AHCI timeouts - 8.1-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: Tue, 01 Jun 2010 07:16:05 -0000 Hi. Phil wrote: > Is it expected behaviour that ahci performs a time-out during boot, even > though camcontrol indicates success? This is on 8.1-PRERELEASE csup'ed > today. > > I've enclosed dmesg, camcontrol and pciconf information. The timeout is > approximately 12 to 14 seconds for each connected disk-drive. If I > run with only usb devices, there are no timeouts. The following > dmesg is when I connect two HDD's on a VIA SN18000 motherboard, and > the BIOS has ahci selected, i.e. not IDE nor RAID. > > # pciconf -lv | grep -A 4 ahci > ahci0@pci0:0:15:0: class=0x010601 card=0x62871106 chip=0x62871106 > rev=0x20 hdr=0x00 > vendor = 'VIA Technologies, Inc.' > device = 'VT8251 AHCI Controller' > class = mass storage > subclass = SATA It seems like timeout during Port Multiplier probe. I don't have such chip to test it, but I can see that Linux disables PMP and NCQ support for it. You may try it in different combinations by adding to respective line in device list in the beginning of the ahci.c quirks AHCI_Q_NOPMP and AHCI_Q_NONCQ. Instead of AHCI_Q_NONCQ (if it is needed for you) you may try to set AHCI_Q_EDGEIS. Report me please about the result. -- Alexander Motin From owner-freebsd-stable@FreeBSD.ORG Tue Jun 1 07:59:07 2010 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 14B131065676; Tue, 1 Jun 2010 07:59:07 +0000 (UTC) (envelope-from stark@mapper.nl) Received: from smtp-out0.tiscali.nl (smtp-out0.tiscali.nl [195.241.79.175]) by mx1.freebsd.org (Postfix) with ESMTP id 2D2018FC08; Tue, 1 Jun 2010 07:59:06 +0000 (UTC) Received: from [82.170.17.27] (helo=mapper.nl) by smtp-out0.tiscali.nl with esmtp (Exim) (envelope-from ) id 1OJMNM-0003e3-QO; Tue, 01 Jun 2010 09:59:05 +0200 Received: from [10.58.235.50] by mapper.nl with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJMND-000OFL-G8; Tue, 01 Jun 2010 09:58:55 +0200 Message-ID: <4C04BDBF.1000304@mapper.nl> Date: Tue, 01 Jun 2010 09:58:55 +0200 From: Mark Stapper User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Garrett Cooper References: <4BF1891F.3040704@mapper.nl> <4BF23029.80104@mapper.nl> <4BFBA130.6060506@mapper.nl> <4BFD70F5.6070005@mapper.nl> In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigAB6E51D7A83ED1C9BA8AA465" Cc: stable@freebsd.org, multimedia@freebsd.org Subject: Re: Buzzing snd_emu10kx enabled card with r206173 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 01 Jun 2010 07:59:07 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigAB6E51D7A83ED1C9BA8AA465 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 30/05/2010 08:31, Garrett Cooper wrote: > On Wed, May 26, 2010 at 12:05 PM, Mark Stapper wrote:= > =20 >> On 25/05/2010 20:05, Garrett Cooper wrote: >> =20 >>> On Tue, May 25, 2010 at 3:06 AM, Mark Stapper wrote= : >>> >>> =20 >>>> On 18/05/2010 08:14, Mark Stapper wrote: >>>> >>>> =20 >>>>> On 18/05/2010 00:22, Garrett Cooper wrote: >>>>> >>>>> >>>>> =20 >>>>>> On Mon, May 17, 2010 at 11:21 AM, Mark Stapper w= rote: >>>>>> >>>>>> >>>>>> >>>>>> =20 >>>>>>> I have the same problem. >>>>>>> I'll try compiling the driver in the kernel. >>>>>>> >>>>>>> =20 >>>>>> FWIW I've compiled the driver into the kernel for several >>>>>> iterations now and it works like a champ, so there's something wit= h >>>>>> the sound subsystem that isn't jiving properly when loading from >>>>>> modules... >>>>>> HTH, >>>>>> -Garrett >>>>>> >>>>>> >>>>>> >>>>>> =20 >>>>> Thanks for the info. >>>>> I've noticed that when I load the kernel module at startup (by addi= ng it >>>>> to loader.conf) chances of it working improve. >>>>> If I load it afterwards, the nice huff puff sounds come out of my >>>>> speaker again. >>>>> Compiling the new and improved kernel today. >>>>> Thanks for your help. >>>>> =20 >>>> I compiled the emu10kx driver into the kernel. >>>> That seemed to work, but now the hissing and buzzing is back. >>>> I really don't know what is going on anymore.. >>>> Any thoughts? >>>> >>>> =20 >>> What modules have you compiled and loaded? >>> =20 >> Kernel config and kldstat output pasted below >> >> =20 > [...] > > =20 >> =20 > Everything I saw there appeared sane (it would have been nice to grab > the -v output from kldstat, but that's ok...). Let's try doing the > following: > > 1. Add `options EMU_MTX_DEBUG' to your kernconf. > 2. Add set the sysctl: dev.emu10kx.0.debug=3D1 . > > Let's see if anything changes... > > Also, if you could provide some more hardware stats (say dmesg.boot > and/or devinfo -v) and version stats (I already know that you're > running amd64 from your kernel config) for the OS that would be > helpful as well. > > I'm going to try upgrading my kernel and I'll try these steps as well. > The locking between this driver and some other sound drivers isn't > exactly the same (interestingly enough this driver uses Giant locking > for some bits, while the ich one doesn't), and there were some past > bugs with other branches of *BSD's drivers related to pci bus > commands, etc; the other BSDs have dramatically different soundsystems > -- I assume the old school soundsystem, s.t. the issues are probably > not the same. > > Thanks, > -Garrett > =20 I'm building the new kernel as we e-mail. The option "EMU_MTX_DEBUG doesn't seem to excist thought. Used SND_DEBUG instead. here are the requested outputs: nexus0 apic0 ram0 acpi0 cpu0 pnpinfo _HID=3Dnone _UID=3D0 at handle=3D\_PR_.C000 acpi_perf0 powernow0 cpufreq0 cpu1 pnpinfo _HID=3Dnone _UID=3D0 at handle=3D\_PR_.C001 acpi_perf1 powernow1 cpufreq1 unknown pnpinfo _HID=3Dnone _UID=3D0 at handle=3D\_PR_.C002 unknown pnpinfo _HID=3Dnone _UID=3D0 at handle=3D\_PR_.C003 acpi_button0 pnpinfo _HID=3DPNP0C0C _UID=3D0 at handle=3D\_SB_.PWRB pcib0 pnpinfo _HID=3DPNP0A08 _UID=3D1 at handle=3D\_SB_.PCI0 pci0 unknown pnpinfo vendor=3D0x10de device=3D0x02f4 subvendor=3D0x10d= e subdevice=3D0x02f0 class=3D0x050000 at slot=3D0 function=3D0 unknown pnpinfo vendor=3D0x10de device=3D0x02fa subvendor=3D0x10d= e subdevice=3D0x02fa class=3D0x050000 at slot=3D0 function=3D1 unknown pnpinfo vendor=3D0x10de device=3D0x02fe subvendor=3D0x10d= e subdevice=3D0x02fe class=3D0x050000 at slot=3D0 function=3D2 unknown pnpinfo vendor=3D0x10de device=3D0x02f8 subvendor=3D0x10d= e subdevice=3D0x02f8 class=3D0x050000 at slot=3D0 function=3D3 unknown pnpinfo vendor=3D0x10de device=3D0x02f9 subvendor=3D0x10d= e subdevice=3D0x02f9 class=3D0x050000 at slot=3D0 function=3D4 unknown pnpinfo vendor=3D0x10de device=3D0x02ff subvendor=3D0x10d= e subdevice=3D0x02ff class=3D0x050000 at slot=3D0 function=3D5 unknown pnpinfo vendor=3D0x10de device=3D0x027f subvendor=3D0x10d= e subdevice=3D0x027f class=3D0x050000 at slot=3D0 function=3D6 unknown pnpinfo vendor=3D0x10de device=3D0x027e subvendor=3D0x10d= e subdevice=3D0x027e class=3D0x050000 at slot=3D0 function=3D7 pcib1 pnpinfo vendor=3D0x10de device=3D0x02fb subvendor=3D0x10de subdevice=3D0x0000 class=3D0x060400 at slot=3D4 function=3D0 handle=3D\_S= B_.PCI0.XVRA pci1 vgapci0 pnpinfo vendor=3D0x10de device=3D0x0193 subvendor=3D0= x10de subdevice=3D0x0420 class=3D0x030000 at slot=3D0 function=3D0 vgapm0 nvidia0 drm0 unknown pnpinfo vendor=3D0x10de device=3D0x0369 subvendor=3D0x10d= e subdevice=3D0xcb84 class=3D0x050000 at slot=3D8 function=3D0 isab0 pnpinfo vendor=3D0x10de device=3D0x0360 subvendor=3D0x10de subdevice=3D0xcb84 class=3D0x060100 at slot=3D9 function=3D0 handle=3D\_S= B_.PCI0.LEG0 isa0 orm0 sc0 vga0 atkbdc0 atkbd0 psm0 ppc0 uart1 unknown pnpinfo vendor=3D0x10de device=3D0x0368 subvendor=3D0x10d= e subdevice=3D0xcb84 class=3D0x0c0500 at slot=3D9 function=3D1 handle=3D\_S= B_.PCI0.SMB0 unknown pnpinfo vendor=3D0x10de device=3D0x036b subvendor=3D0x000= 0 subdevice=3D0x0000 class=3D0x0b4000 at slot=3D9 function=3D3 ohci0 pnpinfo vendor=3D0x10de device=3D0x036c subvendor=3D0x10de subdevice=3D0xcb84 class=3D0x0c0310 at slot=3D10 function=3D0 handle=3D\_= SB_.PCI0.USB0 usbus0 uhub0 uhub2 pnpinfo vendor=3D0x0557 product=3D0x7000 devclass=3D0= x09 devsubclass=3D0x00 sernum=3D"" release=3D0x0100 intclass=3D0x09 intsubcla= ss=3D0x00 at port=3D6 interface=3D0 ukbd0 pnpinfo vendor=3D0x0603 product=3D0x00f2 devclass=3D= 0x00 devsubclass=3D0x00 sernum=3D"" release=3D0x0112 intclass=3D0x03 intsubcla= ss=3D0x01 at port=3D1 interface=3D0 uhid0 pnpinfo vendor=3D0x0603 product=3D0x00f2 devclass=3D= 0x00 devsubclass=3D0x00 sernum=3D"" release=3D0x0112 intclass=3D0x03 intsubcla= ss=3D0x00 at port=3D1 interface=3D1 ums0 pnpinfo vendor=3D0x046d product=3D0xc404 devclass=3D0x= 00 devsubclass=3D0x00 sernum=3D"" release=3D0x0220 intclass=3D0x03 intsubcla= ss=3D0x01 at port=3D5 interface=3D0 ehci0 pnpinfo vendor=3D0x10de device=3D0x036d subvendor=3D0x10de subdevice=3D0xcb84 class=3D0x0c0320 at slot=3D10 function=3D1 handle=3D\_= SB_.PCI0.USB2 usbus1 uhub1 atapci0 pnpinfo vendor=3D0x10de device=3D0x036e subvendor=3D0x10d= e subdevice=3D0xcb84 class=3D0x01018a at slot=3D12 function=3D0 handle=3D\_= SB_.PCI0.IDE0 ata0 acd0 ata1 atapci1 pnpinfo vendor=3D0x10de device=3D0x037f subvendor=3D0x10d= e subdevice=3D0xcb84 class=3D0x010185 at slot=3D13 function=3D0 handle=3D\_= SB_.PCI0.SAT1 ata2 ad4 subdisk4 ata3 ad6 subdisk6 atapci2 pnpinfo vendor=3D0x10de device=3D0x037f subvendor=3D0x10d= e subdevice=3D0xcb84 class=3D0x010185 at slot=3D13 function=3D1 handle=3D\_= SB_.PCI0.SAT2 ata4 ad8 subdisk8 ata5 ad10 subdisk10 atapci3 pnpinfo vendor=3D0x10de device=3D0x037f subvendor=3D0x10d= e subdevice=3D0xcb84 class=3D0x010185 at slot=3D13 function=3D2 handle=3D\_= SB_.PCI0.SAT3 ata6 ata7 acd1 pcib2 pnpinfo vendor=3D0x10de device=3D0x0370 subvendor=3D0x10de subdevice=3D0xcb84 class=3D0x060401 at slot=3D14 function=3D0 handle=3D\_= SB_.PCI0.HUB0 pci2 em0 pnpinfo vendor=3D0x8086 device=3D0x107c subvendor=3D0x808= 6 subdevice=3D0x1376 class=3D0x020000 at slot=3D6 function=3D0 emu10kx0 pnpinfo vendor=3D0x1102 device=3D0x0008 subvendor=3D0x1102 subdevice=3D0x1021 class=3D0x040100 at slot=3D7 functi= on=3D0 pcm0 pcm1 pcm2 pcm3 pcm4 fwohci0 pnpinfo vendor=3D0x1106 device=3D0x3044 subvendor=3D0= x15bd subdevice=3D0x1006 class=3D0x0c0010 at slot=3D9 function=3D0 firewire0 fwe0 fwip0 dcons_crom0 nfe0 pnpinfo vendor=3D0x10de device=3D0x0373 subvendor=3D0x10de subdevice=3D0xcb84 class=3D0x068000 at slot=3D16 function=3D0 handle=3D\_= SB_.PCI0.MMAC miibus0 ciphy0 pnpinfo oui=3D0x1c1 model=3D0x2 rev=3D0x0 at phyno=3D1= nfe1 pnpinfo vendor=3D0x10de device=3D0x0373 subvendor=3D0x10de subdevice=3D0xcb84 class=3D0x068000 at slot=3D17 function=3D0 handle=3D\_= SB_.PCI0.MAC1 miibus1 ciphy1 pnpinfo oui=3D0x1c1 model=3D0x2 rev=3D0x0 at phyno=3D0= pcib3 pnpinfo vendor=3D0x10de device=3D0x0376 subvendor=3D0x10de subdevice=3D0x0000 class=3D0x060400 at slot=3D18 function=3D0 handle=3D\_= SB_.PCI0.XVR5 pci3 pcib4 pnpinfo vendor=3D0x10de device=3D0x0374 subvendor=3D0x10de subdevice=3D0x0000 class=3D0x060400 at slot=3D20 function=3D0 handle=3D\_= SB_.PCI0.XVR3 pci4 pcib5 pnpinfo vendor=3D0x10de device=3D0x0378 subvendor=3D0x10de subdevice=3D0x0000 class=3D0x060400 at slot=3D21 function=3D0 handle=3D\_= SB_.PCI0.XVR2 pci5 pcib6 pnpinfo vendor=3D0x10de device=3D0x0375 subvendor=3D0x10de subdevice=3D0x0000 class=3D0x060400 at slot=3D22 function=3D0 handle=3D\_= SB_.PCI0.XVR1 pci6 pcib7 pnpinfo vendor=3D0x10de device=3D0x0377 subvendor=3D0x10de subdevice=3D0x0000 class=3D0x060400 at slot=3D23 function=3D0 handle=3D\_= SB_.PCI0.XVR0 pci7 hostb0 pnpinfo vendor=3D0x1022 device=3D0x1100 subvendor=3D0x0000= subdevice=3D0x0000 class=3D0x060000 at slot=3D24 function=3D0 hostb1 pnpinfo vendor=3D0x1022 device=3D0x1101 subvendor=3D0x0000= subdevice=3D0x0000 class=3D0x060000 at slot=3D24 function=3D1 hostb2 pnpinfo vendor=3D0x1022 device=3D0x1102 subvendor=3D0x0000= subdevice=3D0x0000 class=3D0x060000 at slot=3D24 function=3D2 hostb3 pnpinfo vendor=3D0x1022 device=3D0x1103 subvendor=3D0x0000= subdevice=3D0x0000 class=3D0x060000 at slot=3D24 function=3D3 amdtemp0 acpi_sysresource0 pnpinfo _HID=3DPNP0C02 _UID=3D5 at handle=3D\_SB_.P= CI0.MBIO unknown pnpinfo _HID=3Dnone _UID=3D0 at handle=3D\_SB_.PCI0.SAT1.PRI0= unknown pnpinfo _HID=3Dnone _UID=3D0 at handle=3D\_SB_.PCI0.SAT1.PRI0= =2EMAST unknown pnpinfo _HID=3Dnone _UID=3D0 at handle=3D\_SB_.PCI0.SAT1.SEC0= unknown pnpinfo _HID=3Dnone _UID=3D0 at handle=3D\_SB_.PCI0.SAT1.SEC0= =2EMAST unknown pnpinfo _HID=3Dnone _UID=3D0 at handle=3D\_SB_.PCI0.SAT2.PRI0= unknown pnpinfo _HID=3Dnone _UID=3D0 at handle=3D\_SB_.PCI0.SAT2.PRI0= =2EMAST unknown pnpinfo _HID=3Dnone _UID=3D0 at handle=3D\_SB_.PCI0.SAT2.SEC0= unknown pnpinfo _HID=3Dnone _UID=3D0 at handle=3D\_SB_.PCI0.SAT2.SEC0= =2EMAST unknown pnpinfo _HID=3Dnone _UID=3D0 at handle=3D\_SB_.PCI0.SAT3.PRI0= unknown pnpinfo _HID=3Dnone _UID=3D0 at handle=3D\_SB_.PCI0.SAT3.PRI0= =2EMAST unknown pnpinfo _HID=3Dnone _UID=3D0 at handle=3D\_SB_.PCI0.SAT3.SEC0= unknown pnpinfo _HID=3Dnone _UID=3D0 at handle=3D\_SB_.PCI0.SAT3.SEC0= =2EMAST unknown pnpinfo _HID=3Dnone _UID=3D0 at handle=3D\_SB_.PCI0.IDE0.PRI0= unknown pnpinfo _HID=3Dnone _UID=3D0 at handle=3D\_SB_.PCI0.IDE0.PRI0= =2EMAST unknown pnpinfo _HID=3Dnone _UID=3D0 at handle=3D\_SB_.PCI0.IDE0.PRI0= =2ESLAV unknown pnpinfo _HID=3Dnone _UID=3D0 at handle=3D\_SB_.PCI0.IDE0.SEC0= unknown pnpinfo _HID=3Dnone _UID=3D0 at handle=3D\_SB_.PCI0.IDE0.SEC0= =2EMAST unknown pnpinfo _HID=3Dnone _UID=3D0 at handle=3D\_SB_.PCI0.IDE0.SEC0= =2ESLAV unknown pnpinfo _HID=3Dnone _UID=3D0 at handle=3D\_SB_.PCI0.XVR4 unknown pnpinfo _HID=3Dnone _UID=3D0 at handle=3D\_SB_.PCI0.XVRB unknown pnpinfo _HID=3Dnone _UID=3D0 at handle=3D\_SB_.PCI0.XVRC acpi_sysresource1 pnpinfo _HID=3DPNP0C02 _UID=3D1 at handle=3D\_SB_.PCI0.LEG0.SYSR unknown pnpinfo _HID=3DPNP0000 _UID=3D0 at handle=3D\_SB_.PCI0.LEG0.P= IC_ atdma0 pnpinfo _HID=3DPNP0200 _UID=3D0 at handle=3D\_SB_.PCI0.LEG0.DM= A1 attimer0 pnpinfo _HID=3DPNP0100 _UID=3D0 at handle=3D\_SB_.PCI0.LEG0.= TMR_ unknown pnpinfo _HID=3DPNP0103 _UID=3D0 at handle=3D\_SB_.PCI0.LEG0.H= PET atrtc0 pnpinfo _HID=3DPNP0B00 _UID=3D0 at handle=3D\_SB_.PCI0.LEG0.RT= C_ unknown pnpinfo _HID=3DPNP0800 _UID=3D0 at handle=3D\_SB_.PCI0.LEG0.S= PKR fpupnp0 pnpinfo _HID=3DPNP0C04 _UID=3D0 at handle=3D\_SB_.PCI0.LEG0.C= OPR fdc0 pnpinfo _HID=3DPNP0700 _UID=3D0 at handle=3D\_SB_.PCI0.LEG0.FDC0= fd0 fd1 uart0 pnpinfo _HID=3DPNP0501 _UID=3D1 at handle=3D\_SB_.PCI0.LEG0.UAR= 1 unknown pnpinfo _HID=3DPNP0501 _UID=3D2 at handle=3D\_SB_.PCI0.LEG0.U= AR2 unknown pnpinfo _HID=3DPNP0510 _UID=3D0 at handle=3D\_SB_.PCI0.LEG0.I= RDA unknown pnpinfo _HID=3DPNP0F13 _UID=3D0 at handle=3D\_SB_.PCI0.LEG0.P= S2M unknown pnpinfo _HID=3DPNP0303 _UID=3D0 at handle=3D\_SB_.PCI0.LEG0.P= S2K unknown pnpinfo _HID=3DPNP0C02 _UID=3D3 at handle=3D\_SB_.PCI0.LEG0.P= SMR unknown pnpinfo _HID=3Dnone _UID=3D0 at handle=3D\_SB_.PCI0.AZAD unknown pnpinfo _HID=3DNVRAIDBUS _UID=3D0 at handle=3D\_SB_.PCI0.NVRB= pci_link0 pnpinfo _HID=3DPNP0C0F _UID=3D1 at handle=3D\_SB_.PCI0.LNK1= pci_link1 pnpinfo _HID=3DPNP0C0F _UID=3D2 at handle=3D\_SB_.PCI0.LNK2= pci_link2 pnpinfo _HID=3DPNP0C0F _UID=3D3 at handle=3D\_SB_.PCI0.LNK3= pci_link3 pnpinfo _HID=3DPNP0C0F _UID=3D4 at handle=3D\_SB_.PCI0.LNK4= pci_link4 pnpinfo _HID=3DPNP0C0F _UID=3D5 at handle=3D\_SB_.PCI0.LNK5= pci_link5 pnpinfo _HID=3DPNP0C0F _UID=3D6 at handle=3D\_SB_.PCI0.LNK6= pci_link6 pnpinfo _HID=3DPNP0C0F _UID=3D7 at handle=3D\_SB_.PCI0.LNK7= pci_link7 pnpinfo _HID=3DPNP0C0F _UID=3D8 at handle=3D\_SB_.PCI0.LNK8= pci_link8 pnpinfo _HID=3DPNP0C0F _UID=3D9 at handle=3D\_SB_.PCI0.LP2P= pci_link9 pnpinfo _HID=3DPNP0C0F _UID=3D10 at handle=3D\_SB_.PCI0.LUB= A pci_link10 pnpinfo _HID=3DPNP0C0F _UID=3D11 at handle=3D\_SB_.PCI0.LM= AC pci_link11 pnpinfo _HID=3DPNP0C0F _UID=3D12 at handle=3D\_SB_.PCI0.LM= C1 pci_link12 pnpinfo _HID=3DPNP0C0F _UID=3D13 at handle=3D\_SB_.PCI0.LA= ZA pci_link13 pnpinfo _HID=3DPNP0C0F _UID=3D14 at handle=3D\_SB_.PCI0.LP= MU pci_link14 pnpinfo _HID=3DPNP0C0F _UID=3D15 at handle=3D\_SB_.PCI0.LS= MB pci_link15 pnpinfo _HID=3DPNP0C0F _UID=3D16 at handle=3D\_SB_.PCI0.LU= B2 pci_link16 pnpinfo _HID=3DPNP0C0F _UID=3D17 at handle=3D\_SB_.PCI0.LI= DE pci_link17 pnpinfo _HID=3DPNP0C0F _UID=3D18 at handle=3D\_SB_.PCI0.LS= ID pci_link18 pnpinfo _HID=3DPNP0C0F _UID=3D19 at handle=3D\_SB_.PCI0.LF= ID pci_link19 pnpinfo _HID=3DPNP0C0F _UID=3D20 at handle=3D\_SB_.PCI0.LS= A2 pci_link20 pnpinfo _HID=3DPNP0C0F _UID=3D21 at handle=3D\_SB_.PCI0.AP= C1 pci_link21 pnpinfo _HID=3DPNP0C0F _UID=3D22 at handle=3D\_SB_.PCI0.AP= C2 pci_link22 pnpinfo _HID=3DPNP0C0F _UID=3D23 at handle=3D\_SB_.PCI0.AP= C3 pci_link23 pnpinfo _HID=3DPNP0C0F _UID=3D24 at handle=3D\_SB_.PCI0.AP= C4 pci_link24 pnpinfo _HID=3DPNP0C0F _UID=3D25 at handle=3D\_SB_.PCI0.AP= C5 pci_link25 pnpinfo _HID=3DPNP0C0F _UID=3D26 at handle=3D\_SB_.PCI0.AP= C6 pci_link26 pnpinfo _HID=3DPNP0C0F _UID=3D27 at handle=3D\_SB_.PCI0.AP= C7 pci_link27 pnpinfo _HID=3DPNP0C0F _UID=3D28 at handle=3D\_SB_.PCI0.AP= C8 pci_link28 pnpinfo _HID=3DPNP0C0F _UID=3D29 at handle=3D\_SB_.PCI0.AP= CF pci_link29 pnpinfo _HID=3DPNP0C0F _UID=3D30 at handle=3D\_SB_.PCI0.AP= CH pci_link30 pnpinfo _HID=3DPNP0C0F _UID=3D31 at handle=3D\_SB_.PCI0.AM= C1 pci_link31 pnpinfo _HID=3DPNP0C0F _UID=3D32 at handle=3D\_SB_.PCI0.AP= MU pci_link32 pnpinfo _HID=3DPNP0C0F _UID=3D33 at handle=3D\_SB_.PCI0.AA= ZA pci_link33 pnpinfo _HID=3DPNP0C0F _UID=3D34 at handle=3D\_SB_.PCI0.AP= CS pci_link34 pnpinfo _HID=3DPNP0C0F _UID=3D35 at handle=3D\_SB_.PCI0.AP= CL pci_link35 pnpinfo _HID=3DPNP0C0F _UID=3D36 at handle=3D\_SB_.PCI0.AP= CM pci_link36 pnpinfo _HID=3DPNP0C0F _UID=3D37 at handle=3D\_SB_.PCI0.AP= CZ pci_link37 pnpinfo _HID=3DPNP0C0F _UID=3D38 at handle=3D\_SB_.PCI0.AP= SI pci_link38 pnpinfo _HID=3DPNP0C0F _UID=3D39 at handle=3D\_SB_.PCI0.AP= SJ pci_link39 pnpinfo _HID=3DPNP0C0F _UID=3D40 at handle=3D\_SB_.PCI0.AS= A2 acpi_sysresource2 pnpinfo _HID=3DPNP0C02 _UID=3D4 at handle=3D\_SB_.P= CI0.EXPL acpi_sysresource3 pnpinfo _HID=3DPNP0C01 _UID=3D0 at handle=3D\_SB_.M= EM_ unknown pnpinfo _HID=3DPNP0C0B _UID=3D0 at handle=3D\_TZ_.FAN_ acpi_tz0 pnpinfo _HID=3Dnone _UID=3D0 at handle=3D\_TZ_.THRM acpi_timer0 pnpinfo unknown at unknown acpi_hpet0 pnpinfo unknown at unknown Copyright (c) 1992-2010 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved.= FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.0-STABLE #0: Tue May 18 19:37:30 CEST 2010 root@:/usr/obj/usr/src/sys/mario amd64 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 5600+ (2812.98-MHz K8-class CPU) Origin =3D "AuthenticAMD" Id =3D 0x40f33 Family =3D f Model =3D 43=20 Stepping =3D 3 =20 Features=3D0x178bfbff Features2=3D0x2001 AMD Features=3D0xea500800 AMD Features2=3D0x1f real memory =3D 4831838208 (4608 MB) avail memory =3D 4104052736 (3913 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Changing APIC ID to 4 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) ACPI Error (psargs-0464): [ROM1] Namespace lookup failure, AE_NOT_FOUND ACPI Error (psparse-0633): Method parse/execution failed [\\_SB_.MEM_._CRS] (Node 0xffffff000260d460), AE_NOT_FOUND Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 cpu0: on acpi0 cpu1: on acpi0 acpi_hpet0: iomem 0xfeff0000-0xfeff03ff on acpi0 Timecounter "HPET" frequency 25000000 Hz quality 900 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: at device 0.0 (no driver attached) pci0: at device 0.1 (no driver attached) pci0: at device 0.2 (no driver attached) pci0: at device 0.3 (no driver attached) pci0: at device 0.4 (no driver attached) pci0: at device 0.5 (no driver attached) pci0: at device 0.6 (no driver attached) pci0: at device 0.7 (no driver attached) pcib1: at device 4.0 on pci0 pci1: on pcib1 vgapci0: port 0xac00-0xac7f mem 0xfa000000-0xfaffffff,0xe0000000-0xefffffff,0xf8000000-0xf9ffffff irq 16 at device 0.0 on pci1 nvidia0: on vgapci0 vgapci0: child nvidia0 requested pci_enable_busmaster vgapci0: child nvidia0 requested pci_enable_io vgapci0: child nvidia0 requested pci_enable_io nvidia0: [ITHREAD] pci0: at device 8.0 (no driver attached) isab0: port 0x1d00-0x1dff at device 9.0 on pci0 isa0: on isab0 pci0: at device 9.1 (no driver attached) pci0: at device 9.3 (no driver attached) ohci0: mem 0xfe02f000-0xfe02ffff irq 21 at device 10.0 on pci0 ohci0: [ITHREAD] usbus0: on ohci0 ehci0: mem 0xfe02e000-0xfe02e0ff irq 22 at device 10.1 on pci0 ehci0: [ITHREAD] usbus1: EHCI version 1.0 usbus1: on ehci0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xf400-0xf40f at device 12.0 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] atapci1: port 0x9f0-0x9f7,0xbf0-0xbf3,0x970-0x977,0xb70-0xb73,0xe000-0xe00f mem 0xfe02d000-0xfe02dfff irq 23 at device 13.0 on pci0 atapci1: [ITHREAD] ata2: on atapci1 ata2: [ITHREAD] ata3: on atapci1 ata3: [ITHREAD] atapci2: port 0x9e0-0x9e7,0xbe0-0xbe3,0x960-0x967,0xb60-0xb63,0xcc00-0xcc0f mem 0xfe02c000-0xfe02cfff irq 20 at device 13.1 on pci0 atapci2: [ITHREAD] ata4: on atapci2 ata4: [ITHREAD] ata5: on atapci2 ata5: [ITHREAD] atapci3: port 0xc800-0xc807,0xc400-0xc403,0xc000-0xc007,0xbc00-0xbc03,0xb800-0xb80f mem 0xfe02b000-0xfe02bfff irq 21 at device 13.2 on pci0 atapci3: [ITHREAD] ata6: on atapci3 ata6: [ITHREAD] ata7: on atapci3 ata7: [ITHREAD] pcib2: at device 14.0 on pci0 pci2: on pcib2 em0: port 0x9c00-0x9c3f mem 0xfdfa0000-0xfdfbffff,0xfdfc0000-0xfdfdffff irq 18 at device 6.0 on pci2 em0: [FILTER] em0: Ethernet address: 00:1b:21:4b:8b:85 emu10kx0: port 0x9800-0x983f irq 19 at device 7.0 on pci2 emu10kx0: [ITHREAD] pcm0: on emu10kx0 pcm0: pcm1: on emu10kx0 pcm2: on emu10kx0 pcm3: on emu10kx0 pcm4: on emu10kx0 fwohci0: port 0x9400-0x947f mem 0xfdfff000-0xfdfff7ff irq 17 at device 9.0 on pci2 fwohci0: [ITHREAD] fwohci0: OHCI version 1.10 (ROM=3D1) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:01:29:20:00:05:ed:ce fwohci0: Phy 1394a available S400, 2 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 02:01:29:05:ed:ce fwe0: Ethernet address: 02:01:29:05:ed:ce fwip0: on firewire0 fwip0: Firewire address: 00:01:29:20:00:05:ed:ce @ 0xfffe00000000, S400, maxrec 2048 dcons_crom0: on firewire0 dcons_crom0: bus_addr 0x182c000 fwohci0: Initiate bus reset fwohci0: fwohci_intr_core: BUS reset fwohci0: fwohci_intr_core: node_id=3D0x00000000, SelfID Count=3D1, CYCLEMASTER mode nfe0: port 0xb400-0xb407 mem 0xfe02a000-0xfe02afff,0xfe029000-0xfe0290ff,0xfe028000-0xfe02800f irq 22 at device 16.0 on pci0 miibus0: on nfe0 ciphy0: PHY 1 on miibus0 ciphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto nfe0: Ethernet address: 00:01:29:d7:34:02 nfe0: [FILTER] nfe0: [FILTER] nfe0: [FILTER] nfe0: [FILTER] nfe0: [FILTER] nfe0: [FILTER] nfe0: [FILTER] nfe0: [FILTER] nfe1: port 0xb000-0xb007 mem 0xfe027000-0xfe027fff,0xfe026000-0xfe0260ff,0xfe025000-0xfe02500f irq 23 at device 17.0 on pci0 miibus1: on nfe1 ciphy1: PHY 0 on miibus1 ciphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto nfe1: Ethernet address: 00:01:29:d7:34:01 nfe1: [FILTER] nfe1: [FILTER] nfe1: [FILTER] nfe1: [FILTER] nfe1: [FILTER] nfe1: [FILTER] nfe1: [FILTER] nfe1: [FILTER] pcib3: at device 18.0 on pci0 pci3: on pcib3 pcib4: at device 20.0 on pci0 pci4: on pcib4 pcib5: at device 21.0 on pci0 pci5: on pcib5 pcib6: at device 22.0 on pci0 pci6: on pcib6 pcib7: at device 23.0 on pci0 pci7: on pcib7 amdtemp0: on hostb3 acpi_tz0: on acpi0 ACPI Warning for \\_TZ_.THRM._PSL: Return Package type mismatch at index 0 - found [NULL Object Descriptor], expected Reference (20100331/nspredef-1197) atrtc0: port 0x70-0x73 on acpi0 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acp= i0 fdc0: [FILTER] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart0: [FILTER] orm0: at iomem 0xd0000-0xd0fff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=3D0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0= atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] powernow0: on cpu0 powernow1: on cpu1 Timecounters tick every 1.000 msec vboxdrv: fAsync=3D0 offMin=3D0xa4 offMax=3D0x23e supdrvGipCreate: omni timer not supported, falling back to synchronous mo= de firewire0: 1 nodes, maxhop <=3D 0 cable IRM irm(0) (me) firewire0: bus manager 0 usbus0: 12Mbps Full Speed USB v1.0 usbus1: 480Mbps High Speed USB v2.0 acd0: DMA limited to UDMA33, device found non-ATA66 cable ugen0.1: at usbus0 uhub0: on usbus0= ugen1.1: at usbus1 uhub1: on usbus1= acd0: DVDR at ata0-master UDMA33 ad4: 476940MB at ata2-master UDMA100 SATA 3Gb= /s ad6: 953869MB at ata3-master UDMA100 SATA 3Gb/s ad8: 476940MB at ata4-master UDMA100 SATA 3Gb/s ad10: 305245MB at ata5-master UDMA100 SATA 3Gb/s acd1: DVDR at ata7-master UDMA100 SATA 1.5Gb/s SMP: AP CPU #1 Launched! uhub0: 10 ports with 10 removable, self powered uhub1: 10 ports with 10 removable, self powered ugen0.2: at usbus0 uhub2: on usbus0 uhub2: 4 ports with 4 removable, self powered ugen0.3: at usbus0 ukbd0: on usbus0= kbd2 at ukbd0 uhid0: on usbus0= acd1: FAILURE - READ_BIG MEDIUM ERROR asc=3D0x02 ascq=3D0x00 Trying to mount root from ufs:/dev/ad10s1a ZFS NOTICE: Prefetch is disabled by default if less than 4GB of RAM is present; to enable, add "vfs.zfs.prefetch_disable=3D0" to /boot/loader.conf. ZFS filesystem version 3 ZFS storage pool version 14 vboxnet0: Ethernet address: 0a:00:27:00:00:00 acd0: FAILURE - ATA_IDENTIFY status=3D51 error=3D4 LBA=3D0 nfe1: link state changed to UP lagg0: link state changed to UP acd1: FAILURE - ATA_IDENTIFY status=3D51 error=3D4 LBA=3D0 fuse4bsd: version 0.3.9-pre1, FUSE ABI 7.8 ugen0.4: at usbus0 ums0: on usbus0 ums0: 3 buttons and [XYZ] coordinates ID=3D0 --------------enigAB6E51D7A83ED1C9BA8AA465 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkwEvcIACgkQN9xNqOOVnWCApwCaA9kzEsmHcruIRP2yCr9EOvCG nlwAmwYsZ1ogJEYs/QaBVxRz4VSuI+ji =BWGj -----END PGP SIGNATURE----- --------------enigAB6E51D7A83ED1C9BA8AA465-- From owner-freebsd-stable@FreeBSD.ORG Tue Jun 1 09:45:09 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6BAAD1065674 for ; Tue, 1 Jun 2010 09:45:09 +0000 (UTC) (envelope-from O.Seibert@cs.ru.nl) Received: from kookpunt.science.ru.nl (kookpunt.science.ru.nl [131.174.30.61]) by mx1.freebsd.org (Postfix) with ESMTP id E580B8FC1E for ; Tue, 1 Jun 2010 09:45:08 +0000 (UTC) Received: from twoquid.cs.ru.nl (twoquid.cs.ru.nl [131.174.142.38]) by kookpunt.science.ru.nl (8.13.7/5.31) with ESMTP id o519j6Jx011006; Tue, 1 Jun 2010 11:45:06 +0200 (MEST) Received: by twoquid.cs.ru.nl (Postfix, from userid 4100) id 492802E063; Tue, 1 Jun 2010 11:45:06 +0200 (CEST) Date: Tue, 1 Jun 2010 11:45:06 +0200 From: Olaf Seibert To: freebsd-stable@freebsd.org Message-ID: <20100601094506.GA25207@twoquid.cs.ru.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.19 (2009-01-05) X-Spam-Score: -0.669 () ALL_TRUSTED,BAYES_50,DNS_FROM_OPENWHOIS X-Scanned-By: MIMEDefang 2.63 on 131.174.30.61 Subject: freebsd-update with non-GENERIC kerrnel X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 01 Jun 2010 09:45:09 -0000 I find the way freebsd-update handles a system that runs a non-GENERIC kernel less than helpful. It is doing this: | fourquid.3:~$ sudo freebsd-update upgrade -r 8.1-BETA1 | Password: | Looking up update.FreeBSD.org mirrors... 3 mirrors found. | Fetching metadata signature for 8.0-RELEASE from update5.FreeBSD.org... done. | Fetching metadata index... done. | Fetching 2 metadata patches.. done. | Applying metadata patches... done. | Inspecting system... done. | | WARNING: This system is running a "fourquid" kernel, which is not a | kernel configuration distributed as part of FreeBSD 8.0-RELEASE. | This kernel will not be updated: you MUST update the kernel manually | before running "/usr/sbin/freebsd-update install". | | The following components of FreeBSD seem to be installed: | src/base src/bin src/cddl src/contrib src/crypto src/etc src/games | src/gnu src/include src/krb5 src/lib src/libexec src/release src/rescue | src/sbin src/secure src/share src/sys src/tools src/ubin src/usbin | world/base world/catpages world/dict world/doc world/games world/info | world/lib32 world/manpages world/proflibs | | The following components of FreeBSD do not seem to be installed: | kernel/generic | | Does this look reasonable (y/n)? n I do have the kernel sources installed, so I would like to have them updated. I don't even mind to have a GENERIC kernel temporarily installed, until I compile my own (fortunately, they are not that different). It is nice that it tells me that I "MUST update the kernel manually", but it gives me no help in getting the sources and doing that. (Can the new kernel even be built in all cases with old tools? NetBSD offers a nice cross-building system for that.) For my previous update to 8.0-RELEASE-p2 I patched freebsd-update simply to think that my kernel *is* GENERIC, --- /usr/sbin/freebsd-update 2009-12-22 17:16:01.000000000 +0100 +++ /tmp/freebsd-update 2010-05-11 10:35:05.000000000 +0200 @@ -631,6 +631,7 @@ # we're running an SMP kernel. This mis-identification is a bug # which was fixed in 6.2-STABLE. KERNCONF=`uname -i` + KERNCONF=GENERIC if [ ${KERNCONF} = "SMP-GENERIC" ]; then KERNCONF=SMP fi but that seems riskier as updates get a bit bigger. The official way seems to be to reboot using GENERIC, upgrade (with a reboot with new GENERIC), rebuild new CUSTOM kernel, reboot again. At least the first reboot ought to be avoided... -Olaf. -- From owner-freebsd-stable@FreeBSD.ORG Tue Jun 1 09:57:43 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D1344106566C for ; Tue, 1 Jun 2010 09:57:43 +0000 (UTC) (envelope-from nr1c0re@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.159]) by mx1.freebsd.org (Postfix) with ESMTP id 55B9B8FC0A for ; Tue, 1 Jun 2010 09:57:42 +0000 (UTC) Received: by fg-out-1718.google.com with SMTP id d23so1318423fga.13 for ; Tue, 01 Jun 2010 02:57:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=w513zRPvvw2+SHAb5BM2UbffOYzbFecJEAm2JAbgnJg=; b=DBTj8gDtzXwMk8bgsmGdzQ724I+3hkPHVCONpfjYJB0tw/LsxG6tx+jCN9KvlBl7Hw g9OKm8aA4OxdkTikoFzD4lhCYzJeA3VwQ5x8odFOOJbz4l0Y2S3BGJ40dj9e8dhsYl7u J5C3pfK5Ec9qOZh1MUFN1hfD7ylIM+RttKd5E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=d8Mzd4rS+jdWdeCMZL5c82e+aI5XV8WH6ieItsvWhNYK1q3dN3OsEioOVY2TPb1Lb9 JmaKIDuHtyYz18lLGhdWw5Ae61/jMlYe8lFFJCY3HW/Lp7fmzu7/G4ZbxQvGgMDKd1J4 +EGfFD2+sCGLXeNIhiTuXPxaDIvbfzjz9luh4= MIME-Version: 1.0 Received: by 10.87.1.2 with SMTP id d2mr10904698fgi.34.1275386260520; Tue, 01 Jun 2010 02:57:40 -0700 (PDT) Received: by 10.86.9.6 with HTTP; Tue, 1 Jun 2010 02:57:40 -0700 (PDT) In-Reply-To: <20100601094506.GA25207@twoquid.cs.ru.nl> References: <20100601094506.GA25207@twoquid.cs.ru.nl> Date: Tue, 1 Jun 2010 13:57:40 +0400 Message-ID: From: c0re To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: freebsd-update with non-GENERIC kerrnel X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 01 Jun 2010 09:57:44 -0000 freebsd-update made for only GENERIC kerndel due to binary diff patches. After you rebuild world and kernel you'll be not able to apply binary patches. 2010/6/1 Olaf Seibert > I find the way freebsd-update handles a system that runs a non-GENERIC > kernel less than helpful. > > It is doing this: > > | fourquid.3:~$ sudo freebsd-update upgrade -r 8.1-BETA1 > | Password: > | Looking up update.FreeBSD.org mirrors... 3 mirrors found. > | Fetching metadata signature for 8.0-RELEASE from update5.FreeBSD.org... > done. > | Fetching metadata index... done. > | Fetching 2 metadata patches.. done. > | Applying metadata patches... done. > | Inspecting system... done. > | > | WARNING: This system is running a "fourquid" kernel, which is not a > | kernel configuration distributed as part of FreeBSD 8.0-RELEASE. > | This kernel will not be updated: you MUST update the kernel manually > | before running "/usr/sbin/freebsd-update install". > | > | The following components of FreeBSD seem to be installed: > | src/base src/bin src/cddl src/contrib src/crypto src/etc src/games > | src/gnu src/include src/krb5 src/lib src/libexec src/release src/rescue > | src/sbin src/secure src/share src/sys src/tools src/ubin src/usbin > | world/base world/catpages world/dict world/doc world/games world/info > | world/lib32 world/manpages world/proflibs > | > | The following components of FreeBSD do not seem to be installed: > | kernel/generic > | > | Does this look reasonable (y/n)? n > > I do have the kernel sources installed, so I would like to have them > updated. I don't even mind to have a GENERIC kernel temporarily > installed, until I compile my own (fortunately, they are not that > different). > > It is nice that it tells me that I "MUST update the kernel manually", > but it gives me no help in getting the sources and doing that. (Can the > new kernel even be built in all cases with old tools? NetBSD offers a > nice cross-building system for that.) > > For my previous update to 8.0-RELEASE-p2 I patched freebsd-update simply > to think that my kernel *is* GENERIC, > > --- /usr/sbin/freebsd-update 2009-12-22 17:16:01.000000000 +0100 > +++ /tmp/freebsd-update 2010-05-11 10:35:05.000000000 +0200 > @@ -631,6 +631,7 @@ > # we're running an SMP kernel. This mis-identification is a bug > # which was fixed in 6.2-STABLE. > KERNCONF=`uname -i` > + KERNCONF=GENERIC > if [ ${KERNCONF} = "SMP-GENERIC" ]; then > KERNCONF=SMP > fi > > but that seems riskier as updates get a bit bigger. > > The official way seems to be to reboot using GENERIC, upgrade (with a > reboot with new GENERIC), rebuild new CUSTOM kernel, reboot again. At > least the first reboot ought to be avoided... > > -Olaf. > -- > _______________________________________________ > 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 Jun 1 11:40:32 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B35991065672 for ; Tue, 1 Jun 2010 11:40:32 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) by mx1.freebsd.org (Postfix) with ESMTP id 6DEA98FC15 for ; Tue, 1 Jun 2010 11:40:32 +0000 (UTC) Received: from elsa.codelab.cz (localhost.codelab.cz [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id 1EEC019E039; Tue, 1 Jun 2010 13:40:31 +0200 (CEST) Received: from [192.168.1.2] (r5bb235.net.upc.cz [86.49.61.235]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id 7F89B19E036; Tue, 1 Jun 2010 13:40:28 +0200 (CEST) Message-ID: <4C04F1AB.3010906@quip.cz> Date: Tue, 01 Jun 2010 13:40:27 +0200 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1.9) Gecko/20100317 SeaMonkey/2.0.4 MIME-Version: 1.0 To: PaulFr References: <20080809195935.F4976@borg> <20080809215249.T5563@borg> <20080810082410.X1306@borg> <57BE2631-7AED-443A-88E4-62456C048DD4@tamu.edu> <20080810102225.V1945@borg> <20080810120156.O1324@borg> <28737218.post@talk.nabble.com> In-Reply-To: <28737218.post@talk.nabble.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: IPMI Console: No luck once OS is booted X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 01 Jun 2010 11:40:32 -0000 PaulFr wrote: > > > Larry Rosenman wrote: >> >> On Sun, 10 Aug 2008, David Duchscher wrote: >> >>> On Aug 10, 2008, at 10:22 AM, Larry Rosenman wrote: >>> >>>>> I don't have that IPMI card but I can say we have other cards of theirs >>>>> working. I would make sure the card is at the latest version of >>>>> firmware. >>>>> The AOC-SIMSO(+) card was not detected correctly until we upgraded. I >>>>> don't know why the card is going away when freebsd boots since I assume >>>>> you are on the dedicated LAN interface with its own IP address. >>>> Yes. It's not going away, just doesn't see the key strokes. >>> >>> Looking through your dmesg file, I don't see a USB keyboard being >>> attached. >>> On my system, the virtual keyboard is a USB keyboard. >>> >>> ukbd0: on >>> uhub3 >>> kbd2 at ukbd0 >> Good catch. When I set it to disable USB Mass Storage when no image >> is loaded, the ukbd came alive, and I'm typing this on the IPMI Console. >> >> Thanks! >>> >>> -- >>> DaveD >>> >> > > Larry > I have a similar problem as you describe in this posting using a SuperMicro > X8SIL-F motherboard with onboard IPMI. The console redirection works fine > during boot until the OS (pfSense - FreebSD 7.2 Release p5) boots and then I > can't enter anything from the keyboard. Screen output is OK. I notice > there is also no usb keyboard being detected during boot - instead a usb > mass storage device is added. Thus I suspect I am seeing the same issue as > you did. > > When you mentioned "When I set it to disable USB Mass Storage when no image > is loaded, the ukbd came alive..." how did you do that? Can you try to boot FreeBSD 8 or 7.3 live system, not installer? I had same problem with 7.2 installer, but IPMI works with installed 7.2 GENERIC kernel from HDD. 8.0 installer and installed GENERIC kernel works fine in both case. So I think there is some bug in older releases. Miroslav Lachman From owner-freebsd-stable@FreeBSD.ORG Tue Jun 1 12:12:25 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 06DE4106566C for ; Tue, 1 Jun 2010 12:12:25 +0000 (UTC) (envelope-from mgamsjager@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 8E56A8FC20 for ; Tue, 1 Jun 2010 12:12:24 +0000 (UTC) Received: by fxm5 with SMTP id 5so3532586fxm.13 for ; Tue, 01 Jun 2010 05:12:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:content-type; bh=Ygftrw+stBqUHRWvc4Jf3wOSgFH8zzuXWNtvhQErk4c=; b=mrOGhUkLpShGM/oI3bFlb0iPjUYUImsNAGz+fLloJd9uiF+7S5Bxnu9/ESX3NLccwu eR9UxFOZxVaNV7QcHr2I3wQw9FJMi0mbBWQRhI6T0V5TP8OTsqSokCpIYhTasRWyB9Wa naTUz0R+kLs293jUhLwzG+nddI+SgAHb0U+UE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; b=Y5iTf/ODADJe0G3yG+LWs8VK7gNdplKpB9kJMPHyW9XX7AyDOX915nsIRvGUDYULze 6myyn1Q73guota4HrekXE2qKFOwYtLTCC+UG1NRcutVg4F4xuL822z0xynanByuQUQIe LYnU5diD8w5eSz4SloRteoJ97SjDWoiI8fyrY= Received: by 10.204.83.218 with SMTP id g26mr595846bkl.52.1275394343320; Tue, 01 Jun 2010 05:12:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.78.194 with HTTP; Tue, 1 Jun 2010 05:11:53 -0700 (PDT) In-Reply-To: <20100527174211.GC1211@michelle.cdnetworks.com> References: <20100527131310.GS883@twoquid.cs.ru.nl> <20100527174211.GC1211@michelle.cdnetworks.com> From: Matthias Gamsjager Date: Tue, 1 Jun 2010 14:11:53 +0200 Message-ID: To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: nfe0 loses network connectivity (8.0-RELEASE-p2) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 01 Jun 2010 12:12:25 -0000 I do have the same problem with my nic but I do seem to get no IP address from time to time after reboot. Ifconfig nfe0 down follow by dhclient nfe0 couple of times does usually the trick. Will look at the mbuf counters next times it looses connection in the middle of an afpd session tho. From owner-freebsd-stable@FreeBSD.ORG Tue Jun 1 13:40:38 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BA525106564A for ; Tue, 1 Jun 2010 13:40:38 +0000 (UTC) (envelope-from michal@ionic.co.uk) Received: from mail1.sharescope.co.uk (pm1.ionic.co.uk [85.159.80.19]) by mx1.freebsd.org (Postfix) with ESMTP id 7AF218FC19 for ; Tue, 1 Jun 2010 13:40:37 +0000 (UTC) Received: from localhost (unknown [127.0.0.1]) by mail1.sharescope.co.uk (Postfix) with ESMTP id 9E5C5FC0B5 for ; Tue, 1 Jun 2010 13:40:37 +0000 (UTC) X-Virus-Scanned: amavisd-new at sharescope.co.uk Received: from mail1.sharescope.co.uk ([127.0.0.1]) by localhost (mail1.sharescope.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dmtxRCLEDBJo for ; Tue, 1 Jun 2010 14:40:33 +0100 (BST) Received: from [192.168.2.37] (office.ionic.co.uk [85.159.85.2]) (Authenticated sender: chris@sharescope.co.uk) by mail1.sharescope.co.uk (Postfix) with ESMTPSA id 3D3ACFC0A2 for ; Tue, 1 Jun 2010 14:40:33 +0100 (BST) Message-ID: <4C050DCF.3050105@ionic.co.uk> Date: Tue, 01 Jun 2010 14:40:31 +0100 From: Michal User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: freebsd-stable@freebsd.org X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Adding a second device to my zfs pool X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 01 Jun 2010 13:40:38 -0000 I am having problems getting my head around a small ZFS issue. If I build a fileserver, say for example a 20 x 1TB disk server with zfs and create a file server, it can work fine and I can have RADIZ or RAIDZ2 or whatever. I could create 4 groups of 5 1TB HDD's and do all things like that...It's shared using iSCSI or samba or whatever, desktops and servers can see the files, everything works fine. But one day I run out of space, so I think right, build an exact copy of the one I have so I have another 20 TB server, given me 40TB, but I want nothing to change for the desktops/servers and as far as they know nothing as happened. But my problem is I could set that second server up, but how do I add the space to my existing pools? I create my RAIDZ2 zpools of hard drives, the raid works and everything, but now I want to increase my existing storage. I could go to my first server and simply add the storage to my groups, thus increasing the size...but then if that server fails I will lose all data? will I not? Basically I'm having trouble finding information on what happens when you add a second file server to increase your space. I see lots of guides and documents for 1 device and adding more HDD's to that device, but not when you need to add a second device (run out of HDD space in the device for example) Thanks From owner-freebsd-stable@FreeBSD.ORG Tue Jun 1 14:04:29 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 47A561065673 for ; Tue, 1 Jun 2010 14:04:29 +0000 (UTC) (envelope-from kirk@strauser.com) Received: from kanga.honeypot.net (kanga.honeypot.net [IPv6:2001:470:a80a:1:21f:d0ff:fe22:b8a8]) by mx1.freebsd.org (Postfix) with ESMTP id 024308FC1F for ; Tue, 1 Jun 2010 14:04:29 +0000 (UTC) Received: from kanga.honeypot.net (localhost [127.0.0.1]) by kanga.honeypot.net (Postfix) with ESMTP id C0B12379C3; Tue, 1 Jun 2010 09:04:27 -0500 (CDT) X-Virus-Scanned: amavisd-new at honeypot.net Received: from kanga.honeypot.net ([127.0.0.1]) by kanga.honeypot.net (kanga.honeypot.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 2vVKAm1PPu5V; Tue, 1 Jun 2010 09:04:22 -0500 (CDT) Received: from athena.daycos.com (athena.daycos.com [10.45.12.8]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by kanga.honeypot.net (Postfix) with ESMTPSA id A5C15379A7; Tue, 1 Jun 2010 09:04:19 -0500 (CDT) Message-ID: <4C051361.7050308@strauser.com> Date: Tue, 01 Jun 2010 09:04:17 -0500 From: Kirk Strauser User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.9) Gecko/20100531 Thunderbird/3.0.4 MIME-Version: 1.0 To: Paul Mather References: <4C017419.9010909@strauser.com> <4632C12D-2B1E-4073-B2C9-E9D15C212EF1@ee.ryerson.ca> <19664824-1B23-4E5F-BC12-BB4D59A9C8AA@ee.ryerson.ca> <7B30E5C6-07F9-4B61-9F09-1615D21F6461@gromit.dlib.vt.edu> In-Reply-To: <7B30E5C6-07F9-4B61-9F09-1615D21F6461@gromit.dlib.vt.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD-STABLE Mailing List , David Magda Subject: Re: Make ZFS auto-destroy snapshots when the out of space? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 01 Jun 2010 14:04:29 -0000 On 05/31/10 08:48, Paul Mather wrote: > Devd already receives several ZFS-based events (failed vdev, I/O > error, checksum mismatch, etc.), so perhaps it would be useful to add > another, e.g., "space" which is set to be triggered when a pool > attains a certain percentage full. This could default to 100%, but be > capable of being set lower by an associated kernel sysctl. You could > then have any auto-pruning/snapshot management script triggered from > devd. (You'd probably also have to figure out some kind of throttling > mechanism for this devd event, too.) I think that's probably the best alternative. Again, I could see that being used for a lot of things. It would be a nice general solution that wouldn't touch any (or very little) non-FreeBSD code. -- Kirk Strauser From owner-freebsd-stable@FreeBSD.ORG Tue Jun 1 15:47:05 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 25EE31065676 for ; Tue, 1 Jun 2010 15:47:05 +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 EBCFB8FC13 for ; Tue, 1 Jun 2010 15:47:04 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id A807246C08; Tue, 1 Jun 2010 11:47:04 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 916F18A026; Tue, 1 Jun 2010 11:47:03 -0400 (EDT) From: John Baldwin To: Jeremy Chadwick Date: Tue, 1 Jun 2010 10:20:01 -0400 User-Agent: KMail/1.12.1 (FreeBSD/7.3-CBSD-20100217; KDE/4.3.1; amd64; ; ) References: <201005272348.o4RNmgWh014243@hugeraid.jetcafe.org> <201005311825.o4VIPp5F051573@hugeraid.jetcafe.org> <20100531184525.GA89545@icarus.home.lan> In-Reply-To: <20100531184525.GA89545@icarus.home.lan> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201006011020.01318.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Tue, 01 Jun 2010 11:47:03 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Garrett Cooper , freebsd-stable@freebsd.org, Clifton Royston Subject: Re: Locking a file backed mdconfig into memory X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 01 Jun 2010 15:47:05 -0000 On Monday 31 May 2010 2:45:25 pm Jeremy Chadwick wrote: > On Mon, May 31, 2010 at 11:25:51AM -0700, Dave Hayes wrote: > > Jeremy Chadwick writes: > > > Is the mfsroot file compressed (.gz extension)? Reason I ask is that > > > the OP states he's using RELENG_7... > > > > Yes it is compressed. > > > > > http://jdc.parodius.com/freebsd/pxeboot_serial_install_7.html#step7 > > > > Thanks much for this. I did a simple test, I rebuilt a DVD that wasn't > > booting to use a lower level of compression (gzip -9 to gzip -6) on > > mfsroot without changing anything else. This caused it to boot normally. > > > > I'm not sure it's conclusive evidence, but it certainly looks like a > > weak datapoint supporting this kernel bug being the source of my > > problem. > > > > Is this problem fixed in 8.0 or by a patch? > > With regards to said bug, gzip compression seems to work fine on > RELENG_8, at least in my experiences: > > http://jdc.parodius.com/freebsd/pxeboot_serial_install_8.html > > I'm not sure the level of compression is what triggers the bug though; > I haven't tested all levels (1 through 9). > > CC'ing jhb@ since he last updated PR kern/120127 (which I would say is > still a problem on RELENG_7 :-) ). John, are you aware of any gzip > decompression / mfsroot changes which might explain the problem on > RELENG_7? I haven't done a "thorough" series of tests, but on my > testbed boxes RELENG_8 works fine with a gzip'd mfsroot. Ok, if you are using a stock mfsroot from a release build, that should work fine. If you have built a custom mfsroot that is larger, then you may need to increase NKPT on i386. In very recent 7 and later you can do this by setting it to a new value in your kernel config. In older versions you can do this by manually adding a #define to set a new value of NKPT in opt_global.h or hacking on the source directly. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Tue Jun 1 15:47:15 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3D38310656EF; Tue, 1 Jun 2010 15:47:14 +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 4E58F8FC21; Tue, 1 Jun 2010 15:47:14 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 7F99646C10; Tue, 1 Jun 2010 11:47:13 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id B15F98A021; Tue, 1 Jun 2010 11:47:12 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Tue, 1 Jun 2010 11:41:09 -0400 User-Agent: KMail/1.12.1 (FreeBSD/7.3-CBSD-20100217; KDE/4.3.1; amd64; ; ) References: <20100530143034.GH43302@hades.panopticon> <20100530150622.GJ83316@deviant.kiev.zoral.com.ua> In-Reply-To: <20100530150622.GJ83316@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201006011141.09699.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Tue, 01 Jun 2010 11:47:12 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Kostik Belousov , Dmitry Marakasov , freebsd-stable@freebsd.org Subject: Re: need better POSIX semaphore support X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 01 Jun 2010 15:47:15 -0000 On Sunday 30 May 2010 11:06:22 am Kostik Belousov wrote: > On Sun, May 30, 2010 at 06:30:35PM +0400, Dmitry Marakasov wrote: > > Hi! > > > > Not long ago, POSIX semaphores support was enabled by default as it's > > becoming more widely used, by e.g. firefox. However, the support > > for these is still incomplete: we only have systemwide limit of 30 > > semaphores, and that doesn't seem to be configurable neither online with > > sysctl, nor at boottime from loader.conf. I only was able to raise > > semaphore count by changing SEM_MAX in kernel sources. > > > > The real appliaction which needs more semaphores is lightspark > > (graphics/lightspark-devel) flash plugin - it uses ~40 sems for simple > > clips and ~250 for something like youtube videos. > > > > Until there more apps that require proper semaphore support, I guess > > we need to improve it asap. Given the amount of memory used by ksem, > > the least can be done is SEM_MAX bumped up to 5120 or so for > > non-embedded kernels. 5120 semaphores require just 644k of kernel > > memory (judging by vmstat), and is "ought to be enough for anybody". > > Another good thing would be to make it configurable at boot-time > > or even better in runtime. > > HEAD contains different implementation. Apparently, it did not made > into stable/8 yet, so it will not appear in the 8.1. The one thing I don't like about this approach is you can write the variable even when sem.ko isn't loaded. The SEM_* values should really only exist when sem.ko is loaded I think, which requires moving them into uipc_sem.c. > Try this, I could try to squeeze it into 8.1. > > diff --git a/sys/kern/posix4_mib.c b/sys/kern/posix4_mib.c > index 5242b31..41e28da 100644 > --- a/sys/kern/posix4_mib.c > +++ b/sys/kern/posix4_mib.c > @@ -57,6 +57,9 @@ SYSCTL_DECL(_p1003_1b); > #define P1B_SYSCTL(num, name) \ > SYSCTL_INT(_p1003_1b, num, \ > name, CTLFLAG_RD, facility + num - 1, 0, ""); > +#define P1B_SYSCTL_RW(num, name) \ > +SYSCTL_INT(_p1003_1b, num, \ > + name, CTLFLAG_RW, facility + num - 1, 0, ""); > > #else > > @@ -65,6 +68,9 @@ SYSCTL_DECL(_kern_p1003_1b); > #define P1B_SYSCTL(num, name) \ > SYSCTL_INT(_kern_p1003_1b, OID_AUTO, \ > name, CTLFLAG_RD, facility + num - 1, 0, ""); > +#define P1B_SYSCTL_RW(num, name) \ > +SYSCTL_INT(_kern_p1003_1b, OID_AUTO, \ > + name, CTLFLAG_RW, facility + num - 1, 0, ""); > SYSCTL_NODE(_kern, OID_AUTO, p1003_1b, CTLFLAG_RW, 0, "P1003.1B"); > > #endif > @@ -91,7 +97,7 @@ P1B_SYSCTL(CTL_P1003_1B_DELAYTIMER_MAX, delaytimer_max); > P1B_SYSCTL(CTL_P1003_1B_MQ_OPEN_MAX, mq_open_max); > P1B_SYSCTL(CTL_P1003_1B_PAGESIZE, pagesize); > P1B_SYSCTL(CTL_P1003_1B_RTSIG_MAX, rtsig_max); > -P1B_SYSCTL(CTL_P1003_1B_SEM_NSEMS_MAX, sem_nsems_max); > +P1B_SYSCTL_RW(CTL_P1003_1B_SEM_NSEMS_MAX, sem_nsems_max); > P1B_SYSCTL(CTL_P1003_1B_SEM_VALUE_MAX, sem_value_max); > P1B_SYSCTL(CTL_P1003_1B_SIGQUEUE_MAX, sigqueue_max); > P1B_SYSCTL(CTL_P1003_1B_TIMER_MAX, timer_max); > -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Tue Jun 1 17:05:32 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8177A106566C; Tue, 1 Jun 2010 17:05:32 +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 C00ED8FC08; Tue, 1 Jun 2010 17:05:31 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id o51H5eDd089021 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 Jun 2010 20:05:40 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id o51H5Qg1048913; Tue, 1 Jun 2010 20:05:26 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id o51H5QFN048912; Tue, 1 Jun 2010 20:05:26 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 1 Jun 2010 20:05:26 +0300 From: Kostik Belousov To: John Baldwin Message-ID: <20100601170526.GJ83316@deviant.kiev.zoral.com.ua> References: <20100530143034.GH43302@hades.panopticon> <20100530150622.GJ83316@deviant.kiev.zoral.com.ua> <201006011141.09699.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="zruoG3PDhkeTLwq7" Content-Disposition: inline In-Reply-To: <201006011141.09699.jhb@freebsd.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=-2.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_50, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org, Dmitry Marakasov Subject: Re: need better POSIX semaphore support X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 01 Jun 2010 17:05:32 -0000 --zruoG3PDhkeTLwq7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jun 01, 2010 at 11:41:09AM -0400, John Baldwin wrote: > On Sunday 30 May 2010 11:06:22 am Kostik Belousov wrote: > > On Sun, May 30, 2010 at 06:30:35PM +0400, Dmitry Marakasov wrote: > > > Hi! > > >=20 > > > Not long ago, POSIX semaphores support was enabled by default as it's > > > becoming more widely used, by e.g. firefox. However, the support > > > for these is still incomplete: we only have systemwide limit of 30 > > > semaphores, and that doesn't seem to be configurable neither online w= ith > > > sysctl, nor at boottime from loader.conf. I only was able to raise > > > semaphore count by changing SEM_MAX in kernel sources. > > >=20 > > > The real appliaction which needs more semaphores is lightspark > > > (graphics/lightspark-devel) flash plugin - it uses ~40 sems for simple > > > clips and ~250 for something like youtube videos. > > >=20 > > > Until there more apps that require proper semaphore support, I guess > > > we need to improve it asap. Given the amount of memory used by ksem, > > > the least can be done is SEM_MAX bumped up to 5120 or so for > > > non-embedded kernels. 5120 semaphores require just 644k of kernel > > > memory (judging by vmstat), and is "ought to be enough for anybody". > > > Another good thing would be to make it configurable at boot-time > > > or even better in runtime. > >=20 > > HEAD contains different implementation. Apparently, it did not made > > into stable/8 yet, so it will not appear in the 8.1. >=20 > The one thing I don't like about this approach is you can write the > variable even when sem.ko isn't loaded. The SEM_* values should really > only exist when sem.ko is loaded I think, which requires moving them > into uipc_sem.c. I think the values should exist always, because sysconf(3) returns error (i.e. -1 and errno set) when sysctl fails. sysconf(3) interprets 0 result as "feature not supported". I modified the patch to only allow change of value when the module is loade= d. Also, the module unload now clears mib. As usual, module unload races are not handled. diff --git a/sys/kern/posix4_mib.c b/sys/kern/posix4_mib.c index 5242b31..cbe140d 100644 --- a/sys/kern/posix4_mib.c +++ b/sys/kern/posix4_mib.c @@ -45,6 +45,8 @@ __FBSDID("$FreeBSD$"); static int facility[CTL_P1003_1B_MAXID - 1]; static int facility_initialized[CTL_P1003_1B_MAXID - 1]; =20 +static int p31b_sysctl_proc(SYSCTL_HANDLER_ARGS); + /* OID_AUTO isn't working with sysconf(3). I guess I'd have to * modify it to do a lookup by name from the index. * For now I've left it a top-level sysctl. @@ -55,16 +57,21 @@ static int facility_initialized[CTL_P1003_1B_MAXID - 1]; SYSCTL_DECL(_p1003_1b); =20 #define P1B_SYSCTL(num, name) \ -SYSCTL_INT(_p1003_1b, num, \ - name, CTLFLAG_RD, facility + num - 1, 0, ""); + SYSCTL_INT(_p1003_1b, num, name, CTLFLAG_RD, facility + num - 1, 0, ""); +#define P1B_SYSCTL_RW(num, name) \ + SYSCTL_PROC(_p1003_1b, num, name, CTLTYPE_INT | CTLFLAG_RW, NULL, num, \ + p31b_sysctl_proc, "I", ""); =20 #else =20 SYSCTL_DECL(_kern_p1003_1b); =20 #define P1B_SYSCTL(num, name) \ -SYSCTL_INT(_kern_p1003_1b, OID_AUTO, \ - name, CTLFLAG_RD, facility + num - 1, 0, ""); + SYSCTL_INT(_kern_p1003_1b, OID_AUTO, name, CTLFLAG_RD, \ + facility + num - 1, 0, ""); +#define P1B_SYSCTL_RW(num, name) \ + SYSCTL_PROC(_p1003_1b, OID_AUTO, name, CTLTYPE_INT | CTLFLAG_RW, NULL, \ + num, p31b_sysctl_proc, "I", ""); SYSCTL_NODE(_kern, OID_AUTO, p1003_1b, CTLFLAG_RW, 0, "P1003.1B"); =20 #endif @@ -91,13 +98,28 @@ P1B_SYSCTL(CTL_P1003_1B_DELAYTIMER_MAX, delaytimer_max); P1B_SYSCTL(CTL_P1003_1B_MQ_OPEN_MAX, mq_open_max); P1B_SYSCTL(CTL_P1003_1B_PAGESIZE, pagesize); P1B_SYSCTL(CTL_P1003_1B_RTSIG_MAX, rtsig_max); -P1B_SYSCTL(CTL_P1003_1B_SEM_NSEMS_MAX, sem_nsems_max); +P1B_SYSCTL_RW(CTL_P1003_1B_SEM_NSEMS_MAX, sem_nsems_max); P1B_SYSCTL(CTL_P1003_1B_SEM_VALUE_MAX, sem_value_max); P1B_SYSCTL(CTL_P1003_1B_SIGQUEUE_MAX, sigqueue_max); P1B_SYSCTL(CTL_P1003_1B_TIMER_MAX, timer_max); =20 #define P31B_VALID(num) ((num) >=3D 1 && (num) < CTL_P1003_1B_MAXID) =20 +static int +p31b_sysctl_proc(SYSCTL_HANDLER_ARGS) +{ + int error, num, val; + + num =3D arg2; + if (!P31B_VALID(num)) + return (EINVAL); + val =3D facility_initialized[num] ? facility[num - 1] : 0; + error =3D sysctl_handle_int(oidp, &val, 0, req); + if (error =3D=3D 0 && req->newptr !=3D NULL && facility_initialized[num]) + facility[num - 1] =3D val; + return (error); +} + /* p31b_setcfg: Set the configuration */ void @@ -110,6 +132,14 @@ p31b_setcfg(int num, int value) } } =20 +void +p31b_unsetcfg(int num) +{ + + facility[num - 1] =3D 0; + facility_initialized[num -1] =3D 0; +} + int p31b_getcfg(int num) { diff --git a/sys/kern/uipc_sem.c b/sys/kern/uipc_sem.c index d9229ea..0b8f132 100644 --- a/sys/kern/uipc_sem.c +++ b/sys/kern/uipc_sem.c @@ -976,6 +976,8 @@ ksem_module_destroy(void) sx_destroy(&ksem_dict_lock); mtx_destroy(&ksem_count_lock); mtx_destroy(&sem_lock); + p31b_unsetcfg(CTL_P1003_1B_SEM_VALUE_MAX); + p31b_unsetcfg(CTL_P1003_1B_SEM_NSEMS_MAX); } =20 static int diff --git a/sys/sys/posix4.h b/sys/sys/posix4.h index ea379c0..34f77f4 100644 --- a/sys/sys/posix4.h +++ b/sys/sys/posix4.h @@ -64,6 +64,7 @@ int p31b_proc(struct proc *, pid_t, struct proc **); void p31b_setcfg(int, int); int p31b_getcfg(int); int p31b_iscfg(int); +void p31b_unsetcfg(int); =20 #ifdef _KPOSIX_PRIORITY_SCHEDULING =20 --zruoG3PDhkeTLwq7 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkwFPdYACgkQC3+MBN1Mb4icFwCeLtYMI7m6kuZ5t9X8YNFEg8dQ 7FkAn24sDS1zePA7HC5oDcgQ3cP3Gbu3 =T0aL -----END PGP SIGNATURE----- --zruoG3PDhkeTLwq7-- From owner-freebsd-stable@FreeBSD.ORG Tue Jun 1 17:19:30 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 415F81065675; Tue, 1 Jun 2010 17:19:30 +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 10C7C8FC14; Tue, 1 Jun 2010 17:19:30 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id AE79B46C0C; Tue, 1 Jun 2010 13:19:29 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id E44198A025; Tue, 1 Jun 2010 13:19:28 -0400 (EDT) From: John Baldwin To: Kostik Belousov Date: Tue, 1 Jun 2010 13:19:22 -0400 User-Agent: KMail/1.12.1 (FreeBSD/7.3-CBSD-20100217; KDE/4.3.1; amd64; ; ) References: <20100530143034.GH43302@hades.panopticon> <201006011141.09699.jhb@freebsd.org> <20100601170526.GJ83316@deviant.kiev.zoral.com.ua> In-Reply-To: <20100601170526.GJ83316@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201006011319.22275.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Tue, 01 Jun 2010 13:19:28 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org, Dmitry Marakasov Subject: Re: need better POSIX semaphore support X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 01 Jun 2010 17:19:30 -0000 On Tuesday 01 June 2010 1:05:26 pm Kostik Belousov wrote: > On Tue, Jun 01, 2010 at 11:41:09AM -0400, John Baldwin wrote: > > On Sunday 30 May 2010 11:06:22 am Kostik Belousov wrote: > > > On Sun, May 30, 2010 at 06:30:35PM +0400, Dmitry Marakasov wrote: > > > > Hi! > > > > > > > > Not long ago, POSIX semaphores support was enabled by default as it's > > > > becoming more widely used, by e.g. firefox. However, the support > > > > for these is still incomplete: we only have systemwide limit of 30 > > > > semaphores, and that doesn't seem to be configurable neither online with > > > > sysctl, nor at boottime from loader.conf. I only was able to raise > > > > semaphore count by changing SEM_MAX in kernel sources. > > > > > > > > The real appliaction which needs more semaphores is lightspark > > > > (graphics/lightspark-devel) flash plugin - it uses ~40 sems for simple > > > > clips and ~250 for something like youtube videos. > > > > > > > > Until there more apps that require proper semaphore support, I guess > > > > we need to improve it asap. Given the amount of memory used by ksem, > > > > the least can be done is SEM_MAX bumped up to 5120 or so for > > > > non-embedded kernels. 5120 semaphores require just 644k of kernel > > > > memory (judging by vmstat), and is "ought to be enough for anybody". > > > > Another good thing would be to make it configurable at boot-time > > > > or even better in runtime. > > > > > > HEAD contains different implementation. Apparently, it did not made > > > into stable/8 yet, so it will not appear in the 8.1. > > > > The one thing I don't like about this approach is you can write the > > variable even when sem.ko isn't loaded. The SEM_* values should really > > only exist when sem.ko is loaded I think, which requires moving them > > into uipc_sem.c. > > I think the values should exist always, because sysconf(3) returns > error (i.e. -1 and errno set) when sysctl fails. sysconf(3) interprets > 0 result as "feature not supported". > > I modified the patch to only allow change of value when the module is loaded. > Also, the module unload now clears mib. As usual, module unload races are > not handled. I think this looks good, thanks! -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Tue Jun 1 17:58:09 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C3745106564A for ; Tue, 1 Jun 2010 17:58:09 +0000 (UTC) (envelope-from jhelfman@e-e.com) Received: from mail.experts-exchange.com (mail.experts-exchange.com [64.156.132.251]) by mx1.freebsd.org (Postfix) with ESMTP id AE8168FC16 for ; Tue, 1 Jun 2010 17:58:09 +0000 (UTC) Received: from [192.168.103.239] (unknown [72.29.180.81]) by mail.experts-exchange.com (Postfix) with ESMTP id 615FB4A2DF0F; Tue, 1 Jun 2010 10:49:48 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Jason Helfman In-Reply-To: Date: Tue, 1 Jun 2010 10:58:07 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <66E74C1C-A64C-45A9-A482-5A65C21213F0@e-e.com> References: <20100601094506.GA25207@twoquid.cs.ru.nl> To: c0re X-Mailer: Apple Mail (2.1078) Cc: freebsd-stable@freebsd.org Subject: Re: freebsd-update with non-GENERIC kerrnel X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 01 Jun 2010 17:58:09 -0000 The only way to have freebsd-update to work on a non-GENERIC kernel is = to run your own freebsd-update server based off an iso that has your = custom kernel within the release. I've been doing this for some time now. On Jun 1, 2010, at 2:57 AM, c0re wrote: > freebsd-update made for only GENERIC kerndel due to binary diff = patches. > After you rebuild world and kernel you'll be not able to apply binary > patches. >=20 > 2010/6/1 Olaf Seibert >=20 >> I find the way freebsd-update handles a system that runs a = non-GENERIC >> kernel less than helpful. >>=20 >> It is doing this: >>=20 >> | fourquid.3:~$ sudo freebsd-update upgrade -r 8.1-BETA1 >> | Password: >> | Looking up update.FreeBSD.org mirrors... 3 mirrors found. >> | Fetching metadata signature for 8.0-RELEASE from = update5.FreeBSD.org... >> done. >> | Fetching metadata index... done. >> | Fetching 2 metadata patches.. done. >> | Applying metadata patches... done. >> | Inspecting system... done. >> | >> | WARNING: This system is running a "fourquid" kernel, which is not a >> | kernel configuration distributed as part of FreeBSD 8.0-RELEASE. >> | This kernel will not be updated: you MUST update the kernel = manually >> | before running "/usr/sbin/freebsd-update install". >> | >> | The following components of FreeBSD seem to be installed: >> | src/base src/bin src/cddl src/contrib src/crypto src/etc src/games >> | src/gnu src/include src/krb5 src/lib src/libexec src/release = src/rescue >> | src/sbin src/secure src/share src/sys src/tools src/ubin src/usbin >> | world/base world/catpages world/dict world/doc world/games = world/info >> | world/lib32 world/manpages world/proflibs >> | >> | The following components of FreeBSD do not seem to be installed: >> | kernel/generic >> | >> | Does this look reasonable (y/n)? n >>=20 >> I do have the kernel sources installed, so I would like to have them >> updated. I don't even mind to have a GENERIC kernel temporarily >> installed, until I compile my own (fortunately, they are not that >> different). >>=20 >> It is nice that it tells me that I "MUST update the kernel manually", >> but it gives me no help in getting the sources and doing that. (Can = the >> new kernel even be built in all cases with old tools? NetBSD offers a >> nice cross-building system for that.) >>=20 >> For my previous update to 8.0-RELEASE-p2 I patched freebsd-update = simply >> to think that my kernel *is* GENERIC, >>=20 >> --- /usr/sbin/freebsd-update 2009-12-22 17:16:01.000000000 +0100 >> +++ /tmp/freebsd-update 2010-05-11 10:35:05.000000000 +0200 >> @@ -631,6 +631,7 @@ >> # we're running an SMP kernel. This mis-identification is a = bug >> # which was fixed in 6.2-STABLE. >> KERNCONF=3D`uname -i` >> + KERNCONF=3DGENERIC >> if [ ${KERNCONF} =3D "SMP-GENERIC" ]; then >> KERNCONF=3DSMP >> fi >>=20 >> but that seems riskier as updates get a bit bigger. >>=20 >> The official way seems to be to reboot using GENERIC, upgrade (with a >> reboot with new GENERIC), rebuild new CUSTOM kernel, reboot again. At >> least the first reboot ought to be avoided... >>=20 >> -Olaf. >> -- >> _______________________________________________ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to = "freebsd-stable-unsubscribe@freebsd.org" >>=20 > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to = "freebsd-stable-unsubscribe@freebsd.org" >=20 From owner-freebsd-stable@FreeBSD.ORG Tue Jun 1 19:28:42 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9D5E11065678 for ; Tue, 1 Jun 2010 19:28:42 +0000 (UTC) (envelope-from bseklecki@collaborativefusion.com) Received: from collaborativefusion.com (pr40.pitbpa0.pub.collaborativefusion.com [206.210.89.202]) by mx1.freebsd.org (Postfix) with ESMTP id 643378FC15 for ; Tue, 1 Jun 2010 19:28:42 +0000 (UTC) Received: from [192.168.2.161] (soundwave.ws.pitbpa0.priv.collaborativefusion.com [192.168.2.161]) by relay.admin.pitbpa0.priv.collaborativefusion.com with esmtp; Tue, 01 Jun 2010 15:18:39 -0400 id 0001754D.000000004C055D0F.00012E75 From: "Brian A. Seklecki" To: freebsd-stable Organization: Collaborative Fusion, Inc. Date: Tue, 01 Jun 2010 15:18:39 -0400 Message-ID: <1275419919.30057.50.camel@soundwave.ws.pitbpa0.priv.collaborativefusion.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=_skyhopper-77429-1275419919-0001-2" X-Mailer: Evolution 2.30.1.2 (2.30.1.2-6.fc13) Cc: Subject: em(4) duplex problems with 82541EI on RELENG_8, -CURRENT on PowerEdge 1850 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bseklecki@collaborativefusion.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jun 2010 19:28:42 -0000 This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_skyhopper-77429-1275419919-0001-2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =3D Re-posted from freebsd-hardware@, since this is more of a bug report than a hardware comparability inquiry / buying strategy discussion. =3D=3D All: Has anyone upgraded their PowerEdge 1850s to 8.0-PL or=20 RELENG_8 -stable? We're seeing problems where 7.2-PL and 6.3-PL were not affected on the same hardware. The problem is that forcing the duplex 100/full on both=20 sides no longer functions. Configuration: =20 - A variety of Cisco L2/L3 switches over the last decade: -- 2848G-L3 -- 2950 -- 2960s -- 3550-12Ts -- 3550XLs -- Duplex forced 100/full on Cisco side - FreeBSD/amd64 RELENG_8 or 9-CURRENT with duplex forced '100baseTX mediaopt full-duplex', - This configuration has worked since FreeBSD 5.4 =20 When connected to PowerEdge 1850r1/r2, with the onboard Intel=20 82541EI, the parenthesis show an actual media speed/duplex of: media: Ethernet 100baseTX (100baseTX ) The same configuration using a Dell-sold Intel dual port 82546EB, in the same system, on the same switch, works fine. ----------------- ifconfig(8): ----------------- em3: flags=3D8843 metric 0 mtu 1500 options=3D9b ether 00:13:72:4f:70:81 inet 192.168.97.20 netmask 0xffffff80 broadcast 192.168.97.127 media: Ethernet 100baseTX (100baseTX ) status: active ----------------- em0: flags=3D8843 metric 0 mtu 1500> options=3D9b ether 00:04:23:c8:fe:ac media: Ethernet 100baseTX status: active ----------------- ----------------- pciconf(8): ----------------- em3@pci0:7:8:0: class=3D0x020000 card=3D0x016d1028 chip=3D0x10768086=20 rev=3D0x05 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D 'Gigabit Ethernet Controller (82541EI)' class =3D network subclass =3D ethernet em0@pci0:3:11:0: class=3D0x020000 card=3D0x10128086 chip=3D0x10108086 rev= =3D0x01 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D 'Dual Port Gigabit Ethernet Controller (Copper) (82546EB)' class =3D network subclass =3D ethernet ----------------- rc.conf(5) for shits & giggles: ifconfig_em0=3D"inet X netmask Y media 100baseTX mediaopt full-duplex" ifconfig_em3=3D"inet Z netmask F media 100baseTX mediaopt full-duplex" -------- Example IOS switch config: interface FastEthernet0/39 description I hate Dell switchport access vlan 100 switchport mode access speed 100 duplex full spanning-tree portfast end -------- I've been clearing interface counters on the switch side, but I'll send 'netstat -i', 'show interface counters', and 'sudo sysctl -w dev.em.3.stats=3D1' ASAP to illustrate connectivity errors soon. Are we being punished for patronizing Dell? Is it possible that ifconfig(8) output has simply changed? Are the values in the parenthesis on the right the Ethernet auto-sense desired values where as outside the parenthesis the current active values? In 6.3/7.2, once you forced a speed/duplex, the values in parenthesis went away entirely.=20 The only way I've been able to make that happen is to #define in src/sys/dev/e1000/if_em.h: #define DO_AUTO_NEG 0 /* * This parameter control whether or not the driver will wait for * autonegotiation to complete. * 1 - Wait for autonegotiation to complete * 0 - Don't wait for autonegotiation to complete */ Also seems odd that some ICs are affected but not others. Its also possible that my problems are pf(4) + setfib(8) related and I that this is a separate issue. Two new notes since the original post: - I have confirmed this problem on two revisions of the Dell 8th gen hardware in two different datacenters - The problem persists on -CURRENT from 05/2010 - RELENG_7 does not seem to be impacted - More stats below. Thanks, ~BAS =20 --------------- em1: link state changed to DOWN em1: link state changed to UP em1: link state changed to DOWN em1: link state changed to UP em1: link state changed to DOWN em1: link state changed to UP em1: link state changed to DOWN em1: link state changed to UP em1: link state changed to DOWN em1: link state changed to UP em1: link state changed to DOWN em0: Excessive collisions =3D 0 em0: Sequence errors =3D 0 em0: Defer count =3D 0 em0: Missed Packets =3D 0 em0: Receive No Buffers =3D 0 em0: Receive Length Errors =3D 0 em0: Receive errors =3D 0 em0: Crc errors =3D 0 em0: Alignment errors =3D 0 em0: Collision/Carrier extension errors =3D 0 em0: RX overruns =3D 0 em0: watchdog timeouts =3D 0 em0: RX MSIX IRQ =3D 0 TX MSIX IRQ =3D 0 LINK MSIX IRQ =3D 0 em0: XON Rcvd =3D 0 em0: XON Xmtd =3D 0 em0: XOFF Rcvd =3D 0 em0: XOFF Xmtd =3D 0 em0: Good Packets Rcvd =3D 1319916 em0: Good Packets Xmtd =3D 1070646 em0: TSO Contexts Xmtd =3D 0 em0: TSO Contexts Failed =3D 0 em1: Excessive collisions =3D 0 em1: Sequence errors =3D 0 em1: Defer count =3D 0 em1: Missed Packets =3D 0 em1: Receive No Buffers =3D 0 em1: Receive Length Errors =3D 0 em1: Receive errors =3D 0 em1: Crc errors =3D 0 em1: Alignment errors =3D 0 em1: Collision/Carrier extension errors =3D 0 em1: RX overruns =3D 0 em1: watchdog timeouts =3D 0 em1: RX MSIX IRQ =3D 0 TX MSIX IRQ =3D 0 LINK MSIX IRQ =3D 0 em1: XON Rcvd =3D 0 em1: XON Xmtd =3D 0 em1: XOFF Rcvd =3D 0 em1: XOFF Xmtd =3D 0 em1: Good Packets Rcvd =3D 251348 em1: Good Packets Xmtd =3D 204160 em1: TSO Contexts Xmtd =3D 0 em1: TSO Contexts Failed =3D 0 -------------------- as0# sh int fa0/43 FastEthernet0/43 is up, line protocol is up (connected) Hardware is Fast Ethernet, address is 0015.c683.51ab (bia 0015.c683.51ab) Description: X-Server EM1 MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,=20 reliability 255/255, txload 1/255, rxload 1/255 Encapsulation ARPA, loopback not set Keepalive set (10 sec) Full-duplex, 100Mb/s, media type is 100BaseTX input flow-control is unsupported output flow-control is unsupported=20 ARP type: ARPA, ARP Timeout 04:00:00 Last input never, output 00:00:08, output hang never Last clearing of "show interface" counters 6d03h Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: fifo Output queue: 0/40 (size/max) 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 1000 bits/sec, 3 packets/sec 291422 packets input, 131521274 bytes, 0 no buffer Received 798 broadcasts (0 multicast) 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored 0 watchdog, 99 multicast, 0 pause input 0 input packets with dribble condition detected 651929 packets output, 73550092 bytes, 0 underruns 0 output errors, 0 collisions, 4 interface resets 0 babbles, 0 late collision, 0 deferred 0 lost carrier, 0 no carrier, 0 PAUSE output 0 output buffer failures, 0 output buffers swapped out --=20 Brian A. Seklecki Collaborative Fusion, Inc. --=_skyhopper-77429-1275419919-0001-2 Content-Type: application/pgp-signature; name="signature.asc" Content-Transfer-Encoding: 7bit Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) iEYEABECAAYFAkwFXQ8ACgkQCne6BNDQ+R9IngCfZt38NKifNfsClLG9OnbwDW39 CrcAn3R7eUM9zu2zKhlsGLQ3HZCaCK/8 =QL1m -----END PGP SIGNATURE----- --=_skyhopper-77429-1275419919-0001-2-- From owner-freebsd-stable@FreeBSD.ORG Tue Jun 1 19:37:37 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1486A106566B for ; Tue, 1 Jun 2010 19:37:37 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [76.96.59.243]) by mx1.freebsd.org (Postfix) with ESMTP id B2A058FC1A for ; Tue, 1 Jun 2010 19:37:36 +0000 (UTC) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta13.westchester.pa.mail.comcast.net with comcast id QcyF1e00D1swQuc5DjdcNb; Tue, 01 Jun 2010 19:37:36 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta15.westchester.pa.mail.comcast.net with comcast id Qjdb1e0053S48mS3bjdbuj; Tue, 01 Jun 2010 19:37:36 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id F1F659B418; Tue, 1 Jun 2010 12:37:33 -0700 (PDT) Date: Tue, 1 Jun 2010 12:37:33 -0700 From: Jeremy Chadwick To: "Brian A. Seklecki" Message-ID: <20100601193733.GA44816@icarus.home.lan> References: <1275419919.30057.50.camel@soundwave.ws.pitbpa0.priv.collaborativefusion.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1275419919.30057.50.camel@soundwave.ws.pitbpa0.priv.collaborativefusion.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable , Jack Vogel Subject: Re: em(4) duplex problems with 82541EI on RELENG_8, -CURRENT on PowerEdge 1850 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 01 Jun 2010 19:37:37 -0000 On Tue, Jun 01, 2010 at 03:18:39PM -0400, Brian A. Seklecki wrote: > = Re-posted from freebsd-hardware@, since this is more of a bug > report than a hardware comparability inquiry / buying strategy > discussion. == > > All: > > Has anyone upgraded their PowerEdge 1850s to 8.0-PL or > RELENG_8 -stable? We're seeing problems where 7.2-PL and > 6.3-PL were not affected on the same hardware. > > The problem is that forcing the duplex 100/full on both > sides no longer functions. > > Configuration: > > - A variety of Cisco L2/L3 switches over the last decade: > -- 2848G-L3 > -- 2950 > -- 2960s > -- 3550-12Ts > -- 3550XLs > -- Duplex forced 100/full on Cisco side > - FreeBSD/amd64 RELENG_8 or 9-CURRENT with duplex > forced '100baseTX mediaopt full-duplex', > - This configuration has worked since FreeBSD 5.4 > > When connected to PowerEdge 1850r1/r2, with the onboard Intel > 82541EI, the parenthesis show an actual media speed/duplex of: > > media: Ethernet 100baseTX (100baseTX ) > > The same configuration using a Dell-sold Intel dual port > 82546EB, in the same system, on the same switch, works fine. > > > ----------------- > ifconfig(8): > ----------------- > em3: flags=8843 MULTICAST> metric 0 mtu 1500 > options=9b > ether 00:13:72:4f:70:81 > inet 192.168.97.20 netmask 0xffffff80 broadcast 192.168.97.127 > media: Ethernet 100baseTX (100baseTX ) > status: active > ----------------- > em0: flags=8843 MULTICAST> metric 0 mtu 1500> > options=9b > ether 00:04:23:c8:fe:ac > media: Ethernet 100baseTX > status: active > ----------------- > ----------------- > pciconf(8): > ----------------- > em3@pci0:7:8:0: class=0x020000 card=0x016d1028 chip=0x10768086 > rev=0x05 hdr=0x00 > vendor = 'Intel Corporation' > device = 'Gigabit Ethernet Controller (82541EI)' > class = network > subclass = ethernet > em0@pci0:3:11:0: class=0x020000 card=0x10128086 chip=0x10108086 rev=0x01 > hdr=0x00 > vendor = 'Intel Corporation' > device = 'Dual Port Gigabit Ethernet Controller (Copper) (82546EB)' > class = network > subclass = ethernet > > ----------------- > > rc.conf(5) for shits & giggles: > > ifconfig_em0="inet X netmask Y media 100baseTX mediaopt full-duplex" > ifconfig_em3="inet Z netmask F media 100baseTX mediaopt full-duplex" > > -------- > > Example IOS switch config: > interface FastEthernet0/39 > description I hate Dell > switchport access vlan 100 > switchport mode access > speed 100 > duplex full > spanning-tree portfast > end > -------- > > I've been clearing interface counters on the switch side, but I'll send > 'netstat -i', 'show interface counters', and 'sudo sysctl -w > dev.em.3.stats=1' ASAP to illustrate connectivity errors soon. > > Are we being punished for patronizing Dell? > > Is it possible that ifconfig(8) output has simply changed? Are the > values in the parenthesis on the right the Ethernet auto-sense desired > values where as outside the parenthesis the current active values? > > In 6.3/7.2, once you forced a speed/duplex, the values in parenthesis > went away entirely. > > The only way I've been able to make that happen is to #define in > src/sys/dev/e1000/if_em.h: > > #define DO_AUTO_NEG 0 > /* > * This parameter control whether or not the driver will wait for > * autonegotiation to complete. > * 1 - Wait for autonegotiation to complete > * 0 - Don't wait for autonegotiation to complete > */ > > Also seems odd that some ICs are affected but not others. > > Its also possible that my problems are pf(4) + setfib(8) related and I > that this is a separate issue. > > Two new notes since the original post: > > - I have confirmed this problem on two revisions of the Dell > 8th gen hardware in two different datacenters > - The problem persists on -CURRENT from 05/2010 > - RELENG_7 does not seem to be impacted > - More stats below. > > > Thanks, > ~BAS > > --------------- > > > > em1: link state changed to DOWN > em1: link state changed to UP > em1: link state changed to DOWN > em1: link state changed to UP > em1: link state changed to DOWN > em1: link state changed to UP > em1: link state changed to DOWN > em1: link state changed to UP > em1: link state changed to DOWN > em1: link state changed to UP > em1: link state changed to DOWN > > em0: Excessive collisions = 0 > em0: Sequence errors = 0 > em0: Defer count = 0 > em0: Missed Packets = 0 > em0: Receive No Buffers = 0 > em0: Receive Length Errors = 0 > em0: Receive errors = 0 > em0: Crc errors = 0 > em0: Alignment errors = 0 > em0: Collision/Carrier extension errors = 0 > em0: RX overruns = 0 > em0: watchdog timeouts = 0 > em0: RX MSIX IRQ = 0 TX MSIX IRQ = 0 LINK MSIX IRQ = 0 > em0: XON Rcvd = 0 > em0: XON Xmtd = 0 > em0: XOFF Rcvd = 0 > em0: XOFF Xmtd = 0 > em0: Good Packets Rcvd = 1319916 > em0: Good Packets Xmtd = 1070646 > em0: TSO Contexts Xmtd = 0 > em0: TSO Contexts Failed = 0 > em1: Excessive collisions = 0 > em1: Sequence errors = 0 > em1: Defer count = 0 > em1: Missed Packets = 0 > em1: Receive No Buffers = 0 > em1: Receive Length Errors = 0 > em1: Receive errors = 0 > em1: Crc errors = 0 > em1: Alignment errors = 0 > em1: Collision/Carrier extension errors = 0 > em1: RX overruns = 0 > em1: watchdog timeouts = 0 > em1: RX MSIX IRQ = 0 TX MSIX IRQ = 0 LINK MSIX IRQ = 0 > em1: XON Rcvd = 0 > em1: XON Xmtd = 0 > em1: XOFF Rcvd = 0 > em1: XOFF Xmtd = 0 > em1: Good Packets Rcvd = 251348 > em1: Good Packets Xmtd = 204160 > em1: TSO Contexts Xmtd = 0 > em1: TSO Contexts Failed = 0 > > -------------------- > > > as0# sh int fa0/43 > FastEthernet0/43 is up, line protocol is up (connected) > Hardware is Fast Ethernet, address is 0015.c683.51ab (bia > 0015.c683.51ab) > Description: X-Server EM1 > MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec, > reliability 255/255, txload 1/255, rxload 1/255 > Encapsulation ARPA, loopback not set > Keepalive set (10 sec) > Full-duplex, 100Mb/s, media type is 100BaseTX > input flow-control is unsupported output flow-control is unsupported > ARP type: ARPA, ARP Timeout 04:00:00 > Last input never, output 00:00:08, output hang never > Last clearing of "show interface" counters 6d03h > Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0 > Queueing strategy: fifo > Output queue: 0/40 (size/max) > 5 minute input rate 0 bits/sec, 0 packets/sec > 5 minute output rate 1000 bits/sec, 3 packets/sec > 291422 packets input, 131521274 bytes, 0 no buffer > Received 798 broadcasts (0 multicast) > 0 runts, 0 giants, 0 throttles > 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored > 0 watchdog, 99 multicast, 0 pause input > 0 input packets with dribble condition detected > 651929 packets output, 73550092 bytes, 0 underruns > 0 output errors, 0 collisions, 4 interface resets > 0 babbles, 0 late collision, 0 deferred > 0 lost carrier, 0 no carrier, 0 PAUSE output > 0 output buffer failures, 0 output buffers swapped out Brian, could you please provide the following output? - uname -a (you can X-out the machine name if need be) - dmesg | egrep 'em0|em3' (provides em driver version number) - pciconf -lvc (this will differ from what you provided above) Next, some of the stats you provided are for em1 when most of your post focuses around em0 and em3. Is there some correlation or was it a mistake? Adding Jack Vogel of Intel to the CC list, as he's been working on em(4) as of late. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Tue Jun 1 20:54:34 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A93D61065675 for ; Tue, 1 Jun 2010 20:54:34 +0000 (UTC) (envelope-from wolfgang@lyxys.ka.sub.org) Received: from saturn.lyxys.ka.sub.org (saturn.lyxys.ka.sub.org [217.29.35.151]) by mx1.freebsd.org (Postfix) with ESMTP id 1BD7A8FC18 for ; Tue, 1 Jun 2010 20:54:33 +0000 (UTC) Received: from juno.lyxys.ka.sub.org (juno.lyx [IPv6:fd2a:89ca:7d54:0:20f:feff:fe0e:7312]) by saturn.lyxys.ka.sub.org (8.14.2/8.14.2) with ESMTP id o51KsIOT067285 for ; Tue, 1 Jun 2010 22:54:18 +0200 (CEST) (envelope-from wolfgang@lyxys.ka.sub.org) Received: from juno.lyxys.ka.sub.org (localhost [127.0.0.1]) by juno.lyxys.ka.sub.org (8.14.4/8.14.4) with ESMTP id o51KsHrB065597 for ; Tue, 1 Jun 2010 22:54:17 +0200 (CEST) (envelope-from wolfgang@lyxys.ka.sub.org) Received: (from wolfgang@localhost) by juno.lyxys.ka.sub.org (8.14.4/8.14.4/Submit) id o51KsFZg065596 for freebsd-stable@freebsd.org; Tue, 1 Jun 2010 22:54:15 +0200 (CEST) (envelope-from wolfgang@lyxys.ka.sub.org) X-Authentication-Warning: juno.lyx: wolfgang set sender to wolfgang@lyxys.ka.sub.org using -f Date: Tue, 1 Jun 2010 22:54:15 +0200 From: Wolfgang Zenker To: freebsd-stable@freebsd.org Message-ID: <20100601205415.GA65310@lyxys.ka.sub.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Organization: private site Subject: usb multicardreader probes only first slot after update X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 01 Jun 2010 20:54:34 -0000 Hi, I just noticed that a usb multicardreader that I have used for a few years stopped working after an update from 8-STABLE around January 10th to 8-STABLE from May 29th. Reason appears to be that now only the first slot (which is empty) is probed instead of all four slots like before. dmesg output from after the update: ugen4.2: at usbus4 umass0: on usbus4 umass0: SCSI over Bulk-Only; quirks = 0x0000 umass0:0:0:-1: Attached to scbus0 (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe0:umass-sim0:0:0:0): CAM status: SCSI Status Error (probe0:umass-sim0:0:0:0): SCSI status: Check Condition (probe0:umass-sim0:0:0:0): SCSI sense: NOT READY asc:3a,0 (Medium not present) ugen4.2: at usbus4 (disconnected) umass0: at uhub4, port 6, addr 2 (disconnected) ugen4.2: at usbus4 umass0: on usbus4 umass0: SCSI over Bulk-Only; quirks = 0x0000 umass0:0:0:-1: Attached to scbus0 (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe0:umass-sim0:0:0:0): CAM status: SCSI Status Error (probe0:umass-sim0:0:0:0): SCSI status: Check Condition (probe0:umass-sim0:0:0:0): SCSI sense: NOT READY asc:3a,0 (Medium not present) ugen4.2: at usbus4 (disconnected) umass0: at uhub4, port 6, addr 2 (disconnected) Before the update dmesg output looked like this: ugen4.2: at usbus4 umass0: on usbus4 umass0: SCSI over Bulk-Only; quirks = 0x0000 umass0:0:0:-1: Attached to scbus0 (probe0:umass-sim0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (probe0:umass-sim0:0:0:0): CAM Status: SCSI Status Error (probe0:umass-sim0:0:0:0): SCSI Status: Check Condition (probe0:umass-sim0:0:0:0): NOT READY asc:3a,0 (probe0:umass-sim0:0:0:0): Medium not present (probe0:umass-sim0:0:0:0): Unretryable error da0 at umass-sim0 bus 0 scbus0 target 0 lun 0 da0: Removable Direct Access SCSI-0 device da0: 40.000MB/s transfers da0: Attempt to query device size failed: NOT READY, Medium not present (probe0:umass-sim0:0:0:1): TEST UNIT READY. CDB: 0 20 0 0 0 0 (probe0:umass-sim0:0:0:1): CAM Status: SCSI Status Error (probe0:umass-sim0:0:0:1): SCSI Status: Check Condition (probe0:umass-sim0:0:0:1): NOT READY asc:3a,0 (probe0:umass-sim0:0:0:1): Medium not present (probe0:umass-sim0:0:0:1): Unretryable error da1 at umass-sim0 bus 0 scbus0 target 0 lun 1 da1: Removable Direct Access SCSI-0 device da1: 40.000MB/s transfers da1: Attempt to query device size failed: NOT READY, Medium not present (probe0:umass-sim0:0:0:2): TEST UNIT READY. CDB: 0 40 0 0 0 0 (probe0:umass-sim0:0:0:2): CAM Status: SCSI Status Error (probe0:umass-sim0:0:0:2): SCSI Status: Check Condition (probe0:umass-sim0:0:0:2): UNIT ATTENTION asc:28,0 (probe0:umass-sim0:0:0:2): Not ready to ready change, medium may have changed (probe0:umass-sim0:0:0:2): Retrying Command (per Sense Data) da2 at umass-sim0 bus 0 scbus0 target 0 lun 2 da2: Removable Direct Access SCSI-0 device da2: 40.000MB/s transfers da2: 1886MB (3862528 512 byte sectors: 255H 63S/T 240C) (probe0:umass-sim0:0:0:3): TEST UNIT READY. CDB: 0 60 0 0 0 0 (probe0:umass-sim0:0:0:3): CAM Status: SCSI Status Error (probe0:umass-sim0:0:0:3): SCSI Status: Check Condition (probe0:umass-sim0:0:0:3): NOT READY asc:3a,0 (probe0:umass-sim0:0:0:3): Medium not present (probe0:umass-sim0:0:0:3): Unretryable error da3 at umass-sim0 bus 0 scbus0 target 0 lun 3 da3: Removable Direct Access SCSI-0 device da3: 40.000MB/s transfers da3: Attempt to query device size failed: NOT READY, Medium not present GEOM: da2: partition 1 does not start on a track boundary. GEOM: da2: partition 1 does not end on a track boundary. Apr 5 21:32:04 vulcan su: wolfgang to root on /dev/pts/3 ugen4.2: at usbus4 (disconnected) umass0: at uhub4, port 6, addr 2 (disconnected) (da0:umass-sim0:0:0:0): lost device (da0:umass-sim0:0:0:0): removing device entry (da1:umass-sim0:0:0:1): lost device (da1:umass-sim0:0:0:1): removing device entry (da2:umass-sim0:0:0:2): lost device (da2:umass-sim0:0:0:2): removing device entry (da3:umass-sim0:0:0:3): lost device (da3:umass-sim0:0:0:3): removing device entry I have not yet tried what happens if I actually put a CF card in the reader (that would be the first slot). Wolfgang From owner-freebsd-stable@FreeBSD.ORG Tue Jun 1 21:40:17 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 33252106566C for ; Tue, 1 Jun 2010 21:40:17 +0000 (UTC) (envelope-from spork@bway.net) Received: from xena.bway.net (xena.bway.net [216.220.96.26]) by mx1.freebsd.org (Postfix) with ESMTP id DCDBF8FC1C for ; Tue, 1 Jun 2010 21:40:16 +0000 (UTC) Received: (qmail 14497 invoked by uid 0); 1 Jun 2010 21:40:15 -0000 Received: from unknown (HELO ?10.3.2.41?) (spork@96.57.144.66) by smtp.bway.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 1 Jun 2010 21:40:15 -0000 Date: Tue, 1 Jun 2010 17:40:15 -0400 (EDT) From: Charles Sprickman X-X-Sender: spork@hotlap.local To: John Baldwin In-Reply-To: <201006011020.01318.jhb@freebsd.org> Message-ID: References: <201005272348.o4RNmgWh014243@hugeraid.jetcafe.org> <201005311825.o4VIPp5F051573@hugeraid.jetcafe.org> <20100531184525.GA89545@icarus.home.lan> <201006011020.01318.jhb@freebsd.org> User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Garrett Cooper , freebsd-stable@freebsd.org, Clifton Royston , Jeremy Chadwick Subject: Re: Locking a file backed mdconfig into memory X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 01 Jun 2010 21:40:17 -0000 On Tue, 1 Jun 2010, John Baldwin wrote: > On Monday 31 May 2010 2:45:25 pm Jeremy Chadwick wrote: >> On Mon, May 31, 2010 at 11:25:51AM -0700, Dave Hayes wrote: >>> Jeremy Chadwick writes: >>>> Is the mfsroot file compressed (.gz extension)? Reason I ask is that >>>> the OP states he's using RELENG_7... >>> >>> Yes it is compressed. >>> >>>> http://jdc.parodius.com/freebsd/pxeboot_serial_install_7.html#step7 >>> >>> Thanks much for this. I did a simple test, I rebuilt a DVD that wasn't >>> booting to use a lower level of compression (gzip -9 to gzip -6) on >>> mfsroot without changing anything else. This caused it to boot normally. >>> >>> I'm not sure it's conclusive evidence, but it certainly looks like a >>> weak datapoint supporting this kernel bug being the source of my >>> problem. >>> >>> Is this problem fixed in 8.0 or by a patch? >> >> With regards to said bug, gzip compression seems to work fine on >> RELENG_8, at least in my experiences: >> >> http://jdc.parodius.com/freebsd/pxeboot_serial_install_8.html >> >> I'm not sure the level of compression is what triggers the bug though; >> I haven't tested all levels (1 through 9). >> >> CC'ing jhb@ since he last updated PR kern/120127 (which I would say is >> still a problem on RELENG_7 :-) ). John, are you aware of any gzip >> decompression / mfsroot changes which might explain the problem on >> RELENG_7? I haven't done a "thorough" series of tests, but on my >> testbed boxes RELENG_8 works fine with a gzip'd mfsroot. > > Ok, if you are using a stock mfsroot from a release build, that should work > fine. If you have built a custom mfsroot that is larger, then you may need to > increase NKPT on i386. In very recent 7 and later you can do this by setting > it to a new value in your kernel config. In older versions you can do this by > manually adding a #define to set a new value of NKPT in opt_global.h or > hacking on the source directly. This is the original post I found confirming all this: http://unix.derkeiler.com/Mailing-Lists/FreeBSD/hackers/2004-02/0241.html I can also confirm your changes that allow it to be a kernel config option works as well. :) It's nice to essentially have a full livefs as your mfsroot for non-sysinstall installs. Charles > -- > 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 Tue Jun 1 23:45:25 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1A431106564A; Tue, 1 Jun 2010 23:45:25 +0000 (UTC) (envelope-from amdmi3@amdmi3.ru) Received: from smtp.timeweb.ru (smtp.timeweb.ru [92.53.116.15]) by mx1.freebsd.org (Postfix) with ESMTP id C42448FC14; Tue, 1 Jun 2010 23:45:24 +0000 (UTC) Received: from [213.148.20.85] (helo=hive.panopticon) by smtp.timeweb.ru with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.71) (envelope-from ) id 1OJb97-0000Xq-Ty; Wed, 02 Jun 2010 03:45:22 +0400 Received: from hades.panopticon (hades.panopticon [192.168.0.32]) by hive.panopticon (Postfix) with ESMTP id 43D6FB84F; Wed, 2 Jun 2010 03:45:21 +0400 (MSD) Received: by hades.panopticon (Postfix, from userid 1000) id 3595BB853; Wed, 2 Jun 2010 03:45:21 +0400 (MSD) Date: Wed, 2 Jun 2010 03:45:21 +0400 From: Dmitry Marakasov To: Kostik Belousov Message-ID: <20100601234521.GA2902@hades.panopticon> References: <20100530143034.GH43302@hades.panopticon> <20100530150622.GJ83316@deviant.kiev.zoral.com.ua> <201006011141.09699.jhb@freebsd.org> <20100601170526.GJ83316@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20100601170526.GJ83316@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org, John Baldwin Subject: Re: need better POSIX semaphore support X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 01 Jun 2010 23:45:25 -0000 * Kostik Belousov (kostikbel@gmail.com) wrote: I've tried the second patch, it works fine. It would be very nice to see it in 8.1, thanks. -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D amdmi3@amdmi3.ru ..: jabber: amdmi3@jabber.ru http://www.amdmi3.ru From owner-freebsd-stable@FreeBSD.ORG Wed Jun 2 00:31:34 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ACC441065674 for ; Wed, 2 Jun 2010 00:31:34 +0000 (UTC) (envelope-from bounces@nabble.com) Received: from kuber.nabble.com (kuber.nabble.com [216.139.236.158]) by mx1.freebsd.org (Postfix) with ESMTP id 71EC18FC12 for ; Wed, 2 Jun 2010 00:31:33 +0000 (UTC) Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1OJbrp-000374-C0 for freebsd-stable@freebsd.org; Tue, 01 Jun 2010 17:31:33 -0700 Message-ID: <28748926.post@talk.nabble.com> Date: Tue, 1 Jun 2010 17:31:33 -0700 (PDT) From: PaulFr To: freebsd-stable@freebsd.org In-Reply-To: <4C04F1AB.3010906@quip.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: pfcomptech@gmail.com References: <20080809195935.F4976@borg> <20080809215249.T5563@borg> <20080810082410.X1306@borg> <57BE2631-7AED-443A-88E4-62456C048DD4@tamu.edu> <20080810102225.V1945@borg> <20080810120156.O1324@borg> <28737218.post@talk.nabble.com> <4C04F1AB.3010906@quip.cz> Subject: Re: IPMI Console: No luck once OS is booted X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Jun 2010 00:31:34 -0000 Miroslav Lachman wrote: > > PaulFr wrote: >> >> >> Larry Rosenman wrote: >>> >>> On Sun, 10 Aug 2008, David Duchscher wrote: >>> >>>> On Aug 10, 2008, at 10:22 AM, Larry Rosenman wrote: >>>> >>>>>> I don't have that IPMI card but I can say we have other cards of >>>>>> theirs >>>>>> working. I would make sure the card is at the latest version of >>>>>> firmware. >>>>>> The AOC-SIMSO(+) card was not detected correctly until we upgraded. >>>>>> I >>>>>> don't know why the card is going away when freebsd boots since I >>>>>> assume >>>>>> you are on the dedicated LAN interface with its own IP address. >>>>> Yes. It's not going away, just doesn't see the key strokes. >>>> >>>> Looking through your dmesg file, I don't see a USB keyboard being >>>> attached. >>>> On my system, the virtual keyboard is a USB keyboard. >>>> >>>> ukbd0: on >>>> uhub3 >>>> kbd2 at ukbd0 >>> Good catch. When I set it to disable USB Mass Storage when no image >>> is loaded, the ukbd came alive, and I'm typing this on the IPMI Console. >>> >>> Thanks! >>>> >>>> -- >>>> DaveD >>>> >>> >> >> Larry >> I have a similar problem as you describe in this posting using a >> SuperMicro >> X8SIL-F motherboard with onboard IPMI. The console redirection works >> fine >> during boot until the OS (pfSense - FreebSD 7.2 Release p5) boots and >> then I >> can't enter anything from the keyboard. Screen output is OK. I notice >> there is also no usb keyboard being detected during boot - instead a usb >> mass storage device is added. Thus I suspect I am seeing the same issue >> as >> you did. >> >> When you mentioned "When I set it to disable USB Mass Storage when no >> image >> is loaded, the ukbd came alive..." how did you do that? > > Can you try to boot FreeBSD 8 or 7.3 live system, not installer? I had > same problem with 7.2 installer, but IPMI works with installed 7.2 > GENERIC kernel from HDD. > 8.0 installer and installed GENERIC kernel works fine in both case. > So I think there is some bug in older releases. > > Miroslav Lachman > _______________________________________________ > 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" > > Miroslav I will try out your suggestion if I get a chance but it maybe some time as the server is in production. In the meantime, I came across a workaround which works for FreeBSD and the version of IPMI (v1.29) on the Supermicro motherboard I am using (X8SIL-F). It involves changing the mouse input mode of the console launched from either IPMIView (Java based, v2.7.13) or the browser interface to the IPMI from Absolute (Windows) to Relative (Linux). Once this change was applied, FreeBSD immediately detected a new USB device (keyboard) on the same USB port as the mouse. Keyboard input then worked in the IPMI remote console. The mouse mode change is stored in the IPMI NVRAM and so it does not have to be set again. Regards Paul -- View this message in context: http://old.nabble.com/IPMI-Console%3A-No-luck-once-OS-is-booted-tp18910013p28748926.html Sent from the freebsd-stable mailing list archive at Nabble.com. From owner-freebsd-stable@FreeBSD.ORG Wed Jun 2 01:25:58 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0D614106564A for ; Wed, 2 Jun 2010 01:25:58 +0000 (UTC) (envelope-from amvandemore@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id B00CC8FC18 for ; Wed, 2 Jun 2010 01:25:56 +0000 (UTC) Received: by vws10 with SMTP id 10so4192813vws.13 for ; Tue, 01 Jun 2010 18:25:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=dW+ah0xCZzzz9RsibhVkIWB5aGHqu6TICIBcYfbAuUI=; b=BvdhwpGYRkNvEFznCN1+VV21f7neInoXgHj6D28A2FJeOnHDiaAVCovbVdFrv1M0nw ccVsYvRuQqWqChXpfZo0utUKLC95ls3OnxmN+C7WyVqBxO3Q4Oe+xf3Xnf8YcDpylYK9 BRh6oSsBg28VfH2rhxSk9IbbV83WE6Jox1Tkk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=etj8PmCSDBZHlf1u2vT1lG3l+9HrkE0l7fI19e/X8j9nLIlynyk0muLjRBURaHvW0Q kBG3K/CfntdWGE+aBC56y9ubbHapWtf9XelF6lPQc+8kNkUVHKZj85dGUvIEXsLTbmsN Ib/8xGtSEjdwHBdezkTiZf/MzM+MiQMd21s6U= MIME-Version: 1.0 Received: by 10.224.14.18 with SMTP id e18mr2774880qaa.99.1275441955968; Tue, 01 Jun 2010 18:25:55 -0700 (PDT) Received: by 10.229.99.67 with HTTP; Tue, 1 Jun 2010 18:25:55 -0700 (PDT) In-Reply-To: <28737218.post@talk.nabble.com> References: <20080809195935.F4976@borg> <20080809215249.T5563@borg> <20080810082410.X1306@borg> <57BE2631-7AED-443A-88E4-62456C048DD4@tamu.edu> <20080810102225.V1945@borg> <20080810120156.O1324@borg> <28737218.post@talk.nabble.com> Date: Tue, 1 Jun 2010 20:25:55 -0500 Message-ID: From: Adam Vande More To: PaulFr Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: IPMI Console: No luck once OS is booted X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Jun 2010 01:25:58 -0000 On Mon, May 31, 2010 at 9:53 PM, PaulFr wrote: > > When you mentioned "When I set it to disable USB Mass Storage when no image > is loaded, the ukbd came alive..." how did you do that? > I would assume the kernel was rebuilt without device umass Maybe setting it in make.conf WITHOUT_MODULES would be a good idea too. -- Adam Vande More From owner-freebsd-stable@FreeBSD.ORG Wed Jun 2 03:51:45 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2F41E106566B; Wed, 2 Jun 2010 03:51:45 +0000 (UTC) (envelope-from quakelee@geekcn.org) Received: from tarsier.geekcn.org (tarsier.geekcn.org [IPv6:2001:470:a803::1]) by mx1.freebsd.org (Postfix) with ESMTP id 990298FC08; Wed, 2 Jun 2010 03:51:44 +0000 (UTC) Received: from mail.geekcn.org (tarsier.geekcn.org [211.166.10.233]) by tarsier.geekcn.org (Postfix) with ESMTP id 88C18A55D9C; Wed, 2 Jun 2010 11:51:33 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([211.166.10.233]) by mail.geekcn.org (mail.geekcn.org [211.166.10.233]) (amavisd-new, port 10024) with LMTP id 3XIdDL-IRA-M; Wed, 2 Jun 2010 11:51:27 +0800 (CST) Received: from quakelee-work (unknown [219.142.100.197]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id 079C0A5643C; Wed, 2 Jun 2010 11:51:27 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=geekcn.org; c=nofws; q=dns; h=content-type:to:subject:references:date:cc:mime-version: content-transfer-encoding:from:organization:message-id:in-reply-to:user-agent; b=tzwqh1HiCY41o66QYLx4k0hs+C4kn7ed4KOdtDQh82tY53xSfw0LJtzzPaDMggFTo iGjbTb7EoK/Zz4ryKxeUA== Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: "freebsd-stable@freebsd.org" References: Date: Wed, 02 Jun 2010 11:51:26 +0800 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: "Chao Shin" Organization: GeekCN Message-ID: In-Reply-To: User-Agent: Opera Mail/10.51 (Win32) Cc: "freebsd-net@freebsd.org" Subject: Re: panic: rtqkill route really not free on freebsd 8.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, 02 Jun 2010 03:51:45 -0000 I worte: > Hi all, > > I have four heavy load mysql database servers which system is 8.0-release > got "panic: rtqkill route really not free" this week. We have a gateway > set up by OpenBSD have a icmp route redirect function between two > subnets, > I suspect the FreeBSD panic at trying to delete routes sent from that > gateway. > > So I set sysctl net.inet.icmp.drop_redirect=1, no more panic in past 24 > hours. > I guess maybe miss some locks or wrong delete route path in 8.0-release. > > Did any one meet this problem before? > After four days research we think the problem is between function in_matroute and in_rtqkill. This two functions' conflicted at processing RTPRF_OURS flag routes. In my opinion, it is a design problem, so I have no idea about how to resolve it. The simple way I think is change the panic assert in in_rtqkill, treat it as a normal state not assert a panic. -- The Power to Serve From owner-freebsd-stable@FreeBSD.ORG Wed Jun 2 09:34:30 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BC4F9106566B for ; Wed, 2 Jun 2010 09:34:30 +0000 (UTC) (envelope-from Johan@double-l.nl) Received: from smtp-vbr7.xs4all.nl (smtp-vbr7.xs4all.nl [194.109.24.27]) by mx1.freebsd.org (Postfix) with ESMTP id 1F7048FC12 for ; Wed, 2 Jun 2010 09:34:29 +0000 (UTC) Received: from w2003s01.double-l.local (double-l.xs4all.nl [80.126.205.144]) by smtp-vbr7.xs4all.nl (8.13.8/8.13.8) with ESMTP id o529YRip072420 for ; Wed, 2 Jun 2010 11:34:27 +0200 (CEST) (envelope-from Johan@double-l.nl) MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 x-cr-puzzleid: {009715EC-A19F-4947-BFF5-7B1DBDC79D14} Content-class: urn:content-classes:message x-cr-hashedpuzzle: AUSh BRJM Civm Ciz3 CxTm EK5f FKj7 FQPy FaP8 FhDe G1Ee HKYp IwbI I+/s Lof0 Lt1A; 1; ZgByAGUAZQBiAHMAZAAtAHMAdABhAGIAbABlAEAAZgByAGUAZQBiAHMAZAAuAG8AcgBnAA==; Sosha1_v1; 7; {009715EC-A19F-4947-BFF5-7B1DBDC79D14}; agBvAGgAYQBuAEAAZABvAHUAYgBsAGUALQBsAC4AbgBsAA==; Wed, 02 Jun 2010 09:34:23 GMT; SABQACAAcAByAG8AbABpAGEAbgB0ACAATQBMADEAMQAwACAARwA2ACAAYQBuAGQAIAA4ACAAcwB0AGEAYgBsAGUALAAgAHAAcgBlAHIAZQBsAGEAcwBlACAAcABhAG4AaQBjAA== Date: Wed, 2 Jun 2010 11:34:23 +0200 Message-ID: <57200BF94E69E54880C9BB1AF714BBCBA57A10@w2003s01.double-l.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: HP proliant ML110 G6 and 8 stable, prerelase panic Thread-Index: AcsCNslUQgg70wZeTeutRicQVQesXw== From: "Johan Hendriks" To: X-Virus-Scanned: by XS4ALL Virus Scanner Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: HP proliant ML110 G6 and 8 stable, prerelase 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, 02 Jun 2010 09:34:30 -0000 Hello all, i have a ML 110 G6 system, and installed 8.0, but the onboard NIC was not detected. So i tried Current and it detected the NIC nicely. So my second thought was to try the latest snapshot from 8, but it goes into a panic. Also the latest prerelease panics on this machine. Also a strange thing is that at boot after the install of 8.0 and a buildworld to prerelease i can not select any other option in the boot menu, the keyboard is not working. This is the panic, and then it halts. =20 Fatal trap 12: page fault while in kernel mode cpuid =3D 1; apic id =3D 04 fault virtual address =3D 0x290 fault code =3D supervisor read data, page not present instuction pointer =3D 0x20:0xffffffff805b03f6 stack pointer =3D 0x28:0xffffff80001cebe0 frame pointer =3D = 0x28:0xffffff80001cec00 code segment =3D base 0x0x, limit 0xfffff, type 0x1b =3DDPL 0, pres 1, long1,de32 0, gran 1 proccessor eflags =3Dinterupt enabled, = resume, IOPL =3D 0 current process =3D 19 (flowcleaner) trap number =3D 12 panic: page fault cpuid =3D 1=20 Uptime 3s =20 Typed over by hand, so it could contain a typo. The machine is totally freezed from here. Regards, Johan Hendriks=20 From owner-freebsd-stable@FreeBSD.ORG Wed Jun 2 15:27:26 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6DDDA1065674 for ; Wed, 2 Jun 2010 15:27:26 +0000 (UTC) (envelope-from uqs@spoerlein.net) Received: from acme.spoerlein.net (acme.spoerlein.net [IPv6:2001:470:9a47::1]) by mx1.freebsd.org (Postfix) with ESMTP id B24998FC13 for ; Wed, 2 Jun 2010 15:27:25 +0000 (UTC) Received: from acme.spoerlein.net (localhost.spoerlein.net [IPv6:::1]) by acme.spoerlein.net (8.14.4/8.14.4) with ESMTP id o52FRLGO061535 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Jun 2010 17:27:22 +0200 (CEST) (envelope-from uqs@spoerlein.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=spoerlein.net; s=dkim200908; t=1275492442; bh=8bVS+fkHVZLvaXssb3yOaCfjxlehGRwNVrLxI6d1DFk=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Transfer-Encoding:In-Reply-To; b=luRGDsWdRXWw94mpf6+593ux1VNx/9FxpnL7lfInstPtM8v/MmkO3kAQ1ZQldddZf GLeGSum3HktMDm6GdaazQBHVR4toG+m90opB0fsi06MX/m0NfVcyxi34+xRbSDQjyA MFZYw1fc+LsUDnc9pw9BBVg6Ja2Z/cxoBfMZliZc= Received: (from uqs@localhost) by acme.spoerlein.net (8.14.4/8.14.4/Submit) id o52FRLQb061510; Wed, 2 Jun 2010 17:27:21 +0200 (CEST) (envelope-from uqs@spoerlein.net) Date: Wed, 2 Jun 2010 17:27:21 +0200 From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= To: Gustau =?utf-8?B?UMOpcmV6?= Message-ID: <20100602152721.GA3594@acme.spoerlein.net> Mail-Followup-To: Gustau =?utf-8?B?UMOpcmV6?= , Mikolaj Golub , freebsd-stable@freebsd.org References: <4B62C890.3020802@entel.upc.edu> <86ljfg7hl3.fsf@kopusha.onet> <4B69C572.1020601@entel.upc.edu> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="jRHKVT23PllUwdXP" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4B69C572.1020601@entel.upc.edu> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org, Mikolaj Golub Subject: Re: bsnmpd returns incorrect hrProcessorLoad values X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Jun 2010 15:27:26 -0000 --jRHKVT23PllUwdXP Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit On Wed, 03.02.2010 at 19:50:26 +0100, Gustau Pérez wrote: > En/na Mikolaj Golub ha escrit: > > On Fri, 29 Jan 2010 12:37:52 +0100 Gustau Pérez wrote: > > > > > >> Hi, > >> > >> I'm using cacti to monitor some servers running FBSD. I was using 7.2 > >> with SCHED_4BSD. With this configuration : bsnmpd+bsnmp-ucd was > >> returning right values for the cores' load. > >> > >> I recently updated the servers (via csup) to RELENG_8 and bsnmpd is > >> returning negative values for the cores' load. If I try something like > >> in a 4-core system : > >> > >> snmpwalk -v 2c -c community server .1.3.6.1.2.1.25.3.3.1 > >> > >> what I get is : > >> > >> .1.3.6.1.2.1.25.3.3.1.1.6 = OID: .0.0 > >> .1.3.6.1.2.1.25.3.3.1.1.10 = OID: .0.0 > >> .1.3.6.1.2.1.25.3.3.1.1.14 = OID: .0.0 > >> .1.3.6.1.2.1.25.3.3.1.1.18 = OID: .0.0 > >> .1.3.6.1.2.1.25.3.3.1.2.6 = INTEGER: -182 > >> .1.3.6.1.2.1.25.3.3.1.2.10 = INTEGER: -182 > >> .1.3.6.1.2.1.25.3.3.1.2.14 = INTEGER: -182 > >> .1.3.6.1.2.1.25.3.3.1.2.18 = INTEGER: -182 Guys, can you please try the attached patch? I haven't yet tried it on an UP system but it should mostly work. It is not finished though. Regards, Uli --jRHKVT23PllUwdXP Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="bsnmpd.diff" Index: usr.sbin/bsnmpd/modules/snmp_hostres/hostres_processor_tbl.c =================================================================== --- usr.sbin/bsnmpd/modules/snmp_hostres/hostres_processor_tbl.c (revision 208628) +++ usr.sbin/bsnmpd/modules/snmp_hostres/hostres_processor_tbl.c (working copy) @@ -63,6 +63,7 @@ /* the samples from the last minute, as required by MIB */ double samples[MAX_CPU_SAMPLES]; + long states[MAX_CPU_SAMPLES][CPUSTATES]; /* current sample to fill in next time, must be < MAX_CPU_SAMPLES */ uint32_t cur_sample_idx; @@ -112,6 +113,43 @@ return ((int)floor((double)sum/(double)e->sample_cnt)); } +static int +get_avg_usage(struct processor_entry *e) +{ + u_int i, oldest; + long delta = 0; + double load = 0.0; + + assert(e != NULL); + + /* Need two samples to perform delta calculation */ + if (e->sample_cnt <= 1) + return (0); + + /* oldest usable index */ + if (e->sample_cnt == MAX_CPU_SAMPLES) + oldest = (e->cur_sample_idx + 1) % MAX_CPU_SAMPLES; + else + oldest = 0; + + /* FIXME handle wrap around */ + for (i = 0; i < CPUSTATES; i++) { + delta += e->states[e->cur_sample_idx][i]; + delta -= e->states[oldest][i]; + } + if (delta == 0) + return 0; + + /* XXX idle time is in the last index always?!? */ + load = (double)(e->states[e->cur_sample_idx][CPUSTATES-1] - + e->states[oldest][CPUSTATES-1]) / delta; + load = 100 - (load*100); + HRDBG("CPU no. %d delta ticks %ld pct usage %.2f", e->cpu_no, + delta, load); + + return (floor(load)); +} + /* * Stolen from /usr/src/bin/ps/print.c. The idle process should never * be swapped out :-) @@ -132,11 +170,15 @@ * Save a new sample */ static void -save_sample(struct processor_entry *e, struct kinfo_proc *kp) +save_sample(struct processor_entry *e, struct kinfo_proc *kp, long *cp_times) { + int i; + for (i = 0; cp_times != NULL && i < CPUSTATES; i++) + e->states[e->cur_sample_idx][i] = cp_times[i]; + e->samples[e->cur_sample_idx] = 100.0 - processor_getpcpu(kp); - e->load = get_avg_load(e); + e->load = get_avg_usage(e); e->cur_sample_idx = (e->cur_sample_idx + 1) % MAX_CPU_SAMPLES; if (++e->sample_cnt > MAX_CPU_SAMPLES) @@ -241,8 +283,6 @@ entry->idle_pid = kp->ki_pid; HRDBG("CPU no. %d with SNMP index=%d has idle PID %d", entry->cpu_no, entry->index, entry->idle_pid); - - save_sample(entry, kp); } } @@ -386,12 +426,22 @@ refresh_processor_tbl(void) { struct processor_entry *entry; - int need_pids; + int need_pids, nproc; struct kinfo_proc *plist; - int nproc; + size_t size; processor_refill_tbl(); + long pcpu_cp_times[hw_ncpu * CPUSTATES]; + memset(pcpu_cp_times, 0, sizeof(pcpu_cp_times)); + + size = hw_ncpu * CPUSTATES * sizeof(long); + /* FIXME: assert entry->ncpu <= hw_ncpu <= length of cp_times */ + if (sysctlbyname("kern.cp_times", pcpu_cp_times, &size, NULL, 0) == -1) { + syslog(LOG_ERR, "hrProcessorTable: sysctl(kern.cp_times) failed"); + return; + } + need_pids = 0; TAILQ_FOREACH(entry, &processor_tbl, link) { if (entry->idle_pid <= 0) { @@ -410,7 +460,7 @@ need_pids = 1; continue; } - save_sample(entry, plist); + save_sample(entry, plist, &pcpu_cp_times[entry->cpu_no * CPUSTATES]); } if (need_pids == 1) Index: usr.sbin/bsnmpd/modules/snmp_hostres/Makefile =================================================================== --- usr.sbin/bsnmpd/modules/snmp_hostres/Makefile (revision 208628) +++ usr.sbin/bsnmpd/modules/snmp_hostres/Makefile (working copy) @@ -48,7 +48,8 @@ printcap.c #Not having NDEBUG defined will enable assertions and a lot of output on stderr -CFLAGS+= -DNDEBUG -I${LPRSRC} +WARNS?= 1 +CFLAGS+= -I${LPRSRC} XSYM= host hrStorageOther hrStorageRam hrStorageVirtualMemory \ hrStorageFixedDisk hrStorageRemovableDisk hrStorageFloppyDisk \ hrStorageCompactDisc hrStorageRamDisk hrStorageFlashMemory \ --jRHKVT23PllUwdXP-- From owner-freebsd-stable@FreeBSD.ORG Wed Jun 2 16:17:01 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 584A3106564A for ; Wed, 2 Jun 2010 16:17:01 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [76.96.62.24]) by mx1.freebsd.org (Postfix) with ESMTP id 0434C8FC12 for ; Wed, 2 Jun 2010 16:17:00 +0000 (UTC) Received: from omta11.westchester.pa.mail.comcast.net ([76.96.62.36]) by qmta02.westchester.pa.mail.comcast.net with comcast id R0ez1e0080mv7h0524H1i8; Wed, 02 Jun 2010 16:17:01 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta11.westchester.pa.mail.comcast.net with comcast id R4Gz1e0093S48mS3X4H0Y7; Wed, 02 Jun 2010 16:17:01 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 261AA9B418; Wed, 2 Jun 2010 09:16:58 -0700 (PDT) Date: Wed, 2 Jun 2010 09:16:58 -0700 From: Jeremy Chadwick To: Gustau =?iso-8859-1?Q?P=E9rez?= , Mikolaj Golub , freebsd-stable@freebsd.org Message-ID: <20100602161658.GA75243@icarus.home.lan> References: <4B62C890.3020802@entel.upc.edu> <86ljfg7hl3.fsf@kopusha.onet> <4B69C572.1020601@entel.upc.edu> <20100602152721.GA3594@acme.spoerlein.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20100602152721.GA3594@acme.spoerlein.net> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Subject: Re: bsnmpd returns incorrect hrProcessorLoad values X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Jun 2010 16:17:01 -0000 On Wed, Jun 02, 2010 at 05:27:21PM +0200, Ulrich Spörlein wrote: > On Wed, 03.02.2010 at 19:50:26 +0100, Gustau Pérez wrote: > > En/na Mikolaj Golub ha escrit: > > > On Fri, 29 Jan 2010 12:37:52 +0100 Gustau Pérez wrote: > > > > > > > > >> Hi, > > >> > > >> I'm using cacti to monitor some servers running FBSD. I was using 7.2 > > >> with SCHED_4BSD. With this configuration : bsnmpd+bsnmp-ucd was > > >> returning right values for the cores' load. > > >> > > >> I recently updated the servers (via csup) to RELENG_8 and bsnmpd is > > >> returning negative values for the cores' load. If I try something like > > >> in a 4-core system : > > >> > > >> snmpwalk -v 2c -c community server .1.3.6.1.2.1.25.3.3.1 > > >> > > >> what I get is : > > >> > > >> .1.3.6.1.2.1.25.3.3.1.1.6 = OID: .0.0 > > >> .1.3.6.1.2.1.25.3.3.1.1.10 = OID: .0.0 > > >> .1.3.6.1.2.1.25.3.3.1.1.14 = OID: .0.0 > > >> .1.3.6.1.2.1.25.3.3.1.1.18 = OID: .0.0 > > >> .1.3.6.1.2.1.25.3.3.1.2.6 = INTEGER: -182 > > >> .1.3.6.1.2.1.25.3.3.1.2.10 = INTEGER: -182 > > >> .1.3.6.1.2.1.25.3.3.1.2.14 = INTEGER: -182 > > >> .1.3.6.1.2.1.25.3.3.1.2.18 = INTEGER: -182 > > Guys, > > can you please try the attached patch? I haven't yet tried it on an UP > system but it should mostly work. It is not finished though. When polling hrProcessorLoad for a RELENG_8 system (8.0-STABLE built April 26th) running bsnmpd, I don't see the behaviour the OP does. Instead, I see the values remain static. Example: r8host$ uptime 9:05am up 37 days, 6 hrs, 1 user, load averages: 0.00, 0.00, 0.00 r8host$ yes > /dev/null r8host$ top -b 2 last pid: 98721; load averages: 0.79, 0.28, 0.10 up 37+06:04:20 09:08:31 39 processes: 2 running, 37 sleeping Mem: 40M Active, 214M Inact, 5444M Wired, 192K Cache, 828M Buf, 2219M Free Swap: 32G Total, 32G Free PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 98715 jdc 1 118 0 5756K 1008K CPU2 2 1:03 100.00% yes 945 root 1 44 0 6840K 1292K select 3 514:21 0.00% powerd r8host$ sysctl hw.model hw.ncpu hw.model: Intel(R) Core(TM)2 Quad CPU Q8200 @ 2.33GHz hw.ncpu: 4 box1$ snmpwalk -v2c -c community r8host hrProcessorLoad HOST-RESOURCES-MIB::hrProcessorLoad.5 = INTEGER: 100 HOST-RESOURCES-MIB::hrProcessorLoad.11 = INTEGER: 100 HOST-RESOURCES-MIB::hrProcessorLoad.17 = INTEGER: 100 HOST-RESOURCES-MIB::hrProcessorLoad.23 = INTEGER: 100 I found it to be more effective polling and graphing laLoadInt.1 (OID .1.3.6.1.4.1.2021.10.1.5.1), which is provided by bsnmp-ucd. There are some other problems I found with bsnmpd pertaining to pf counters (snmp_pf.so) not getting updated but only when querying SNMP in a specific manner (which works with other modules/MIBs). I reported the problem + full diagnosis + debug data to Philip Paeps, but he's quite busy right now. Not sure if someone wants to hear about it or not, but it's easy to reproduce. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Wed Jun 2 20:25:06 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1499C106564A for ; Wed, 2 Jun 2010 20:25:06 +0000 (UTC) (envelope-from demelier.david@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 8CC168FC0C for ; Wed, 2 Jun 2010 20:25:05 +0000 (UTC) Received: by fxm5 with SMTP id 5so5244873fxm.13 for ; Wed, 02 Jun 2010 13:25:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=n0Ef21rVF4A/IsPz3OTa0/a23R6Uj2eicJC9Y1hxKRU=; b=NFUCWMwb0QzagObX67xc/DPVKfyYKPB7xgbcnPDpflKhgshvjj6ocvlZVSfvTxbd3p Mdet0uWcFo+L5POG2Uu6AfZ98i1QxVMjaxSFXhSW/X7ezFaOPisaR86jFP3RBeoLJqBV UzfGTYORcmT4/1/rQRQvbwk+xY06KiAB7F0LY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=sevOmDeg9djXucuqhQ6kPwD7+mW6xPEollpNjzAZec38GldDa/IR0a8uIgmwvjs/VS ZZ3x6BzFkdfhW1NhQXWlX/9gTskxOzFtLf6NYMboPrh9ZQ7g9G+CG8TnEcPwl6E4jYG2 IfRN5LDqb2jqwzVaSRccjYThHCVnCorSAM+qo= MIME-Version: 1.0 Received: by 10.204.162.136 with SMTP id v8mr2143232bkx.7.1275510304020; Wed, 02 Jun 2010 13:25:04 -0700 (PDT) Received: by 10.204.123.202 with HTTP; Wed, 2 Jun 2010 13:25:03 -0700 (PDT) In-Reply-To: References: Date: Wed, 2 Jun 2010 22:25:03 +0200 Message-ID: From: David DEMELIER To: freebsd-stable@freebsd.org Content-Type: multipart/mixed; boundary=000325553f069419a4048811e2c8 Subject: Strange video mode output with VESA X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Jun 2010 20:25:06 -0000 --000325553f069419a4048811e2c8 Content-Type: text/plain; charset=UTF-8 Hi there, I was so happy to see that VESA is available for amd64, but unfortunately it does not work really well for me. Take a look at this picture : http://img717.imageshack.us/img717/7311/dsc00399h.jpg My laptop is a 15,6" so the best resolution is 1366x768, I tried this : vidcontrol MODE_496. As you can see on the picture all the lines are completely everywhere, if I mouse the cursor they move away (I'm not drunk!). I have SC_PIXEL_MODE in my kernel config. The console terminal is okay until I don't excess 1280x960x32 video mode. Do you have any idea to fix this ? -- Demelier David --000325553f069419a4048811e2c8 Content-Type: text/plain; charset=US-ASCII; name="vidcontrolmodes.txt" Content-Disposition: attachment; filename="vidcontrolmodes.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_g9yl9h731 ICAgIG1vZGUjICAgICBmbGFncyAgIHR5cGUgICAgc2l6ZSAgICAgICBmb250ICAgICAgd2luZG93 ICAgICAgbGluZWFyIGJ1ZmZlcgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KICAwICgweDAwMCkgMHgw MDAwMDAwMSBUIDQweDI1ICAgICAgICAgICA4eDggICAweGI4MDAwIDMyayAzMmsgMHgwMDAwMDAw MCAzMmsKICAxICgweDAwMSkgMHgwMDAwMDAwMSBUIDQweDI1ICAgICAgICAgICA4eDggICAweGI4 MDAwIDMyayAzMmsgMHgwMDAwMDAwMCAzMmsKICAyICgweDAwMikgMHgwMDAwMDAwMSBUIDgweDI1 ICAgICAgICAgICA4eDggICAweGI4MDAwIDMyayAzMmsgMHgwMDAwMDAwMCAzMmsKICAzICgweDAw MykgMHgwMDAwMDAwMSBUIDgweDI1ICAgICAgICAgICA4eDggICAweGI4MDAwIDMyayAzMmsgMHgw MDAwMDAwMCAzMmsKICA0ICgweDAwNCkgMHgwMDAwMDAwMyBHIDMyMHgyMDB4MiBDICAgICA4eDgg ICAweGI4MDAwIDMyayAzMmsgMHgwMDAwMDAwMCAzMmsKICA1ICgweDAwNSkgMHgwMDAwMDAwMyBH IDMyMHgyMDB4MiBDICAgICA4eDggICAweGI4MDAwIDMyayAzMmsgMHgwMDAwMDAwMCAzMmsKICA2 ICgweDAwNikgMHgwMDAwMDAwMyBHIDY0MHgyMDB4MSBDICAgICA4eDggICAweGI4MDAwIDMyayAz MmsgMHgwMDAwMDAwMCAzMmsKIDEzICgweDAwZCkgMHgwMDAwMDAwMyBHIDMyMHgyMDB4NCA0ICAg ICA4eDggICAweGEwMDAwIDY0ayA2NGsgMHgwMDAwMDAwMCAyNTZrCiAxNCAoMHgwMGUpIDB4MDAw MDAwMDMgRyA2NDB4MjAweDQgNCAgICAgOHg4ICAgMHhhMDAwMCA2NGsgNjRrIDB4MDAwMDAwMDAg MjU2awogMTYgKDB4MDEwKSAweDAwMDAwMDAzIEcgNjQweDM1MHgyIDIgICAgIDh4MTQgIDB4YTAw MDAgNjRrIDY0ayAweDAwMDAwMDAwIDEyOGsKIDE4ICgweDAxMikgMHgwMDAwMDAwMyBHIDY0MHgz NTB4NCA0ICAgICA4eDE0ICAweGEwMDAwIDY0ayA2NGsgMHgwMDAwMDAwMCAyNTZrCiAxOSAoMHgw MTMpIDB4MDAwMDAwMDEgVCA0MHgyNSAgICAgICAgICAgOHgxNCAgMHhiODAwMCAzMmsgMzJrIDB4 MDAwMDAwMDAgMzJrCiAyMCAoMHgwMTQpIDB4MDAwMDAwMDEgVCA0MHgyNSAgICAgICAgICAgOHgx NCAgMHhiODAwMCAzMmsgMzJrIDB4MDAwMDAwMDAgMzJrCiAyMSAoMHgwMTUpIDB4MDAwMDAwMDEg VCA4MHgyNSAgICAgICAgICAgOHgxNCAgMHhiODAwMCAzMmsgMzJrIDB4MDAwMDAwMDAgMzJrCiAy MiAoMHgwMTYpIDB4MDAwMDAwMDEgVCA4MHgyNSAgICAgICAgICAgOHgxNCAgMHhiODAwMCAzMmsg MzJrIDB4MDAwMDAwMDAgMzJrCiAyMyAoMHgwMTcpIDB4MDAwMDAwMDEgVCA0MHgyNSAgICAgICAg ICAgOHgxNiAgMHhiODAwMCAzMmsgMzJrIDB4MDAwMDAwMDAgMzJrCiAyNCAoMHgwMTgpIDB4MDAw MDAwMDEgVCA4MHgyNSAgICAgICAgICAgOHgxNiAgMHhiODAwMCAzMmsgMzJrIDB4MDAwMDAwMDAg MzJrCiAyNiAoMHgwMWEpIDB4MDAwMDAwMDMgRyA2NDB4NDgweDQgNCAgICAgOHgxNiAgMHhhMDAw MCA2NGsgNjRrIDB4MDAwMDAwMDAgMjU2awogMjcgKDB4MDFiKSAweDAwMDAwMDAzIEcgNjQweDQ4 MHg0IDQgICAgIDh4MTYgIDB4YTAwMDAgNjRrIDY0ayAweDAwMDAwMDAwIDI1NmsKIDI4ICgweDAx YykgMHgwMDAwMDAwMyBHIDMyMHgyMDB4OCBQICAgICA4eDggICAweGEwMDAwIDY0ayA2NGsgMHgw MDAwMDAwMCA2NGsKIDMwICgweDAxZSkgMHgwMDAwMDAwMSBUIDgweDUwICAgICAgICAgICA4eDgg ICAweGI4MDAwIDMyayAzMmsgMHgwMDAwMDAwMCAzMmsKIDMyICgweDAyMCkgMHgwMDAwMDAwMSBU IDgweDMwICAgICAgICAgICA4eDE2ICAweGI4MDAwIDMyayAzMmsgMHgwMDAwMDAwMCAzMmsKIDM0 ICgweDAyMikgMHgwMDAwMDAwMSBUIDgweDYwICAgICAgICAgICA4eDggICAweGI4MDAwIDMyayAz MmsgMHgwMDAwMDAwMCAzMmsKIDM3ICgweDAyNSkgMHgwMDAwMDAwMyBHIDMyMHgyNDB4OCBWICAg ICA4eDggICAweGEwMDAwIDY0ayA2NGsgMHgwMDAwMDAwMCAyNTZrCjExMiAoMHgwNzApIDB4MDAw MDAwMDAgVCA4MHg0MyAgICAgICAgICAgOHg4ICAgMHhiODAwMCAzMmsgMzJrIDB4MDAwMDAwMDAg MzJrCjExMyAoMHgwNzEpIDB4MDAwMDAwMDEgVCA4MHg0MyAgICAgICAgICAgOHg4ICAgMHhiODAw MCAzMmsgMzJrIDB4MDAwMDAwMDAgMzJrCjI1NiAoMHgxMDApIDB4MDAwMDAwMWYgRyA2NDB4NDAw eDggUCAgICAgOHgxNiAgMHhhMDAwMCA2NGsgNjRrIDB4YzAwMDAwMDAgMjUwawoyNTcgKDB4MTAx KSAweDAwMDAwMDFmIEcgNjQweDQ4MHg4IFAgICAgIDh4MTYgIDB4YTAwMDAgNjRrIDY0ayAweGMw MDAwMDAwIDMwMGsKMjU5ICgweDEwMykgMHgwMDAwMDAxZiBHIDgwMHg2MDB4OCBQICAgICA4eDE0 ICAweGEwMDAwIDY0ayA2NGsgMHhjMDAwMDAwMCA0ODdrCjI2MSAoMHgxMDUpIDB4MDAwMDAwMWYg RyAxMDI0eDc2OHg4IFAgICAgOHgxNiAgMHhhMDAwMCA2NGsgNjRrIDB4YzAwMDAwMDAgNzY4awoy NjMgKDB4MTA3KSAweDAwMDAwMDFmIEcgMTI4MHgxMDI0eDggUCAgIDh4MTYgIDB4YTAwMDAgNjRr IDY0ayAweGMwMDAwMDAwIDEyODBrCjI2OSAoMHgxMGQpIDB4MDAwMDAwMWYgRyAzMjB4MjAweDE2 IEQgICAgOHg4ICAgMHhhMDAwMCA2NGsgNjRrIDB4YzAwMDAwMDAgMTI1awoyNzAgKDB4MTBlKSAw eDAwMDAwMDFmIEcgMzIweDIwMHgxNiBEICAgIDh4OCAgIDB4YTAwMDAgNjRrIDY0ayAweGMwMDAw MDAwIDEyNWsKMjcyICgweDExMCkgMHgwMDAwMDAxZiBHIDY0MHg0ODB4MTYgRCAgICA4eDE2ICAw eGEwMDAwIDY0ayA2NGsgMHhjMDAwMDAwMCA2MDBrCjI3MyAoMHgxMTEpIDB4MDAwMDAwMWYgRyA2 NDB4NDgweDE2IEQgICAgOHgxNiAgMHhhMDAwMCA2NGsgNjRrIDB4YzAwMDAwMDAgNjAwawoyNzUg KDB4MTEzKSAweDAwMDAwMDFmIEcgODAweDYwMHgxNiBEICAgIDh4MTQgIDB4YTAwMDAgNjRrIDY0 ayAweGMwMDAwMDAwIDkzN2sKMjc2ICgweDExNCkgMHgwMDAwMDAxZiBHIDgwMHg2MDB4MTYgRCAg ICA4eDE0ICAweGEwMDAwIDY0ayA2NGsgMHhjMDAwMDAwMCA5MzdrCjI3OCAoMHgxMTYpIDB4MDAw MDAwMWYgRyAxMDI0eDc2OHgxNiBEICAgOHgxNiAgMHhhMDAwMCA2NGsgNjRrIDB4YzAwMDAwMDAg MTUzNmsKMjc5ICgweDExNykgMHgwMDAwMDAxZiBHIDEwMjR4NzY4eDE2IEQgICA4eDE2ICAweGEw MDAwIDY0ayA2NGsgMHhjMDAwMDAwMCAxNTM2awoyODEgKDB4MTE5KSAweDAwMDAwMDFmIEcgMTI4 MHgxMDI0eDE2IEQgIDh4MTYgIDB4YTAwMDAgNjRrIDY0ayAweGMwMDAwMDAwIDI1NjBrCjI4MiAo MHgxMWEpIDB4MDAwMDAwMWYgRyAxMjgweDEwMjR4MTYgRCAgOHgxNiAgMHhhMDAwMCA2NGsgNjRr IDB4YzAwMDAwMDAgMjU2MGsKMjg4ICgweDEyMCkgMHgwMDAwMDAxZiBHIDMyMHgyMDB4MzIgRCAg ICA4eDggICAweGEwMDAwIDY0ayA2NGsgMHhjMDAwMDAwMCAyNTBrCjI4OSAoMHgxMjEpIDB4MDAw MDAwMWYgRyA2NDB4NDgweDMyIEQgICAgOHgxNiAgMHhhMDAwMCA2NGsgNjRrIDB4YzAwMDAwMDAg MTIwMGsKMjkwICgweDEyMikgMHgwMDAwMDAxZiBHIDgwMHg2MDB4MzIgRCAgICA4eDE0ICAweGEw MDAwIDY0ayA2NGsgMHhjMDAwMDAwMCAxODc1awoyOTEgKDB4MTIzKSAweDAwMDAwMDFmIEcgMTAy NHg3Njh4MzIgRCAgIDh4MTYgIDB4YTAwMDAgNjRrIDY0ayAweGMwMDAwMDAwIDMwNzJrCjI5MiAo MHgxMjQpIDB4MDAwMDAwMWYgRyAxMjgweDEwMjR4MzIgRCAgOHgxNiAgMHhhMDAwMCA2NGsgNjRr IDB4YzAwMDAwMDAgNTEyMGsKMzA3ICgweDEzMykgMHgwMDAwMDAxZiBHIDcyMHg0MDB4OCBQICAg ICA4eDE2ICAweGEwMDAwIDY0ayA2NGsgMHhjMDAwMDAwMCAzMDBrCjMwOSAoMHgxMzUpIDB4MDAw MDAwMWYgRyA3MjB4NDAweDE2IEQgICAgOHgxNiAgMHhhMDAwMCA2NGsgNjRrIDB4YzAwMDAwMDAg NTc1awozMTAgKDB4MTM2KSAweDAwMDAwMDFmIEcgNzIweDQwMHgzMiBEICAgIDh4MTYgIDB4YTAw MDAgNjRrIDY0ayAweGMwMDAwMDAwIDExNTBrCjMyMyAoMHgxNDMpIDB4MDAwMDAwMWYgRyAxNDAw eDEwNTB4OCBQICAgOHgxNiAgMHhhMDAwMCA2NGsgNjRrIDB4YzAwMDAwMDAgMTQ0M2sKMzI1ICgw eDE0NSkgMHgwMDAwMDAxZiBHIDE0MDB4MTA1MHgxNiBEICA4eDE2ICAweGEwMDAwIDY0ayA2NGsg MHhjMDAwMDAwMCAyODg3awozMjYgKDB4MTQ2KSAweDAwMDAwMDFmIEcgMTQwMHgxMDUweDMyIEQg IDh4MTYgIDB4YTAwMDAgNjRrIDY0ayAweGMwMDAwMDAwIDU3NzVrCjMzOSAoMHgxNTMpIDB4MDAw MDAwMWYgRyAxMTUyeDg2NHg4IFAgICAgOHgxNiAgMHhhMDAwMCA2NGsgNjRrIDB4YzAwMDAwMDAg OTcyawozNDEgKDB4MTU1KSAweDAwMDAwMDFmIEcgMTE1Mng4NjR4MTYgRCAgIDh4MTYgIDB4YTAw MDAgNjRrIDY0ayAweGMwMDAwMDAwIDE5NDRrCjM0MiAoMHgxNTYpIDB4MDAwMDAwMWYgRyAxMTUy eDg2NHgzMiBEICAgOHgxNiAgMHhhMDAwMCA2NGsgNjRrIDB4YzAwMDAwMDAgMzg4OGsKMzU1ICgw eDE2MykgMHgwMDAwMDAxZiBHIDEyODB4OTYweDggUCAgICA4eDE2ICAweGEwMDAwIDY0ayA2NGsg MHhjMDAwMDAwMCAxMjAwawozNTcgKDB4MTY1KSAweDAwMDAwMDFmIEcgMTI4MHg5NjB4MTYgRCAg IDh4MTYgIDB4YTAwMDAgNjRrIDY0ayAweGMwMDAwMDAwIDI0MDBrCjM1OCAoMHgxNjYpIDB4MDAw MDAwMWYgRyAxMjgweDk2MHgzMiBEICAgOHgxNiAgMHhhMDAwMCA2NGsgNjRrIDB4YzAwMDAwMDAg NDgwMGsKMzcxICgweDE3MykgMHgwMDAwMDAxZiBHIDE2MDB4MTIwMHg4IFAgICA4eDE2ICAweGEw MDAwIDY0ayA2NGsgMHhjMDAwMDAwMCAxODc1awozNzMgKDB4MTc1KSAweDAwMDAwMDFmIEcgMTYw MHgxMjAweDE2IEQgIDh4MTYgIDB4YTAwMDAgNjRrIDY0ayAweGMwMDAwMDAwIDM3NTBrCjM3NCAo MHgxNzYpIDB4MDAwMDAwMWYgRyAxNjAweDEyMDB4MzIgRCAgOHgxNiAgMHhhMDAwMCA2NGsgNjRr IDB4YzAwMDAwMDAgNzUwMGsKMzg3ICgweDE4MykgMHgwMDAwMDAxZiBHIDE3OTJ4MTM0NHg4IFAg ICA4eDE2ICAweGEwMDAwIDY0ayA2NGsgMHhjMDAwMDAwMCAyMzUyawozODkgKDB4MTg1KSAweDAw MDAwMDFmIEcgMTc5MngxMzQ0eDE2IEQgIDh4MTYgIDB4YTAwMDAgNjRrIDY0ayAweGMwMDAwMDAw IDQ3MDRrCjM5MCAoMHgxODYpIDB4MDAwMDAwMWYgRyAxNzkyeDEzNDR4MzIgRCAgOHgxNiAgMHhh MDAwMCA2NGsgNjRrIDB4YzAwMDAwMDAgOTQwOGsKNDAzICgweDE5MykgMHgwMDAwMDAxZiBHIDMy MHgyNDB4OCBQICAgICA4eDggICAweGEwMDAwIDY0ayA2NGsgMHhjMDAwMDAwMCA3NWsKNDA1ICgw eDE5NSkgMHgwMDAwMDAxZiBHIDMyMHgyNDB4MTYgRCAgICA4eDggICAweGEwMDAwIDY0ayA2NGsg MHhjMDAwMDAwMCAxNTBrCjQwNiAoMHgxOTYpIDB4MDAwMDAwMWYgRyAzMjB4MjQweDMyIEQgICAg OHg4ICAgMHhhMDAwMCA2NGsgNjRrIDB4YzAwMDAwMDAgMzAwawo0MzUgKDB4MWIzKSAweDAwMDAw MDFmIEcgNTEyeDM4NHg4IFAgICAgIDh4MTYgIDB4YTAwMDAgNjRrIDY0ayAweGMwMDAwMDAwIDE5 MmsKNDM3ICgweDFiNSkgMHgwMDAwMDAxZiBHIDUxMngzODR4MTYgRCAgICA4eDE2ICAweGEwMDAw IDY0ayA2NGsgMHhjMDAwMDAwMCAzODRrCjQzOCAoMHgxYjYpIDB4MDAwMDAwMWYgRyA1MTJ4Mzg0 eDMyIEQgICAgOHgxNiAgMHhhMDAwMCA2NGsgNjRrIDB4YzAwMDAwMDAgNzY4awo0NTEgKDB4MWMz KSAweDAwMDAwMDFmIEcgNjQweDM1MHg4IFAgICAgIDh4MTQgIDB4YTAwMDAgNjRrIDY0ayAweGMw MDAwMDAwIDIxOGsKNDUzICgweDFjNSkgMHgwMDAwMDAxZiBHIDY0MHgzNTB4MTYgRCAgICA4eDE0 ICAweGEwMDAwIDY0ayA2NGsgMHhjMDAwMDAwMCA0MzdrCjQ1NCAoMHgxYzYpIDB4MDAwMDAwMWYg RyA2NDB4MzUweDMyIEQgICAgOHgxNCAgMHhhMDAwMCA2NGsgNjRrIDB4YzAwMDAwMDAgODc1awo0 NjcgKDB4MWQzKSAweDAwMDAwMDFmIEcgMTg1NngxMzkyeDggUCAgIDh4MTYgIDB4YTAwMDAgNjRr IDY0ayAweGMwMDAwMDAwIDI1MjNrCjQ2OSAoMHgxZDUpIDB4MDAwMDAwMWYgRyAxODU2eDEzOTJ4 MTYgRCAgOHgxNiAgMHhhMDAwMCA2NGsgNjRrIDB4YzAwMDAwMDAgNTA0NmsKNDcwICgweDFkNikg MHgwMDAwMDAxZiBHIDE4NTZ4MTM5MngzMiBEICA4eDE2ICAweGEwMDAwIDY0ayA2NGsgMHhjMDAw MDAwMCAxMDA5MmsKNDgzICgweDFlMykgMHgwMDAwMDAxZiBHIDE5MjB4MTQ0MHg4IFAgICA4eDE2 ICAweGEwMDAwIDY0ayA2NGsgMHhjMDAwMDAwMCAyNzAwawo0ODUgKDB4MWU1KSAweDAwMDAwMDFm IEcgMTkyMHgxNDQweDE2IEQgIDh4MTYgIDB4YTAwMDAgNjRrIDY0ayAweGMwMDAwMDAwIDU0MDBr CjQ4NiAoMHgxZTYpIDB4MDAwMDAwMWYgRyAxOTIweDE0NDB4MzIgRCAgOHgxNiAgMHhhMDAwMCA2 NGsgNjRrIDB4YzAwMDAwMDAgMTA4MDBrCjQ5NCAoMHgxZWUpIDB4MDAwMDAwMWYgRyAxMzY2eDc2 OHg4IFAgICAgOHgxNiAgMHhhMDAwMCA2NGsgNjRrIDB4YzAwMDAwMDAgMTA1NmsKNDk1ICgweDFl ZikgMHgwMDAwMDAxZiBHIDEzNjZ4NzY4eDE2IEQgICA4eDE2ICAweGEwMDAwIDY0ayA2NGsgMHhj MDAwMDAwMCAyMDY0awo0OTYgKDB4MWYwKSAweDAwMDAwMDFmIEcgMTM2Nng3Njh4MzIgRCAgIDh4 MTYgIDB4YTAwMDAgNjRrIDY0ayAweGMwMDAwMDAwIDQxMjhrCg== --000325553f069419a4048811e2c8-- From owner-freebsd-stable@FreeBSD.ORG Wed Jun 2 20:47:50 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from [127.0.0.1] (unknown [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 952F2106567A; Wed, 2 Jun 2010 20:47:47 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-stable@FreeBSD.org Date: Wed, 2 Jun 2010 16:47:35 -0400 User-Agent: KMail/1.6.2 References: In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201006021647.37531.jkim@FreeBSD.org> Cc: David DEMELIER , ed@FreeBSD.org Subject: Re: Strange video mode output with VESA X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Jun 2010 20:47:50 -0000 On Wednesday 02 June 2010 04:25 pm, David DEMELIER wrote: > Hi there, > > I was so happy to see that VESA is available for amd64, but > unfortunately it does not work really well for me. Take a look at > this picture : > > http://img717.imageshack.us/img717/7311/dsc00399h.jpg > > My laptop is a 15,6" so the best resolution is 1366x768, I tried > this > > : vidcontrol MODE_496. As you can see on the picture all the lines > : are > > completely everywhere, if I mouse the cursor they move away (I'm > not drunk!). > > I have SC_PIXEL_MODE in my kernel config. > > The console terminal is okay until I don't excess 1280x960x32 video > mode. > > Do you have any idea to fix this ? It is kinda known problem. If the mode has larger bytes per scan line than the minimum, few characters per line are lost when the screen is scrolled up or down, i.e., framebuffer copies of whole screen. When you move the mouse onto the line, entire line is redrawn and restored. That's what you are seeing. Ed might have a better idea how to fix it (CC'ed). Jung-uk Kim From owner-freebsd-stable@FreeBSD.ORG Wed Jun 2 22:38:00 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DEF66106566B; Wed, 2 Jun 2010 22:38:00 +0000 (UTC) (envelope-from dave@jetcafe.org) Received: from hugeraid.jetcafe.org (hugeraid.jetcafe.org [205.147.26.109]) by mx1.freebsd.org (Postfix) with ESMTP id BE33C8FC12; Wed, 2 Jun 2010 22:38:00 +0000 (UTC) Received: from hugeraid.jetcafe.org (localhost [127.0.0.1]) by hugeraid.jetcafe.org (8.13.8/8.13.8) with ESMTP id o52MbxZM066281; Wed, 2 Jun 2010 15:37:59 -0700 (PDT) Message-Id: <201006022237.o52MbxZM066281@hugeraid.jetcafe.org> X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.0.4 To: John Baldwin In-reply-to: <201006011020.01318.jhb@freebsd.org> References: <201005272348.o4RNmgWh014243@hugeraid.jetcafe.org> <201005311825.o4VIPp5F051573@hugeraid.jetcafe.org> <20100531184525.GA89545@icarus.home.lan> <201006011020.01318.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 02 Jun 2010 15:37:59 -0700 From: Dave Hayes Cc: Garrett Cooper , freebsd-stable@freebsd.org, Clifton Royston , Jeremy Chadwick Subject: Re: Locking a file backed mdconfig into memory X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Jun 2010 22:38:01 -0000 John Baldwin writes: > Ok, if you are using a stock mfsroot from a release build, that should > work fine. If you have built a custom mfsroot that is larger, then > you may need to increase NKPT on i386. In very recent 7 and later you > can do this by setting it to a new value in your kernel config. In > older versions you can do this by manually adding a #define to set a > new value of NKPT in opt_global.h or hacking on the source directly. Is this also true for amd64 (which is my particular target)? -- Dave Hayes - Consultant - Altadena CA, USA - dave@jetcafe.org >>> The opinions expressed above are entirely my own <<< "Be who you are and say what you feel, because those who mind don't matter, and those who matter don't mind." - Dr. Seuss From owner-freebsd-stable@FreeBSD.ORG Thu Jun 3 06:29:26 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D557A1065677; Thu, 3 Jun 2010 06:29:26 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 350A38FC1C; Thu, 3 Jun 2010 06:29:25 +0000 (UTC) Received: by fxm5 with SMTP id 5so5533847fxm.13 for ; Wed, 02 Jun 2010 23:29:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=9Q1LvrtyZXQdkofIFWhud3dCVhh+d/p6POceAH+KzDg=; b=LUG/dTximnmr7r3dGVngqbyVq0V262LN5hzRnTTBLfVUe7PMElU9idn+9yBcBHB2O1 kZ71KSc9eHjDTZkoK+Ds+sHft4jIf+NkAy1niec6HA3YcjG8zdpd/8HfREB8uR50JdvH nj8ev7MKb6uqKNHBoIRpy4/p/xydWEOtB8LTI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=vGPwLwqqX37zpyRyIowDfqpd4/ko1ZjCOTUPDgq/dFpbGHqlG/cCCgasIUoCpWZgrP GnTGUn/bYLJb3HSSLgcUVQlw/C2O35QginAk6CupRML43662uqAD5YSq15BUBdHXSgKn geGD4HHvZ4n8oKJCB7ZWSw17fCPbfrzv6rMU0= Received: by 10.87.64.25 with SMTP id r25mr15066802fgk.20.1275546565132; Wed, 02 Jun 2010 23:29:25 -0700 (PDT) Received: from ndenev.totalterror.net (93-152-151-19.ddns.onlinedirect.bg [93.152.151.19]) by mx.google.com with ESMTPS id 4sm514954fgg.7.2010.06.02.23.29.21 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 02 Jun 2010 23:29:22 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Nikolay Denev In-Reply-To: <20100524171210.GA1418@michelle.cdnetworks.com> Date: Thu, 3 Jun 2010 09:29:20 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <87BA8EDC-BE95-4C84-94CD-5CA12961708A@gmail.com> References: <77DFF2E5-7A1E-4063-A852-2C7AD9BC3DD4@gmail.com> <201005240948.33555.jhb@freebsd.org> <20100524171210.GA1418@michelle.cdnetworks.com> To: pyunyh@gmail.com X-Mailer: Apple Mail (2.1078) Cc: freebsd-stable@freebsd.org, John Baldwin Subject: Re: if_sge related panics X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Jun 2010 06:29:26 -0000 On May 24, 2010, at 8:12 PM, Pyun YongHyeon wrote: > On Mon, May 24, 2010 at 09:48:33AM -0400, John Baldwin wrote: >> On Monday 24 May 2010 6:35:01 am Nikolay Denev wrote: >>> On May 24, 2010, at 8:57 AM, Nikolay Denev wrote: >>>=20 >>>> Hi, >>>>=20 >>>> Recently I started to experience a if_sge(4) related panic. >>>> It happens almost every time I try to download a torrent file for = example. >>>> Copying of large files over NFS seem not to trigger it, but I = haven't tested extensively. >>>>=20 >>>> Here is the panic message : >>>>=20 >>>> Fatal trap 12: page fault while in kernel mode >>>> cpuid =3D 0; apic id =3D 00 >>>> fault virtual address =3D 0x8 >>>> fault code =3D supervisor write data, page = not present >>>> instruction pointer =3D 0x20:0xffffffff80230413 >>>> stack pointer =3D = 0x28:0xffffff80001e9280 >>>> frame pointer =3D 0x28:0xffffff80001e9510 >>>> 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 12 (irq19: sge0) >>>> trap number =3D 12 >>>> panic: page fault >>>> cpuid =3D 0 >>>> Uptime: 1d20h56m20s >>>> Cannot dump. Device not defined or unavailable >>>> Automatic reboot in 15 seconds - press a key on the console to = abort >>>> Sleeping thread (tid 100039, pid 12) owns a non-sleepable lock >>>>=20 >>>> My swap is on a zvol, so I don't have dump. I'll try to attach a = disk on the eSATA port and dump there if needed. >>>=20 >>> Here is some info from the crashdump : >>>=20 >>> (kgdb) #0 doadump () at pcpu.h:223 >>> #1 0xffffffff802fb149 in boot (howto=3D260) >>> at /usr/src/sys/kern/kern_shutdown.c:416 >>> #2 0xffffffff802fb57c in panic (fmt=3D0xffffffff8055d564 "%s") >>> at /usr/src/sys/kern/kern_shutdown.c:590 >>> #3 0xffffffff805055b8 in trap_fatal (frame=3D0xffffff000288a3e0, = eva=3DVariable "eva" is not available. >>> ) >>> at /usr/src/sys/amd64/amd64/trap.c:777 >>> #4 0xffffffff805059dc in trap_pfault (frame=3D0xffffff80001e91d0, = usermode=3D0) >>> at /usr/src/sys/amd64/amd64/trap.c:693 >>> #5 0xffffffff805061c5 in trap (frame=3D0xffffff80001e91d0) >>> at /usr/src/sys/amd64/amd64/trap.c:451 >>> #6 0xffffffff804eb977 in calltrap () >>> at /usr/src/sys/amd64/amd64/exception.S:223 >>> #7 0xffffffff80230413 in sge_start_locked (ifp=3D0xffffff000270d800) >>> at /usr/src/sys/dev/sge/if_sge.c:1591 >>=20 >> Try this. sge_encap() can sometimes return an error with m_head set = to NULL: >>=20 >=20 > Thanks John. Committed in r208512. >=20 >> Index: if_sge.c >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> --- if_sge.c (revision 208375) >> +++ if_sge.c (working copy) >> @@ -1588,7 +1588,8 @@ >> if (m_head =3D=3D NULL) >> break; >> if (sge_encap(sc, &m_head)) { >> - IFQ_DRV_PREPEND(&ifp->if_snd, m_head); >> + if (m_head !=3D NULL) >> + IFQ_DRV_PREPEND(&ifp->if_snd, m_head); >> ifp->if_drv_flags |=3D IFF_DRV_OACTIVE; >> break; >> } >>=20 >> --=20 >> John Baldwin After the patch I experienced several network outages (ping reporting = "no buffer space available") that were resolved by ifconfig down/up of the sge(4) interface. I can see that most of the other drivers that handle XXX_encap() = returning m_head pointing NULL, break when this condition is hit: i.e. : Index: if_sge.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- if_sge.c (revision 208375) +++ if_sge.c (working copy) @@ -1588,7 +1588,8 @@ if (m_head =3D=3D NULL) break; if (sge_encap(sc, &m_head)) { - IFQ_DRV_PREPEND(&ifp->if_snd, m_head); + if (m_head =3D=3D NULL) + break; IFQ_DRV_PREPEND(&ifp->if_snd, m_head); ifp->if_drv_flags |=3D IFF_DRV_OACTIVE; break; } But here in sge(4) we always set IFF_DRV_OACTIVE. Do you think this can be the source of the problem ? Regards, Niki= From owner-freebsd-stable@FreeBSD.ORG Thu Jun 3 08:07:28 2010 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 6FE1B1065677; Thu, 3 Jun 2010 08:07:28 +0000 (UTC) (envelope-from stark@mapper.nl) Received: from smtp-out0.tiscali.nl (smtp-out0.tiscali.nl [195.241.79.175]) by mx1.freebsd.org (Postfix) with ESMTP id EC0978FC15; Thu, 3 Jun 2010 08:07:27 +0000 (UTC) Received: from [82.170.17.27] (helo=mapper.nl) by smtp-out0.tiscali.nl with esmtp (Exim) (envelope-from ) id 1OK5SY-0004n3-7t; Thu, 03 Jun 2010 10:07:26 +0200 Received: from [10.58.235.50] by mapper.nl with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OK5SO-0008p3-Vv; Thu, 03 Jun 2010 10:07:17 +0200 Message-ID: <4C0762B6.8010706@mapper.nl> Date: Thu, 03 Jun 2010 10:07:18 +0200 From: Mark Stapper User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Garrett Cooper References: <4BF1891F.3040704@mapper.nl> <4BF23029.80104@mapper.nl> <4BFBA130.6060506@mapper.nl> <4BFD70F5.6070005@mapper.nl> In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigE68EAA0CF673FB5894585381" Cc: stable@freebsd.org, multimedia@freebsd.org Subject: Re: Buzzing snd_emu10kx enabled card with r206173 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Jun 2010 08:07:28 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigE68EAA0CF673FB5894585381 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 30/05/2010 08:31, Garrett Cooper wrote: > > Everything I saw there appeared sane (it would have been nice to grab > the -v output from kldstat, but that's ok...). Let's try doing the > following: > > 1. Add `options EMU_MTX_DEBUG' to your kernconf. > 2. Add set the sysctl: dev.emu10kx.0.debug=3D1 . > > Let's see if anything changes... > =20 I've set SND_DEBUG and dev.emu10kx.0.debug=3D1. I'll listen to my sound output when I get home. > I'm going to try upgrading my kernel and I'll try these steps as well. > The locking between this driver and some other sound drivers isn't > exactly the same (interestingly enough this driver uses Giant locking > for some bits, while the ich one doesn't), and there were some past > bugs with other branches of *BSD's drivers related to pci bus > commands, etc; the other BSDs have dramatically different soundsystems > -- I assume the old school soundsystem, s.t. the issues are probably > not the same. > =20 The part about PCI commands is very interesting. Could this be related to my PCI NIC (em) not working properly? Greetz, Mark --------------enigE68EAA0CF673FB5894585381 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkwHYrgACgkQN9xNqOOVnWDlJACfRCU5ZC6vgbrFINWYQFl2ibcj 4L4An3K/V92DroFPuVYNWzVBjhGtXoP0 =MbQN -----END PGP SIGNATURE----- --------------enigE68EAA0CF673FB5894585381-- From owner-freebsd-stable@FreeBSD.ORG Thu Jun 3 08:51:36 2010 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 3D05F106566C for ; Thu, 3 Jun 2010 08:51:36 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by mx1.freebsd.org (Postfix) with ESMTP id D9D3E8FC1D for ; Thu, 3 Jun 2010 08:51:34 +0000 (UTC) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta09.westchester.pa.mail.comcast.net with comcast id RLrK1e0031ZXKqc59LrbvE; Thu, 03 Jun 2010 08:51:35 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta21.westchester.pa.mail.comcast.net with comcast id RLrZ1e0043S48mS3hLrah4; Thu, 03 Jun 2010 08:51:35 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 376B59B418; Thu, 3 Jun 2010 01:51:32 -0700 (PDT) Date: Thu, 3 Jun 2010 01:51:32 -0700 From: Jeremy Chadwick To: Mark Stapper Message-ID: <20100603085132.GA98990@icarus.home.lan> References: <4BF1891F.3040704@mapper.nl> <4BF23029.80104@mapper.nl> <4BFBA130.6060506@mapper.nl> <4BFD70F5.6070005@mapper.nl> <4C0762B6.8010706@mapper.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C0762B6.8010706@mapper.nl> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Garrett Cooper , stable@freebsd.org, multimedia@freebsd.org Subject: Re: Buzzing snd_emu10kx enabled card with r206173 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Jun 2010 08:51:36 -0000 On Thu, Jun 03, 2010 at 10:07:18AM +0200, Mark Stapper wrote: > > I'm going to try upgrading my kernel and I'll try these steps as well. > > The locking between this driver and some other sound drivers isn't > > exactly the same (interestingly enough this driver uses Giant locking > > for some bits, while the ich one doesn't), and there were some past > > bugs with other branches of *BSD's drivers related to pci bus > > commands, etc; the other BSDs have dramatically different soundsystems > > -- I assume the old school soundsystem, s.t. the issues are probably > > not the same. > > > The part about PCI commands is very interesting. > Could this be related to my PCI NIC (em) not working properly? Let's keep this thread focused on the issue you originally reported, re: snd_emu10kx. Open up another separate thread (don't reply to this one and start a new topic; send a brand new Email) for whatever issues you're having with em(4). In *that* thread, provide output from: - uname -a (you can X-out the machine name if need be) - dmesg | grep em0 (or whatever interface number, e.g. em2) - pciconf -lvc Thanks. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Thu Jun 3 11:29:27 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D0EFC106566B for ; Thu, 3 Jun 2010 11:29:27 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 5E5DC8FC17 for ; Thu, 3 Jun 2010 11:29:27 +0000 (UTC) Received: by wyf28 with SMTP id 28so1719525wyf.13 for ; Thu, 03 Jun 2010 04:29:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=EkyUEfDWalQIj+d5tql5OdezCaiINhgl843ZZSkl2k0=; b=uckRNrqjq8EE0xi48OnS+eOAG830lCemlfl5Rnu04nPImslqPfhwuauWRjH+ffJENP +DvANXJfSeZuf1H06sT0pAB7L7/pAraawJjWIGpK3cFIITMr/irEUB5OP3fDR5t3wzAv unm6qi2EaIKh1pOwi3rP+B1vEBsyaSAKck2tQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=vDSP/ofcg22R4d2hJZ86fIglcxePZK3WttSyUyMdQCR1jFrM4vPOVpho0/kfy2tsLH WQT8HjVO2MXYHCWGRZvdqRSqcPJPpFXg2QZryU+nyj0TKEmUU5VKuqoO0+LkpsMzPqrG pkeIBNjuDFJ0nVoK0f3dUxd2aBKSREwWF1Zxo= MIME-Version: 1.0 Received: by 10.216.155.196 with SMTP id j46mr1015901wek.1.1275564559040; Thu, 03 Jun 2010 04:29:19 -0700 (PDT) Received: by 10.216.51.78 with HTTP; Thu, 3 Jun 2010 04:29:18 -0700 (PDT) In-Reply-To: References: Date: Thu, 3 Jun 2010 15:29:18 +0400 Message-ID: From: pluknet To: freebsd-stable Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: 6.4-STABLE periodically stucks on boot around cpufreq:est X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Jun 2010 11:29:27 -0000 On 27 May 2010 13:00, pluknet wrote: > Hi, > > When booting box with recent 6.4-STABLE often it's stuck > while trying to switch context in sysctl dev.0.cpu.freq handler. fwiw, that is not an issue for 6.4-RELEASE. I'm going to binary search between them. > > AFAIK it stucks somewhere here: > /etc/rc.d/initrandom > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0# XXX temporary until we can improve the e= ntropy > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0# harvesting rate. > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0# Entropy below is not great, but better t= han nothing. > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0# This unblocks the generator at startup > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0( ps -fauxww; sysctl -a; date; df -ib; dme= sg; ps -fauxww ) \ > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| dd of=3D/dev/random bs=3D8k 2>/d= ev/null > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0cat /bin/ls | dd of=3D/dev/random bs=3D8k = 2>/dev/null > > Some useful info (on successful boot): > > [root@web72 ~]# sysctl dev.cpufreq > dev.cpufreq.0.%driver: cpufreq > dev.cpufreq.0.%parent: cpu0 > > [root@web72 ~]# sysctl -a dev.cpu > dev.cpu.0.%desc: ACPI CPU > dev.cpu.0.%driver: cpu > dev.cpu.0.%location: handle=3D\_PR_.CPU0 > dev.cpu.0.%pnpinfo: _HID=3Dnone _UID=3D0 > dev.cpu.0.%parent: acpi0 > dev.cpu.0.freq: 3144 > dev.cpu.0.freq_levels: 3144/-1 2751/-1 2358/-1 1965/-1 1572/-1 1179/-1 > 786/-1 393/-1 > dev.cpu.0.cx_supported: C1/0 > dev.cpu.0.cx_lowest: C1 > dev.cpu.0.cx_usage: 100.00% > dev.cpu.1.%desc: ACPI CPU > dev.cpu.1.%driver: cpu > dev.cpu.1.%location: handle=3D\_PR_.CPU1 > dev.cpu.1.%pnpinfo: _HID=3Dnone _UID=3D0 > dev.cpu.1.%parent: acpi0 > dev.cpu.1.cx_supported: C1/0 > dev.cpu.1.cx_lowest: C1 > dev.cpu.1.cx_usage: 100.00% > dev.cpu.2.%desc: ACPI CPU > dev.cpu.2.%driver: cpu > dev.cpu.2.%location: handle=3D\_PR_.CPU2 > dev.cpu.2.%pnpinfo: _HID=3Dnone _UID=3D0 > dev.cpu.2.%parent: acpi0 > dev.cpu.2.cx_supported: C1/0 > dev.cpu.2.cx_lowest: C1 > dev.cpu.2.cx_usage: 100.00% > dev.cpu.3.%desc: ACPI CPU > dev.cpu.3.%driver: cpu > dev.cpu.3.%location: handle=3D\_PR_.CPU3 > dev.cpu.3.%pnpinfo: _HID=3Dnone _UID=3D0 > dev.cpu.3.%parent: acpi0 > dev.cpu.3.cx_supported: C1/0 > dev.cpu.3.cx_lowest: C1 > dev.cpu.3.cx_usage: 100.00% > dev.cpu.4.%desc: ACPI CPU > dev.cpu.4.%driver: cpu > dev.cpu.4.%location: handle=3D\_PR_.CPU4 > dev.cpu.4.%pnpinfo: _HID=3Dnone _UID=3D0 > dev.cpu.4.%parent: acpi0 > dev.cpu.4.cx_supported: C1/0 > dev.cpu.4.cx_lowest: C1 > dev.cpu.4.cx_usage: 100.00% > dev.cpu.5.%desc: ACPI CPU > dev.cpu.5.%driver: cpu > dev.cpu.5.%location: handle=3D\_PR_.CPU5 > dev.cpu.5.%pnpinfo: _HID=3Dnone _UID=3D0 > dev.cpu.5.%parent: acpi0 > dev.cpu.5.cx_supported: C1/0 > dev.cpu.5.cx_lowest: C1 > dev.cpu.5.cx_usage: 100.00% > dev.cpu.6.%desc: ACPI CPU > dev.cpu.6.%driver: cpu > dev.cpu.6.%location: handle=3D\_PR_.CPU6 > dev.cpu.6.%pnpinfo: _HID=3Dnone _UID=3D0 > dev.cpu.6.%parent: acpi0 > dev.cpu.6.cx_supported: C1/0 > dev.cpu.6.cx_lowest: C1 > dev.cpu.6.cx_usage: 100.00% > dev.cpu.7.%desc: ACPI CPU > dev.cpu.7.%driver: cpu > dev.cpu.7.%location: handle=3D\_PR_.CPU7 > dev.cpu.7.%pnpinfo: _HID=3Dnone _UID=3D0 > dev.cpu.7.%parent: acpi0 > dev.cpu.7.cx_supported: C1/0 > dev.cpu.7.cx_lowest: C1 > dev.cpu.7.cx_usage: 100.00% > > Related part of dmesg: > FreeBSD 6.4-STABLE #3: Fri May 21 14:25:41 MSD 2010 > acpi_alloc_wakeup_handler: can't alloc wake memory > ACPI APIC Table: > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: Intel(R) Xeon(R) CPU =A0 =A0 =A0 =A0 =A0 X5460 =A0@ 3.16GHz (3158.77= -MHz 686-class CPU) > =A0Origin =3D "GenuineIntel" =A0Id =3D 0x10676 =A0Stepping =3D 6 > =A0Features=3D0xbfebfbff MOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE> > =A0Features2=3D0xce3bd b19>> > =A0AMD Features=3D0x20000000 > =A0AMD Features2=3D0x1 > =A0Cores per package: 4 > real memory =A0=3D 3221008384 (3071 MB) > avail memory =3D 3146702848 (3000 MB) > FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs > =A0cpu0 (BSP): APIC ID: =A00 > =A0cpu1 (AP): APIC ID: =A01 > =A0cpu2 (AP): APIC ID: =A02 > =A0cpu3 (AP): APIC ID: =A03 > =A0cpu4 (AP): APIC ID: =A04 > =A0cpu5 (AP): APIC ID: =A05 > =A0cpu6 (AP): APIC ID: =A06 > =A0cpu7 (AP): APIC ID: =A07 > ioapic0 irqs 0-23 on motherboard > kbd1 at kbdmux0 > ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413= ) > hptrr: HPT RocketRAID controller driver v1.1 (May 11 2010 16:10:15) > acpi0: on motherboard > acpi0: Power Button (fixed) > Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x588-0x58b on acpi0 > acpi_hpet0: iomem 0xfed00000-0xfed003ff on a= cpi0 > Timecounter "HPET" frequency 14318180 Hz quality 900 > cpu0: on acpi0 > acpi_throttle0: on cpu0 > cpu1: on acpi0 > acpi_throttle1: on cpu1 > acpi_throttle1: failed to attach P_CNT > device_attach: acpi_throttle1 attach returned 6 > cpu2: on acpi0 > acpi_throttle2: on cpu2 > acpi_throttle2: failed to attach P_CNT > device_attach: acpi_throttle2 attach returned 6 > cpu3: on acpi0 > acpi_throttle3: on cpu3 > acpi_throttle3: failed to attach P_CNT > device_attach: acpi_throttle3 attach returned 6 > cpu4: on acpi0 > acpi_throttle4: on cpu4 > acpi_throttle4: failed to attach P_CNT > device_attach: acpi_throttle4 attach returned 6 > cpu5: on acpi0 > acpi_throttle5: on cpu5 > acpi_throttle5: failed to attach P_CNT > device_attach: acpi_throttle5 attach returned 6 > cpu6: on acpi0 > acpi_throttle6: on cpu6 > acpi_throttle6: failed to attach P_CNT > device_attach: acpi_throttle6 attach returned 6 > cpu7: on acpi0 > acpi_throttle7: on cpu7 > acpi_throttle7: failed to attach P_CNT > device_attach: acpi_throttle7 attach returned 6 > [...] > > > Any hints? > > db> ps > =A0pid =A0ppid =A0pgrp =A0 uid =A0 state =A0 wmesg =A0 =A0 wchan =A0 =A0c= md > =A0 68 =A0 =A066 =A0 =A051 =A0 =A0 0 =A0R+ =A0 =A0 =A0CPU 255 =A0 =A0 =A0= =A0 =A0 =A0 sysctl > =A0 66 =A0 =A064 =A0 =A051 =A0 =A0 0 =A0S+ =A0 =A0 =A0wait =A0 =A0 0xc82e= 6648 sh > =A0 65 =A0 =A059 =A0 =A051 =A0 =A0 0 =A0S+ =A0 =A0 =A0piperd =A0 0xc85404= c8 dd > =A0 64 =A0 =A059 =A0 =A051 =A0 =A0 0 =A0S+ =A0 =A0 =A0wait =A0 =A0 0xc82e= 6218 sh > =A0 59 =A0 =A051 =A0 =A051 =A0 =A0 0 =A0S+ =A0 =A0 =A0wait =A0 =A0 0xc82e= 6a78 sh > =A0 51 =A0 =A0 1 =A0 =A051 =A0 =A0 0 =A0Ss+ =A0 =A0 wait =A0 =A0 0xc852ec= 90 sh > =A0 50 =A0 =A0 0 =A0 =A0 0 =A0 =A0 0 =A0SL =A0 =A0 =A0sdflush =A00xc0af56= 54 [softdepflush] > =A0 49 =A0 =A0 0 =A0 =A0 0 =A0 =A0 0 =A0SL =A0 =A0 =A0syncer =A0 0xc0adc1= bc [syncer] > =A0 48 =A0 =A0 0 =A0 =A0 0 =A0 =A0 0 =A0SL =A0 =A0 =A0vlruwt =A0 0xc8292a= 78 [vnlru] > =A0 47 =A0 =A0 0 =A0 =A0 0 =A0 =A0 0 =A0SL =A0 =A0 =A0psleep =A0 0xc0ae7d= a0 [bufdaemon] > =A0 46 =A0 =A0 0 =A0 =A0 0 =A0 =A0 0 =A0RL =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0[pagezero] > =A0 45 =A0 =A0 0 =A0 =A0 0 =A0 =A0 0 =A0SL =A0 =A0 =A0psleep =A0 0xc0af61= 94 [vmdaemon] > > db> bt 68 > Tracing pid 68 tid 100053 td 0xc8291b60 > sched_switch(c8291b60,0,1) at sched_switch+0x143 > mi_switch(1,0,c8291cc0,0,c0adf600,...) at mi_switch+0x1ba > sched_bind(c8291b60,0) at sched_bind+0x52 > cpu_est_clockrate(0,e897bad4,c84c1400,3,c84c1400,...) at cpu_est_clockrat= e+0xc1 > cf_levels_method(c8214900,c858f000,e897bb48) at cf_levels_method+0x303 > cf_get_method(c8214900,c857f000) at cf_get_method+0x12b > cpufreq_curr_sysctl(c8218e40,c81ea000,0,e897bc04,c8218e40,...) at > cpufreq_curr_sysctl+0x81 > sysctl_root(0,e897bc74,4,e897bc04) at sysctl_root+0x107 > userland_sysctl(c8291b60,e897bc74,4,0,bfbfdbdc,0,0,0,e897bc70,0) at > userland_sysctl+0x112 > __sysctl(c8291b60,e897bd04) at __sysctl+0x93 > syscall(3b,bfbf003b,bfbf003b,4,bfbfdbdc,...) at syscall+0x2bf > Xint0x80_syscall() at Xint0x80_syscall+0x1f > --- syscall (202, FreeBSD ELF32, __sysctl), eip =3D 0x2812650b, esp =3D > 0xbfbfdb4c, ebp =3D 0xbfbfdb88 --- > > db> bt 65 > Tracing pid 65 tid 100051 td 0xc82e4000 > sched_switch(c82e4000,0,1) at sched_switch+0x143 > mi_switch(1,0,c85404c8,ec997bec,c06e32b9,...) at mi_switch+0x1ba > sleepq_switch(c85404c8) at sleepq_switch+0x87 > sleepq_wait_sig(c85404c8) at sleepq_wait_sig+0x1d > msleep(c85404c8,c8540638,14c,c09d8540,0,...) at msleep+0x25a > pipe_read(c8536ab0,ec997cbc,c80f5700,0,c82e4000) at pipe_read+0x42d > dofileread(c82e4000,0,c8536ab0,ec997cbc,ffffffff,...) at dofileread+0x85 > kern_readv(c82e4000,0,ec997cbc,804f000,2000,...) at kern_readv+0x36 > read(c82e4000,ec997d04) at read+0x45 > syscall(3b,3b,3b,2004,bfbfeebc,...) at syscall+0x2bf > Xint0x80_syscall() at Xint0x80_syscall+0x1f > --- syscall (3, FreeBSD ELF32, read), eip =3D 0x2813d8d7, esp =3D > 0xbfbfee0c, ebp =3D 0xbfbfee58 --- > > db> show allpcpu > Current CPU: 1 > > cpuid =A0 =A0 =A0 =A0=3D 0 > curthread =A0 =A0=3D 0xc80fa9c0: pid 18 "swi4: clock sio" > curpcb =A0 =A0 =A0 =3D 0xe6ce4d90 > fpcurthread =A0=3D none > idlethread =A0 =3D 0xc80fa820: pid 17 "idle: cpu0" > APIC ID =A0 =A0 =A0=3D 0 > currentldt =A0 =3D 0x50 > > cpuid =A0 =A0 =A0 =A0=3D 1 > curthread =A0 =A0=3D 0xc80fa000: pid 16 "idle: cpu1" > curpcb =A0 =A0 =A0 =3D 0xe6cd2d90 > fpcurthread =A0=3D none > idlethread =A0 =3D 0xc80fa000: pid 16 "idle: cpu1" > APIC ID =A0 =A0 =A0=3D 1 > currentldt =A0 =3D 0x50 > > cpuid =A0 =A0 =A0 =A0=3D 2 > curthread =A0 =A0=3D 0xc80f8d00: pid 15 "idle: cpu2" > curpcb =A0 =A0 =A0 =3D 0xe6ccfd90 > fpcurthread =A0=3D none > > idlethread =A0 =3D 0xc80f8d00: pid 15 "idle: cpu2" > APIC ID =A0 =A0 =A0=3D 2 > currentldt =A0 =3D 0x50 > > cpuid =A0 =A0 =A0 =A0=3D 3 > curthread =A0 =A0=3D 0xc80f8b60: pid 14 "idle: cpu3" > curpcb =A0 =A0 =A0 =3D 0xe6cccd90 > fpcurthread =A0=3D none > idlethread =A0 =3D 0xc80f8b60: pid 14 "idle: cpu3" > APIC ID =A0 =A0 =A0=3D 3 > currentldt =A0 =3D 0x50 > > cpuid =A0 =A0 =A0 =A0=3D 4 > curthread =A0 =A0=3D 0xc80f89c0: pid 13 "idle: cpu4" > curpcb =A0 =A0 =A0 =3D 0xe6cc9d90 > fpcurthread =A0=3D none > idlethread =A0 =3D 0xc80f89c0: pid 13 "idle: cpu4" > APIC ID =A0 =A0 =A0=3D 4 > currentldt =A0 =3D 0x50 > cpuid =A0 =A0 =A0 =A0=3D 5 > curthread =A0 =A0=3D 0xc80f8820: pid 12 "idle: cpu5" > curpcb =A0 =A0 =A0 =3D 0xe6cc6d90 > fpcurthread =A0=3D none > idlethread =A0 =3D 0xc80f8820: pid 12 "idle: cpu5" > APIC ID =A0 =A0 =A0=3D 5 > currentldt =A0 =3D 0x50 > > cpuid =A0 =A0 =A0 =A0=3D 6 > curthread =A0 =A0=3D 0xc80f8680: pid 11 "idle: cpu6" > curpcb =A0 =A0 =A0 =3D 0xe6cc3d90 > fpcurthread =A0=3D none > idlethread =A0 =3D 0xc80f8680: pid 11 "idle: cpu6" > APIC ID =A0 =A0 =A0=3D 6 > currentldt =A0 =3D 0x50 > > cpuid =A0 =A0 =A0 =A0=3D 7 > curthread =A0 =A0=3D 0xc80f84e0: pid 10 "idle: cpu7" > curpcb =A0 =A0 =A0 =3D 0xe6cc0d90 > fpcurthread =A0=3D none > idlethread =A0 =3D 0xc80f84e0: pid 10 "idle: cpu7" > APIC ID =A0 =A0 =A0=3D 7 > currentldt =A0 =3D 0x50 > > db> bt 18 > Tracing pid 18 tid 100015 td 0xc80fa9c0 > sched_switch(c0b21c20,c093091c,0,0,0,...) at sched_switch+0x143 > --=20 wbr, pluknet From owner-freebsd-stable@FreeBSD.ORG Thu Jun 3 14:32:08 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3C53C106564A for ; Thu, 3 Jun 2010 14:32:08 +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 0DCC78FC1C for ; Thu, 3 Jun 2010 14:32:08 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id BB8C446C1D; Thu, 3 Jun 2010 10:32:07 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id F376A8A025; Thu, 3 Jun 2010 10:32:06 -0400 (EDT) From: John Baldwin To: Dave Hayes Date: Thu, 3 Jun 2010 10:29:00 -0400 User-Agent: KMail/1.12.1 (FreeBSD/7.3-CBSD-20100217; KDE/4.3.1; amd64; ; ) References: <201005272348.o4RNmgWh014243@hugeraid.jetcafe.org> <201006011020.01318.jhb@freebsd.org> <201006022237.o52MbxZM066281@hugeraid.jetcafe.org> In-Reply-To: <201006022237.o52MbxZM066281@hugeraid.jetcafe.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201006031029.00588.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Thu, 03 Jun 2010 10:32:07 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Garrett Cooper , freebsd-stable@freebsd.org, Clifton Royston , Jeremy Chadwick Subject: Re: Locking a file backed mdconfig into memory X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Jun 2010 14:32:08 -0000 On Wednesday 02 June 2010 6:37:59 pm Dave Hayes wrote: > John Baldwin writes: > > Ok, if you are using a stock mfsroot from a release build, that should > > work fine. If you have built a custom mfsroot that is larger, then > > you may need to increase NKPT on i386. In very recent 7 and later you > > can do this by setting it to a new value in your kernel config. In > > older versions you can do this by manually adding a #define to set a > > new value of NKPT in opt_global.h or hacking on the source directly. > > Is this also true for amd64 (which is my particular target)? It might be. What is the panic you are seeing? -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Thu Jun 3 18:57:10 2010 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 459C0106566C; Thu, 3 Jun 2010 18:57:10 +0000 (UTC) (envelope-from stark@mapper.nl) Received: from smtp-out2.tiscali.nl (smtp-out2.tiscali.nl [195.241.79.177]) by mx1.freebsd.org (Postfix) with ESMTP id C6FCE8FC25; Thu, 3 Jun 2010 18:57:09 +0000 (UTC) Received: from [82.170.17.27] (helo=mapper.nl) by smtp-out2.tiscali.nl with esmtp (Exim) (envelope-from ) id 1OKFbI-0002X3-KA; Thu, 03 Jun 2010 20:57:08 +0200 Received: from bowser ([10.58.235.1] helo=[10.58.235.6]) by mapper.nl with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OKFb9-000ALM-Eb; Thu, 03 Jun 2010 20:56:59 +0200 Message-ID: <4C07FB08.9010603@mapper.nl> Date: Thu, 03 Jun 2010 20:57:12 +0200 From: Mark Stapper User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.9) Gecko/20100514 Thunderbird/3.0.4 MIME-Version: 1.0 To: Garrett Cooper References: <4BF1891F.3040704@mapper.nl> <4BF23029.80104@mapper.nl> <4BFBA130.6060506@mapper.nl> <4BFD70F5.6070005@mapper.nl> In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org, multimedia@freebsd.org Subject: Re: Buzzing snd_emu10kx enabled card with r206173 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Jun 2010 18:57:10 -0000 On 05/30/10 08:31, Garrett Cooper wrote: > > Everything I saw there appeared sane (it would have been nice to grab > the -v output from kldstat, but that's ok...). Let's try doing the > following: > > 1. Add `options EMU_MTX_DEBUG' to your kernconf. > 2. Add set the sysctl: dev.emu10kx.0.debug=1 . > > Let's see if anything changes... > > Also, if you could provide some more hardware stats (say dmesg.boot > and/or devinfo -v) and version stats (I already know that you're > running amd64 from your kernel config) for the OS that would be > helpful as well. > > I'm going to try upgrading my kernel and I'll try these steps as well. > The locking between this driver and some other sound drivers isn't > exactly the same (interestingly enough this driver uses Giant locking > for some bits, while the ich one doesn't), and there were some past > bugs with other branches of *BSD's drivers related to pci bus > commands, etc; the other BSDs have dramatically different soundsystems > -- I assume the old school soundsystem, s.t. the issues are probably > not the same. > > Thanks, > -Garrett > I've update my kernel, put in the SND_DEBUG flag and set "dev.emu10kx.0.debug=1" Everything worked. Then I unset the flag. Everything still worked. Then I did a reboot without the flag in loader.conf Everything still worked! Weird... If it fails again i'll try to find something usefull in my loggings for you. Thanks for the help. Regards, Mark From owner-freebsd-stable@FreeBSD.ORG Thu Jun 3 19:52:05 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DB3C310656C8 for ; Thu, 3 Jun 2010 19:52:05 +0000 (UTC) (envelope-from u.drolshagen@t-online.de) Received: from mailout10.t-online.de (mailout10.t-online.de [194.25.134.21]) by mx1.freebsd.org (Postfix) with ESMTP id 9DCAC8FC18 for ; Thu, 3 Jun 2010 19:52:04 +0000 (UTC) Received: from fwd04.aul.t-online.de (fwd04.aul.t-online.de ) by mailout10.t-online.de with smtp id 1OKGDi-0004OU-1Z; Thu, 03 Jun 2010 21:36:50 +0200 Received: from lysander.localnet (TzyqDuZ-8hBORn0nga76z1UQJwL3Cleq4+aYjoll6-yuPb8W+5a8cSEN8CFREy6wox@[84.134.72.66]) by fwd04.aul.t-online.de with esmtp id 1OKGDf-0cJqYi0; Thu, 3 Jun 2010 21:36:47 +0200 From: Ulrich Drolshagen To: "freebsd-stable" Date: Thu, 3 Jun 2010 21:36:46 +0200 User-Agent: KMail/1.12.4 (Linux/2.6.31-gentoo-r6; KDE/4.3.5; i686; ; ) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201006032136.46625.u.drolshagen@t-online.de> X-ID: TzyqDuZ-8hBORn0nga76z1UQJwL3Cleq4+aYjoll6-yuPb8W+5a8cSEN8CFREy6wox X-TOI-MSGID: f9828502-3780-4480-8395-ebad9a072163 Subject: Support for ICH sata raid controler X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Jun 2010 19:52:05 -0000 Hi, we are about to aquire a new Primergy TX150. I can not find any information on support of the Intel ICHx sata raid controller in the Hardware Notes of 8- Stable. Does anybody know? Thank you very much for your support Ulrich Drolshagen -- http://www.ulrich-drolshagen.de From owner-freebsd-stable@FreeBSD.ORG Thu Jun 3 20:40:27 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A7E481065670 for ; Thu, 3 Jun 2010 20:40:27 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta07.emeryville.ca.mail.comcast.net (qmta07.emeryville.ca.mail.comcast.net [76.96.30.64]) by mx1.freebsd.org (Postfix) with ESMTP id 8F1EE8FC12 for ; Thu, 3 Jun 2010 20:40:27 +0000 (UTC) Received: from omta22.emeryville.ca.mail.comcast.net ([76.96.30.89]) by qmta07.emeryville.ca.mail.comcast.net with comcast id RSX31e0031vN32cA7YgTXS; Thu, 03 Jun 2010 20:40:27 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta22.emeryville.ca.mail.comcast.net with comcast id RYgS1e0023S48mS8iYgSbC; Thu, 03 Jun 2010 20:40:26 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id EFDC49B418; Thu, 3 Jun 2010 13:40:25 -0700 (PDT) Date: Thu, 3 Jun 2010 13:40:25 -0700 From: Jeremy Chadwick To: Ulrich Drolshagen Message-ID: <20100603204025.GA17762@icarus.home.lan> References: <201006032136.46625.u.drolshagen@t-online.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201006032136.46625.u.drolshagen@t-online.de> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable Subject: Re: Support for ICH sata raid controler X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Jun 2010 20:40:27 -0000 On Thu, Jun 03, 2010 at 09:36:46PM +0200, Ulrich Drolshagen wrote: > we are about to aquire a new Primergy TX150. I can not find any information on > support of the Intel ICHx sata raid controller in the Hardware Notes of 8- > Stable. Does anybody know? All revisions of the ICHxx series are supported (ICH3 to ICH10 I can confirm). If you plan on using the RAID functionality of the chipset (otherwise known as "MatrixRAID" or "Matrix Storage Technology"), don't bother[1]. Instead, enable AHCI on the controller (usually in the system BIOS) and use one of FreeBSD (software/OS-level) RAID/RAID-like implementations such as gmirror, gvinum, or ZFS. I'd also recommend using ahci.ko instead of ataahci.ko for AHCI support. achi.ko provides a AHCI/SATA-to-CAM translation layer (which means you gain benefits like NCQ; disks show up as adaX), while ataahci.ko (the default) does not use CAM (and does not support NCQ; disks show up as adX). You can use ahci.ko by placing 'ahci_load="yes"' in /boot/loader.conf, or when booting a FreeBSD installation medium, dropping to the loader prompt and typing "load ahci" then "boot". [1]: http://en.wikipedia.org/wiki/Intel_Matrix_RAID -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Thu Jun 3 20:51:18 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 406521065675 for ; Thu, 3 Jun 2010 20:51:18 +0000 (UTC) (envelope-from demelier.david@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id C64078FC18 for ; Thu, 3 Jun 2010 20:51:17 +0000 (UTC) Received: by bwz2 with SMTP id 2so231118bwz.13 for ; Thu, 03 Jun 2010 13:51:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=juof99woN26jI1SZmT70rS5XuCkcg3ZqbfQ3sSim1oQ=; b=TAYEmifXCIWcjVvy/wLHG4IDW4rbXWjrul8vCyOkxw4d4lIysp6K2bmQvMl6G1QolR argTLjkH43/hkGZivwY8NAUx4CWzCh5ZUW9WixkhuysLQhVp4SiftRFXxbhCJLc1T6QN kmcfHYQAzBEkDafLESaPIla38EWrq9gUGEEng= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=bMLCDK8uHn6WEhSQppjKWTySL94yVpXibGGnzijMBYoiN7pzlxrnPwef5/+3ocqfap jnrhh0HLh/4ZniD/MBOAGNmSWh5Eg6F/s1xA+cEvKGsX/C6qxkwNCXJyKpMvkDnULTqh k0I8GUyU+D8Ff8Y47IC/sDuSDwDotZeCR6phM= MIME-Version: 1.0 Received: by 10.204.46.207 with SMTP id k15mr3320426bkf.106.1275598276014; Thu, 03 Jun 2010 13:51:16 -0700 (PDT) Received: by 10.204.123.202 with HTTP; Thu, 3 Jun 2010 13:51:15 -0700 (PDT) Date: Thu, 3 Jun 2010 22:51:15 +0200 Message-ID: From: David DEMELIER To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=UTF-8 Subject: textproc/iso8879 fails to build. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Jun 2010 20:51:18 -0000 Hi, I got this build error when trying to build editors/abiword : ===> Extracting for iso8879-1986_2 => MD5 Checksum OK for isoENTS.zip. => SHA256 Checksum OK for isoENTS.zip. ===> Patching for iso8879-1986_2 ===> iso8879-1986_2 depends on executable: unzip - found ===> Configuring for iso8879-1986_2 ===> Installing for iso8879-1986_2 ===> iso8879-1986_2 depends on file: /usr/local/bin/xmlcatmgr - found ===> Generating temporary packing list ===> Checking if textproc/iso8879 already installed Archive: /usr/distfiles/isoENTS.zip caution: filename not matched: -d caution: filename not matched: /usr/local/share/sgml/iso8879 *** Error code 11 Stop in /usr/ports/textproc/iso8879. *** Error code 1 Stop in /usr/ports/textproc/docbook-410. *** Error code 1 Stop in /usr/ports/sysutils/polkit. Cheers. -- Demelier David From owner-freebsd-stable@FreeBSD.ORG Thu Jun 3 21:04:38 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3E961106567A for ; Thu, 3 Jun 2010 21:04:38 +0000 (UTC) (envelope-from u.drolshagen@t-online.de) Received: from mailout03.t-online.de (mailout03.t-online.de [194.25.134.81]) by mx1.freebsd.org (Postfix) with ESMTP id E97E88FC15 for ; Thu, 3 Jun 2010 21:04:36 +0000 (UTC) Received: from fwd09.aul.t-online.de (fwd09.aul.t-online.de ) by mailout03.t-online.de with smtp id 1OKHad-0006HU-4h; Thu, 03 Jun 2010 23:04:35 +0200 Received: from lysander.localnet (XH2Ie4ZH8hD1pjYuINWq0-rIB0gviYAkilMgbWXbDE0wVrSVVClsfptQ7LKswuOQJi@[84.134.72.66]) by fwd09.aul.t-online.de with esmtp id 1OKHaa-1jpe5I0; Thu, 3 Jun 2010 23:04:32 +0200 From: Ulrich Drolshagen To: freebsd-stable@freebsd.org Date: Thu, 3 Jun 2010 23:04:31 +0200 User-Agent: KMail/1.12.4 (Linux/2.6.31-gentoo-r6; KDE/4.3.5; i686; ; ) References: <201006032136.46625.u.drolshagen@t-online.de> <20100603204025.GA17762@icarus.home.lan> In-Reply-To: <20100603204025.GA17762@icarus.home.lan> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201006032304.31539.u.drolshagen@t-online.de> X-ID: XH2Ie4ZH8hD1pjYuINWq0-rIB0gviYAkilMgbWXbDE0wVrSVVClsfptQ7LKswuOQJi X-TOI-MSGID: caf1bf7e-7b3b-43f3-9c6b-8143db7e1987 Subject: Re: Support for ICH sata raid controler X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Jun 2010 21:04:38 -0000 Am Donnerstag 03 Juni 2010 schrieb Jeremy Chadwick: > On Thu, Jun 03, 2010 at 09:36:46PM +0200, Ulrich Drolshagen wrote: > > we are about to aquire a new Primergy TX150. I can not find any > > information on support of the Intel ICHx sata raid controller in the > > Hardware Notes of 8- Stable. Does anybody know? > > All revisions of the ICHxx series are supported (ICH3 to ICH10 I can > confirm). > > If you plan on using the RAID functionality of the chipset (otherwise > known as "MatrixRAID" or "Matrix Storage Technology"), don't bother[1]. > > Instead, enable AHCI on the controller (usually in the system BIOS) and > use one of FreeBSD (software/OS-level) RAID/RAID-like implementations > such as gmirror, gvinum, or ZFS. > > I'd also recommend using ahci.ko instead of ataahci.ko for AHCI support. > achi.ko provides a AHCI/SATA-to-CAM translation layer (which means you > gain benefits like NCQ; disks show up as adaX), while ataahci.ko (the > default) does not use CAM (and does not support NCQ; disks show up as > adX). > > You can use ahci.ko by placing 'ahci_load="yes"' in /boot/loader.conf, > or when booting a FreeBSD installation medium, dropping to the loader > prompt and typing "load ahci" then "boot". > > [1]: http://en.wikipedia.org/wiki/Intel_Matrix_RAID > Indeed much to consider. Thank you Jeremy for your suggestions Ulrich -- http://www.ulrich-drolshagen.de From owner-freebsd-stable@FreeBSD.ORG Thu Jun 3 21:04:40 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5E3A0106566B for ; Thu, 3 Jun 2010 21:04:40 +0000 (UTC) (envelope-from spawk@acm.poly.edu) Received: from acm.poly.edu (acm.poly.edu [128.238.9.200]) by mx1.freebsd.org (Postfix) with ESMTP id ED1868FC0A for ; Thu, 3 Jun 2010 21:04:38 +0000 (UTC) Received: (qmail 6618 invoked from network); 3 Jun 2010 21:04:37 -0000 Received: from unknown (HELO ?10.0.0.170?) (spawk@128.238.64.31) by acm.poly.edu with AES256-SHA encrypted SMTP; 3 Jun 2010 21:04:37 -0000 Message-ID: <4C0818DB.1050101@acm.poly.edu> Date: Thu, 03 Jun 2010 17:04:27 -0400 From: Boris Kochergin User-Agent: Thunderbird 2.0.0.24 (X11/20100330) MIME-Version: 1.0 To: Jeremy Chadwick References: <201006032136.46625.u.drolshagen@t-online.de> <20100603204025.GA17762@icarus.home.lan> In-Reply-To: <20100603204025.GA17762@icarus.home.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable , Ulrich Drolshagen Subject: Re: Support for ICH sata raid controler X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Jun 2010 21:04:40 -0000 Jeremy Chadwick wrote: > On Thu, Jun 03, 2010 at 09:36:46PM +0200, Ulrich Drolshagen wrote: > >> we are about to aquire a new Primergy TX150. I can not find any information on >> support of the Intel ICHx sata raid controller in the Hardware Notes of 8- >> Stable. Does anybody know? >> > > All revisions of the ICHxx series are supported (ICH3 to ICH10 I can > confirm). > > If you plan on using the RAID functionality of the chipset (otherwise > known as "MatrixRAID" or "Matrix Storage Technology"), don't bother[1]. > > Instead, enable AHCI on the controller (usually in the system BIOS) and > use one of FreeBSD (software/OS-level) RAID/RAID-like implementations > such as gmirror, gvinum, or ZFS. > > I'd also recommend using ahci.ko instead of ataahci.ko for AHCI support. > achi.ko provides a AHCI/SATA-to-CAM translation layer (which means you > gain benefits like NCQ; disks show up as adaX), while ataahci.ko (the > default) does not use CAM (and does not support NCQ; disks show up as > adX). > > You can use ahci.ko by placing 'ahci_load="yes"' in /boot/loader.conf, > or when booting a FreeBSD installation medium, dropping to the loader > prompt and typing "load ahci" then "boot". > > [1]: http://en.wikipedia.org/wiki/Intel_Matrix_RAID > While it probably won't be done in time to be immediately useful to the original poster, I am working on a GEOM-based ataraid replacement that will behave better. -Boris From owner-freebsd-stable@FreeBSD.ORG Thu Jun 3 23:42:31 2010 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 144EE106566B for ; Thu, 3 Jun 2010 23:42:31 +0000 (UTC) (envelope-from freebsdlists@bsdunix.ch) Received: from conversation.bsdunix.ch (ns1.bsdunix.ch [82.220.1.90]) by mx1.freebsd.org (Postfix) with ESMTP id 96A138FC08 for ; Thu, 3 Jun 2010 23:42:30 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by conversation.bsdunix.ch (Postfix) with ESMTP id 26BFE65F9 for ; Fri, 4 Jun 2010 01:25:00 +0200 (CEST) Received: from conversation.bsdunix.ch ([127.0.0.1]) by localhost (conversation.bsdunix.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id si3SPpukp9h2 for ; Fri, 4 Jun 2010 01:24:58 +0200 (CEST) Received: from Tom-iMac.local (dmhd.bsdunix.ch [82.220.17.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by conversation.bsdunix.ch (Postfix) with ESMTP id B78086489 for ; Fri, 4 Jun 2010 01:24:58 +0200 (CEST) Message-ID: <4C0839CB.2070802@bsdunix.ch> Date: Fri, 04 Jun 2010 01:24:59 +0200 From: Thomas User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; de; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: Subject: Is crunchgen broken? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Jun 2010 23:42:31 -0000 Hello I tryed to use crunchgen. It's not working for me. I always get a NFS4ACL error. root@bert:/usr/src/release/i386# crunchgen boot_crunch.conf Run "make -f boot_crunch.mk" to build crunched binary. (cd /usr/src/sbin/tunefs && make -DRELEASE_CRUNCH -Dlint depend && make -DRELEASE_CRUNCH -Dlint tunefs.o) cc -mtune=native -O2 -fno-strict-aliasing -pipe -march=native -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/sbin/tunefs/tunefs.c /usr/src/sbin/tunefs/tunefs.c: In function 'main': /usr/src/sbin/tunefs/tunefs.c:274: error: 'FS_NFS4ACLS' undeclared (first use in this function) /usr/src/sbin/tunefs/tunefs.c:274: error: (Each undeclared identifier is reported only once /usr/src/sbin/tunefs/tunefs.c:274: error: for each function it appears in.) /usr/src/sbin/tunefs/tunefs.c: In function 'printfs': /usr/src/sbin/tunefs/tunefs.c:475: error: 'FS_NFS4ACLS' undeclared (first use in this function) *** Error code 1 Stop in /usr/src/sbin/tunefs. *** Error code 1 root@bert:/usr/src/usr.sbin/crunch/examples# crunchgen kcopy.conf Run "make -f kcopy.mk" to build crunched binary. root@bert:/usr/src/usr.sbin/crunch/examples# make -f kcopy.mk (cd /usr/src/sbin/mount && make depend && make mount.o mount_fs.o getmntopts.o vfslist.o) cc -mtune=native -O2 -fno-strict-aliasing -pipe -march=native -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /usr/src/sbin/mount/mount.c /usr/src/sbin/mount/mount.c:114: error: 'MNT_NFS4ACLS' undeclared here (not in a function) /usr/src/sbin/mount/mount.c: In function 'flags2opts': /usr/src/sbin/mount/mount.c:922: error: invalid operands to binary & *** Error code 1 I also tried the example as described in man (1) crunchgen: root@bert:/usr/src/usr.sbin/crunch/examples# crunchgen -m Makefile kcopy.conf Run "make -f Makefile" to build crunched binary. root@bert:/usr/src/usr.sbin/crunch/examples# make objs (cd /usr/src/sbin/mount && make depend && make mount.o mount_fs.o getmntopts.o vfslist.o) cc -mtune=native -O2 -fno-strict-aliasing -pipe -march=native -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /usr/src/sbin/mount/mount.c /usr/src/sbin/mount/mount.c:114: error: 'MNT_NFS4ACLS' undeclared here (not in a function) /usr/src/sbin/mount/mount.c: In function 'flags2opts': /usr/src/sbin/mount/mount.c:922: error: invalid operands to binary & How can i fix this? my system: FreeBSD 8.0-STABLE #11: Sun Apr 18 15:55:23 CEST 2010 root@bert/usr/obj/usr/src/sys/GENERIC i386 Regards, Thomas From owner-freebsd-stable@FreeBSD.ORG Thu Jun 3 23:51:50 2010 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 1500B1065675 for ; Thu, 3 Jun 2010 23:51:50 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [IPv6:2001:470:a803::1]) by mx1.freebsd.org (Postfix) with ESMTP id 56D478FC15 for ; Thu, 3 Jun 2010 23:51:48 +0000 (UTC) Received: from mail.geekcn.org (tarsier.geekcn.org [211.166.10.233]) by tarsier.geekcn.org (Postfix) with ESMTP id D4545A561B1; Fri, 4 Jun 2010 07:51:46 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([211.166.10.233]) by mail.geekcn.org (mail.geekcn.org [211.166.10.233]) (amavisd-new, port 10024) with LMTP id DGF9Ho5Z1rMi; Fri, 4 Jun 2010 07:51:40 +0800 (CST) Received: from delta.delphij.net (drawbridge.ixsystems.com [206.40.55.65]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id 79FE5A5501B; Fri, 4 Jun 2010 07:51:39 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:cc:subject:references:in-reply-to: x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=F5VWDAcYdzcitV8KeT+ULsOGCor/h6ZYsy0o9K+QdbyHYyA92DNy1ouAuWp89UM7H tqlnZJ38Hl2/tKOFM6+AQ== Message-ID: <4C084006.5060702@delphij.net> Date: Thu, 03 Jun 2010 16:51:34 -0700 From: Xin LI Organization: The Geek China Organization User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.9) Gecko/20100602 Thunderbird/3.0.4 ThunderBrowse/3.2.8.1 MIME-Version: 1.0 To: Thomas References: <4C0839CB.2070802@bsdunix.ch> In-Reply-To: <4C0839CB.2070802@bsdunix.ch> X-Enigmail-Version: 1.0.1 OpenPGP: id=3FCA37C1; url=http://www.delphij.net/delphij.asc Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org Subject: Re: Is crunchgen broken? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jun 2010 23:51:50 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2010/06/03 16:24, Thomas wrote: > Hello > > I tryed to use crunchgen. It's not working for me. I always get a > NFS4ACL error. > > root@bert:/usr/src/release/i386# crunchgen boot_crunch.conf > Run "make -f boot_crunch.mk" to build crunched binary. > > (cd /usr/src/sbin/tunefs && make -DRELEASE_CRUNCH -Dlint depend && > make -DRELEASE_CRUNCH -Dlint tunefs.o) > cc -mtune=native -O2 -fno-strict-aliasing -pipe -march=native -std=gnu99 > -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k > -Wno-uninitialized -Wno-pointer-sign -c /usr/src/sbin/tunefs/tunefs.c > /usr/src/sbin/tunefs/tunefs.c: In function 'main': > /usr/src/sbin/tunefs/tunefs.c:274: error: 'FS_NFS4ACLS' undeclared > (first use in this function) > /usr/src/sbin/tunefs/tunefs.c:274: error: (Each undeclared identifier is > reported only once > /usr/src/sbin/tunefs/tunefs.c:274: error: for each function it appears in.) > /usr/src/sbin/tunefs/tunefs.c: In function 'printfs': > /usr/src/sbin/tunefs/tunefs.c:475: error: 'FS_NFS4ACLS' undeclared > (first use in this function) > *** Error code 1 Just a guess - did you have done a full build and 'make installworld'? Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iQEcBAEBCAAGBQJMCEAGAAoJEATO+BI/yjfB7zUIANjCi6H25g9LOPBF0Fmj6EfU WbcfdCohtnpnN7RLc8XozksKudakCyvL0Abefw0WMJlicdTHDm0sfl50BRGXjAVl UV68fsFtZT+VLDZTZMuS6RNNmxuM8kPrNvO5AlDIaeDh7I8Kk8Q/vdpCXuDyxDqp SjykzXHqsAvdKE8IiNWBbv2DDB65ozQV+ZLyJo9XlppQ/Rgbw9xZ9UkeH2TgsVS5 pHUBFiVpU7o0jEsQBHSgb5R2Oqt/HwWefFdUKktYh3PdZviXGggHPjJYDOVe/vvR 5nC78/WMxrCk0lmz5mOFdjt2OjdcNqi27wc9Ho7Ld+hdoftjtas0+e6+Y72aBj4= =hALf -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Thu Jun 3 23:56:11 2010 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 021F51065672 for ; Thu, 3 Jun 2010 23:56:11 +0000 (UTC) (envelope-from sdrhodus@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id AE1568FC13 for ; Thu, 3 Jun 2010 23:56:10 +0000 (UTC) Received: by vws19 with SMTP id 19so206628vws.13 for ; Thu, 03 Jun 2010 16:56:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=yJwSQ5PwWP7+IyWxMinzNwnePLVuZ3JH3N80HhJLtPU=; b=fIoKwGhPSXAk3z18S7xI0RScBcTROi/TMGU/NuG/ae1hipbMXWia/OswWY7nh2kRqy NPREW47VQ9SmRBqFWVpKZVGM3G975Kt7xowCw4Nbi2RmqOkp0VAJTWZ79YuTpypUrcst tM8U6UpADqf2S6cclcIRHdoM1As3LgNNxJZ1c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=ebU53by1y90PLVTkGpTegSgD/mSvAjnGLvxTMF6OlbM+4E3rvj9ZQkQjD4FK8HJfp5 zUEqEOmps1eR23BAhGFmx+MMhDgo+4516wzv/7arEH71iKjHEuhd+6PC0EfUjVenJPyU 2COY3g114H0qMjin0mWJeiYETbiKK1DhhIfnA= MIME-Version: 1.0 Received: by 10.224.53.91 with SMTP id l27mr5464909qag.352.1275607480594; Thu, 03 Jun 2010 16:24:40 -0700 (PDT) Received: by 10.229.232.212 with HTTP; Thu, 3 Jun 2010 16:24:40 -0700 (PDT) Date: Thu, 3 Jun 2010 19:24:40 -0400 Message-ID: From: David Rhodus To: current@freebsd.org, stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: SUJ Patches for 8.X ??? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jun 2010 23:56:11 -0000 Anyone have a SUJ patch set for 8.x ? From owner-freebsd-stable@FreeBSD.ORG Fri Jun 4 00:35:28 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CCC8D1065672; Fri, 4 Jun 2010 00:35:28 +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 5667E8FC14; Fri, 4 Jun 2010 00:35:28 +0000 (UTC) Received: by pwj1 with SMTP id 1so455244pwj.13 for ; Thu, 03 Jun 2010 17:35:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=pAARgqQ4rGOhFyNP0sPwKVofENdOFrDSF6+2iE/5JeY=; b=siqczMbUZjL14xokmoP6EowKHDDckY9B3z0SNN5tZa+CL6E4R+fZmxP+8xkKVmoCU4 bIuU+AcfgNkyt7XNiyWv3CWjCWe5xCE64ex1MWWUoJ+qBFisS1FbK5QkH+cYQoxTe+hg cLT2lpKFuV1CHpID41sxrcwfCLXXRbsFLbqds= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=aUB4k/HKvCjrC3dHTsD4lv3KwKE7R3UhiUIbdU7id+qbp0cI3Fpmo8GjmqyoNIz/qr QDfyR9SgAzHI20a/TygWyNRiKLaZg/76IDUjr3pVaWOvplLgDp6xw4+mEYA22AUlZqlv MxAlhyMh3ZROSlhvCPSX7nmwbpxRI2A3Bu6NQ= Received: by 10.114.236.18 with SMTP id j18mr7915954wah.16.1275611727690; Thu, 03 Jun 2010 17:35:27 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id d20sm3576038waa.15.2010.06.03.17.35.25 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 03 Jun 2010 17:35:25 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Thu, 3 Jun 2010 17:35:02 -0700 From: Pyun YongHyeon Date: Thu, 3 Jun 2010 17:35:02 -0700 To: Nikolay Denev Message-ID: <20100604003502.GF13502@michelle.cdnetworks.com> References: <77DFF2E5-7A1E-4063-A852-2C7AD9BC3DD4@gmail.com> <201005240948.33555.jhb@freebsd.org> <20100524171210.GA1418@michelle.cdnetworks.com> <87BA8EDC-BE95-4C84-94CD-5CA12961708A@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87BA8EDC-BE95-4C84-94CD-5CA12961708A@gmail.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-stable@freebsd.org, John Baldwin Subject: Re: if_sge related panics 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, 04 Jun 2010 00:35:28 -0000 On Thu, Jun 03, 2010 at 09:29:20AM +0300, Nikolay Denev wrote: > On May 24, 2010, at 8:12 PM, Pyun YongHyeon wrote: > > > On Mon, May 24, 2010 at 09:48:33AM -0400, John Baldwin wrote: > >> On Monday 24 May 2010 6:35:01 am Nikolay Denev wrote: > >>> On May 24, 2010, at 8:57 AM, Nikolay Denev wrote: > >>> > >>>> Hi, > >>>> > >>>> Recently I started to experience a if_sge(4) related panic. > >>>> It happens almost every time I try to download a torrent file for example. > >>>> Copying of large files over NFS seem not to trigger it, but I haven't tested extensively. > >>>> > >>>> Here is the panic message : > >>>> > >>>> Fatal trap 12: page fault while in kernel mode > >>>> cpuid = 0; apic id = 00 > >>>> fault virtual address = 0x8 > >>>> fault code = supervisor write data, page not present > >>>> instruction pointer = 0x20:0xffffffff80230413 > >>>> stack pointer = 0x28:0xffffff80001e9280 > >>>> frame pointer = 0x28:0xffffff80001e9510 > >>>> 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 = 12 (irq19: sge0) > >>>> trap number = 12 > >>>> panic: page fault > >>>> cpuid = 0 > >>>> Uptime: 1d20h56m20s > >>>> Cannot dump. Device not defined or unavailable > >>>> Automatic reboot in 15 seconds - press a key on the console to abort > >>>> Sleeping thread (tid 100039, pid 12) owns a non-sleepable lock > >>>> > >>>> My swap is on a zvol, so I don't have dump. I'll try to attach a disk on the eSATA port and dump there if needed. > >>> > >>> Here is some info from the crashdump : > >>> > >>> (kgdb) #0 doadump () at pcpu.h:223 > >>> #1 0xffffffff802fb149 in boot (howto=260) > >>> at /usr/src/sys/kern/kern_shutdown.c:416 > >>> #2 0xffffffff802fb57c in panic (fmt=0xffffffff8055d564 "%s") > >>> at /usr/src/sys/kern/kern_shutdown.c:590 > >>> #3 0xffffffff805055b8 in trap_fatal (frame=0xffffff000288a3e0, eva=Variable "eva" is not available. > >>> ) > >>> at /usr/src/sys/amd64/amd64/trap.c:777 > >>> #4 0xffffffff805059dc in trap_pfault (frame=0xffffff80001e91d0, usermode=0) > >>> at /usr/src/sys/amd64/amd64/trap.c:693 > >>> #5 0xffffffff805061c5 in trap (frame=0xffffff80001e91d0) > >>> at /usr/src/sys/amd64/amd64/trap.c:451 > >>> #6 0xffffffff804eb977 in calltrap () > >>> at /usr/src/sys/amd64/amd64/exception.S:223 > >>> #7 0xffffffff80230413 in sge_start_locked (ifp=0xffffff000270d800) > >>> at /usr/src/sys/dev/sge/if_sge.c:1591 > >> > >> Try this. sge_encap() can sometimes return an error with m_head set to NULL: > >> > > > > Thanks John. Committed in r208512. > > > >> Index: if_sge.c > >> =================================================================== > >> --- if_sge.c (revision 208375) > >> +++ if_sge.c (working copy) > >> @@ -1588,7 +1588,8 @@ > >> if (m_head == NULL) > >> break; > >> if (sge_encap(sc, &m_head)) { > >> - IFQ_DRV_PREPEND(&ifp->if_snd, m_head); > >> + if (m_head != NULL) > >> + IFQ_DRV_PREPEND(&ifp->if_snd, m_head); > >> ifp->if_drv_flags |= IFF_DRV_OACTIVE; > >> break; > >> } > >> > >> -- > >> John Baldwin > > After the patch I experienced several network outages (ping reporting "no buffer space available") > that were resolved by ifconfig down/up of the sge(4) interface. > Because I don't have access to sge(4) controllers I never had chance to run it. Does ping(8) generates "no buffer space available" when the system is in idle state? Could you show me more information on how you checked network outages? > I can see that most of the other drivers that handle XXX_encap() returning m_head pointing NULL, break when this condition Yes, most drivers written/touched by me behaves like that. > is hit: i.e. : > > Index: if_sge.c > =================================================================== > --- if_sge.c (revision 208375) > +++ if_sge.c (working copy) > @@ -1588,7 +1588,8 @@ > if (m_head == NULL) > break; > if (sge_encap(sc, &m_head)) { > - IFQ_DRV_PREPEND(&ifp->if_snd, m_head); > + if (m_head == NULL) > + break; > IFQ_DRV_PREPEND(&ifp->if_snd, m_head); > ifp->if_drv_flags |= IFF_DRV_OACTIVE; > break; > } > > But here in sge(4) we always set IFF_DRV_OACTIVE. > Do you think this can be the source of the problem ? > More correct way to set IFF_DRV_OACTIVE would be check the number of queued frames or just exit the transmit loop. If there is no queued frames, IFF_DRV_OACTIVE would never be cleared which in turn cause ENOBUFS in ping(8). I think your change looks more reasonable to me. Do you still see the same issue with the change you suggested? From owner-freebsd-stable@FreeBSD.ORG Fri Jun 4 04:52:24 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6881E1065672 for ; Fri, 4 Jun 2010 04:52:24 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.154]) by mx1.freebsd.org (Postfix) with ESMTP id E53EF8FC18 for ; Fri, 4 Jun 2010 04:52:23 +0000 (UTC) Received: by fg-out-1718.google.com with SMTP id d23so444040fga.13 for ; Thu, 03 Jun 2010 21:52:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=Foa89T06TCxlBGcTvNnGYuLnqV2vB8wX5FLDt6LVAMY=; b=PZb3rG6PD1Nmo2fzlyuHfY/hM+6wJ5dwtPil2ZDqlI5XjIQFZUimxAo7/m8Pt6V4iM GwP+SORT62Tf5qs25s187d96e+Idt2C6QYKnUhUX4O0wLXOsOeIHzKFi28ldjqfah6JT kEFVEJlDtgH3bNUmVPzf8BDTSfqYfCdL+Az6Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=x9h7VXf6iTU3hkAjKukTMa1PmRqjiQM9iLCYR43JfZ4p3hfxH+aCN9U2xXJ4K1vc+I F7FR6clmhSiXstI6Y58Ib6W++IN0/ltxoouUXolVmjlnQyw9ebxL1XqsHh+SfeBCa6OT chz6TlfBeJipbov2YnHO136yJS/mF9mvJIQ7U= Received: by 10.87.66.14 with SMTP id t14mr16898497fgk.64.1275627142796; Thu, 03 Jun 2010 21:52:22 -0700 (PDT) Received: from ndenev.totalterror.net (93-152-151-19.ddns.onlinedirect.bg [93.152.151.19]) by mx.google.com with ESMTPS id d6sm3969240fga.23.2010.06.03.21.52.20 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 03 Jun 2010 21:52:21 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Nikolay Denev In-Reply-To: <20100604003502.GF13502@michelle.cdnetworks.com> Date: Fri, 4 Jun 2010 07:52:19 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <77DFF2E5-7A1E-4063-A852-2C7AD9BC3DD4@gmail.com> <201005240948.33555.jhb@freebsd.org> <20100524171210.GA1418@michelle.cdnetworks.com> <87BA8EDC-BE95-4C84-94CD-5CA12961708A@gmail.com> <20100604003502.GF13502@michelle.cdnetworks.com> To: pyunyh@gmail.com X-Mailer: Apple Mail (2.1078) Cc: freebsd-stable@freebsd.org Subject: Re: if_sge related panics X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 04 Jun 2010 04:52:24 -0000 On Jun 4, 2010, at 3:35 AM, Pyun YongHyeon wrote: > On Thu, Jun 03, 2010 at 09:29:20AM +0300, Nikolay Denev wrote: >> On May 24, 2010, at 8:12 PM, Pyun YongHyeon wrote: >>=20 >>> On Mon, May 24, 2010 at 09:48:33AM -0400, John Baldwin wrote: >>>> On Monday 24 May 2010 6:35:01 am Nikolay Denev wrote: >>>>> On May 24, 2010, at 8:57 AM, Nikolay Denev wrote: >>>>>=20 >>>>>> Hi, >>>>>>=20 >>>>>> Recently I started to experience a if_sge(4) related panic. >>>>>> It happens almost every time I try to download a torrent file for = example. >>>>>> Copying of large files over NFS seem not to trigger it, but I = haven't tested extensively. >>>>>>=20 >>>>>> Here is the panic message : >>>>>>=20 >>>>>> Fatal trap 12: page fault while in kernel mode >>>>>> cpuid =3D 0; apic id =3D 00 >>>>>> fault virtual address =3D 0x8 >>>>>> fault code =3D supervisor write = data, page not present >>>>>> instruction pointer =3D 0x20:0xffffffff80230413 >>>>>> stack pointer =3D = 0x28:0xffffff80001e9280 >>>>>> frame pointer =3D 0x28:0xffffff80001e9510 >>>>>> 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 12 (irq19: sge0) >>>>>> trap number =3D 12 >>>>>> panic: page fault >>>>>> cpuid =3D 0 >>>>>> Uptime: 1d20h56m20s >>>>>> Cannot dump. Device not defined or unavailable >>>>>> Automatic reboot in 15 seconds - press a key on the console to = abort >>>>>> Sleeping thread (tid 100039, pid 12) owns a non-sleepable lock >>>>>>=20 >>>>>> My swap is on a zvol, so I don't have dump. I'll try to attach a = disk on the eSATA port and dump there if needed. >>>>>=20 >>>>> Here is some info from the crashdump : >>>>>=20 >>>>> (kgdb) #0 doadump () at pcpu.h:223 >>>>> #1 0xffffffff802fb149 in boot (howto=3D260) >>>>> at /usr/src/sys/kern/kern_shutdown.c:416 >>>>> #2 0xffffffff802fb57c in panic (fmt=3D0xffffffff8055d564 "%s") >>>>> at /usr/src/sys/kern/kern_shutdown.c:590 >>>>> #3 0xffffffff805055b8 in trap_fatal (frame=3D0xffffff000288a3e0, = eva=3DVariable "eva" is not available. >>>>> ) >>>>> at /usr/src/sys/amd64/amd64/trap.c:777 >>>>> #4 0xffffffff805059dc in trap_pfault (frame=3D0xffffff80001e91d0, = usermode=3D0) >>>>> at /usr/src/sys/amd64/amd64/trap.c:693 >>>>> #5 0xffffffff805061c5 in trap (frame=3D0xffffff80001e91d0) >>>>> at /usr/src/sys/amd64/amd64/trap.c:451 >>>>> #6 0xffffffff804eb977 in calltrap () >>>>> at /usr/src/sys/amd64/amd64/exception.S:223 >>>>> #7 0xffffffff80230413 in sge_start_locked = (ifp=3D0xffffff000270d800) >>>>> at /usr/src/sys/dev/sge/if_sge.c:1591 >>>>=20 >>>> Try this. sge_encap() can sometimes return an error with m_head = set to NULL: >>>>=20 >>>=20 >>> Thanks John. Committed in r208512. >>>=20 >>>> Index: if_sge.c >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>> --- if_sge.c (revision 208375) >>>> +++ if_sge.c (working copy) >>>> @@ -1588,7 +1588,8 @@ >>>> if (m_head =3D=3D NULL) >>>> break; >>>> if (sge_encap(sc, &m_head)) { >>>> - IFQ_DRV_PREPEND(&ifp->if_snd, m_head); >>>> + if (m_head !=3D NULL) >>>> + IFQ_DRV_PREPEND(&ifp->if_snd, m_head); >>>> ifp->if_drv_flags |=3D IFF_DRV_OACTIVE; >>>> break; >>>> } >>>>=20 >>>> --=20 >>>> John Baldwin >>=20 >> After the patch I experienced several network outages (ping reporting = "no buffer space available") >> that were resolved by ifconfig down/up of the sge(4) interface. >>=20 >=20 > Because I don't have access to sge(4) controllers I never had chance > to run it. Does ping(8) generates "no buffer space available" when > the system is in idle state? Could you show me more information on > how you checked network outages? >=20 It happened 4-5 times recently. I didn't do extensive investigation, but = yes, ping returned "no buffer space avail" when I tried pinging from the machine = itself. It was unreachable from other hosts on the network. I'm not sure what you bean by idle state but there was a torrent client = running on the machine, which printed errors about inability to reach peers. >> I can see that most of the other drivers that handle XXX_encap() = returning m_head pointing NULL, break when this condition >=20 > Yes, most drivers written/touched by me behaves like that. >=20 >> is hit: i.e. : >>=20 >> Index: if_sge.c >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> --- if_sge.c (revision 208375) >> +++ if_sge.c (working copy) >> @@ -1588,7 +1588,8 @@ >> if (m_head =3D=3D NULL) >> break; >> if (sge_encap(sc, &m_head)) { >> - IFQ_DRV_PREPEND(&ifp->if_snd, m_head); >> + if (m_head =3D=3D NULL) >> + break; >> IFQ_DRV_PREPEND(&ifp->if_snd, m_head); >> ifp->if_drv_flags |=3D IFF_DRV_OACTIVE; >> break; >> } >>=20 >> But here in sge(4) we always set IFF_DRV_OACTIVE. >> Do you think this can be the source of the problem ? >>=20 >=20 > More correct way to set IFF_DRV_OACTIVE would be check the number > of queued frames or just exit the transmit loop. If there is no > queued frames, IFF_DRV_OACTIVE would never be cleared which in turn > cause ENOBUFS in ping(8). I think your change looks more reasonable > to me. Do you still see the same issue with the change you suggested? I'm runing with this change for a day or something now without any = issues. Thanks, Niki= From owner-freebsd-stable@FreeBSD.ORG Fri Jun 4 08:09:50 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F3CD110656C1 for ; Fri, 4 Jun 2010 08:09:49 +0000 (UTC) (envelope-from Krzysztof.Dajka@agora.pl) Received: from mail.agora.pl (mail.agora.pl [193.42.230.53]) by mx1.freebsd.org (Postfix) with ESMTP id 74FB98FC24 for ; Fri, 4 Jun 2010 08:09:48 +0000 (UTC) Received: from agstamp1.agora.pl (agstamp1.agora.pl [10.205.39.114]) by mail.agora.pl (8.13.8/8.11.1) with ESMTP id o5489lar006488; Fri, 4 Jun 2010 10:09:47 +0200 Received: from agora.pl (agstamp1.agora.pl [10.205.39.114]) by agstamp1.agora.pl (Postfix) with SMTP id BB02D244C7; Fri, 4 Jun 2010 10:09:47 +0200 (CEST) Received: from zcs01.agora.pl (vzcs03.agora.pl [10.205.98.92]) by agstamp1.agora.pl (Postfix) with ESMTP id B8A3D244B4; Fri, 4 Jun 2010 10:09:47 +0200 (CEST) Received: from localhost (localhost.localdomain [127.0.0.1]) by zcs01.agora.pl (Postfix) with ESMTP id B590F21C97; Fri, 4 Jun 2010 10:09:47 +0200 (CEST) X-Virus-Scanned: amavisd-new at zcs01.agora.pl Received: from zcs01.agora.pl ([127.0.0.1]) by localhost (zcs01.agora.pl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CKGd8WOJMi2H; Fri, 4 Jun 2010 10:09:47 +0200 (CEST) Received: from t42.localnet (unknown [10.201.55.171]) by zcs01.agora.pl (Postfix) with ESMTPSA id 95BCA21AFB; Fri, 4 Jun 2010 10:09:47 +0200 (CEST) From: Krzysztof Dajka Organization: Agora To: Dan Naumov Date: Fri, 4 Jun 2010 10:09:46 +0200 User-Agent: KMail/1.13.3 (Linux/2.6.30-1-686; KDE/4.4.3; i686; ; ) References: <684e57ec1003221341s241c6d4fl9f2afa411c55d697@mail.gmail.com> In-Reply-To: <684e57ec1003221341s241c6d4fl9f2afa411c55d697@mail.gmail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201006041009.47004.kdajka@new.agora.pl> Cc: FreeBSD-STABLE Mailing List Subject: Booting after make installworld takes ages [Was Re: Can't boot after make installworld] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 04 Jun 2010 08:09:50 -0000 On Sunday, 21 of March 2010 20:15:29 Krzysztof Dajka wrote: > Hi, I'm having problem with upgrading my FreeBSD to RELENG_8. Building > world and kernel went smoothly I can boot with new kernel, but after 'make > installworld' I could boot my system. My system prints only: > BTX loader 1.00 BTX version is 1.01 > Console: internal video/keyboard > BIOS drive C: is disk0 > BIOS drive D: is disk1 > BIOS drive E: is disk2 > BIOS drive F: is disk3 > | > And freezes... > I had a problem in march with booting after 'makeinstall' as stated above. It seems that I was impatient prejudged facts. For few months I was running newer kernel than world. After all I decided to upgrade whole system yesterday. After 'make installkernel', booting to new kernel went as usual. After 'make installworld' and rebooting it hangs at: > BIOS drive C: is disk0 > BIOS drive D: is disk1 > BIOS drive E: is disk2 > BIOS drive F: is disk3 > | After waiting 50 seconds it started booting. During this time my usb flash drive, which contains only bootcode blinked as crazy. I remembered that Dan Naumov told me > The ZFS bootloader has been changed in 8-STABLE compared to > 8.0-RELEASE. Reinstall your boot blocks. So this time I did: gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 da0 But this didn't help, booting is still painfully slow. -- Niniejsza wiadomość pochodzi z domeny @agora.pl, należącej do Grupy KapitaÅ‚owej Agory. Główne spółki wchodzÄ…ce w skÅ‚ad Grupy KapitaÅ‚owej Agory to: Agora SA, ul. Czerska 8/10, 00-732 Warszawa; Numer identyfikacji podatkowej: PL 526-030-56-44; Miejsce zarejestrowania: SÄ…d Rejonowy dla m. st. Warszawy: Numer rejestru KRS: 59944; KapitaÅ‚ zakÅ‚adowy: 50.937.386 zÅ‚, wpÅ‚acony w caÅ‚oÅ›ci. Agora - Poligrafia Sp. z o.o., ul. Towarowa 4, 43-110 Tychy; Numer identyfikacji podatkowej: PL 646-20-72-095; Miejsce zarejestrowania: SÄ…d Rejonowy w Katowicach Numer rejestru KRS: 72481; KapitaÅ‚ zakÅ‚adowy: 1.000.000,00 zÅ‚. Grupa Radiowa Agory Sp. z o.o., ul. Czerska 8/10, 00-732 Warszawa; Numer identyfikacji podatkowej: PL 521-289-70-03; Miejsce zarejestrowania: SÄ…d Rejonowy dla m. st. Warszawy Numer rejestru KRS: 126767; KapitaÅ‚ zakÅ‚adowy: 25.019.500,00 zÅ‚. WiÄ™cej informacji o spółkach na stronie: www.agora.pl Wiadomość jest przeznaczona wyÅ‚Ä…cznie dla zamierzonego adresata i może zawierać informacje o charakterze poufnym. W razie stwierdzenia, że odbiorcÄ… miaÅ‚a być inna osoba prosimy poinformować nadawcÄ™ oraz niezwÅ‚ocznie usunąć wiadomość. Wiadomość może nie stanowić oficjalnego stanowiska spółki Agora SA i nie być zwiÄ…zana z jej dziaÅ‚alnoÅ›ciÄ…. ------------ This message was sent from domain @agora.pl belonging to Agora Group. Principal companies in the Agora Group structure are: Agora SA, ul. Czerska 8/10, 00-732 Warszawa; Polish VAT and tax ID no.: PL 526-030-56-44; Place of registration: Regional Court for the Capital City of Warsaw; Registration no.: 59944; Share capital: PLN 50.937.386, fully paid-up. Agora - Poligrafia Sp. z o.o., ul. Towarowa 4, 43-110 Tychy; Polish VAT and tax ID no.: PL 646-20-72-095; Place of registration: Regional Court in Katowice; Registration no.: 72481; Share capital: PLN 1.000.000,00. Grupa Radiowa Agory Sp. z o.o., ul. Czerska 8/10, 00-732 Warszawa; Polish VAT and tax ID no.: PL 521-289-70-03; Place of registration: Regional Court for the Capital City of Warsaw; Registration no.: 126767; Share capital: PLN 25.019.500,00. For more information about our companies see site: www.agora.pl This message is for the intended recipient only and it may contain confidential information. If you receive this message in error, please immediately delete it and notify the sender. This message may not represent the official views of Agora SA and may not be related to its business. From owner-freebsd-stable@FreeBSD.ORG Fri Jun 4 09:37:15 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 37D211065674; Fri, 4 Jun 2010 09:37:15 +0000 (UTC) (envelope-from dave@jetcafe.org) Received: from hugeraid.jetcafe.org (hugeraid.jetcafe.org [205.147.26.109]) by mx1.freebsd.org (Postfix) with ESMTP id 1528B8FC08; Fri, 4 Jun 2010 09:37:14 +0000 (UTC) Received: from hugeraid.jetcafe.org (localhost [127.0.0.1]) by hugeraid.jetcafe.org (8.13.8/8.13.8) with ESMTP id o549bEFt054288; Fri, 4 Jun 2010 02:37:14 -0700 (PDT) Message-Id: <201006040937.o549bEFt054288@hugeraid.jetcafe.org> X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.0.4 To: John Baldwin In-reply-to: <201006031029.00588.jhb@freebsd.org> References: <201005272348.o4RNmgWh014243@hugeraid.jetcafe.org> <201006011020.01318.jhb@freebsd.org> <201006022237.o52MbxZM066281@hugeraid.jetcafe.org> <201006031029.00588.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 04 Jun 2010 02:37:14 -0700 From: Dave Hayes Cc: Garrett Cooper , freebsd-stable@freebsd.org, Clifton Royston , Jeremy Chadwick Subject: Re: Locking a file backed mdconfig into memory X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 04 Jun 2010 09:37:15 -0000 John Baldwin writes: > On Wednesday 02 June 2010 6:37:59 pm Dave Hayes wrote: >> John Baldwin writes: >> > Ok, if you are using a stock mfsroot from a release build, that should >> > work fine. If you have built a custom mfsroot that is larger, then >> > you may need to increase NKPT on i386. In very recent 7 and later you >> > can do this by setting it to a new value in your kernel config. In >> > older versions you can do this by manually adding a #define to set a >> > new value of NKPT in opt_global.h or hacking on the source directly. >> >> Is this also true for amd64 (which is my particular target)? > > It might be. What is the panic you are seeing? I can't see the panic as it repeatedly scrolls across the console screen faster than I can read it. In this case the mfsroot is around 275MB. I have noticed that sometimes I can build an mfsroot that does not crash of this size. -- Dave Hayes - Consultant - Altadena CA, USA - dave@jetcafe.org >>> The opinions expressed above are entirely my own <<< People usually oppose things because they are ignorant of them. From owner-freebsd-stable@FreeBSD.ORG Fri Jun 4 10:26:53 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5332B1065676 for ; Fri, 4 Jun 2010 10:26:53 +0000 (UTC) (envelope-from hans.dampf@eml.cc) Received: from out5.smtp.messagingengine.com (out5.smtp.messagingengine.com [66.111.4.29]) by mx1.freebsd.org (Postfix) with ESMTP id 25C108FC17 for ; Fri, 4 Jun 2010 10:26:52 +0000 (UTC) Received: from compute1.internal (compute1.internal [10.202.2.41]) by gateway1.messagingengine.com (Postfix) with ESMTP id 67237F7B3C for ; Fri, 4 Jun 2010 06:07:10 -0400 (EDT) Received: from vweb8.messagingengine.com ([10.202.2.38]) by compute1.internal (MEProxy); Fri, 04 Jun 2010 06:07:10 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=message-id:from:to:content-transfer-encoding:content-type:mime-version:subject:date; s=smtpout; bh=dqPHPMQXYT3VwFNh2w0los+BzEI=; b=NJ3aEH/4iES2OfMUDo/5Z0nefTcqHriiUDD+p4I4cop1EajlE6r1vcBp2+eMr8/SEZfJnnxK4TwVtMNPOms3Ypg1ZWZBX7I2+II6SnNH5zWiCodycjVvzbI2n+veJqSYVin2VjvA2geR5ivepcHXz8OftcZcLJxmp9H6GjgVTsI= Received: by vweb8.messagingengine.com (Postfix, from userid 99) id 43BBA1B6D; Fri, 4 Jun 2010 06:07:10 -0400 (EDT) Message-Id: <1275646030.1428.1378445975@webmail.messagingengine.com> X-Sasl-Enc: QaRIlE5QIazwIagv1tr+0gMhuVBNyeSGDgVSdQ5C8Svz 1275646030 From: hans.dampf@eml.cc To: freebsd-stable@freebsd.org Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 X-Mailer: MessagingEngine.com Webmail Interface Date: Fri, 04 Jun 2010 12:07:10 +0200 Subject: atapicam issue X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 04 Jun 2010 10:26:53 -0000 Hi, FreeBSD-stable clandestinely dropped support for my p-ata DVD drive some two or three weeks ago. The relevant "devcontrol list"-entry is still in its place, yet atapicam fails to create "/dev/cd0". # camcontrol devlist at scbus0 target 0 lun 0 (pass0) dmesg reports: ------------------------ (probe0:ata0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (probe0:ata0:0:0:0): CAM status: SCSI Status Error (probe0:ata0:0:0:0): SCSI status: Check Condition (probe0:ata0:0:0:0): SCSI sense: UNIT ATTENTION asc:29,0 (Power on, reset, or bus device reset occurred) (probe0:ata0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (probe0:ata0:0:0:0): CAM status: SCSI Status Error (probe0:ata0:0:0:0): SCSI status: Check Condition (probe0:ata0:0:0:0): SCSI sense: NOT READY asc:3a,1 (Medium not present - tray closed) --------------------------- Thanks in advance for your help! Hans From owner-freebsd-stable@FreeBSD.ORG Fri Jun 4 12:26:43 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6B6C9106564A for ; Fri, 4 Jun 2010 12:26:43 +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 3A2418FC16 for ; Fri, 4 Jun 2010 12:26:43 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id DEE8E46B51; Fri, 4 Jun 2010 08:26:42 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id F0C768A01F; Fri, 4 Jun 2010 08:26:41 -0400 (EDT) From: John Baldwin To: Dave Hayes Date: Fri, 4 Jun 2010 08:20:49 -0400 User-Agent: KMail/1.12.1 (FreeBSD/7.3-CBSD-20100217; KDE/4.3.1; amd64; ; ) References: <201005272348.o4RNmgWh014243@hugeraid.jetcafe.org> <201006031029.00588.jhb@freebsd.org> <201006040937.o549bEFt054288@hugeraid.jetcafe.org> In-Reply-To: <201006040937.o549bEFt054288@hugeraid.jetcafe.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201006040820.49741.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Fri, 04 Jun 2010 08:26:42 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Garrett Cooper , freebsd-stable@freebsd.org, Clifton Royston , Jeremy Chadwick Subject: Re: Locking a file backed mdconfig into memory X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 04 Jun 2010 12:26:43 -0000 On Friday 04 June 2010 5:37:14 am Dave Hayes wrote: > John Baldwin writes: > > On Wednesday 02 June 2010 6:37:59 pm Dave Hayes wrote: > >> John Baldwin writes: > >> > Ok, if you are using a stock mfsroot from a release build, that should > >> > work fine. If you have built a custom mfsroot that is larger, then > >> > you may need to increase NKPT on i386. In very recent 7 and later you > >> > can do this by setting it to a new value in your kernel config. In > >> > older versions you can do this by manually adding a #define to set a > >> > new value of NKPT in opt_global.h or hacking on the source directly. > >> > >> Is this also true for amd64 (which is my particular target)? > > > > It might be. What is the panic you are seeing? > > I can't see the panic as it repeatedly scrolls across the console screen > faster than I can read it. In this case the mfsroot is around 275MB. > > I have noticed that sometimes I can build an mfsroot that does not crash > of this size. Hmmm, I would just try increasing NKPT then. You might have to poke around in sys/amd64 to see what the default size is and how to tune it. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Fri Jun 4 15:00:24 2010 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 257CF106566B; Fri, 4 Jun 2010 15:00:24 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id DEA558FC14; Fri, 4 Jun 2010 15:00:23 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:814:2dff:a4e6:c897] (unknown [IPv6:2001:7b8:3a7:0:814:2dff:a4e6:c897]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 024A95C59; Fri, 4 Jun 2010 17:00:21 +0200 (CEST) Message-ID: <4C091509.2070607@andric.com> Date: Fri, 04 Jun 2010 17:00:25 +0200 From: Dimitry Andric User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.2.4) Gecko/20100531 Lanikai/3.1.1pre MIME-Version: 1.0 To: David Rhodus References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org, current@freebsd.org Subject: Re: SUJ Patches for 8.X ??? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jun 2010 15:00:24 -0000 On 2010-06-04 01:24, David Rhodus wrote: > Anyone have a SUJ patch set for 8.x ? http://www.andric.com/freebsd/suj/suj-stable8-r208287-1.diff.bz2 This backports SUJ from head to stable/8 (at r208799), by cherry-picking the following revisions: r207141 | jeff | 2010-04-24 09:05:35 +0200 (Sat, 24 Apr 2010) | 7 lines r207142 | pjd | 2010-04-24 09:36:33 +0200 (Sat, 24 Apr 2010) | 2 lines r207143 | pjd | 2010-04-24 09:54:49 +0200 (Sat, 24 Apr 2010) | 2 lines r207144 | pjd | 2010-04-24 09:58:59 +0200 (Sat, 24 Apr 2010) | 3 lines r207145 | jeff | 2010-04-24 09:59:45 +0200 (Sat, 24 Apr 2010) | 4 lines r207309 | jeff | 2010-04-28 09:26:41 +0200 (Wed, 28 Apr 2010) | 2 lines r207310 | jeff | 2010-04-28 09:57:37 +0200 (Wed, 28 Apr 2010) | 5 lines r207421 | jeff | 2010-04-30 06:21:22 +0200 (Fri, 30 Apr 2010) | 7 lines r207462 | edwin | 2010-05-01 11:05:06 +0200 (Sat, 01 May 2010) | 7 lines r207476 | emaste | 2010-05-01 20:56:45 +0200 (Sat, 01 May 2010) | 4 lines r207741 | jeff | 2010-05-07 10:20:56 +0200 (Fri, 07 May 2010) | 8 lines r207742 | jeff | 2010-05-07 10:45:21 +0200 (Fri, 07 May 2010) | 7 lines r208241 | jeff | 2010-05-18 03:45:28 +0200 (Tue, 18 May 2010) | 11 lines r208287 | jeff | 2010-05-19 08:18:01 +0200 (Wed, 19 May 2010) | 11 lines I have tested: - Applying this diff to stable/8 at r208799 (any other rev is NOT guaranteed to work, but there is a good chance, if not too far off) - Doing a full buildworld, buildkernel, installkernel, reboot, installworld and mergemaster. - Enabling SUJ on a big filesystem with "tunefs -j enable". - Randomly resetting the box during a large copy operation on that filesystem, seeing the journal is replayed at boot time, and the filesystem recovered. That said, there is NO WARRANTY that this patch works properly. It could hose all your filesystems, and/or cause irreversible damage to your system. Most likely, even. You have been warned. :) Also, please do NOT bother Jeff Roberson about this, as he is probably busy enough supporting SUJ in head. :) Instead, direct any problem reports to me first, or to the freebsd-stable mailing list, if you prefer. From owner-freebsd-stable@FreeBSD.ORG Fri Jun 4 16:04:49 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 171BA1065670; Fri, 4 Jun 2010 16:04:49 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id D21C78FC1A; Fri, 4 Jun 2010 16:04:48 +0000 (UTC) Received: by pvh11 with SMTP id 11so815668pvh.13 for ; Fri, 04 Jun 2010 09:04:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=d2BC1UgELiqWnnQRrf3g3m3+JoXmyevgG/DI7c/prOg=; b=DdSLWbDmzX/+Dd1a9dcnHV3zJW6Aq09IGuhe9LSVEJTDELWybgaJVg2KmyNDYH04Cc IhFgYlWHvr/fePQ3DUHwQMT47hLqlvLbxUw7aZIUXNEMAOQFv/GLQx7qMwdflN8mjIaN 3IU0Mrj7Oo34GPhP0ScSuuJ0g9PTWrvZJyPcM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=V7m9pzVGvqtVhkCco9rqWUP21zfYO8vqc4PgQjhxFlo3+td8whjRBwEyNtkitpoQ1B +E3hho68wTXD+gQCsKZjoGr+bppJqn2xiT3h3F9NdygO1Xd5+AyuMw2XldLQG7v1+FhD Th27iwzCNDOn1MWSSBMrh9n4arb8ncLaBaa84= Received: by 10.140.255.17 with SMTP id c17mr9059674rvi.179.1275665628910; Fri, 04 Jun 2010 08:33:48 -0700 (PDT) Received: from amaretto (gw-105.extranet.sea01.isilon.com [74.85.160.105]) by mx.google.com with ESMTPS id d14sm2455594rva.18.2010.06.04.08.33.46 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 04 Jun 2010 08:33:47 -0700 (PDT) Date: Fri, 4 Jun 2010 08:32:10 -0700 From: Matthew D Fleming To: John Baldwin Message-ID: <20100604153210.GA8522@amaretto> References: <201005272348.o4RNmgWh014243@hugeraid.jetcafe.org> <201006031029.00588.jhb@freebsd.org> <201006040937.o549bEFt054288@hugeraid.jetcafe.org> <201006040820.49741.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201006040820.49741.jhb@freebsd.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org, Clifton Royston , alc@freebsd.org, Garrett Cooper , Jeremy Chadwick Subject: Re: Locking a file backed mdconfig into memory X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 04 Jun 2010 16:04:49 -0000 On Fri, Jun 04, 2010 at 08:20:49AM -0400, John Baldwin wrote: > Hmmm, I would just try increasing NKPT then. You might have to poke > around in sys/amd64 to see what the default size is and how to tune > it. When Isilon did the stable/7 merge and amd64 default NKPT changed from 240 to 32 amd64 started having weird pmap issues during boot. At panic time the stack wasn't very useful, and I didn't finish debugging the issue since eventually I just had to get something working. We just reverted NKPT to 240 and it worked for us. I didn't see an anything in optsions.amd64 so I hard-coded it in amd64/include/pmap.h. Supposedly amd64 can deal with a small NKPT and grow dynamically, but it didn't seem to work for us. :-( Perhaps when we do the next merge project I'll have a few days to devote to debugging the root cause. Thanks, matthew From owner-freebsd-stable@FreeBSD.ORG Fri Jun 4 16:28:33 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AF1B1106564A for ; Fri, 4 Jun 2010 16:28:33 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 3B8B88FC1D for ; Fri, 4 Jun 2010 16:28:32 +0000 (UTC) Received: by fxm20 with SMTP id 20so836940fxm.13 for ; Fri, 04 Jun 2010 09:28:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=eU0i1rvZ/ilJQ+PQEu05EHNn6L02b+FJHR9mR8h9WL4=; b=wM0/9wN152opF4PVoG2YfWfSOGOUP+fwukN0T3HKqSRQoD5HqGoXYrh+RaHL3fV7ws SZQV8xDPC5PGtQJu4kRCRQBRK7sbNtT3hgZ+9/Sf/0tnwTnKnJxnTreH25m35/ERi4RZ y4k+e6ldhzq8frILAryapt70dFENQv6V+mLtk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=FXYkq8SocKeceJMlyc2sQzDXN7vPApCPsmDphY61HFA7TUnGcSTEoVz+qQ6jGA3cIn AzrdqaWffRSluU0huOP9XeGdRpc9FEtrJmDq/iVlTPoR99kasOPlbtWJ8mvZhw5Kogyn EeHKjFOApzZtwOmGJ1DthtimokpImsgxRAkik= Received: by 10.223.92.152 with SMTP id r24mr12052950fam.74.1275668912138; Fri, 04 Jun 2010 09:28:32 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id 2sm5950871faf.3.2010.06.04.09.28.30 (version=SSLv3 cipher=RC4-MD5); Fri, 04 Jun 2010 09:28:31 -0700 (PDT) Sender: Alexander Motin Message-ID: <4C09299A.1000406@FreeBSD.org> Date: Fri, 04 Jun 2010 19:28:10 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.24 (X11/20100402) MIME-Version: 1.0 To: hans.dampf@eml.cc, FreeBSD Stable References: In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Subject: Re: atapicam issue X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 04 Jun 2010 16:28:33 -0000 hans.dampf@eml.cc wrote: > FreeBSD-stable clandestinely dropped support for my p-ata DVD drive some > two or three weeks ago. The relevant "devcontrol list"-entry is still in > its place, yet atapicam fails to create "/dev/cd0". > > # camcontrol devlist > at scbus0 target 0 lun 0 (pass0) > > dmesg reports: > ------------------------ > (probe0:ata0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 > (probe0:ata0:0:0:0): CAM status: SCSI Status Error > (probe0:ata0:0:0:0): SCSI status: Check Condition > (probe0:ata0:0:0:0): SCSI sense: UNIT ATTENTION asc:29,0 (Power on, > reset, or bus device reset occurred) > (probe0:ata0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 > (probe0:ata0:0:0:0): CAM status: SCSI Status Error > (probe0:ata0:0:0:0): SCSI status: Check Condition > (probe0:ata0:0:0:0): SCSI sense: NOT READY asc:3a,1 (Medium not present > - tray closed) > --------------------------- This is not fatal errors. It is normal. Could you boot with verbose messages and show full log? -- Alexander Motin From owner-freebsd-stable@FreeBSD.ORG Fri Jun 4 16:53:38 2010 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 CA7081065680; Fri, 4 Jun 2010 16:53:38 +0000 (UTC) (envelope-from jhelfman@e-e.com) Received: from mail.experts-exchange.com (mail.experts-exchange.com [64.156.132.251]) by mx1.freebsd.org (Postfix) with ESMTP id AD88C8FC16; Fri, 4 Jun 2010 16:53:38 +0000 (UTC) Received: from eggman.experts-exchange.com (unknown [72.29.180.81]) by mail.experts-exchange.com (Postfix) with ESMTP id EAD874A2E6CD; Fri, 4 Jun 2010 09:01:21 -0700 (PDT) Received: by eggman.experts-exchange.com (sSMTP sendmail emulation); Fri, 04 Jun 2010 09:07:57 -0700 Date: Fri, 4 Jun 2010 09:07:57 -0700 From: Jason To: Dimitry Andric Message-ID: <20100604160755.GB43193@eggman.experts-exchange.com> References: <4C091509.2070607@andric.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <4C091509.2070607@andric.com> X-Operating-System: FreeBSD 7.2-RELEASE-p7 X-Living-The-Dream: I love the SLO Life! User-Agent: Mutt/1.5.20 (2009-06-14) Cc: stable@freebsd.org, David Rhodus , current@freebsd.org Subject: Re: SUJ Patches for 8.X ??? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jun 2010 16:53:38 -0000 On Fri, Jun 04, 2010 at 05:00:25PM +0200, Dimitry Andric thus spake: >On 2010-06-04 01:24, David Rhodus wrote: >> Anyone have a SUJ patch set for 8.x ? > >http://www.andric.com/freebsd/suj/suj-stable8-r208287-1.diff.bz2 > >This backports SUJ from head to stable/8 (at r208799), by cherry-picking >the following revisions: > > r207141 | jeff | 2010-04-24 09:05:35 +0200 (Sat, 24 Apr 2010) | 7 lines > r207142 | pjd | 2010-04-24 09:36:33 +0200 (Sat, 24 Apr 2010) | 2 lines > r207143 | pjd | 2010-04-24 09:54:49 +0200 (Sat, 24 Apr 2010) | 2 lines > r207144 | pjd | 2010-04-24 09:58:59 +0200 (Sat, 24 Apr 2010) | 3 lines > r207145 | jeff | 2010-04-24 09:59:45 +0200 (Sat, 24 Apr 2010) | 4 lines > r207309 | jeff | 2010-04-28 09:26:41 +0200 (Wed, 28 Apr 2010) | 2 lines > r207310 | jeff | 2010-04-28 09:57:37 +0200 (Wed, 28 Apr 2010) | 5 lines > r207421 | jeff | 2010-04-30 06:21:22 +0200 (Fri, 30 Apr 2010) | 7 lines > r207462 | edwin | 2010-05-01 11:05:06 +0200 (Sat, 01 May 2010) | 7 lines > r207476 | emaste | 2010-05-01 20:56:45 +0200 (Sat, 01 May 2010) | 4 lines > r207741 | jeff | 2010-05-07 10:20:56 +0200 (Fri, 07 May 2010) | 8 lines > r207742 | jeff | 2010-05-07 10:45:21 +0200 (Fri, 07 May 2010) | 7 lines > r208241 | jeff | 2010-05-18 03:45:28 +0200 (Tue, 18 May 2010) | 11 lines > r208287 | jeff | 2010-05-19 08:18:01 +0200 (Wed, 19 May 2010) | 11 lines > >I have tested: >- Applying this diff to stable/8 at r208799 (any other rev is NOT > guaranteed to work, but there is a good chance, if not too far off) >- Doing a full buildworld, buildkernel, installkernel, reboot, > installworld and mergemaster. >- Enabling SUJ on a big filesystem with "tunefs -j enable". >- Randomly resetting the box during a large copy operation on that > filesystem, seeing the journal is replayed at boot time, and the > filesystem recovered. > >That said, there is NO WARRANTY that this patch works properly. It >could hose all your filesystems, and/or cause irreversible damage to >your system. Most likely, even. You have been warned. :) > >Also, please do NOT bother Jeff Roberson about this, as he is probably >busy enough supporting SUJ in head. :) Instead, direct any problem >reports to me first, or to the freebsd-stable mailing list, if you >prefer. >_______________________________________________ >freebsd-stable@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-stable >To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > I wasn't sure what SUJ was, so I looked it up and it sounds like a great feature to come to FreeBSD. I also found this email from Jeff that may be a good resource as well. http://lists.freebsd.org/pipermail/freebsd-current/2010-January/014811.html -j From owner-freebsd-stable@FreeBSD.ORG Fri Jun 4 17:15:09 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E56E11065673 for ; Fri, 4 Jun 2010 17:15: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 AE92B8FC1A for ; Fri, 4 Jun 2010 17:15:08 +0000 (UTC) Received: by pwj1 with SMTP id 1so877649pwj.13 for ; Fri, 04 Jun 2010 10:15:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=fByUcvmNyoGq0+dEWvukiRVjNySjjA2Y1lVNna4zQlQ=; b=eQ1zjBbUN+7pEUGV6lWqYgAdbrppKEQ09kM3uqoOsIZXN2XKlIlZails4WvIUD/NAI YbDyf4/aQVts9B6aazG4rwC3lVPltrq/ElQdSY4dJz/fimXCDMqgCGXpoLuuMjSzCHDb 9TRnqjiBp6y4ZwODyhDzHO/N75tpPsOBNQB7o= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=DaAFZkkjJEvCtBelaBIeYlxbZ24DCU/IUWscqUya6T+iXCCG1fvmfxEQ5ap5oevYfm Qp8WafsDaWAJnL0ffJGr9PXRM07SC8xD+oXpfLh3BkAEOhBMpJuPQ+xWFNf4WpT4NAil d23bLAC8uiHbHHRvbIcFftbajAEVkYofWNFSU= Received: by 10.115.39.21 with SMTP id r21mr8792766waj.155.1275671708046; Fri, 04 Jun 2010 10:15:08 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id f11sm10307158wai.11.2010.06.04.10.15.06 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 04 Jun 2010 10:15:06 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Fri, 4 Jun 2010 10:14:44 -0700 From: Pyun YongHyeon Date: Fri, 4 Jun 2010 10:14:44 -0700 To: Nikolay Denev Message-ID: <20100604171444.GA17648@michelle.cdnetworks.com> References: <77DFF2E5-7A1E-4063-A852-2C7AD9BC3DD4@gmail.com> <201005240948.33555.jhb@freebsd.org> <20100524171210.GA1418@michelle.cdnetworks.com> <87BA8EDC-BE95-4C84-94CD-5CA12961708A@gmail.com> <20100604003502.GF13502@michelle.cdnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-stable@freebsd.org Subject: Re: if_sge related panics 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, 04 Jun 2010 17:15:09 -0000 On Fri, Jun 04, 2010 at 07:52:19AM +0300, Nikolay Denev wrote: > > On Jun 4, 2010, at 3:35 AM, Pyun YongHyeon wrote: > > > On Thu, Jun 03, 2010 at 09:29:20AM +0300, Nikolay Denev wrote: > >> On May 24, 2010, at 8:12 PM, Pyun YongHyeon wrote: > >> > >>> On Mon, May 24, 2010 at 09:48:33AM -0400, John Baldwin wrote: > >>>> On Monday 24 May 2010 6:35:01 am Nikolay Denev wrote: > >>>>> On May 24, 2010, at 8:57 AM, Nikolay Denev wrote: > >>>>> > >>>>>> Hi, > >>>>>> > >>>>>> Recently I started to experience a if_sge(4) related panic. > >>>>>> It happens almost every time I try to download a torrent file for example. > >>>>>> Copying of large files over NFS seem not to trigger it, but I haven't tested extensively. > >>>>>> > >>>>>> Here is the panic message : > >>>>>> > >>>>>> Fatal trap 12: page fault while in kernel mode > >>>>>> cpuid = 0; apic id = 00 > >>>>>> fault virtual address = 0x8 > >>>>>> fault code = supervisor write data, page not present > >>>>>> instruction pointer = 0x20:0xffffffff80230413 > >>>>>> stack pointer = 0x28:0xffffff80001e9280 > >>>>>> frame pointer = 0x28:0xffffff80001e9510 > >>>>>> 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 = 12 (irq19: sge0) > >>>>>> trap number = 12 > >>>>>> panic: page fault > >>>>>> cpuid = 0 > >>>>>> Uptime: 1d20h56m20s > >>>>>> Cannot dump. Device not defined or unavailable > >>>>>> Automatic reboot in 15 seconds - press a key on the console to abort > >>>>>> Sleeping thread (tid 100039, pid 12) owns a non-sleepable lock > >>>>>> > >>>>>> My swap is on a zvol, so I don't have dump. I'll try to attach a disk on the eSATA port and dump there if needed. > >>>>> > >>>>> Here is some info from the crashdump : > >>>>> > >>>>> (kgdb) #0 doadump () at pcpu.h:223 > >>>>> #1 0xffffffff802fb149 in boot (howto=260) > >>>>> at /usr/src/sys/kern/kern_shutdown.c:416 > >>>>> #2 0xffffffff802fb57c in panic (fmt=0xffffffff8055d564 "%s") > >>>>> at /usr/src/sys/kern/kern_shutdown.c:590 > >>>>> #3 0xffffffff805055b8 in trap_fatal (frame=0xffffff000288a3e0, eva=Variable "eva" is not available. > >>>>> ) > >>>>> at /usr/src/sys/amd64/amd64/trap.c:777 > >>>>> #4 0xffffffff805059dc in trap_pfault (frame=0xffffff80001e91d0, usermode=0) > >>>>> at /usr/src/sys/amd64/amd64/trap.c:693 > >>>>> #5 0xffffffff805061c5 in trap (frame=0xffffff80001e91d0) > >>>>> at /usr/src/sys/amd64/amd64/trap.c:451 > >>>>> #6 0xffffffff804eb977 in calltrap () > >>>>> at /usr/src/sys/amd64/amd64/exception.S:223 > >>>>> #7 0xffffffff80230413 in sge_start_locked (ifp=0xffffff000270d800) > >>>>> at /usr/src/sys/dev/sge/if_sge.c:1591 > >>>> > >>>> Try this. sge_encap() can sometimes return an error with m_head set to NULL: > >>>> > >>> > >>> Thanks John. Committed in r208512. > >>> > >>>> Index: if_sge.c > >>>> =================================================================== > >>>> --- if_sge.c (revision 208375) > >>>> +++ if_sge.c (working copy) > >>>> @@ -1588,7 +1588,8 @@ > >>>> if (m_head == NULL) > >>>> break; > >>>> if (sge_encap(sc, &m_head)) { > >>>> - IFQ_DRV_PREPEND(&ifp->if_snd, m_head); > >>>> + if (m_head != NULL) > >>>> + IFQ_DRV_PREPEND(&ifp->if_snd, m_head); > >>>> ifp->if_drv_flags |= IFF_DRV_OACTIVE; > >>>> break; > >>>> } > >>>> > >>>> -- > >>>> John Baldwin > >> > >> After the patch I experienced several network outages (ping reporting "no buffer space available") > >> that were resolved by ifconfig down/up of the sge(4) interface. > >> > > > > Because I don't have access to sge(4) controllers I never had chance > > to run it. Does ping(8) generates "no buffer space available" when > > the system is in idle state? Could you show me more information on > > how you checked network outages? > > > > It happened 4-5 times recently. I didn't do extensive investigation, but yes, ping > returned "no buffer space avail" when I tried pinging from the machine itself. > It was unreachable from other hosts on the network. > I'm not sure what you bean by idle state but there was a torrent client running > on the machine, which printed errors about inability to reach peers. > If system is under heavy TX load(e.g. 64bytes UDP test), ping(8) may show that message. > > >> I can see that most of the other drivers that handle XXX_encap() returning m_head pointing NULL, break when this condition > > > > Yes, most drivers written/touched by me behaves like that. > > > >> is hit: i.e. : > >> > >> Index: if_sge.c > >> =================================================================== > >> --- if_sge.c (revision 208375) > >> +++ if_sge.c (working copy) > >> @@ -1588,7 +1588,8 @@ > >> if (m_head == NULL) > >> break; > >> if (sge_encap(sc, &m_head)) { > >> - IFQ_DRV_PREPEND(&ifp->if_snd, m_head); > >> + if (m_head == NULL) > >> + break; > >> IFQ_DRV_PREPEND(&ifp->if_snd, m_head); > >> ifp->if_drv_flags |= IFF_DRV_OACTIVE; > >> break; > >> } > >> > >> But here in sge(4) we always set IFF_DRV_OACTIVE. > >> Do you think this can be the source of the problem ? > >> > > > > More correct way to set IFF_DRV_OACTIVE would be check the number > > of queued frames or just exit the transmit loop. If there is no > > queued frames, IFF_DRV_OACTIVE would never be cleared which in turn > > cause ENOBUFS in ping(8). I think your change looks more reasonable > > to me. Do you still see the same issue with the change you suggested? > > I'm runing with this change for a day or something now without any issues. Ok, committed in r208806. Thanks for the patch. From owner-freebsd-stable@FreeBSD.ORG Fri Jun 4 17:58:23 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AA3BF1065674; Fri, 4 Jun 2010 17:58:23 +0000 (UTC) (envelope-from alc@cs.rice.edu) Received: from mail.cs.rice.edu (mail.cs.rice.edu [128.42.1.31]) by mx1.freebsd.org (Postfix) with ESMTP id 7B2838FC2A; Fri, 4 Jun 2010 17:58:23 +0000 (UTC) Received: from mail.cs.rice.edu (localhost.localdomain [127.0.0.1]) by mail.cs.rice.edu (Postfix) with ESMTP id 846E32C2B58; Fri, 4 Jun 2010 12:58:22 -0500 (CDT) X-Virus-Scanned: by amavis-2.4.0 at mail.cs.rice.edu Received: from mail.cs.rice.edu ([127.0.0.1]) by mail.cs.rice.edu (mail.cs.rice.edu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id dwfWIXRGEi9N; Fri, 4 Jun 2010 12:58:14 -0500 (CDT) Received: from adsl-216-63-78-18.dsl.hstntx.swbell.net (adsl-216-63-78-18.dsl.hstntx.swbell.net [216.63.78.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.cs.rice.edu (Postfix) with ESMTP id 3D2862C2B32; Fri, 4 Jun 2010 12:58:14 -0500 (CDT) Message-ID: <4C093EB5.3060406@cs.rice.edu> Date: Fri, 04 Jun 2010 12:58:13 -0500 From: Alan Cox User-Agent: Thunderbird 2.0.0.24 (X11/20100501) MIME-Version: 1.0 To: Matthew D Fleming , John Baldwin References: <201005272348.o4RNmgWh014243@hugeraid.jetcafe.org> <201006031029.00588.jhb@freebsd.org> <201006040937.o549bEFt054288@hugeraid.jetcafe.org> <201006040820.49741.jhb@freebsd.org> <20100604153210.GA8522@amaretto> In-Reply-To: <20100604153210.GA8522@amaretto> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, Clifton Royston , alc@freebsd.org, Garrett Cooper , Jeremy Chadwick Subject: Re: Locking a file backed mdconfig into memory X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 04 Jun 2010 17:58:23 -0000 Matthew D Fleming wrote: > On Fri, Jun 04, 2010 at 08:20:49AM -0400, John Baldwin wrote: > >> Hmmm, I would just try increasing NKPT then. You might have to poke >> around in sys/amd64 to see what the default size is and how to tune >> it. >> > > When Isilon did the stable/7 merge and amd64 default NKPT changed from > 240 to 32 amd64 started having weird pmap issues during boot. At panic > time the stack wasn't very useful, and I didn't finish debugging the > issue since eventually I just had to get something working. We just > reverted NKPT to 240 and it worked for us. I didn't see an anything in > optsions.amd64 so I hard-coded it in amd64/include/pmap.h. > > Supposedly amd64 can deal with a small NKPT and grow dynamically, but it > didn't seem to work for us. :-( Perhaps when we do the next merge > project I'll have a few days to devote to debugging the root cause. > NKPT controls the number of page table pages that are initially allocated at the bottom of the top 2GB of the kernel address space. However, the vast majority of the kernel address space, 510GB in FreeBSD >=7.3, is below these page table pages. The page table pages for this region are dynamically allocated as needed. If you're booting a kernel and modules greater than 64GB in size, then I can certainly see why you would need to increase NKPT. John, is there some way to know at boot time how big the kernel and modules were? Then, we could probably eliminate NKPT. Alan From owner-freebsd-stable@FreeBSD.ORG Fri Jun 4 20:21:24 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CEA861065676; Fri, 4 Jun 2010 20:21:24 +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 9BD128FC08; Fri, 4 Jun 2010 20:21:24 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 472A846B51; Fri, 4 Jun 2010 16:21:24 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 2667E8A026; Fri, 4 Jun 2010 16:21:23 -0400 (EDT) From: John Baldwin To: Alan Cox Date: Fri, 4 Jun 2010 14:53:36 -0400 User-Agent: KMail/1.12.1 (FreeBSD/7.3-CBSD-20100217; KDE/4.3.1; amd64; ; ) References: <201005272348.o4RNmgWh014243@hugeraid.jetcafe.org> <20100604153210.GA8522@amaretto> <4C093EB5.3060406@cs.rice.edu> In-Reply-To: <4C093EB5.3060406@cs.rice.edu> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201006041453.36467.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Fri, 04 Jun 2010 16:21:23 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Matthew D Fleming , Clifton Royston , alc@freebsd.org, Garrett Cooper , freebsd-stable@freebsd.org, Jeremy Chadwick Subject: Re: Locking a file backed mdconfig into memory X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 04 Jun 2010 20:21:24 -0000 On Friday 04 June 2010 1:58:13 pm Alan Cox wrote: > Matthew D Fleming wrote: > > On Fri, Jun 04, 2010 at 08:20:49AM -0400, John Baldwin wrote: > > > >> Hmmm, I would just try increasing NKPT then. You might have to poke > >> around in sys/amd64 to see what the default size is and how to tune > >> it. > >> > > > > When Isilon did the stable/7 merge and amd64 default NKPT changed from > > 240 to 32 amd64 started having weird pmap issues during boot. At panic > > time the stack wasn't very useful, and I didn't finish debugging the > > issue since eventually I just had to get something working. We just > > reverted NKPT to 240 and it worked for us. I didn't see an anything in > > optsions.amd64 so I hard-coded it in amd64/include/pmap.h. > > > > Supposedly amd64 can deal with a small NKPT and grow dynamically, but it > > didn't seem to work for us. :-( Perhaps when we do the next merge > > project I'll have a few days to devote to debugging the root cause. > > > > NKPT controls the number of page table pages that are initially > allocated at the bottom of the top 2GB of the kernel address space. > However, the vast majority of the kernel address space, 510GB in FreeBSD > >=7.3, is below these page table pages. The page table pages for this > region are dynamically allocated as needed. > > If you're booting a kernel and modules greater than 64GB in size, then I > can certainly see why you would need to increase NKPT. 64GB seems like a lot of address space, I would not expect that to be completely used by kernel and modules. I think earlier in the thread someone said they had problems with a "mere" 295MB mfsroot. > John, is there some way to know at boot time how big the kernel and > modules were? Then, we could probably eliminate NKPT. I think the loader knows, so it could pass that info to the kernel. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Fri Jun 4 20:51:47 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EDEB31065674; Fri, 4 Jun 2010 20:51:47 +0000 (UTC) (envelope-from alc@cs.rice.edu) Received: from mail.cs.rice.edu (mail.cs.rice.edu [128.42.1.31]) by mx1.freebsd.org (Postfix) with ESMTP id B483B8FC16; Fri, 4 Jun 2010 20:51:47 +0000 (UTC) Received: from mail.cs.rice.edu (localhost.localdomain [127.0.0.1]) by mail.cs.rice.edu (Postfix) with ESMTP id 45E682C2A8C; Fri, 4 Jun 2010 15:51:47 -0500 (CDT) X-Virus-Scanned: by amavis-2.4.0 at mail.cs.rice.edu Received: from mail.cs.rice.edu ([127.0.0.1]) by mail.cs.rice.edu (mail.cs.rice.edu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id poboG2QnedAa; Fri, 4 Jun 2010 15:51:39 -0500 (CDT) Received: from [10.209.194.87] (unknown [10.209.194.87]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.cs.rice.edu (Postfix) with ESMTP id 5134A2C2B32; Fri, 4 Jun 2010 15:51:39 -0500 (CDT) Message-ID: <4C09674C.10009@cs.rice.edu> Date: Fri, 04 Jun 2010 15:51:24 -0500 From: Alan Cox User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: John Baldwin References: <201005272348.o4RNmgWh014243@hugeraid.jetcafe.org> <20100604153210.GA8522@amaretto> <4C093EB5.3060406@cs.rice.edu> <201006041453.36467.jhb@freebsd.org> In-Reply-To: <201006041453.36467.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Matthew D Fleming , Clifton Royston , alc@freebsd.org, Garrett Cooper , freebsd-stable@freebsd.org, Jeremy Chadwick Subject: Re: Locking a file backed mdconfig into memory X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 04 Jun 2010 20:51:48 -0000 On 6/4/2010 1:53 PM, John Baldwin wrote: > On Friday 04 June 2010 1:58:13 pm Alan Cox wrote: > >> Matthew D Fleming wrote: >> >>> On Fri, Jun 04, 2010 at 08:20:49AM -0400, John Baldwin wrote: >>> >>> >>>> Hmmm, I would just try increasing NKPT then. You might have to poke >>>> around in sys/amd64 to see what the default size is and how to tune >>>> it. >>>> >>>> >>> When Isilon did the stable/7 merge and amd64 default NKPT changed from >>> 240 to 32 amd64 started having weird pmap issues during boot. At panic >>> time the stack wasn't very useful, and I didn't finish debugging the >>> issue since eventually I just had to get something working. We just >>> reverted NKPT to 240 and it worked for us. I didn't see an anything in >>> optsions.amd64 so I hard-coded it in amd64/include/pmap.h. >>> >>> Supposedly amd64 can deal with a small NKPT and grow dynamically, but it >>> didn't seem to work for us. :-( Perhaps when we do the next merge >>> project I'll have a few days to devote to debugging the root cause. >>> >>> >> NKPT controls the number of page table pages that are initially >> allocated at the bottom of the top 2GB of the kernel address space. >> However, the vast majority of the kernel address space, 510GB in FreeBSD >> >=7.3, is below these page table pages. The page table pages for this >> region are dynamically allocated as needed. >> >> If you're booting a kernel and modules greater than 64GB in size, then I >> can certainly see why you would need to increase NKPT. >> > 64GB seems like a lot of address space, I would not expect that to be > completely used by kernel and modules. I think earlier in the thread someone > said they had problems with a "mere" 295MB mfsroot. > > Oops. I meant to say 64MB. :-) >> John, is there some way to know at boot time how big the kernel and >> modules were? Then, we could probably eliminate NKPT. >> > I think the loader knows, so it could pass that info to the kernel. > > From owner-freebsd-stable@FreeBSD.ORG Sat Jun 5 06:16:34 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 997A9106566C for ; Sat, 5 Jun 2010 06:16:34 +0000 (UTC) (envelope-from hans.dampf@eml.cc) Received: from out5.smtp.messagingengine.com (out5.smtp.messagingengine.com [66.111.4.29]) by mx1.freebsd.org (Postfix) with ESMTP id 68AEF8FC19 for ; Sat, 5 Jun 2010 06:16:34 +0000 (UTC) Received: from compute2.internal (compute2.internal [10.202.2.42]) by gateway1.messagingengine.com (Postfix) with ESMTP id B942BF6530 for ; Sat, 5 Jun 2010 02:16:33 -0400 (EDT) Received: from vweb6.messagingengine.com ([10.202.2.36]) by compute2.internal (MEProxy); Sat, 05 Jun 2010 02:16:33 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=message-id:from:to:content-transfer-encoding:content-type:mime-version:references:subject:in-reply-to:date; s=smtpout; bh=woyQMR5EoPEOUfO/g7ij9S4S3f0=; b=L/budZ3yux1FPWxabfeuRMMGu/ObG3H+5g/bpbRR2lyfKnIuR2//Nfb2YfqnZB7JM6qIzSvECoKrzvXoNlgsekJEJ1ZHv6IMD6ihGE/QOfkdFyBrIcVXoWX9WpmGJsmj2FsAUD5UoT9ywnGS3yiHQSPE3coUH9Dq+dC+Dvx5tPs= Received: by vweb6.messagingengine.com (Postfix, from userid 99) id 9499B252A; Sat, 5 Jun 2010 02:16:33 -0400 (EDT) Message-Id: <1275718593.23568.1378582011@webmail.messagingengine.com> X-Sasl-Enc: G28rMkga1v0lqjicsMC2QEX0qwwzVuhFyLSdjl3JXGc6 1275718593 From: hans.dampf@eml.cc To: "FreeBSD Stable" Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 X-Mailer: MessagingEngine.com Webmail Interface References: <4C09299A.1000406@FreeBSD.org> In-Reply-To: <4C09299A.1000406@FreeBSD.org> Date: Sat, 05 Jun 2010 08:16:33 +0200 Subject: Re: atapicam issue X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 05 Jun 2010 06:16:34 -0000 Here's the full and uncensored log: http://pastebin.org/308021 Thank you On Fri, 04 Jun 2010 19:28:10 +0300, "Alexander Motin" said: > hans.dampf@eml.cc wrote: > > FreeBSD-stable clandestinely dropped support for my p-ata DVD drive some > > two or three weeks ago. The relevant "devcontrol list"-entry is still in > > its place, yet atapicam fails to create "/dev/cd0". > > > > # camcontrol devlist > > at scbus0 target 0 lun 0 (pass0) > > > > dmesg reports: > > ------------------------ > > (probe0:ata0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 > > (probe0:ata0:0:0:0): CAM status: SCSI Status Error > > (probe0:ata0:0:0:0): SCSI status: Check Condition > > (probe0:ata0:0:0:0): SCSI sense: UNIT ATTENTION asc:29,0 (Power on, > > reset, or bus device reset occurred) > > (probe0:ata0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 > > (probe0:ata0:0:0:0): CAM status: SCSI Status Error > > (probe0:ata0:0:0:0): SCSI status: Check Condition > > (probe0:ata0:0:0:0): SCSI sense: NOT READY asc:3a,1 (Medium not present > > - tray closed) > > --------------------------- > > This is not fatal errors. It is normal. Could you boot with verbose > messages and show full log? > > -- > Alexander Motin From owner-freebsd-stable@FreeBSD.ORG Sat Jun 5 08:08:38 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BB9051065672; Sat, 5 Jun 2010 08:08:38 +0000 (UTC) (envelope-from quakelee@geekcn.org) Received: from tarsier.geekcn.org (tarsier.geekcn.org [IPv6:2001:470:a803::1]) by mx1.freebsd.org (Postfix) with ESMTP id 643B98FC1D; Sat, 5 Jun 2010 08:08:38 +0000 (UTC) Received: from mail.geekcn.org (tarsier.geekcn.org [211.166.10.233]) by tarsier.geekcn.org (Postfix) with ESMTP id 67EB9A5667D; Sat, 5 Jun 2010 16:08:37 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([211.166.10.233]) by mail.geekcn.org (mail.geekcn.org [211.166.10.233]) (amavisd-new, port 10024) with LMTP id J6SD2Q-FrbrS; Sat, 5 Jun 2010 16:08:32 +0800 (CST) Received: from quakelee-work (unknown [222.131.125.41]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id 47F53A5664E; Sat, 5 Jun 2010 16:08:29 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=geekcn.org; c=nofws; q=dns; h=content-type:to:subject:date:cc:mime-version: content-transfer-encoding:from:organization:message-id:user-agent; b=ti/+cWU11SxkFWREt2/3O9OZB4FCuG8RuF/4e31UhJiyjhvF9MTwfVx3rR7k/fEah D0igCh8YbpZS0VDTrYhHw== Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: freebsd-stable@freebsd.org Date: Sat, 05 Jun 2010 16:08:18 +0800 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: "Chao Shin" Organization: GeekCN Message-ID: User-Agent: Opera Mail/10.51 (Win32) Cc: "freebsd-net@freebsd.org" , sam@freebsd.org, bz@freebsd.org, julian@freebsd.org, qingli@freebsd.org Subject: panic: rtqkill route really not free on freebsd 8.0-release update X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 05 Jun 2010 08:08:38 -0000 Hi, all We add kdb/ddb and extra panic info printing into kernel and catch this panic again. We have instrumented the kernel and found that this panic happens when draining == 1, but seems to be confused with the fact that all access to radix trees are protected by locks. Can anyone familiar with these code shed us some light on this? below is url to screenshot in ddb: http://www.delphij.net/zhao/1.png http://www.delphij.net/zhao/2.png -- The Power to Serve From owner-freebsd-stable@FreeBSD.ORG Sat Jun 5 12:06:46 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4C6C2106564A for ; Sat, 5 Jun 2010 12:06:46 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id C8A3C8FC12 for ; Sat, 5 Jun 2010 12:06:45 +0000 (UTC) Received: by fxm20 with SMTP id 20so1319479fxm.13 for ; Sat, 05 Jun 2010 05:06:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=X2w5494xMOe+W2nORyn6B6n20yXh/aP1V4d2nG2Z4Ho=; b=Oe0ymWRYhgSxWJK46vePw0V59ao470+5PQ1VdgXwgQcow7ixRPdhbd6/WT2mh/Nlt4 sztQ2s4jlSfATrdqyky/2Ne8TdsNF81DK+64A84yhaYFZm6HFUIFRQ9NJViQpBu+1XEF LXb/PTXZgkQoYBZPCaGA9FxBGJGWryg7tKOJw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=vxaJy8Y8PnA1aLPJEeQxBOvExmJ4EW3JsgghG7TvXmMQk0QZou/QpclD0FTf4WHgxt B5BlrJdBPXkF+TzWfngJ8imvDaTaqXq70QffefG7iJ/wyq0+dWrW+sXEYKH9h4HabnXX 7ajnyquWrxZwnSwfjuu6BKhyb5GnShlRz+3YY= Received: by 10.223.23.83 with SMTP id q19mr13022665fab.12.1275739603577; Sat, 05 Jun 2010 05:06:43 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id r25sm10081580fai.11.2010.06.05.05.06.42 (version=SSLv3 cipher=RC4-MD5); Sat, 05 Jun 2010 05:06:42 -0700 (PDT) Sender: Alexander Motin Message-ID: <4C0A3DBE.4050304@FreeBSD.org> Date: Sat, 05 Jun 2010 15:06:22 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.24 (X11/20100402) MIME-Version: 1.0 To: hans.dampf@eml.cc, FreeBSD Stable References: <4C09299A.1000406@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Subject: Re: atapicam issue X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 05 Jun 2010 12:06:46 -0000 hans.dampf@eml.cc wrote: > Here's the full and uncensored log: http://pastebin.org/308021 > > On Fri, 04 Jun 2010 19:28:10 +0300, "Alexander Motin" > said: >> hans.dampf@eml.cc wrote: >>> FreeBSD-stable clandestinely dropped support for my p-ata DVD drive some >>> two or three weeks ago. The relevant "devcontrol list"-entry is still in >>> its place, yet atapicam fails to create "/dev/cd0". >>> >>> # camcontrol devlist >>> at scbus0 target 0 lun 0 (pass0) >>> >>> dmesg reports: >>> ------------------------ >>> (probe0:ata0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 >>> (probe0:ata0:0:0:0): CAM status: SCSI Status Error >>> (probe0:ata0:0:0:0): SCSI status: Check Condition >>> (probe0:ata0:0:0:0): SCSI sense: UNIT ATTENTION asc:29,0 (Power on, >>> reset, or bus device reset occurred) >>> (probe0:ata0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 >>> (probe0:ata0:0:0:0): CAM status: SCSI Status Error >>> (probe0:ata0:0:0:0): SCSI status: Check Condition >>> (probe0:ata0:0:0:0): SCSI sense: NOT READY asc:3a,1 (Medium not present >>> - tray closed) I don't see there not only cdX, but also acdX device. So either it is not atapicam problem, or you have custom kernel without both acd and cd drivers. -- Alexander Motin From owner-freebsd-stable@FreeBSD.ORG Sat Jun 5 15:05:42 2010 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 150201065675 for ; Sat, 5 Jun 2010 15:05:42 +0000 (UTC) (envelope-from cperciva@freebsd.org) Received: from xps.daemonology.net (unknown [IPv6:2001:4f8:fff6::28]) by mx2.freebsd.org (Postfix) with SMTP id 6533D14FEF7 for ; Sat, 5 Jun 2010 15:05:41 +0000 (UTC) Received: (qmail 12266 invoked from network); 5 Jun 2010 15:05:40 -0000 Received: from unknown (HELO xps.daemonology.net) (127.0.0.1) by localhost with SMTP; 5 Jun 2010 15:05:40 -0000 Message-ID: <4C0A67C4.6000701@freebsd.org> Date: Sat, 05 Jun 2010 08:05:40 -0700 From: FreeBSD Security Officer Organization: FreeBSD Project User-Agent: Thunderbird 2.0.0.24 (X11/20100329) MIME-Version: 1.0 To: freebsd security , FreeBSD Stable X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: HEADS UP: FreeBSD 7.2 EoL coming soon X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: security-officer@freebsd.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jun 2010 15:05:42 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello Everyone, On June 30th, FreeBSD 7.2 will reach its End of Life and will no longer be supported by the FreeBSD Security Team. Users of this release are strongly encouraged to upgrade to FreeBSD 7.3 before that date; FreeBSD 7.3 will be supported until the end of March 2012. Please note that since FreeBSD 7.1 has been designated for 'Extended' support, it will continue to be supported until the end of January 2011, i.e., FreeBSD 7.1 will be supported longer than FreeBSD 7.2. The End of Life date for FreeBSD 7.2 was originally announced as May 31, but was delayed by one month in accordance with Security Team policy in order to allow a 3 month window between the release of FreeBSD 7.3 and the End of Life of FreeBSD 7.2 to allow time for systems to be upgraded. The freebsd-update(8) utility can be used to upgrade i386 and amd64 systems from 7.2-RELEASE (or 7.2-RELEASE-pX for some X) to 7.3-RELEASE using binary updates (i.e., without compiling from source) as described in the 7.3-RELEASE announcement; given an adequate internet connection, this process usually takes 15 minutes or less. The current supported branches and expected EoL dates are: +---------------------------------------------------------------------+ | Branch | Release | Type | Release date | Estimated EoL | |-----------+------------+--------+-----------------+-----------------| |RELENG_6 |n/a |n/a |n/a |November 30, 2010| |---------------------------------------------------------------------| |RELENG_6_4 |6.4-RELEASE |Extended|November 18, 2008|November 30, 2010| |---------------------------------------------------------------------| |RELENG_7 |n/a |n/a |n/a |last release + 2y| |-----------+------------+--------+-----------------+-----------------| |RELENG_7_1 |7.1-RELEASE |Extended|January 4, 2009 |January 31, 2011 | |-----------+------------+--------+-----------------+-----------------| |RELENG_7_2 |7.2-RELEASE |Normal |May 4, 2009 |June 30, 2010 | |-----------+------------+--------+-----------------+-----------------| |RELENG_7_3 |7.3-RELEASE |Extended|March 23, 2010 |March 31, 2012 | |-----------+------------+--------+-----------------+-----------------| |RELENG_8 |n/a |n/a |n/a |last release + 2y| |-----------+------------+--------+-----------------+-----------------| |RELENG_8_0 |8.0-RELEASE |Normal |November 25, 2009|November 30, 2010| |-----------+------------+--------+-----------------+-----------------| |RELENG_8_1 |8.1-RELEASE |Extended|not yet |release + 2 years| +---------------------------------------------------------------------+ - -- Colin Percival Security Officer, FreeBSD | freebsd.org | The power to serve Founder / author, Tarsnap | tarsnap.com | Online backups for the truly paranoid -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkwKZ8QACgkQFdaIBMps37LL9wCfRspIGXYatsdPDbBR8OZEDocs BagAnAmTXen6TQ+2ER3oF6702stmxVIJ =ydCN -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Sat Jun 5 18:17:59 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 183391065679 for ; Sat, 5 Jun 2010 18:17:59 +0000 (UTC) (envelope-from hans.dampf@eml.cc) Received: from out5.smtp.messagingengine.com (out5.smtp.messagingengine.com [66.111.4.29]) by mx1.freebsd.org (Postfix) with ESMTP id DD1D18FC13 for ; Sat, 5 Jun 2010 18:17:58 +0000 (UTC) Received: from compute1.internal (compute1.internal [10.202.2.41]) by gateway1.messagingengine.com (Postfix) with ESMTP id 4CA53F8C30 for ; Sat, 5 Jun 2010 14:17:45 -0400 (EDT) Received: from vweb6.messagingengine.com ([10.202.2.36]) by compute1.internal (MEProxy); Sat, 05 Jun 2010 14:17:45 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=message-id:from:to:content-transfer-encoding:content-type:mime-version:references:subject:in-reply-to:date; s=smtpout; bh=aYBOQdwzxAZjyDcHjcrZR1T4rOY=; b=LFAqbrVdS9/wf4GZcCbRQ8xZ8qffnFb/hHuExdlpMYV+JTHt0PKw1NV2nrnHR5b+cMYpRVyuepUj3afUXdMPdDh6BbBCZxCO4CthJKoxkyXqEkx5oKCzMKo9lI8dBm1jvguJ77b2p/yf44cFX0qZKK9YfuADnBEJ7TKSCtPrKAY= Received: by vweb6.messagingengine.com (Postfix, from userid 99) id 1F42A119; Sat, 5 Jun 2010 14:17:45 -0400 (EDT) Message-Id: <1275761864.15472.1378633255@webmail.messagingengine.com> X-Sasl-Enc: E1QD0//BOssaWfeteWLqqblSz2kAezaHGzSfd1szE2We 1275761864 From: hans.dampf@eml.cc To: "FreeBSD Stable" Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 X-Mailer: MessagingEngine.com Webmail Interface References: <4C09299A.1000406@FreeBSD.org> <4C0A3DBE.4050304@FreeBSD.org> In-Reply-To: <4C0A3DBE.4050304@FreeBSD.org> Date: Sat, 05 Jun 2010 20:17:44 +0200 Subject: Re: atapicam issue --- solved! X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 05 Jun 2010 18:17:59 -0000 Thank you, Alexander. For some obscure reason, my kernel configuration lacked "device cd". Hans On Sat, 05 Jun 2010 15:06:22 +0300, "Alexander Motin" said: > hans.dampf@eml.cc wrote: > > Here's the full and uncensored log: http://pastebin.org/308021 > > > > On Fri, 04 Jun 2010 19:28:10 +0300, "Alexander Motin" > > said: > >> hans.dampf@eml.cc wrote: > >>> FreeBSD-stable clandestinely dropped support for my p-ata DVD drive some > >>> two or three weeks ago. The relevant "devcontrol list"-entry is still in > >>> its place, yet atapicam fails to create "/dev/cd0". > >>> > >>> # camcontrol devlist > >>> at scbus0 target 0 lun 0 (pass0) > >>> > >>> dmesg reports: > >>> ------------------------ > >>> (probe0:ata0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 > >>> (probe0:ata0:0:0:0): CAM status: SCSI Status Error > >>> (probe0:ata0:0:0:0): SCSI status: Check Condition > >>> (probe0:ata0:0:0:0): SCSI sense: UNIT ATTENTION asc:29,0 (Power on, > >>> reset, or bus device reset occurred) > >>> (probe0:ata0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 > >>> (probe0:ata0:0:0:0): CAM status: SCSI Status Error > >>> (probe0:ata0:0:0:0): SCSI status: Check Condition > >>> (probe0:ata0:0:0:0): SCSI sense: NOT READY asc:3a,1 (Medium not present > >>> - tray closed) > > I don't see there not only cdX, but also acdX device. So either it is > not atapicam problem, or you have custom kernel without both acd and cd > drivers. > > -- > Alexander Motin