From owner-freebsd-stable@FreeBSD.ORG Sun Feb 27 02:58:34 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8B8D51065670; Sun, 27 Feb 2011 02:58:34 +0000 (UTC) (envelope-from jhelfman@experts-exchange.com) Received: from mail.experts-exchange.com (mail.experts-exchange.com [72.29.183.251]) by mx1.freebsd.org (Postfix) with ESMTP id 229FC8FC17; Sun, 27 Feb 2011 02:58:34 +0000 (UTC) Received: from mail.experts-exchange.com (localhost [127.0.0.1]) by mail.experts-exchange.com (Postfix) with ESMTP id 0815D6F4F5B; Sat, 26 Feb 2011 18:58:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=e-e.com; h= user-agent:in-reply-to:content-disposition:content-type :content-type:mime-version:references:message-id:subject:subject :from:from:date:date:received:received:received; s=ee; t= 1298775513; x=1300589913; bh=aL1meeohjy8761CDuSyS6g2gm4QGqXBUGHB f5gkCUkQ=; b=JI8+gUyfCh6hrQKWXA45hmJYt1p6NYJpKVigwjU52bpw4coL8cG b1VyKP/PhL25BuUcQK0ukPWW/wLxjNQ3OmxCGFO4VvaMQWCSk2a04bhoJrenli7T Ef9LFNAOEVSyoriaglFsINZuD8MO2+cpxHdQTP9XoTfEyYPYWuFh6tzE= X-Virus-Scanned: amavisd-new at experts-exchange.com Received: from mail.experts-exchange.com ([127.0.0.1]) by mail.experts-exchange.com (mail.experts-exchange.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3XEP2t4ybYbZ; Sat, 26 Feb 2011 18:58:33 -0800 (PST) Received: from experts-exchange.com (unknown [72.29.180.81]) by mail.experts-exchange.com (Postfix) with SMTP id A7FA36F4F56; Sat, 26 Feb 2011 18:58:33 -0800 (PST) Received: (nullmailer pid 64268 invoked by uid 1001); Sun, 27 Feb 2011 02:55:12 -0000 Date: Sat, 26 Feb 2011 18:55:12 -0800 From: Jason Helfman To: John Baldwin Message-ID: <20110227025512.GA64170@eggman.experts-exchange.com> References: <4D66CCFF.9020903@buffalo.edu> <20110225160109.GA32260@lava.net> <20110225180019.GD76063@eggman.experts-exchange.com> <201102251501.11318.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <201102251501.11318.jhb@freebsd.org> X-Operating-System: FreeBSD 8.2-RELEASE X-Living-The-Dream: I love the SLO Life! User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@freebsd.org, cperciva@freebsd.org Subject: Re: 8.2/7.4-RELEASEs Announced... X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Feb 2011 02:58:34 -0000 On Fri, Feb 25, 2011 at 03:01:11PM -0500, John Baldwin thus spake: >On Friday, February 25, 2011 1:00:19 pm jhelfman@e-e.com wrote: >> > On Fri, Feb 25, 2011 at 02:42:25PM +0100, Marco van Tol wrote: >> >> >> >> Read up on the mergemaster manual for options "-F" and "-i" :-) >> > >> > freebsd-update does not use mergemaster, though probably it should. >> >> My understanding is that freebsd-update was introduced prior to releases >> being branched, so this issue surfaced at that time. The patch I believe >> would be a fix to the freebsd-update client to better handle the tag. I >> can't see mergemaster as being an easier solution, as the actual binary >> would need to be verified against a known good index that would exist on the >> update server. > >No, release branches long pre-date freebsd-update. However, before we >switched to svn for source, new branches did not bump all the $FreeBSD$ tags. >That is a side effect of the way that the SVN -> CVS exporter works (and >arguably a bug). Yes. This is what I was trying to explain. Thanks for clearing this up, John. > >BTW, I did design etcupdate to support this sort of use case (you can build a >tarball from a given release tree and use that as the basis for comparisons >assuming you were bootstrapped to use etcupdate). Currently freebsd-update >doesn't use etcupdate and the author doesn't have any interest in changing it >to do so. Speaking as an administrator of my own set of freebsd-update-servers, I would suggest a different path to solve the issue. I am not certain what the exact path would be, but let me attempt to explain the issues I believe would come up. The freebsd-update-server software builds binary updates for distribution using that are updated using the freebsd-client off of an actual distribution iso that is built using the standard 'make release' process. So in edition to modifying the freebsd-update-server code to not build this portion of the release, or at least not distribute it, the client would need to be aware not to look for it, as well. You can update the client to use a different method for updating /etc, however the freebsd-update mirror servers will still be distributing the files, so you will have either a similar issue, or a new issue. Using the freebsd-update-software, I am not only able to apply security patches that are distributed by the security team, but I can also apply patches to /etc, or any part of the release for that matter, when it comes to distribution of updates from my updates servers. This is the flexibility I enjoy, and celebrate, in using FreeBSD. All of this being said, if an update software, and respective client were created specifically for /etc, it would be great to have similar functionality, in building off of a distributed iso, with the possibility of patching available, so this functionality is not lost. In addition to this, also using keyprints to authenticate the client, and distribute in a similar matter. I am copying Colin on this, in case he has any thoughts on the matter, or ideas that may make this a possibility. > >At some point if I have some time to hack on freebsd-update to be more useful >for modified versions of FreeBSD (e.g. building snaps from tags in an SVN >repository instead of a directory of patches against a CVS checkout), I will >probably hack it to support using etcupdate to manage /etc updates as well. > This would be great, if you can have it build and work off of a distributed iso. It would be very disappointing to be restricted to an svn/cvs tag/branch from FreeBSD, without the flexibility that is possible now using the freebsd-update-server software. This flexibility allows me to distribute binary updates for a custom kernel, and to modify /etc and distribute it at my leisure. >(etcupdate uses something akin to 'svn up' to update files in /etc, so things >like $FreeBSD$ changes just auto-update assuming they don't result in merge >conficts.) > >-- >John Baldwin > Thanks, and would enjoy being in on any future development thoughts, or ideas regarding your work on this. Jason -- Jason Helfman System Administrator experts-exchange.com http://www.experts-exchange.com/M_4830110.html E4AD 7CF1 1396 27F6 79DD 4342 5E92 AD66 8C8C FBA5 From owner-freebsd-stable@FreeBSD.ORG Sun Feb 27 03:38:50 2011 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 3E3191065675; Sun, 27 Feb 2011 03:38:50 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from doug-optiplex.ka9q.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 00282156FAD; Sun, 27 Feb 2011 03:38:33 +0000 (UTC) Message-ID: <4D69C739.6050002@FreeBSD.org> Date: Sat, 26 Feb 2011 19:38:33 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.13) Gecko/20110129 Thunderbird/3.1.7 MIME-Version: 1.0 To: Jason Helfman References: <4D66CCFF.9020903@buffalo.edu> <20110225160109.GA32260@lava.net> <20110225180019.GD76063@eggman.experts-exchange.com> <201102251501.11318.jhb@freebsd.org> <20110227025512.GA64170@eggman.experts-exchange.com> In-Reply-To: <20110227025512.GA64170@eggman.experts-exchange.com> X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, cperciva@freebsd.org, John Baldwin Subject: Re: 8.2/7.4-RELEASEs Announced... X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Feb 2011 03:38:50 -0000 When I was looking at this problem myself recently it occurred to me that one way to handle it would be to have the freebsd-update code build and populate the temproot directory that mergemaster uses and then offer the user the option to use that alternative. The process could use something like what's done in src/release/scripts/mm-mtree.sh if this direction is desirable. Obviously the temproot directory would have to be distributed as an additional blob by freebsd-update, but this method has the advantage of reusing existing tools, and it's able to handle updates from arbitrarily old existing installations. hth, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-stable@FreeBSD.ORG Sun Feb 27 12:18:07 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1AAF3106564A for ; Sun, 27 Feb 2011 12:18:07 +0000 (UTC) (envelope-from ml@my.gd) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id C74ED8FC12 for ; Sun, 27 Feb 2011 12:18:04 +0000 (UTC) Received: by qyk27 with SMTP id 27so2477592qyk.13 for ; Sun, 27 Feb 2011 04:18:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.184.149 with SMTP id ck21mr3300331qcb.180.1298809082624; Sun, 27 Feb 2011 04:18:02 -0800 (PST) Received: by 10.229.97.133 with HTTP; Sun, 27 Feb 2011 04:18:02 -0800 (PST) In-Reply-To: <20110224075517.GA18146@icarus.home.lan> References: <4D660909.6090202@my.gd> <20110224075517.GA18146@icarus.home.lan> Date: Sun, 27 Feb 2011 13:18:02 +0100 Message-ID: From: Damien Fleuriot To: Jeremy Chadwick Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-stable@freebsd.org" Subject: Re: ZFS - abysmal performance with samba since upgrade to 8.2-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: Sun, 27 Feb 2011 12:18:07 -0000 On 24 February 2011 08:55, Jeremy Chadwick wrote= : > On Thu, Feb 24, 2011 at 08:30:17AM +0100, Damien Fleuriot wrote: >> Hello list, >> >> I've recently upgraded my home box from 8.2-PRE to 8.2-RELEASE and since >> then I've been experiencing *abysmal* performance with samba. >> >> We're talking transfer rates of say 50kbytes/s here, and I'm the only >> client on the box. > > I have a similar system with significantly less disks (two pools, one > disk each; yes, no redundancy). =A0The system can push, via SMB/CIFS > across the network about 65-70MBytes/sec, and 80-90MByte/sec via FTP. > I'll share with you my tunings for Samba, ZFS, and the system. =A0I spent > quite some time messing with different values in Samba and FreeBSD to > find out what got me the "best" performance without destroying the > system horribly. > > Please note the amount of memory matters greatly here, so don't go > blindly setting these if your system has some absurdly small amount of > physical RAM installed. > > Before getting into what my system has, I also want to make clear that > there have been cases in the past where people were seeing abysmal > performance from ZFS, only to find out it was a *single disk* in their > pool which was causing all of the problems (meaning a single disk was > performing horribly, impacting everything). =A0I can try to find the > mailing list post, but I believe the user offlined the disk (and later > replaced it) and everything was fast again. =A0Just a FYI. > > > System specifications > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > * Case - Supermicro SC733T-645B > * =A0 MB - Supermicro X7SBA > * =A0CPU - Intel Core 2 Duo E8400 > * =A0RAM - CT2KIT25672AA800, 4GB ECC > * =A0RAM - CT2KIT25672AA80E, 4GB ECC > * Disk - Intel X25-V SSD (ada0, boot) > * Disk - WD1002FAEX (ada1, ZFS "data" pool) > * Disk - WD2001FASS (ada2, ZFS "backups" pool) > > > > Samba > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Rebuild the port (ports/net/samba35) with AIO_SUPPORT enabled. =A0To use > AIO you will need to load the aio.ko kernel module (kldload aio) first. > > Relevant smb.conf tunings: > > =A0[global] > =A0socket options =3D TCP_NODELAY SO_SNDBUF=3D131072 SO_RCVBUF=3D131072 > =A0use sendfile =3D no > =A0min receivefile size =3D 16384 > =A0aio read size =3D 16384 > =A0aio write size =3D 16384 > =A0aio write behind =3D yes > > > > ZFS pools > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > =A0pool: backups > =A0state: ONLINE > =A0scrub: none requested > config: > > =A0 =A0 =A0 =A0NAME =A0 =A0 =A0 =A0STATE =A0 =A0 READ WRITE CKSUM > =A0 =A0 =A0 =A0backups =A0 =A0 ONLINE =A0 =A0 =A0 0 =A0 =A0 0 =A0 =A0 0 > =A0 =A0 =A0 =A0 =A0ada2 =A0 =A0 =A0ONLINE =A0 =A0 =A0 0 =A0 =A0 0 =A0 =A0= 0 > > errors: No known data errors > > =A0pool: data > =A0state: ONLINE > =A0scrub: none requested > config: > > =A0 =A0 =A0 =A0NAME =A0 =A0 =A0 =A0STATE =A0 =A0 READ WRITE CKSUM > =A0 =A0 =A0 =A0data =A0 =A0 =A0 =A0ONLINE =A0 =A0 =A0 0 =A0 =A0 0 =A0 =A0= 0 > =A0 =A0 =A0 =A0 =A0ada1 =A0 =A0 =A0ONLINE =A0 =A0 =A0 0 =A0 =A0 0 =A0 =A0= 0 > > errors: No known data errors > > > > ZFS tunings > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Your tunings here are "wild" (meaning all over the place). =A0Your use > of vfs.zfs.txg.synctime=3D"1" is probably hurting you quite badly, in > addition to your choice to enable prefetching (every ZFS FreeBSD system > I've used has benefit tremendously from having prefetching disabled, > even on systems with 8GB RAM and more). =A0You do not need to specify > vm.kmem_size_max, so please remove that. =A0Keeping vm.kmem_size is fine. > Also get rid of your vdev tunings, I'm not sure why you have those. > > My relevant /boot/loader.conf tunings for 8.2-RELEASE (note to readers: > the version of FreeBSD you're running, and build date, matters greatly > here so do not just blindly apply these without thinking first): > > =A0# We use Samba built with AIO support; we need this module! > =A0aio_load=3D"yes" > > =A0# Increase vm.kmem_size to allow for ZFS ARC to utilise more memory. > =A0vm.kmem_size=3D"8192M" > =A0vfs.zfs.arc_max=3D"6144M" > > =A0# Disable ZFS prefetching > =A0# http://southbrain.com/south/2008/04/the-nightmare-comes-slowly-zfs.h= tml > =A0# Increases overall speed of ZFS, but when disk flushing/writes occur, > =A0# system is less responsive (due to extreme disk I/O). > =A0# NOTE: Systems with 8GB of RAM or more have prefetch enabled by > =A0# default. > =A0vfs.zfs.prefetch_disable=3D"1" > > =A0# Decrease ZFS txg timeout value from 30 (default) to 5 seconds. =A0Th= is > =A0# should increase throughput and decrease the "bursty" stalls that > =A0# happen during immense I/O with ZFS. > =A0# http://lists.freebsd.org/pipermail/freebsd-fs/2009-December/007343.h= tml > =A0# http://lists.freebsd.org/pipermail/freebsd-fs/2009-December/007355.h= tml > =A0vfs.zfs.txg.timeout=3D"5" > > > > sysctl tunings > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Please note that the below kern.maxvnodes tuning is based on my system > usage, and yours may vary, so you can remove or comment out this option > if you wish. =A0The same goes for vfs.ufs.dirhash_maxmem. =A0As for > vfs.zfs.txg.write_limit_override, I strongly suggest you keep this > commented out for starters; it effectively "rate limits" ZFS I/O, and > this smooths out overall performance (otherwise I was seeing what > appeared to be incredible network transfer speed, then the system would > churn hard for quite some time on physical I/O, then fast network speed, > physical I/O, etc... very "bursty", which I didn't want). > > =A0# Increase send/receive buffer maximums from 256KB to 16MB. > =A0# FreeBSD 7.x and later will auto-tune the size, but only up to the ma= x. > =A0net.inet.tcp.sendbuf_max=3D16777216 > =A0net.inet.tcp.recvbuf_max=3D16777216 > > =A0# Double send/receive TCP datagram memory allocation. =A0This defines = the > =A0# amount of memory taken up by default *per socket*. > =A0net.inet.tcp.sendspace=3D65536 > =A0net.inet.tcp.recvspace=3D131072 > > =A0# dirhash_maxmem defaults to 2097152 (2048KB). =A0dirhash_mem has reac= hed > =A0# this limit a few times, so we should increase dirhash_maxmem to > =A0# something like 16MB (16384*1024). > =A0vfs.ufs.dirhash_maxmem=3D16777216 > > =A0# > =A0# ZFS tuning parameters > =A0# NOTE: Be sure to see /boot/loader.conf for additional tunings > =A0# > > =A0# Increase number of vnodes; we've seen vfs.numvnodes reach 115,000 > =A0# at times. =A0Default max is a little over 200,000. =A0Playing it saf= e... > =A0kern.maxvnodes=3D250000 > > =A0# Set TXG write limit to a lower threshold. =A0This helps "level out" > =A0# the throughput rate (see "zpool iostat"). =A0A value of 256MB works = well > =A0# for systems with 4GB of RAM, while 1GB works well for us w/ 8GB on > =A0# disks which have 64MB cache. > =A0vfs.zfs.txg.write_limit_override=3D1073741824 > > > > Good luck. > > -- > | Jeremy Chadwick =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 jdc@parodius.com | > | Parodius Networking =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 http://= www.parodius.com/ | > | UNIX Systems Administrator =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Mountain = View, CA, USA | > | Making life hard for others since 1977. =A0 =A0 =A0 =A0 =A0 =A0 =A0 PGP= 4BD6C0CB | > > Hi again Jeremy, list, I've been able to test with the settings you recommended and this obviously did the trick. I'm now getting much better overall performance, see below the iostat output during the transfer of a ~5gb file through samba: capacity operations bandwidth pool used avail read write read write ---------- ----- ----- ----- ----- ----- ----- rtank 5.17T 7.08T 1 1 146K 188K rtank 5.17T 7.08T 539 0 67.0M 0 rtank 5.17T 7.08T 564 0 69.9M 0 rtank 5.17T 7.08T 530 0 65.8M 0 rtank 5.17T 7.08T 570 0 70.8M 0 rtank 5.17T 7.08T 567 0 70.3M 0 rtank 5.17T 7.08T 546 0 67.8M 0 rtank 5.17T 7.08T 546 0 67.9M 0 rtank 5.17T 7.08T 571 0 70.9M 0 rtank 5.17T 7.08T 549 0 68.2M 0 rtank 5.17T 7.08T 608 0 75.4M 0 rtank 5.17T 7.08T 565 0 70.3M 0 rtank 5.17T 7.08T 534 0 66.4M 0 rtank 5.17T 7.08T 557 0 69.2M 0 rtank 5.17T 7.08T 557 0 69.1M 0 rtank 5.17T 7.08T 538 0 66.8M 0 Not only am I getting much higher speed (~65mbytes/s as opposed to ~20-40 previously, before getting the abysmal drop) but now the load on the ZFS pool is leveled. Thank you again, settings definitely did it :) From owner-freebsd-stable@FreeBSD.ORG Sun Feb 27 14:16:17 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 62F331065674; Sun, 27 Feb 2011 14:16:17 +0000 (UTC) (envelope-from dan.naumov@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 BEFC98FC0A; Sun, 27 Feb 2011 14:16:16 +0000 (UTC) Received: by bwz12 with SMTP id 12so3463791bwz.13 for ; Sun, 27 Feb 2011 06:16:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=jbRjiyH3JcxsbYfk8NGhu2G/Bhm8dSAunTWaqwZ1h48=; b=G2A1LQUv9eooYJZWGlMBGBUpNtBPd7m7QQuyPno6+bWQRPZgCyYJjoC1eNbXEfSRq8 tJlbJYkL3pL2Bfje08JgkGaQsNaXkTT/g/Mjb8seKPL7cPp+8LfZBXlqKMBNJ+A6t2MT Uv8IQBcGdoe4MaYPs2GPj/akvpF3v5aZN7f0E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=Q+BXYiOFGDcClKONgpeeh6Yc2OZ1uJoE4dMy+Er5P4A0rrQRgHBCP5pYNOGIDSDhOs 7VG0NrCdLs5e/LUxGJVCYlBk5pF7y90gn2bVCHBIueHLSaYiI/iskirwroBUmRaWKrI3 PuAb7S+DyRR5BqSdigGm4YmQ7RqAgbhl/fDwo= MIME-Version: 1.0 Received: by 10.204.14.6 with SMTP id e6mr3758287bka.9.1298814485712; Sun, 27 Feb 2011 05:48:05 -0800 (PST) Received: by 10.204.62.205 with HTTP; Sun, 27 Feb 2011 05:48:05 -0800 (PST) Date: Sun, 27 Feb 2011 15:48:05 +0200 Message-ID: From: Dan Naumov To: freebsd-stable@freebsd.org, freebsd-questions@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: using freebsd-update to update jails and their host X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Feb 2011 14:16:17 -0000 I have a 8.0 host system with a few jails (using ezjail) that I am gearing to update to 8.2. I have used freebsd-update a few times in the past to upgrade a system between releases, but how I would I go about using it to also upgrade a few jails made using ezjail? I would obviously need to point freebsd-update to use /basejail as root which I assume isn't too hard, but what about having it merge the new/changed /etc files in individual jails? I've also discovered the "ezjail-admin install -h file://" option which installs a basejail using the host system as base, am I right in thinking I could also use this by first upgrading my host and then running this command to write the /basejail over with the updated files from the host to bring them into sync? I still don't know how I would then fix the /etc under each individual jail though. - Sincerely, Dan Naumov From owner-freebsd-stable@FreeBSD.ORG Sun Feb 27 15:02:16 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D612B106566B; Sun, 27 Feb 2011 15:02:16 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from sarah.protected-networks.net (sarah.protected-networks.net [IPv6:2001:470:1f07:4e1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 9DAD98FC0C; Sun, 27 Feb 2011 15:02:16 +0000 (UTC) Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [202.12.127.84]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "Iain Butler", Issuer "RSA Class 2 Personal CA" (verified OK)) (Authenticated sender: imb@protected-networks.net) by sarah.protected-networks.net (Postfix) with ESMTPSA id B3FCE6154; Sun, 27 Feb 2011 10:02:14 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=protected-networks.net; s=200705; t=1298818934; bh=dwFoD2SToxdZ1tl8CGHWe19nGqj/mJOmhSDVY9oMSsU=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=DQh8lmMJOrsPqy4ioJ1EWwl7jKi6H7Ll5b5gmQfbOL3YMIVp9C69BboFiJYRHj6Ci zb9Iz1hzsy/R7bTwjyxqrAGhWOYb7Mf6MWSgpNBkjM9abnrovg90HUerhscU027 DomainKey-Signature: a=rsa-sha1; s=200509; d=protected-networks.net; c=nofws; q=dns; h=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=GooQa8dGzNJgYr6ieRXYWWCKlwp9xZkjxBqhweHq0c8NXO47Qh6j/skrClYq2qiw9 0rlv0jI5JZNHBPjs4so/dTNuxdmZ9QbHaozmCk96KoYV4q+J72ffxPSamlHsqNK Message-ID: <4D6A6774.70108@protected-networks.net> Date: Sun, 27 Feb 2011 10:02:12 -0500 From: Michael Butler User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.13) Gecko/20110116 Thunderbird/3.1.7 MIME-Version: 1.0 To: Dan Naumov References: In-Reply-To: X-Enigmail-Version: 1.1.2 OpenPGP: id=0442D492 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, freebsd-questions@freebsd.org Subject: Re: using freebsd-update to update jails and their host X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Feb 2011 15:02:16 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02/27/11 08:48, Dan Naumov wrote: > I've also discovered the "ezjail-admin install -h file://" option which > installs a basejail using the host system as base, am I right in thinking I > could also use this by first upgrading my host and then running this command > to write the /basejail over with the updated files from the host to bring > them into sync? I still don't know how I would then fix the /etc under each > individual jail though. I've been using .. ezjail-admin update -i .. to update the binaries after a full update of the host system and something like .. #!/bin/sh for JAIL in {list-your-jails-here} do mv /usr/src /usr/local/jails/${JAIL}/usr JAIL_ID=`jls | grep $JAIL | awk '{ print $1 };'` echo "Updating: ${JAIL}" jexec ${JAIL_ID} mergemaster -scvi mv /usr/local/jails/${JAIL}/usr/src /usr done .. to update/merge with jail-specific config data, imb -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk1qZ3IACgkQQv9rrgRC1JLqugCcCRUttSFubQnc6IJtgjR6wcjr xioAoKllN6juSk1A7hHso7/AXP8mMZ9p =tkVj -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Sun Feb 27 15:13:08 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0B63A106566B; Sun, 27 Feb 2011 15:13:08 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from sarah.protected-networks.net (sarah.protected-networks.net [IPv6:2001:470:1f07:4e1::1]) by mx1.freebsd.org (Postfix) with ESMTP id C34758FC0A; Sun, 27 Feb 2011 15:13:07 +0000 (UTC) Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [202.12.127.84]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "Iain Butler", Issuer "RSA Class 2 Personal CA" (verified OK)) (Authenticated sender: imb@protected-networks.net) by sarah.protected-networks.net (Postfix) with ESMTPSA id E6AB56154; Sun, 27 Feb 2011 10:13:06 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=protected-networks.net; s=200705; t=1298819587; bh=/BSKcVc/1dF02GOOC0NSvMvOSDUKjVuIfB2B4kyJyzI=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=ml+iaKOL3kCVr/nahBk/FejVijMscHDsLBRGstOvHTO6KKlOc0MTCGu+GsK71+WG1 4gMrTdU4PEEK1/8GUHAKkcsU2XQko4pRdWWJo3JFOYQn2FWLBGly7K/FWYjTtGe DomainKey-Signature: a=rsa-sha1; s=200509; d=protected-networks.net; c=nofws; q=dns; h=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=XmOPYBGUhWt8YwRTnElSYgO3ueDGEaW3HWNbqwCJZ+LUET27DC3moJA68/Kdg/2sL 6/+xSDvqcjlN85rk9FcimO9kqADkIksGK6Go/Nv8+LN1tZuFxERI4Dh6dasEI84 Message-ID: <4D6A6A01.4090104@protected-networks.net> Date: Sun, 27 Feb 2011 10:13:05 -0500 From: Michael Butler User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.13) Gecko/20110116 Thunderbird/3.1.7 MIME-Version: 1.0 To: Dan Naumov References: <4D6A6774.70108@protected-networks.net> In-Reply-To: <4D6A6774.70108@protected-networks.net> X-Enigmail-Version: 1.1.2 OpenPGP: id=0442D492 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, freebsd-questions@freebsd.org Subject: Re: using freebsd-update to update jails and their host X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Feb 2011 15:13:08 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Apologies .. correcting myself here .. > .. to update the binaries after a full update of the host system and > something like .. > > #!/bin/sh > for JAIL in {list-your-jails-here} > do > mv /usr/src /usr/local/jails/${JAIL}/usr > JAIL_ID=`jls | grep $JAIL | awk '{ print $1 };'` > echo "Updating: ${JAIL}" > jexec ${JAIL_ID} mergemaster -scvi > mv /usr/local/jails/${JAIL}/usr/src /usr > done This should, of course, be .. #!/bin/sh rmdir /usr/local/jails/basejail/usr/src mv /usr/src /usr/local/jails/basejail/usr/src for JAIL in {list-your-jails-here} do JAIL_ID=`jls | grep $JAIL | awk '{ print $1 };'` echo "Updating: ${JAIL}" jexec ${JAIL_ID} mergemaster -scvi done mv /usr/local/jails/basejail/usr/src /usr mkdir /usr/local/jails/basejail/usr/src imb -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk1qagEACgkQQv9rrgRC1JJVdwCfWeTcTSheVvMDFDLMfZj/56he ZUcAoLwiSObA6UmCmALfiFK/tJaVyj8+ =1pnX -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Sun Feb 27 16:01:48 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EC997106564A for ; Sun, 27 Feb 2011 16:01:48 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by mx1.freebsd.org (Postfix) with ESMTP id 9DB478FC08 for ; Sun, 27 Feb 2011 16:01:48 +0000 (UTC) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta05.westchester.pa.mail.comcast.net with comcast id D3wT1g0071ZXKqc5541oVu; Sun, 27 Feb 2011 16:01:48 +0000 Received: from koitsu.dyndns.org ([98.248.33.18]) by omta21.westchester.pa.mail.comcast.net with comcast id D41n1g00w0PUQVN3h41ofM; Sun, 27 Feb 2011 16:01:48 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 3DA6F9B427; Sun, 27 Feb 2011 08:01:46 -0800 (PST) Date: Sun, 27 Feb 2011 08:01:46 -0800 From: Jeremy Chadwick To: freebsd-stable@freebsd.org Message-ID: <20110227160145.GA1885@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: ath(4) panic + stuck beacon 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: Sun, 27 Feb 2011 16:01:49 -0000 I have a crash report to provide (for RELENG_8 dated 2010/02/12), but I'd like to know who's maintaining ath(4) at this point in time. I also need to discuss a commonly-reported issue with AR5416 and/or AR9280 cards (e.g. D-Link DWA-552 running in 802.11g mode w/ WEP) spitting out "stuck beacon" errors, which are what I was trying to resolve when the kernel crashed. (I induced the crash, but I'm not sure exactly why/how). Given that the issue has existed for years now... http://www.daemonforums.org/showthread.php?t=3388 http://forums.freebsd.org/showthread.php?t=5983 http://forum.pfsense.org/index.php?topic=21374.0 http://forum.pfsense.org/index.php?topic=32041.0 http://www.broadbandreports.com/forum/r25070916-FreeBSD-MIPS-dev-Adrian-Chad-on-stuck-beacon-issue http://forums.freebsd.org/showthread.php?t=22112 (recent & thorough!) ...and "bintval 1000" does not solve it, let's work together to find a solution. If you need hardware I will be more than happy to buy you (brand new) cards which you can keep. If you have beta/test drivers and/or can provide *thorough* debugging instructions, I will be more than happy to do what I can. I'll also point out the Linux madwifi folks have an *entire page* dedicated to this problem, which is quite interesting: http://madwifi-project.org/wiki/StuckBeacon If a workaround or solution isn't plausible, what cards do people actually recommend that work reliably / have reliable drivers? I was under the impression Atheros cards were reliable/decent compared to, say, Broadcom. Is iwn(4) reliable? -- | 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 Sun Feb 27 17:35:12 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DB05F106564A for ; Sun, 27 Feb 2011 17:35:12 +0000 (UTC) (envelope-from bounces@nabble.com) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) by mx1.freebsd.org (Postfix) with ESMTP id B77A08FC0C for ; Sun, 27 Feb 2011 17:35:12 +0000 (UTC) Received: from isper.nabble.com ([192.168.236.156]) by sam.nabble.com with esmtp (Exim 4.69) (envelope-from ) id 1PtkFe-0005pM-9j for freebsd-stable@freebsd.org; Sun, 27 Feb 2011 09:17:46 -0800 Message-ID: <31026005.post@talk.nabble.com> Date: Sun, 27 Feb 2011 09:17:46 -0800 (PST) From: Hubert Tournier To: freebsd-stable@freebsd.org In-Reply-To: <4D629BE7.8020501@my.gd> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: hubert@frbsd.org References: <20110218164209.GA77903@nargothrond.kdm.org> <4D629BE7.8020501@my.gd> Subject: Re: mps(4) driver (LSI 6Gb SAS) commited to stable/8 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Feb 2011 17:35:12 -0000 Yes, thank you Ken (and everybody involved) for this driver! Ken, i think you left out the mps.4 man page from CURRENT in the 8-STABLE backporting. Damien, i've made an archive that you can drop down into 8.2 RELEASE or RELENG /usr/src, if needed: http://www.projet-hev.org/dist/mps-20110223.tar.bz2 Best regards, Hubert -- View this message in context: http://old.nabble.com/mps%284%29-driver-%28LSI-6Gb-SAS%29-commited-to-stable-8-tp30960541p31026005.html Sent from the freebsd-stable mailing list archive at Nabble.com. From owner-freebsd-stable@FreeBSD.ORG Sun Feb 27 21:55:54 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9B00B1065677 for ; Sun, 27 Feb 2011 21:55:54 +0000 (UTC) (envelope-from ubm.freebsd@googlemail.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 226838FC16 for ; Sun, 27 Feb 2011 21:55:53 +0000 (UTC) Received: by bwz12 with SMTP id 12so3653746bwz.13 for ; Sun, 27 Feb 2011 13:55:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:date:from:to:subject:message-id:in-reply-to :references:x-mailer:mime-version:content-type :content-transfer-encoding; bh=JQoSrJiHSZl0CBs5HzVF57KyMoYAVWkvNPFZpCj3iOA=; b=bCssyGOf2q87b28D6o/HkEP9UgXlk0Qgj/wDPeipmvusg5y/WkDaZ3cm7gDgFuqC/1 Oset93foowGThBU3Xav/nhS4yn4CGdVEpmWnt/ly5QO3vyvcmKhibR8l2tYtjKnbgzit 68uFoY4i02rYiN+j7pz6Ge5fVRbnaar1JWBFk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=date:from:to:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type:content-transfer-encoding; b=vyMRJwV7EMoIH1/mRyyB533V36XI+wJdeomuOtPSDFIeYnJ4O6KAAtqQCDb2lxEnEp oAgsk90DMMg6mANUOZdElfBgIxJKMJZuy6WA7caeXn7Ip8mWYXIWSxrtCUmE/0VmAYZi mJew7FhneVK9H9NN5iJ9Aaw7lM7bjR0y7h+ME= Received: by 10.204.6.215 with SMTP id a23mr531291bka.37.1298842360649; Sun, 27 Feb 2011 13:32:40 -0800 (PST) Received: from ubm.mine.nu (e181046079.adsl.alicedsl.de [85.181.46.79]) by mx.google.com with ESMTPS id b6sm2092268bkb.10.2011.02.27.13.32.38 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 27 Feb 2011 13:32:39 -0800 (PST) Date: Sun, 27 Feb 2011 22:32:37 +0100 From: Marc UBM Bocklet To: "freebsd-stable@freebsd.org" Message-Id: <20110227223237.83624b8c.ubm.freebsd@gmail.com> In-Reply-To: <20110224075517.GA18146@icarus.home.lan> References: <4D660909.6090202@my.gd> <20110224075517.GA18146@icarus.home.lan> X-Mailer: Sylpheed 3.0.3 (GTK+ 2.20.1; i386-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: ZFS - abysmal performance with samba since upgrade to 8.2-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: Sun, 27 Feb 2011 21:55:54 -0000 On Wed, 23 Feb 2011 23:55:17 -0800 Jeremy Chadwick wrote: > On Thu, Feb 24, 2011 at 08:30:17AM +0100, Damien Fleuriot wrote: > > Hello list, > > > > I've recently upgraded my home box from 8.2-PRE to 8.2-RELEASE and > > since then I've been experiencing *abysmal* performance with samba. > > > > We're talking transfer rates of say 50kbytes/s here, and I'm the > > only client on the box. [tuning tips] Wow, thanks a lot! :-) Those tips have finally stopped "chopiness" with our fileserver as well as giving consistent throughput with samba. Bye Marc -- Marc "UBM" Bocklet From owner-freebsd-stable@FreeBSD.ORG Mon Feb 28 09:11:02 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E0A87106564A for ; Mon, 28 Feb 2011 09:11:02 +0000 (UTC) (envelope-from Johan@double-l.nl) Received: from smtp-vbr1.xs4all.nl (smtp-vbr1.xs4all.nl [194.109.24.21]) by mx1.freebsd.org (Postfix) with ESMTP id 5532F8FC08 for ; Mon, 28 Feb 2011 09:11:01 +0000 (UTC) Received: from w2003s01.double-l.local (double-l.xs4all.nl [80.126.205.144]) by smtp-vbr1.xs4all.nl (8.13.8/8.13.8) with ESMTP id p1S8s959029129; Mon, 28 Feb 2011 09:54:10 +0100 (CET) (envelope-from Johan@double-l.nl) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 28 Feb 2011 09:54:09 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <57200BF94E69E54880C9BB1AF714BBCBDD318F@w2003s01.double-l.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 8.2-RELEASE - gmirror and gpart issue. Metadata overlap? Thread-Index: AcvV4VMJfEz+HZFETjm4osEy+epg0QBQjpVw References: <4D694336.3090203@yandex.ru> From: "Johan Hendriks" To: "Andrey V. Elsukov" X-Virus-Scanned: by XS4ALL Virus Scanner Cc: freebsd-stable@freebsd.org Subject: RE: 8.2-RELEASE - gmirror and gpart issue. Metadata overlap? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 28 Feb 2011 09:11:03 -0000 On 26.02.2011 15:26, Marin Atanasov Nikolov wrote: >> After a reboot I get this right before the FreeBSD bootloader starts: >>=20 >> gptboot: invalid GPT backup header >>=20 >> I suppose this error simply means that gpart can't find it's backup=20 >> header, because gmirror and gpart both are using the last sectors for >> a provider to write it's metadata. >This message is from gptboot. Loader does not know about your software mirror and it just checks GPT headers in the second and last LBA. >As i see now, there is inconsistency in the behavior between gptboot and GEOM_PART_GPT. >gptboot does reading of GPT backup header from the last LBA, but GEOM_PART_GPT from the alternate LBA which is not equal to last LBA in your case. >> Which would mean that gmirror and gpart metadata overlap, and that's=20 >> why I see this message? >No. >> Anyway, I can still boot from the primary GPT header, and here's the=20 >> second message I get during boot: >>=20 >> GEOM: ad0: secondary GPT header is not in the last LBA. >>=20 >> Why does GEOM reports ad0, and not mirror/gm0 as the provider? I've=20 >> used the gmirror'ed device for gpart, not ad0. >This is how GEOM tasting works. Do you have any problem except for those messages? What does not work? >Also when you are writing problem report about gpart it will be not bad to add output of `gpart show` or `gpart list` commands. >And `gmirror list` for GEOM_MIRROR. I opened a discussion on this before the release. http://lists.freebsd.org/pipermail/freebsd-stable/2011-January/061184.ht ml On my 8.1 system, i get this message about the corrupt headers, but it booted on the 8.2 system it panics... I think a lot of people are going to get bit by this. As far as i know there is no warning anywhere that you can not use gpart and gmirror the whole disk. I also get this answer: << Maybe the boot process was made to be more standard-compliant :) >>> That is not the way it should work, well we make the boot process more standard compliant, bad luck for those who thougt it worked. I also convert back to normal partitioning and gmirror. Regards Johan =20 From owner-freebsd-stable@FreeBSD.ORG Mon Feb 28 12:37:05 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5E6971065672 for ; Mon, 28 Feb 2011 12:37:05 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward1.mail.yandex.net (forward1.mail.yandex.net [77.88.46.6]) by mx1.freebsd.org (Postfix) with ESMTP id 0D60C8FC16 for ; Mon, 28 Feb 2011 12:37:04 +0000 (UTC) Received: from smtp4.mail.yandex.net (smtp4.mail.yandex.net [77.88.46.104]) by forward1.mail.yandex.net (Yandex) with ESMTP id 21DC31244273; Mon, 28 Feb 2011 15:37:03 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1298896623; bh=ExlEKuxBmUgbDO5XZYyJsUvZKjMBp4D3sULB9sikeM8=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type; b=L73ALILzgv0/ikYTBd136cvEFsQEFxo336JT2T6grkji6+4eryo80hDB0pZesY2DA /S+sdjz3KzdeU9cytkoOTAHxuqjbDFvhsiQUuHOZBX7ng//wVjHCBW6FjJwlgoLDpB XAW+0O9Qv9hu23F9H1q+pTp5gVNHKINTx3pp3/+I= Received: from [127.0.0.1] (ns.kirov.so-cdu.ru [77.72.136.145]) by smtp4.mail.yandex.net (Yandex) with ESMTPSA id CD7AC649802B; Mon, 28 Feb 2011 15:37:02 +0300 (MSK) Message-ID: <4D6B96E4.1050709@yandex.ru> Date: Mon, 28 Feb 2011 15:36:52 +0300 From: "Andrey V. Elsukov" User-Agent: Mozilla Thunderbird 1.5 (FreeBSD/20051231) MIME-Version: 1.0 To: Johan Hendriks References: <4D694336.3090203@yandex.ru> <57200BF94E69E54880C9BB1AF714BBCBDD318F@w2003s01.double-l.local> In-Reply-To: <57200BF94E69E54880C9BB1AF714BBCBDD318F@w2003s01.double-l.local> X-Enigmail-Version: 1.1.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig63ED331FCE5A1C1329EAC934" Cc: freebsd-stable@freebsd.org Subject: Re: 8.2-RELEASE - gmirror and gpart issue. Metadata overlap? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 28 Feb 2011 12:37:05 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig63ED331FCE5A1C1329EAC934 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable On 28.02.2011 11:54, Johan Hendriks wrote: > I opened a discussion on this before the release. > http://lists.freebsd.org/pipermail/freebsd-stable/2011-January/061184.h= t > ml > On my 8.1 system, i get this message about the corrupt headers, but it > booted on the 8.2 system it panics... >=20 > I think a lot of people are going to get bit by this. >=20 > As far as i know there is no warning anywhere that you can not use gpar= t > and gmirror the whole disk. So, my guess is when all is properly configured all should work as expect= ed. You should get some non-fatal messages, but not a kernel panic. I'll try to get some free machines to test, but it will be no so fast. --=20 WBR, Andrey V. Elsukov --------------enig63ED331FCE5A1C1329EAC934 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) iQEcBAEBAgAGBQJNa5brAAoJEAHF6gQQyKF6inwH/0x7kQvuGjPpC8jIIvjs9E8X 39yPTT7KQdz0e+0kB2Z9mrk+UBHoZOIsfJlho0AvqUCcEpz39BBP8Tso+7tFUxnF MqJ1KNBucqDLG28TwtXrvPoeeFfkLn6xeY+IH7ysAhWlPF3x7jaHKxxAoqaqj6/6 Q/8rI0JuVTwFBE4dzjeM0E7lN82haR/OGq7yMZIpG0pGkr3mGRHjxk8XeyPAhEPh El8ADicb+yjTvfPPqDGnGFKzOihj4NOr2VnzE7BYC0xL2WWMSgmw3wSYiyn0zTKD 8L2yUsgcB7wLL+Qhs0FepsXkpaUCR1aePhZyWf0O1Wi7ksJpbJWGg6lsTECuIJU= =WXPd -----END PGP SIGNATURE----- --------------enig63ED331FCE5A1C1329EAC934-- From owner-freebsd-stable@FreeBSD.ORG Mon Feb 28 16:23:12 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3B778106566B for ; Mon, 28 Feb 2011 16:23:12 +0000 (UTC) (envelope-from dnaeon@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 C28738FC12 for ; Mon, 28 Feb 2011 16:23:11 +0000 (UTC) Received: by wyb32 with SMTP id 32so4495669wyb.13 for ; Mon, 28 Feb 2011 08:23:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=FTHqEwM2cernxjIxwmGbiGzV8H8PQ0Dcn/OsGd7r7lw=; b=h8kd3i4APiHwxzNLcU9UlFh5av+1q5EouwVSxlcneJHIqa6T9PCFE0fiNrDb68FrvZ w+2chzU3a+L/kU6p6Dj1+CnSqigZ2jymVX5yTSSw9fs5ECgY345ZeK+4fdyG07MdzdqY 0IxTdE/WXU71Leu63VH+cj80UEKGkTrJtZSkM= 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=ZdN312lMDxJFHuIopRSLQFwcRXPSyvi1RLnBpqDvWAeoUeCkJGytgSVE3ZdYQ1eRU1 2PtPzZFNufyhpzRW77k8eF6RbUY0DoCjJXDa8F/ORNmR2Fd39aD69l7VQKn6sltyJuJv bvFDZPG+OcygYw0T6u9FdCDPHad7GosAouS+w= MIME-Version: 1.0 Received: by 10.227.2.83 with SMTP id 19mr5139978wbi.115.1298910190598; Mon, 28 Feb 2011 08:23:10 -0800 (PST) Received: by 10.227.72.213 with HTTP; Mon, 28 Feb 2011 08:23:10 -0800 (PST) In-Reply-To: <4D6B96E4.1050709@yandex.ru> References: <4D694336.3090203@yandex.ru> <57200BF94E69E54880C9BB1AF714BBCBDD318F@w2003s01.double-l.local> <4D6B96E4.1050709@yandex.ru> Date: Mon, 28 Feb 2011 18:23:10 +0200 Message-ID: From: Marin Atanasov Nikolov To: "Andrey V. Elsukov" Content-Type: text/plain; charset=ISO-8859-1 Cc: Johan Hendriks , freebsd-stable@freebsd.org Subject: Re: 8.2-RELEASE - gmirror and gpart issue. Metadata overlap? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 28 Feb 2011 16:23:12 -0000 2011/2/28 Andrey V. Elsukov : > On 28.02.2011 11:54, Johan Hendriks wrote: >> I opened a discussion on this before the release. >> http://lists.freebsd.org/pipermail/freebsd-stable/2011-January/061184.ht >> ml >> On my 8.1 system, i get this message about the corrupt headers, but it >> booted on the 8.2 system it panics... >> >> I think a lot of people are going to get bit by this. >> >> As far as i know there is no warning anywhere that you can not use gpart >> and gmirror the whole disk. > I can confirm as well that I get kernel panic if I gpart and then gmirror a disk on 8.2-RELEASE. To reproduce it, I just did the following: 1) Boot a system with a Fixit image 2) Remove all gpart partitions 3) gpart the first disk (ad0) 4) Restored my data to the partitions from backups 5) Reboot 6) gmirror the ad0 disk And that's where I got kernel panic. gpart'ing the disk and the mirroring the partitions works just as fine, but not when you mirror the whole disk. Regards, Marin > So, my guess is when all is properly configured all should work as expected. > You should get some non-fatal messages, but not a kernel panic. > I'll try to get some free machines to test, but it will be no so fast. > > -- > WBR, Andrey V. Elsukov > > -- Marin Atanasov Nikolov dnaeon AT gmail DOT com daemon AT unix-heaven DOT org http://www.unix-heaven.org/ From owner-freebsd-stable@FreeBSD.ORG Mon Feb 28 16:55:14 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 439051065677 for ; Mon, 28 Feb 2011 16:55:14 +0000 (UTC) (envelope-from cliftonr@oz.volcano.org) Received: from hrndva-omtalb.mail.rr.com (hrndva-omtalb.mail.rr.com [71.74.56.124]) by mx1.freebsd.org (Postfix) with ESMTP id 656DE8FC20 for ; Mon, 28 Feb 2011 16:55:08 +0000 (UTC) X-Authority-Analysis: v=1.1 cv=3uSaImBeuprzHBlOOPjkqgu+7PcxSRW0m2Aphm9Zmck= c=1 sm=0 a=6R0BXTaMqiEA:10 a=kj9zAlcOel0A:10 a=G5OLwwqwWgs+1dCEPNHTSw==:17 a=6I5d2MoRAAAA:8 a=jb__rZ8GAAAA:8 a=H9iEQFZ8AAAA:8 a=FYktocSE-NT4r9RigYoA:9 a=rgTvh_llIcvb31861CUA:7 a=mr_pZeCKQL0A9u4xJPQsBY15CncA:4 a=CjuIK1q_8ugA:10 a=sHp_62vNEjwA:10 a=fZFZujrNNEQA:10 a=G5OLwwqwWgs+1dCEPNHTSw==:117 X-Cloudmark-Score: 0 X-Originating-IP: 75.80.196.236 Received: from [75.80.196.236] ([75.80.196.236:43830] helo=oz.volcano.org) by hrndva-oedge04.mail.rr.com (envelope-from ) (ecelerity 2.2.3.46 r()) with ESMTP id 15/16-04612-B63DB6D4; Mon, 28 Feb 2011 16:55:08 +0000 Received: by oz.volcano.org (Postfix, from userid 1001) id CD80F50824; Mon, 28 Feb 2011 06:55:06 -1000 (HST) Date: Mon, 28 Feb 2011 06:55:06 -1000 From: Clifton Royston To: Marin Atanasov Nikolov Message-ID: <20110228165506.GA61412@lava.net> Mail-Followup-To: Marin Atanasov Nikolov , "Andrey V. Elsukov" , Johan Hendriks , freebsd-stable@freebsd.org References: <4D694336.3090203@yandex.ru> <57200BF94E69E54880C9BB1AF714BBCBDD318F@w2003s01.double-l.local> <4D6B96E4.1050709@yandex.ru> 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: "Andrey V. Elsukov" , freebsd-stable@freebsd.org, Johan Hendriks Subject: Re: 8.2-RELEASE - gmirror and gpart issue. Metadata overlap? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 28 Feb 2011 16:55:14 -0000 On Mon, Feb 28, 2011 at 06:23:10PM +0200, Marin Atanasov Nikolov wrote: > 2011/2/28 Andrey V. Elsukov : > > On 28.02.2011 11:54, Johan Hendriks wrote: > >> I opened a discussion on this before the release. > >> http://lists.freebsd.org/pipermail/freebsd-stable/2011-January/061184.ht > >> ml > >> On my 8.1 system, i get this message about the corrupt headers, but it > >> booted on the 8.2 system it panics... > >> > >> I think a lot of people are going to get bit by this. > >> > >> As far as i know there is no warning anywhere that you can not use gpart > >> and gmirror the whole disk. > > > > I can confirm as well that I get kernel panic if I gpart and then > gmirror a disk on 8.2-RELEASE. > > To reproduce it, I just did the following: > > 1) Boot a system with a Fixit image > 2) Remove all gpart partitions > 3) gpart the first disk (ad0) > 4) Restored my data to the partitions from backups > 5) Reboot > 6) gmirror the ad0 disk > > And that's where I got kernel panic. > > gpart'ing the disk and the mirroring the partitions works just as > fine, but not when you mirror the whole disk. I think this only ever worked accidentally at best. It would work fine with the older fdisk-style disk partition because that doesn't touch the end of the disk, but any time you tell two different programs that they both have absolute control over the last sector on the disk and can write critical data there - which is what this is doing - that's begging for trouble. Something cleaner than a kernel panic would be *nice* however... And your point about warnings in the documentation is a good one. -- Clifton -- Clifton Royston -- cliftonr@iandicomputing.com / cliftonr@lava.net President - I and I Computing * http://www.iandicomputing.com/ Custom programming, network design, systems and network consulting services From owner-freebsd-stable@FreeBSD.ORG Mon Feb 28 16:55:42 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5741C1065781 for ; Mon, 28 Feb 2011 16:55:42 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-yi0-f54.google.com (mail-yi0-f54.google.com [209.85.218.54]) by mx1.freebsd.org (Postfix) with ESMTP id 0BB448FC14 for ; Mon, 28 Feb 2011 16:55:41 +0000 (UTC) Received: by yie12 with SMTP id 12so836068yie.13 for ; Mon, 28 Feb 2011 08:55:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ySKw/TnXmsPGrMDnvNb4MUmykMJ/nbYNsmAobmP4MHk=; b=vNmPAm28n1NWPq/iS2PIzCXkVkVfI3XyKbTq/XQ+0llm0+VG/fqmZB5MBk6v7MS050 GgwkIGe8hfL7xMR6qNJfEJxyUP+Cgf/9bpCqYraTg5qtKuarBgcDp6pfOMp8rrHMbIjv 0yaiMlNnS+m5X4y9tamA4vdxVvdGFLsz0bc/U= 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=fm/Nxpz5BxY74k+X37ZSaFr9AZOiWbfb+Ji9vNEf/R5BvXpU/4BKiE2srqhhk2Y/KG Z2TkiFdKptjF/lqQPbavqW9OuUDHyicN9OnNbGQMoN8o6VsUOp0CfGsd/rhxDYT7uf50 37tOMciXFYkx2ZcUOEtC5YVZJ3x8mPkxwNd6I= MIME-Version: 1.0 Received: by 10.91.81.13 with SMTP id i13mr7737646agl.118.1298912141037; Mon, 28 Feb 2011 08:55:41 -0800 (PST) Received: by 10.100.171.8 with HTTP; Mon, 28 Feb 2011 08:55:40 -0800 (PST) In-Reply-To: References: <4D694336.3090203@yandex.ru> <57200BF94E69E54880C9BB1AF714BBCBDD318F@w2003s01.double-l.local> <4D6B96E4.1050709@yandex.ru> Date: Mon, 28 Feb 2011 08:55:40 -0800 Message-ID: From: Freddie Cash To: Marin Atanasov Nikolov Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "Andrey V. Elsukov" , freebsd-stable@freebsd.org, Johan Hendriks Subject: Re: 8.2-RELEASE - gmirror and gpart issue. Metadata overlap? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 28 Feb 2011 16:55:42 -0000 On Mon, Feb 28, 2011 at 8:23 AM, Marin Atanasov Nikolov wrote: > 2011/2/28 Andrey V. Elsukov : >> On 28.02.2011 11:54, Johan Hendriks wrote: >>> I opened a discussion on this before the release. >>> http://lists.freebsd.org/pipermail/freebsd-stable/2011-January/061184.h= t >>> ml >>> On my 8.1 system, i get this message about the corrupt headers, but it >>> booted on the 8.2 system it panics... >>> >>> I think a lot of people are going to get bit by this. >>> >>> As far as i know there is no warning anywhere that you can not use gpar= t >>> and gmirror the whole disk. >> > > I can confirm as well that I get kernel panic =C2=A0if I gpart and then > gmirror a disk on 8.2-RELEASE. > > To reproduce it, I just did the following: > > 1) Boot a system with a Fixit image > 2) Remove all gpart partitions > 3) gpart the first disk (ad0) > 4) Restored my data to the partitions from backups > 5) Reboot > 6) gmirror the ad0 disk The above process is operator error, as both your gpart and gmirror commands are working on the same GEOM (ad0). You need to stack / layer your GEOMs (ie, do one operation on the disk, the other operations on the sub-parts). Either: 1) gmirror the disk (ad0), and then gpart the mirror device (/dev/mirror/whatever), or 2) gpart the disk (ad0), and the mirror the partititons (/dev/gpt/whatev= er) The process you list above is the same as partitioning a disk (ad0), and then newfs-ing the disk (ad0), and wondering where your partitions went. :) (I believe option 1 above is what's causing issues in this thread.) --=20 Freddie Cash fjwcash@gmail.com From owner-freebsd-stable@FreeBSD.ORG Mon Feb 28 17:07:23 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7E839106566C for ; Mon, 28 Feb 2011 17:07:23 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward20.mail.yandex.net (forward20.mail.yandex.net [95.108.253.145]) by mx1.freebsd.org (Postfix) with ESMTP id 1D9008FC0C for ; Mon, 28 Feb 2011 17:07:22 +0000 (UTC) Received: from smtp17.mail.yandex.net (smtp17.mail.yandex.net [95.108.252.17]) by forward20.mail.yandex.net (Yandex) with ESMTP id 36587104141F; Mon, 28 Feb 2011 20:07:21 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1298912841; bh=NcKviOccw97f7vknz6mnF0Zp7ImX45sJWNvgBKGrwXU=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type; b=KXKi6DwPx7YskjDnDms8e/IW01ETTmklgRv5e1Og21kjDryD2oZ9IE1vB48vm/BHN vVrPyrzVPf66JHnGhSCowgrjmCIiDq1A9G3ntBre2tQo//X1t0SOVtz/e6g2p554Po nx2Mxzh1dudZ8tGu2912RRum0UUOB64il+NQAD8k= Received: from smtp17.mail.yandex.net (localhost [127.0.0.1]) by smtp17.mail.yandex.net (Yandex) with ESMTP id 22F7E1900527; Mon, 28 Feb 2011 20:07:21 +0300 (MSK) Received: from dynamic-178-141-6-53.kirov.comstar-r.ru (dynamic-178-141-6-53.kirov.comstar-r.ru [178.141.6.53]) by smtp17.mail.yandex.net (nwsmtp/Yandex) with ESMTP id 7KMqXfxu; Mon, 28 Feb 2011 20:07:20 +0300 Authentication-Results: smtp17.mail.yandex.net; spf=softfail (smtp17.mail.yandex.net: transitioning domain of yandex.ru does not designate 178.141.6.53 as permitted sender) smtp.mail=bu7cher@yandex.ru Message-ID: <4D6BD634.5070602@yandex.ru> Date: Mon, 28 Feb 2011 20:07:00 +0300 From: "Andrey V. Elsukov" User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.13) Gecko/20110122 Thunderbird/3.1.7 MIME-Version: 1.0 To: Marin Atanasov Nikolov References: <4D694336.3090203@yandex.ru> <57200BF94E69E54880C9BB1AF714BBCBDD318F@w2003s01.double-l.local> <4D6B96E4.1050709@yandex.ru> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig6B84CB77FA162F5745A10046" Cc: Johan Hendriks , freebsd-stable@freebsd.org Subject: Re: 8.2-RELEASE - gmirror and gpart issue. Metadata overlap? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 28 Feb 2011 17:07:23 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig6B84CB77FA162F5745A10046 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable On 28.02.2011 19:23, Marin Atanasov Nikolov wrote: > I can confirm as well that I get kernel panic if I gpart and then > gmirror a disk on 8.2-RELEASE. >=20 > To reproduce it, I just did the following: >=20 > 1) Boot a system with a Fixit image > 2) Remove all gpart partitions > 3) gpart the first disk (ad0) > 4) Restored my data to the partitions from backups > 5) Reboot > 6) gmirror the ad0 disk >=20 > And that's where I got kernel panic. >=20 > gpart'ing the disk and the mirroring the partitions works just as > fine, but not when you mirror the whole disk. What do you mean when you said 'gpart the first disk'? gpart(8) is the default tool to make any type of partitions and partition tables. The list of exact commands and at least a photo of screen with the panic message will be good. --=20 WBR, Andrey V. Elsukov --------------enig6B84CB77FA162F5745A10046 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iQEcBAEBAgAGBQJNa9Y4AAoJEAHF6gQQyKF6AwAH/RjJ4ERVzdlJWL213XQXjZJ4 FIZdj+aAuOOpQ4EdWbDCTWjKVOB5WTpuEbSIbqMu1zhtOHNZRvixxZH31KZ3WKPS LfF/0f84lhs+QVWqmbtqex4mMprNeAe9OSepPLaQXnHDh+XMhsz8UpEbEw2chxnA bf9oX0QZOwjrhLADYIXeMH2AttK3hToH/yIR/QwM67uOVG9tji93ELXY1kNXuo9/ lB6/5Qy6JaDxpq9emoNPMI5opVDEpcF44QqLFl8nim2hd3sFwe3bIsm3BFcXjWoc E7I2pn7tToNENsODF40Y40CCI2X7q4caXCwWh1qG6gbKCE05vsSZNP6TXP3hfMs= =6aK4 -----END PGP SIGNATURE----- --------------enig6B84CB77FA162F5745A10046-- From owner-freebsd-stable@FreeBSD.ORG Mon Feb 28 17:30:11 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5A4F31065670 for ; Mon, 28 Feb 2011 17:30:11 +0000 (UTC) (envelope-from stephen@missouri.edu) Received: from wilberforce.math.missouri.edu (wilberforce.math.missouri.edu [128.206.184.213]) by mx1.freebsd.org (Postfix) with ESMTP id EF8768FC14 for ; Mon, 28 Feb 2011 17:30:10 +0000 (UTC) Received: from [128.206.184.213] (wilberforce.math.missouri.edu [128.206.184.213]) by wilberforce.math.missouri.edu (8.14.4/8.14.4) with ESMTP id p1SHFdFK095832 for ; Mon, 28 Feb 2011 11:15:39 -0600 (CST) (envelope-from stephen@missouri.edu) Message-ID: <4D6BD83B.3040609@missouri.edu> Date: Mon, 28 Feb 2011 11:15:39 -0600 From: Stephen Montgomery-Smith User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.16) Gecko/20101225 SeaMonkey/2.0.11 MIME-Version: 1.0 To: FreeBSD Stable Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Change in behavior to stat(1) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 28 Feb 2011 17:30:11 -0000 I had a little script that would remove broken links. I used to do it like this: if ! stat -L $link > /dev/null; then rm $link; fi But recently (some time in February according to the CVS records) stat was changed so that stat -L would use lstat(2) if the link is broken. So I had to change it to if stat -L $link | awk '{print $3}' | grep l > /dev/null; then rm $link; fi but it is a lot less elegant. What is the proper accepted way to remove broken links? Stephen From owner-freebsd-stable@FreeBSD.ORG Mon Feb 28 17:31:24 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F36B1106567A for ; Mon, 28 Feb 2011 17:31:23 +0000 (UTC) (envelope-from dnaeon@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 8519C8FC20 for ; Mon, 28 Feb 2011 17:31:23 +0000 (UTC) Received: by wyb32 with SMTP id 32so4578062wyb.13 for ; Mon, 28 Feb 2011 09:31:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=vZrRhv6F6r0pGk1REoWxYHokRJm0hulQpvTI4g9B9jo=; b=w6a478CNcHpw7YvkjIl+6nNIuo1zGolFmfmsqUlzLdBAztYJEE4h7Qx3IngyA8QPXg Y0b21Mi/tkLhvFt45uh9ZeU4/5NGd8nWHbKTypJqFfX55TR1clFGOH/ytKz+hLO1gTxY g7itGkbUBBwxeXlvqQw8w0Hby4PCaRFsw1LNc= 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=aVROs/JgCJ2dvNnGSCP3Vx/AGDYmdxxXHIraFiVVFj9Jnzj1Wt0NCv4HXD3TUZf9/c Di1rzYs4hK31fVBmQjACXN+15BcX8htTij0PErjlN1h0JDqat3YyeR3fOm5N5VtaTHSP 2VyoI5jsMNMmED9XJxUYeIR/ebzE5CBXFULLM= MIME-Version: 1.0 Received: by 10.227.154.74 with SMTP id n10mr5145208wbw.116.1298914282394; Mon, 28 Feb 2011 09:31:22 -0800 (PST) Received: by 10.227.72.213 with HTTP; Mon, 28 Feb 2011 09:31:22 -0800 (PST) In-Reply-To: <4D6BD634.5070602@yandex.ru> References: <4D694336.3090203@yandex.ru> <57200BF94E69E54880C9BB1AF714BBCBDD318F@w2003s01.double-l.local> <4D6B96E4.1050709@yandex.ru> <4D6BD634.5070602@yandex.ru> Date: Mon, 28 Feb 2011 19:31:22 +0200 Message-ID: From: Marin Atanasov Nikolov To: "Andrey V. Elsukov" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Johan Hendriks , freebsd-stable@freebsd.org Subject: Re: 8.2-RELEASE - gmirror and gpart issue. Metadata overlap? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 28 Feb 2011 17:31:24 -0000 @Johan Hendriks > As far as i know there is no warning anywhere that you can not use gpart > and gmirror the whole disk. Well, there is actually :) >From gpart(8): NOTE: The GEOM class PART can detect the same partition table on diffe= r- ent GEOM providers and some of them will marked as corrupt. Be careful when choising a provider for recovering. If you did incorrect choise y= ou can destroy metadata of another GEOM class, e.g. GEOM MIRROR or GEOM LABEL. @Cliffton Royston > I think this only ever worked accidentally at best. It would work > fine with the older fdisk-style disk partition because that doesn't > touch the end of the disk, but any time you tell two different programs > that they both have absolute control over the last sector on the disk > and can write critical data there - which is what this is doing - > that's begging for trouble. I think I've tried this with bsdlabel(8) and gmirror(8) some time ago, and didn't have any issues, but that of course should be because bsdlabel does not touch the last sectors, so gmirror would work. @Freddie Cash > The above process is operator error, as both your gpart and gmirror > commands are working on the same GEOM (ad0). You need to stack / > layer your GEOMs (ie, do one operation on the disk, the other > operations on the sub-parts). You are right. Typo mistake I made in my previous mail :) What you describe is what I actually did. gmirror'ed the disk, and then gpart'ed it. See my very first mail, for exact steps I made to do this. @Andrey V. Elsukov > What do you mean when you said 'gpart the first disk'? > gpart(8) is the default tool to make any type of partitions and > partition tables. The list of exact commands and at least a photo of > screen with the panic message will be good. Please check my first mail for all the details. I'm currently running the system with mirrored partitions, instead of disks= . I'll setup a test system as well in the following days and give you all the details of the steps, commands and output of them.. screenshot will be made as well :) Regards, Marin 2011/2/28 Andrey V. Elsukov : > On 28.02.2011 19:23, Marin Atanasov Nikolov wrote: >> I can confirm as well that I get kernel panic =A0if I gpart and then >> gmirror a disk on 8.2-RELEASE. >> >> To reproduce it, I just did the following: >> >> 1) Boot a system with a Fixit image >> 2) Remove all gpart partitions >> 3) gpart the first disk (ad0) >> 4) Restored my data to the partitions from backups >> 5) Reboot >> 6) gmirror the ad0 disk >> >> And that's where I got kernel panic. >> >> gpart'ing the disk and the mirroring the partitions works just as >> fine, but not when you mirror the whole disk. > > What do you mean when you said 'gpart the first disk'? > gpart(8) is the default tool to make any type of partitions and > partition tables. The list of exact commands and at least a photo of > screen with the panic message will be good. > > -- > WBR, Andrey V. Elsukov > > --=20 Marin Atanasov Nikolov dnaeon AT gmail DOT com daemon AT unix-heaven DOT org http://www.unix-heaven.org/ From owner-freebsd-stable@FreeBSD.ORG Mon Feb 28 17:34:10 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 99B8F1065672; Mon, 28 Feb 2011 17:34:10 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: cb@severious.net Date: Mon, 28 Feb 2011 12:33:44 -0500 User-Agent: KMail/1.6.2 References: <4D6888A8.20505@severious.net> In-Reply-To: <4D6888A8.20505@severious.net> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201102281233.58810.jkim@FreeBSD.org> Cc: freebsd-stable@freebsd.org Subject: Re: FreeBSD 8.1 regression in x86bios.c X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 28 Feb 2011 17:34:10 -0000 On Friday 25 February 2011 11:59 pm, Craig Boston wrote: > Hi all, > > My laptop (Toshiba Portege R100) stopped working with an early boot > hang at some point between 8.0 and 8.1. After it broke last year I > had ended up just reverting to an earlier kernel, but finally found > the time to do a binary search and narrow it down. > > The offending commit is: > http://svn.freebsd.org/viewvc/base?view=revision&revision=205647 > > > Fix stupid typos. Some VESA BIOSes directly call BIOS interrupt > handlers within the VBE interrupt handler. Unfortunately it was > causing real mode page faults because we were fetching instructions > from bogus addresses. Pass me the pointyhat, please. > > PR: kern/144654 > MFC after: 3 days > > With this commit in place, the system hangs almost immediately on > boot, right after probing kdbmux. With debug.x86bios.{call,int} > enabled from the loader, the final lines before the hang are: > > avail memory = 1299705856 (1239 MB) > kbd1 at kbdmux0 > Calling int 0x10 (ax=0x4f00 bx=0x0000 cx=0x0000 dx=0x0000 es=0x9e00 > di=0x0000) > Exiting int 0x10 (ax=0x004f bx=0x0000 cx=0x0000 dx=0x0000 es=0x9e00 > di=0x0000) > Calling int 0x10 (ax=0x4f01 bx=0x0000 cx=0x0144 dx=0x0000 es=0x0200 > di=0x0000) > > Then a hard hang. With the 2 lines in x86bios.c reverted, the > system boots fine (even on a fresh 8.2 build with just that commit > backed out). The debug output from a successful boot looks like > this: > > kbd1 at kbdmux0 > Calling int 0x10 (ax=0x4f00 bx=0x0000 cx=0x0000 dx=0x0000 es=0x9e00 > di=0x0000) > Exiting int 0x10 (ax=0x004f bx=0x0000 cx=0x0000 dx=0x0000 es=0x9e00 > di=0x0000) > Calling int 0x10 (ax=0x4f01 bx=0x0000 cx=0x0144 dx=0x0000 es=0x0200 > di=0x0000) > Exiting int 0x10 (ax=0xb13e bx=0x2065 cx=0x9e32 dx=0x1023 es=0x0200 > di=0x0028) > Calling int 0x10 (ax=0x4f01 bx=0x0000 cx=0x0143 dx=0x0000 es=0x9c00 > di=0x0000) > Exiting int 0x10 (ax=0xb13e bx=0x1065 cx=0x9e32 dx=0x1023 es=0x9c00 > di=0x0028) > Calling int 0x10 (ax=0x4f01 bx=0x0000 cx=0x0141 dx=0x0000 es=0x0200 > di=0x0000) > Exiting int 0x10 (ax=0xb13e bx=0x0865 cx=0x9e32 dx=0x1023 es=0x0200 > di=0x0028) > (many more lines) > > In any event, I'm not sure if this is a true bug, or just a broken > BIOS, but either way I thought you might want to know about it. See the exit status of the "working" cases. Bogus status (%ax == 0xb13e) was returned, which means the VBE calls failed and aborted. So, yes, I guess it is one of those broken VESA BIOSes. :-( Jung-uk Kim From owner-freebsd-stable@FreeBSD.ORG Mon Feb 28 17:50:44 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4E787106566B for ; Mon, 28 Feb 2011 17:50:44 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward20.mail.yandex.net (forward20.mail.yandex.net [95.108.253.145]) by mx1.freebsd.org (Postfix) with ESMTP id B8BF58FC08 for ; Mon, 28 Feb 2011 17:50:43 +0000 (UTC) Received: from smtp17.mail.yandex.net (smtp17.mail.yandex.net [95.108.252.17]) by forward20.mail.yandex.net (Yandex) with ESMTP id 661BA10415F4; Mon, 28 Feb 2011 20:50:42 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1298915442; bh=LwZ/8sM4WcgTRkuTrpyRmtdyjN7dhr4vhzuycK3xu0Y=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type; b=ZmUkLzM6AUm5TrF5jik4LASw6hFNWSZ0SKSeLTEp3ag2O70gHYK6PzpXRO8c7Z3Ai 3xlO9T20uloTo8KfYxN7B33x7oSstXwHdlm4w9aAnVSnpxdWlFgPcjTjFu0qNXQ/in E22YZjXxgsl5K0mgrI7yMbcnZWrgAD/ypvIJlNH8= Received: from smtp17.mail.yandex.net (localhost [127.0.0.1]) by smtp17.mail.yandex.net (Yandex) with ESMTP id 58FB01900521; Mon, 28 Feb 2011 20:50:42 +0300 (MSK) Received: from dynamic-178-141-6-53.kirov.comstar-r.ru (dynamic-178-141-6-53.kirov.comstar-r.ru [178.141.6.53]) by smtp17.mail.yandex.net (nwsmtp/Yandex) with ESMTP id ogMqWuvU; Mon, 28 Feb 2011 20:50:42 +0300 Authentication-Results: smtp17.mail.yandex.net; spf=softfail (smtp17.mail.yandex.net: transitioning domain of yandex.ru does not designate 178.141.6.53 as permitted sender) smtp.mail=bu7cher@yandex.ru Message-ID: <4D6BE061.6090102@yandex.ru> Date: Mon, 28 Feb 2011 20:50:25 +0300 From: "Andrey V. Elsukov" User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.13) Gecko/20110122 Thunderbird/3.1.7 MIME-Version: 1.0 To: Joan Picanyol i Puig References: <4D694336.3090203@yandex.ru> <57200BF94E69E54880C9BB1AF714BBCBDD318F@w2003s01.double-l.local> <4D6B96E4.1050709@yandex.ru> <20110228142317.GC70900@grummit.biaix.org> In-Reply-To: <20110228142317.GC70900@grummit.biaix.org> X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig9CC9412A8FDE2A68645AB8EF" Cc: freebsd-stable@freebsd.org Subject: Re: 8.2-RELEASE - gmirror and gpart issue. Metadata overlap? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 28 Feb 2011 17:50:44 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig9CC9412A8FDE2A68645AB8EF Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable On 28.02.2011 17:23, Joan Picanyol i Puig wrote: > http://lists.freebsd.org/pipermail/freebsd-geom/2010-July/004278.html >=20 > 1. glabeled discs > 2. two of this previous discs are gmirrored > 3. this mirror is gparted=20 >=20 > We got distracted by side issues, but I believe this issue is still > present, even though I have been unable to investigate further (it migh= t > well be that GPT specification is incompatible with gmirror'ed disks). > For your convinience the interesting bits from that thread are: >=20 > GEOM: da1: the secondary GPT table is corrupt or invalid. > GEOM: da1: using the primary only -- recovery suggested. >=20 > So, what explains the messages? gpart probes the disk before gmirro= r > (or at least it prints later on dmesg), but since the offset is in > the header, it should not even know about the gmirror + glabel part= =2E When you create gmirror on the whole disk you have got: whole disk da0 +----------------------------------------+----+ | mirror/gm0 | MD | +----------------------------------------+----+ MD - gmirror's metadata in the last sector of da0. Now when you create GPT on the mirror/gm0: mirror/gm0 +-+-----+--------------------------+-----+ | | GPT | | GPT | +-+-----+--------------------------+-----+ When mirror/gm0 provider is tasted all is good. You got mirror with GPT without any warnings. But when da0 provider is tasted you got this: da0 +-+-----+--------------------------+-----+----+ | | GPT | | GPT | | +-+-----+--------------------------+-----+----+ This provider has one sector in the end of the disk with unknown data, but there should be secondary GPT header. First of you got a message from gptboot about corrupt GPT. The second message is from GEOM_PART that it does not like that secondary GPT located not in the end of disk. This message > GEOM: da1: the secondary GPT table is corrupt or invalid. > GEOM: da1: using the primary only -- recovery suggested. does mean that your secondary GPT header or table is lost, or it is in disagree with primary one. AFAIR, it may mean different things in 8.1 and 8.2. --=20 WBR, Andrey V. Elsukov --------------enig9CC9412A8FDE2A68645AB8EF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iQEcBAEBAgAGBQJNa+BhAAoJEAHF6gQQyKF6evsH/0sDvE2P0P4sgjuGOZDZro6j UJ0TSdUXP5M1G1LQWTtuCcQE9j4/MJosPRowfRUqwkX4OxWSwqgrFf8FNhDQgf4D 05MFSKRg50SAa62Lv5muYB/BvPIJTRHDSyhzPtwv/rX2J0Yf7rd0EKIBs+yOnaG7 QfoAc9+DRYo+uNtuAED6k7Cpj9GUESluV1YXXqbOxpgMT/lz/GJNHghiISUTS2vX c7aMiYcxXuHaz6g6x+M9IXyrVuZaL7bLiX9+RzSRKYy5XQtFhdvEpXovmdov9Tn8 gB8zYKLyY/iXoE1hoiAfIvIaKapBavHWplRviCNsTy+ZmwrGK1ox+y/U6UMQsqQ= =mYnI -----END PGP SIGNATURE----- --------------enig9CC9412A8FDE2A68645AB8EF-- From owner-freebsd-stable@FreeBSD.ORG Mon Feb 28 19:36:28 2011 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 2C822106566B; Mon, 28 Feb 2011 19:36:25 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-stable@FreeBSD.org Date: Mon, 28 Feb 2011 14:36:05 -0500 User-Agent: KMail/1.6.2 References: <4D6888A8.20505@severious.net> <201102281233.58810.jkim@FreeBSD.org> In-Reply-To: <201102281233.58810.jkim@FreeBSD.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: Multipart/Mixed; boundary="Boundary-00=_pk/aN156ePK4xTq" Message-Id: <201102281436.09812.jkim@FreeBSD.org> Cc: cb@severious.net Subject: Re: FreeBSD 8.1 regression in x86bios.c X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 28 Feb 2011 19:36:28 -0000 --Boundary-00=_pk/aN156ePK4xTq Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline On Monday 28 February 2011 12:33 pm, Jung-uk Kim wrote: > On Friday 25 February 2011 11:59 pm, Craig Boston wrote: > > Hi all, > > > > My laptop (Toshiba Portege R100) stopped working with an early > > boot hang at some point between 8.0 and 8.1. After it broke last > > year I had ended up just reverting to an earlier kernel, but > > finally found the time to do a binary search and narrow it down. > > > > The offending commit is: > > http://svn.freebsd.org/viewvc/base?view=revision&revision=205647 > > >> > > > > Fix stupid typos. Some VESA BIOSes directly call BIOS interrupt > > handlers within the VBE interrupt handler. Unfortunately it was > > causing real mode page faults because we were fetching > > instructions from bogus addresses. Pass me the pointyhat, please. > > > > PR: kern/144654 > > MFC after: 3 days > > > > With this commit in place, the system hangs almost immediately on > > boot, right after probing kdbmux. With debug.x86bios.{call,int} > > enabled from the loader, the final lines before the hang are: > > > > avail memory = 1299705856 (1239 MB) > > kbd1 at kbdmux0 > > Calling int 0x10 (ax=0x4f00 bx=0x0000 cx=0x0000 dx=0x0000 > > es=0x9e00 di=0x0000) > > Exiting int 0x10 (ax=0x004f bx=0x0000 cx=0x0000 dx=0x0000 > > es=0x9e00 di=0x0000) > > Calling int 0x10 (ax=0x4f01 bx=0x0000 cx=0x0144 dx=0x0000 > > es=0x0200 di=0x0000) > > > > Then a hard hang. With the 2 lines in x86bios.c reverted, the > > system boots fine (even on a fresh 8.2 build with just that > > commit backed out). The debug output from a successful boot looks > > like this: > > > > kbd1 at kbdmux0 > > Calling int 0x10 (ax=0x4f00 bx=0x0000 cx=0x0000 dx=0x0000 > > es=0x9e00 di=0x0000) > > Exiting int 0x10 (ax=0x004f bx=0x0000 cx=0x0000 dx=0x0000 > > es=0x9e00 di=0x0000) > > Calling int 0x10 (ax=0x4f01 bx=0x0000 cx=0x0144 dx=0x0000 > > es=0x0200 di=0x0000) > > Exiting int 0x10 (ax=0xb13e bx=0x2065 cx=0x9e32 dx=0x1023 > > es=0x0200 di=0x0028) > > Calling int 0x10 (ax=0x4f01 bx=0x0000 cx=0x0143 dx=0x0000 > > es=0x9c00 di=0x0000) > > Exiting int 0x10 (ax=0xb13e bx=0x1065 cx=0x9e32 dx=0x1023 > > es=0x9c00 di=0x0028) > > Calling int 0x10 (ax=0x4f01 bx=0x0000 cx=0x0141 dx=0x0000 > > es=0x0200 di=0x0000) > > Exiting int 0x10 (ax=0xb13e bx=0x0865 cx=0x9e32 dx=0x1023 > > es=0x0200 di=0x0028) > > (many more lines) > > > > In any event, I'm not sure if this is a true bug, or just a > > broken BIOS, but either way I thought you might want to know > > about it. > > See the exit status of the "working" cases. Bogus status (%ax == > 0xb13e) was returned, which means the VBE calls failed and aborted. > So, yes, I guess it is one of those broken VESA BIOSes. :-( Please try the attached patch and let me know if it makes any difference. Thanks, Jung-uk Kim --Boundary-00=_pk/aN156ePK4xTq Content-Type: text/plain; charset="iso-8859-1"; name="x86bios.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="x86bios.diff" Index: sys/compat/x86bios/x86bios.c =================================================================== --- sys/compat/x86bios/x86bios.c (revision 219101) +++ sys/compat/x86bios/x86bios.c (working copy) @@ -291,25 +291,6 @@ x86bios_emu_outl(struct x86emu *emu, uint16_t port outl(port, val); } -static void -x86bios_emu_get_intr(struct x86emu *emu, int intno) -{ - uint16_t *sp; - uint32_t iv; - - emu->x86.R_SP -= 6; - - sp = (uint16_t *)((vm_offset_t)x86bios_seg + emu->x86.R_SP); - sp[0] = htole16(emu->x86.R_IP); - sp[1] = htole16(emu->x86.R_CS); - sp[2] = htole16(emu->x86.R_FLG); - - iv = x86bios_get_intr(intno); - emu->x86.R_IP = iv & 0xffff; - emu->x86.R_CS = (iv >> 16) & 0xffff; - emu->x86.R_FLG &= ~(F_IF | F_TF); -} - void * x86bios_alloc(uint32_t *offset, size_t size) { @@ -567,7 +548,6 @@ x86bios_unmap_mem(void) static void x86bios_init(void *arg __unused) { - int i; mtx_init(&x86bios_lock, "x86bios lock", NULL, MTX_SPIN); @@ -598,9 +578,6 @@ x86bios_init(void *arg __unused) x86bios_emu.emu_outb = x86bios_emu_outb; x86bios_emu.emu_outw = x86bios_emu_outw; x86bios_emu.emu_outl = x86bios_emu_outl; - - for (i = 0; i < 256; i++) - x86bios_emu._x86emu_intrTab[i] = x86bios_emu_get_intr; } static void --Boundary-00=_pk/aN156ePK4xTq-- From owner-freebsd-stable@FreeBSD.ORG Mon Feb 28 20:16:37 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 32891106566B for ; Mon, 28 Feb 2011 20:16:37 +0000 (UTC) (envelope-from bartosz.stec@it4pro.pl) Received: from mainframe.kkip.pl (kkip.pl [87.105.164.78]) by mx1.freebsd.org (Postfix) with ESMTP id 8B5768FC08 for ; Mon, 28 Feb 2011 20:16:36 +0000 (UTC) Received: from static-78-8-144-74.ssp.dialog.net.pl ([78.8.144.74] helo=[192.168.0.2]) by mainframe.kkip.pl with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.73 (FreeBSD)) (envelope-from ) id 1Pu9W5-000P5U-Mn; Mon, 28 Feb 2011 21:16:34 +0100 Message-ID: <4D6C0297.5020402@it4pro.pl> Date: Mon, 28 Feb 2011 21:16:23 +0100 From: Bartosz Stec Organization: IT4Pro User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; pl; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Jeremy Chadwick References: <4D660909.6090202@my.gd> <20110224075517.GA18146@icarus.home.lan> In-Reply-To: <20110224075517.GA18146@icarus.home.lan> X-Authenticated-User: bartosz.stec@it4pro.pl X-Authenticator: plain X-Sender-Verify: SUCCEEDED (sender exists & accepts mail) X-Spam-Score: -8.1 X-Spam-Score-Int: -80 X-Exim-Version: 4.73 (build at 10-Jan-2011 16:29:01) X-Date: 2011-02-28 21:16:34 X-Connected-IP: 78.8.144.74:53901 X-Message-Linecount: 499 X-Body-Linecount: 485 X-Message-Size: 17375 X-Body-Size: 16687 X-Received-Count: 1 X-Recipient-Count: 2 X-Local-Recipient-Count: 2 X-Local-Recipient-Defer-Count: 0 X-Local-Recipient-Fail-Count: 0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "freebsd-stable@freebsd.org" Subject: Re: ZFS - abysmal performance with samba since upgrade to 8.2-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: Mon, 28 Feb 2011 20:16:37 -0000 W dniu 2011-02-24 08:55, Jeremy Chadwick pisze: > (...snip...) > Samba > ======================= > Rebuild the port (ports/net/samba35) with AIO_SUPPORT enabled. To use > AIO you will need to load the aio.ko kernel module (kldload aio) first. > > Relevant smb.conf tunings: > > [global] > socket options = TCP_NODELAY SO_SNDBUF=131072 SO_RCVBUF=131072 > use sendfile = no > min receivefile size = 16384 > aio read size = 16384 > aio write size = 16384 > aio write behind = yes > > > > ZFS pools > ======================= > pool: backups > state: ONLINE > scrub: none requested > config: > > NAME STATE READ WRITE CKSUM > backups ONLINE 0 0 0 > ada2 ONLINE 0 0 0 > > errors: No known data errors > > pool: data > state: ONLINE > scrub: none requested > config: > > NAME STATE READ WRITE CKSUM > data ONLINE 0 0 0 > ada1 ONLINE 0 0 0 > > errors: No known data errors > > > > ZFS tunings > ======================= > Your tunings here are "wild" (meaning all over the place). Your use > of vfs.zfs.txg.synctime="1" is probably hurting you quite badly, in > addition to your choice to enable prefetching (every ZFS FreeBSD system > I've used has benefit tremendously from having prefetching disabled, > even on systems with 8GB RAM and more). You do not need to specify > vm.kmem_size_max, so please remove that. Keeping vm.kmem_size is fine. > Also get rid of your vdev tunings, I'm not sure why you have those. > > My relevant /boot/loader.conf tunings for 8.2-RELEASE (note to readers: > the version of FreeBSD you're running, and build date, matters greatly > here so do not just blindly apply these without thinking first): > > # We use Samba built with AIO support; we need this module! > aio_load="yes" > > # Increase vm.kmem_size to allow for ZFS ARC to utilise more memory. > vm.kmem_size="8192M" > vfs.zfs.arc_max="6144M" > > # Disable ZFS prefetching > # http://southbrain.com/south/2008/04/the-nightmare-comes-slowly-zfs.html > # Increases overall speed of ZFS, but when disk flushing/writes occur, > # system is less responsive (due to extreme disk I/O). > # NOTE: Systems with 8GB of RAM or more have prefetch enabled by > # default. > vfs.zfs.prefetch_disable="1" > > # Decrease ZFS txg timeout value from 30 (default) to 5 seconds. This > # should increase throughput and decrease the "bursty" stalls that > # happen during immense I/O with ZFS. > # http://lists.freebsd.org/pipermail/freebsd-fs/2009-December/007343.html > # http://lists.freebsd.org/pipermail/freebsd-fs/2009-December/007355.html > vfs.zfs.txg.timeout="5" > > > > sysctl tunings > ======================= > Please note that the below kern.maxvnodes tuning is based on my system > usage, and yours may vary, so you can remove or comment out this option > if you wish. The same goes for vfs.ufs.dirhash_maxmem. As for > vfs.zfs.txg.write_limit_override, I strongly suggest you keep this > commented out for starters; it effectively "rate limits" ZFS I/O, and > this smooths out overall performance (otherwise I was seeing what > appeared to be incredible network transfer speed, then the system would > churn hard for quite some time on physical I/O, then fast network speed, > physical I/O, etc... very "bursty", which I didn't want). > > # Increase send/receive buffer maximums from 256KB to 16MB. > # FreeBSD 7.x and later will auto-tune the size, but only up to the max. > net.inet.tcp.sendbuf_max=16777216 > net.inet.tcp.recvbuf_max=16777216 > > # Double send/receive TCP datagram memory allocation. This defines the > # amount of memory taken up by default *per socket*. > net.inet.tcp.sendspace=65536 > net.inet.tcp.recvspace=131072 > > # dirhash_maxmem defaults to 2097152 (2048KB). dirhash_mem has reached > # this limit a few times, so we should increase dirhash_maxmem to > # something like 16MB (16384*1024). > vfs.ufs.dirhash_maxmem=16777216 > > # > # ZFS tuning parameters > # NOTE: Be sure to see /boot/loader.conf for additional tunings > # > > # Increase number of vnodes; we've seen vfs.numvnodes reach 115,000 > # at times. Default max is a little over 200,000. Playing it safe... > kern.maxvnodes=250000 > > # Set TXG write limit to a lower threshold. This helps "level out" > # the throughput rate (see "zpool iostat"). A value of 256MB works well > # for systems with 4GB of RAM, while 1GB works well for us w/ 8GB on > # disks which have 64MB cache. > vfs.zfs.txg.write_limit_override=1073741824 > > > > Good luck. > Jeremy, you're just invaluable! :) In short - I applied tips suggested above (only difference was vfs.zfs.txg.write_limit_override set to 128MB, and sendfile, which I still have enabled) and it's first time _ever_ I see samba performing so fast on FreeBSD (on 100Mb link)! long story: I'm using old, crappy, low memory desktop PC as home router/test server/(very little) storage: FreeBSD 9.0-CURRENT #2 r219090: Mon Feb 28 03:06:13 CET 2011 CPU: mobile AMD Athlon(tm) XP 2200+ (1800.10-MHz 686-class CPU) real memory = 1610612736 (1536 MB) avail memory = 1562238976 (1489 MB) ad0: 39205MB at ata0-master UDMA133 ad1: 38166MB at ata0-slave UDMA100 ad2: 39205MB at ata1-master UDMA133 xl0: <3Com 3c905B-TX Fast Etherlink XL> It's ZFS only (just updated to v28) system in RAIDZ1 configuration, attached to cheap belkin 100Mb switch used for home network. From couple of months I experienced pathetic SMB transfer - from 20kB/s to 200kB/s. Especially when system was idle, because the most funny thing about that - transfer was much better when system was busy (csup or make world for instance). SMB throughput jumped to 2-4MB/s then (well, from time to time at least). I've been using following settings and tunings while I was experiencing this issue: smb.conf: [global] socket options = TCP_NODELAY SO_SNDBUF=65536 SO_RCVBUF=65536 use sendfile = yes min receivefile size = 16384 aio read size = 16384 aio write size = 16384 aio write behind = true loader.conf: vm.kmem_size="1536M" vm.kmem_size_max="1536M" vfs.zfs.arc_max="1024M" aio_load="YES" sysctl.conf: kern.ipc.maxsockbuf=2097152 net.inet.tcp.recvspace=262144 net.inet.tcp.recvspace=262144 net.inet.tcp.mssdflt=1452 net.inet.udp.recvspace=65535 net.inet.udp.maxdgram=65535 net.local.stream.recvspace=65535 net.local.stream.sendspace=65535 After applying tunables from Jeremy my configs looks like this: smb.conf: [global] socket options = TCP_NODELAY SO_SNDBUF=131072 SO_RCVBUF=131072 use sendfile = yes min receivefile size = 16384 aio read size = 16384 aio write size = 16384 aio write behind = yes loader.conf: vm.kmem_size="1536M" vm.kmem_size_max="1536M" vfs.zfs.arc_max="1024M" vfs.zfs.txg.timeout="5" aio_load="YES" sysctl.conf: net.inet.tcp.sendbuf_max=16777216 net.inet.tcp.recvbuf_max=16777216 net.inet.tcp.sendspace=65536 net.inet.tcp.recvspace=131072 vfs.ufs.dirhash_maxmem=16777216 kern.maxvnodes=250000 vfs.zfs.txg.write_limit_override=134217728 Test: copying 1GB file both sides. Results: stable 8MB/s both sides! Thank you very much! -- Bartosz Stec From owner-freebsd-stable@FreeBSD.ORG Mon Feb 28 20:56:18 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 50A4E1065670 for ; Mon, 28 Feb 2011 20:56:18 +0000 (UTC) (envelope-from john.r.davis.jr@gmail.com) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by mx1.freebsd.org (Postfix) with ESMTP id E4FE88FC18 for ; Mon, 28 Feb 2011 20:56:17 +0000 (UTC) Received: by gwaa18 with SMTP id a18so3980786gwa.17 for ; Mon, 28 Feb 2011 12:56:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type; bh=QCNHiVseEtf+cu1XzHgrR/ZLtmzqVMwGQpB03WSDq1o=; b=TRb45s5gZ/wBmWg/PpoNOO9Ni2IjOeJD5D6M8gGBT0GVJG8z0UD+TMgixL0KH0EBLA MS36rAb/Ycg9OPEvBW7sybUhS0DJNaykTaJ21zUhn2knvvt+UKRt4/wtFhSkSeeCPiQX q0yjJac0hQiLVZtpAgIhs5L3Eup/Qw4f0CTfE= 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=ddbsBdohlRcXGhHzi0EyDpgkXDJWJs655eKb1c0bjHd+mt0DILggaT8ADV5MBdJYN/ /SBob0q+qWsB8uu4oTGj0OP4ztAN7C/xC4L+GMGyU6aTDElPCf2RCDGk89TbvkNeUhcZ vyL9uBNGktYmwook++3Y9VJ7Bb4lrzx/kyc48= Received: by 10.91.33.32 with SMTP id l32mr8024493agj.196.1298926577184; Mon, 28 Feb 2011 12:56:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.91.50.33 with HTTP; Mon, 28 Feb 2011 12:55:57 -0800 (PST) In-Reply-To: References: From: John Davis Date: Mon, 28 Feb 2011 15:55:57 -0500 Message-ID: To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Possible dri issue on the Kernel side X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 28 Feb 2011 20:56:18 -0000 I am an avid Linux user and recent BSD convert. I have a Lenovo Thinkpad L412 with an Intel i3 370M & ATI HD 5145(rebadged HD4570) graphics. I recently tried Fedora 14 and had the same problem that I have had with PC-BSD, the underside of the laptop got HOT! When I was running on the radeon driver it was ridiculously hot, then when i switched to the catalyst it was managable. I found out that the following link worked in Fedora 14: http://forums.fedoraforum.org/showthread.php?t=155503. In PC-BSD I was using the radeon driver with DynamicPM, Clockgating, and ForceLowPowerMode all on and it was still hot. After careful consideration and diagnosis, with thanks to Dru and Martin, we believe that this might be a dri problem on the kernel side, possibly linked to the Intel Core i3. I am willing to do testing for you on PC-BSD 8.2 if you would like to help everyone. Let me know what I can do to help! Thought I would list the repo link: http://download1.rpmfusion.org/nonfree/fedora/updates/testing/14/i386/repoview/index.html * pciconf -lv:* hostb0@pci0:0:0:0: class=0x060000 card=0x218317aa chip=0x00448086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' class = bridge subclass = HOST-PCI pcib1@pci0:0:1:0: class=0x060400 card=0x218417aa chip=0x00458086 rev=0x02 hdr=0x01 vendor = 'Intel Corporation' class = bridge subclass = PCI-PCI none0@pci0:0:22:0: class=0x078000 card=0x215f17aa chip=0x3b648086 rev=0x06 hdr=0x00 vendor = 'Intel Corporation' class = simple comms ehci0@pci0:0:26:0: class=0x0c0320 card=0x216317aa chip=0x3b3c8086 rev=0x06 hdr=0x00 vendor = 'Intel Corporation' class = serial bus subclass = USB hdac0@pci0:0:27:0: class=0x040300 card=0x215e17aa chip=0x3b568086 rev=0x06 hdr=0x00 vendor = 'Intel Corporation' class = multimedia subclass = HDA pcib2@pci0:0:28:0: class=0x060400 card=0x216417aa chip=0x3b428086 rev=0x06 hdr=0x01 vendor = 'Intel Corporation' class = bridge subclass = PCI-PCI pcib3@pci0:0:28:1: class=0x060400 card=0x216417aa chip=0x3b448086 rev=0x06 hdr=0x01 vendor = 'Intel Corporation' class = bridge subclass = PCI-PCI pcib4@pci0:0:28:2: class=0x060400 card=0x216417aa chip=0x3b468086 rev=0x06 hdr=0x01 vendor = 'Intel Corporation' class = bridge subclass = PCI-PCI pcib5@pci0:0:28:3: class=0x060400 card=0x216417aa chip=0x3b488086 rev=0x06 hdr=0x01 vendor = 'Intel Corporation' class = bridge subclass = PCI-PCI pcib6@pci0:0:28:4: class=0x060400 card=0x216417aa chip=0x3b4a8086 rev=0x06 hdr=0x01 vendor = 'Intel Corporation' class = bridge subclass = PCI-PCI pcib7@pci0:0:28:5: class=0x060400 card=0x216417aa chip=0x3b4c8086 rev=0x06 hdr=0x01 vendor = 'Intel Corporation' class = bridge subclass = PCI-PCI ehci1@pci0:0:29:0: class=0x0c0320 card=0x216317aa chip=0x3b348086 rev=0x06 hdr=0x00 vendor = 'Intel Corporation' class = serial bus subclass = USB pcib8@pci0:0:30:0: class=0x060401 card=0x216517aa chip=0x24488086 rev=0xa6 hdr=0x01 vendor = 'Intel Corporation' device = '82801 Family (ICH2/3/4/5/6/7/8/9-M) Hub Interface to PCI Bridge' class = bridge subclass = PCI-PCI isab0@pci0:0:31:0: class=0x060100 card=0x216617aa chip=0x3b098086 rev=0x06 hdr=0x00 vendor = 'Intel Corporation' class = bridge subclass = PCI-ISA ahci0@pci0:0:31:2: class=0x010601 card=0x216817aa chip=0x3b298086 rev=0x06 hdr=0x00 vendor = 'Intel Corporation' device = 'IBEX AHCI Controller(4Port)' class = mass storage subclass = SATA none1@pci0:0:31:3: class=0x0c0500 card=0x216717aa chip=0x3b308086 rev=0x06 hdr=0x00 vendor = 'Intel Corporation' class = serial bus subclass = SMBus vgapci0@pci0:1:0:0: class=0x030000 card=0x21bb17aa chip=0x95531002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' device = 'ATI Mobility Radeon HD 4570 Series (M92)' class = display subclass = VGA hdac1@pci0:1:0:1: class=0x040300 card=0x21bb17aa chip=0xaa381002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' class = multimedia subclass = HDA none2@pci0:2:0:0: class=0x088000 card=0x212e17aa chip=0x2382197b rev=0x00 hdr=0x00 vendor = 'JMicron Technology Corp.' device = 'JMB38X SD/MMC Host Controller (JMB38X)' class = base peripheral sdhci0@pci0:2:0:2: class=0x080501 card=0x212d17aa chip=0x2381197b rev=0x00 hdr=0x00 vendor = 'JMicron Technology Corp.' class = base peripheral subclass = SD host controller none3@pci0:2:0:3: class=0x088000 card=0x212f17aa chip=0x2383197b rev=0x00 hdr=0x00 vendor = 'JMicron Technology Corp.' device = 'JMB38X MS Host Controller (JMB38X)' class = base peripheral none4@pci0:2:0:4: class=0x088000 card=0x213017aa chip=0x2384197b rev=0x00 hdr=0x00 vendor = 'JMicron Technology Corp.' device = 'JMB38X xD Host Controller (JMB38X)' class = base peripheral none5@pci0:3:0:0: class=0x028000 card=0xe02010ec chip=0x817210ec rev=0x10 hdr=0x00 vendor = 'Realtek Semiconductor' device = 'Realtek RTL8191SE wireless LAN 802.11N PCI-E NIC (RTL8191SE ?)' class = network re0@pci0:4:0:0: class=0x020000 card=0x213117aa chip=0x816810ec rev=0x03 hdr=0x00 vendor = 'Realtek Semiconductor' device = 'Gigabit Ethernet NIC(NDIS 6.0) (RTL8168/8111/8111c)' class = network subclass = ethernet hostb1@pci0:255:0:0: class=0x060000 card=0x219617aa chip=0x2c628086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' class = bridge subclass = HOST-PCI hostb2@pci0:255:0:1: class=0x060000 card=0x219617aa chip=0x2d018086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' class = bridge subclass = HOST-PCI hostb3@pci0:255:2:0: class=0x060000 card=0x219617aa chip=0x2d108086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' class = bridge subclass = HOST-PCI hostb4@pci0:255:2:1: class=0x060000 card=0x219617aa chip=0x2d118086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' class = bridge subclass = HOST-PCI hostb5@pci0:255:2:2: class=0x060000 card=0x219617aa chip=0x2d128086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' class = bridge subclass = HOST-PCI hostb6@pci0:255:2:3: class=0x060000 card=0x219617aa chip=0x2d138086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' class = bridge subclass = HOST-PCI *dmesg:* Copyright (c) 1992-2011 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.2-RELEASE #7: Wed Feb 16 12:19:08 PST 2011 root@build8x32.pcbsd.org:/usr/obj/usr/local_storage/pcbsd-build82/fbsd-source/8.2/sys/PCBSD i386 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM) i3 CPU M 370 @ 2.40GHz (2394.01-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x20655 Family = 6 Model = 25 Stepping = 5 Features=0xbfebfbff Features2=0x9ae3bd AMD Features=0x28100000 AMD Features2=0x1 TSC: P-state invariant real memory = 4294967296 (4096 MB) avail memory = 3129618432 (2984 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) x 2 SMT threads cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 4 cpu3 (AP): APIC ID: 5 ioapic0 irqs 0-23 on motherboard Cuse4BSD v0.1.13 @ /dev/cuse kbd1 at kbdmux0 cryptosoft0: on motherboard acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 cpu0: on acpi0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 acpi_ec0: port 0x62,0x66 on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 16 at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0x2000-0x20ff mem 0xd0000000-0xdfffffff,0xcfef0000-0xcfefffff irq 16 at device 0.0 on pci1 pci1: at device 0.1 (no driver attached) pci0: at device 22.0 (no driver attached) ehci0: mem 0xf0806000-0xf08063ff irq 16 at device 26.0 on pci0 ehci0: [ITHREAD] usbus0: EHCI version 1.0 usbus0: on ehci0 pci0: at device 27.0 (no driver attached) pcib2: irq 16 at device 28.0 on pci0 pci2: on pcib2 pci2: at device 0.0 (no driver attached) sdhci0: mem 0xf0301000-0xf03010ff irq 16 at device 0.2 on pci2 sdhci0: 1 slot(s) allocated sdhci0: [ITHREAD] pci2: at device 0.3 (no driver attached) pci2: at device 0.4 (no driver attached) pcib3: irq 17 at device 28.1 on pci0 pci3: on pcib3 pci3: at device 0.0 (no driver attached) pcib4: irq 18 at device 28.2 on pci0 pci4: on pcib4 re0: port 0x4000-0x40ff mem 0xf0204000-0xf0204fff,0xf0200000-0xf0203fff irq 18 at device 0.0 on pci4 re0: Using 1 MSI messages re0: Chip rev. 0x28000000 re0: MAC rev. 0x00000000 miibus0: on re0 rgephy0: PHY 1 on miibus0 rgephy0: 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow re0: Ethernet address: c8:0a:a9:a5:e4:48 re0: [FILTER] pcib5: irq 19 at device 28.3 on pci0 pci5: on pcib5 pcib6: irq 16 at device 28.4 on pci0 pci8: on pcib6 pcib7: irq 17 at device 28.5 on pci0 pci9: on pcib7 ehci1: mem 0xf0807000-0xf08073ff irq 23 at device 29.0 on pci0 ehci1: [ITHREAD] usbus1: EHCI version 1.0 usbus1: on ehci1 pcib8: at device 30.0 on pci0 pci12: on pcib8 isab0: at device 31.0 on pci0 isa0: on isab0 ahci0: port 0x1830-0x1837,0x1824-0x1827,0x1828-0x182f,0x1820-0x1823,0x1800-0x181f mem 0xf0808000-0xf08087ff irq 19 at device 31.2 on pci0 ahci0: [ITHREAD] ahci0: AHCI v1.30 with 4 3Gbps ports, Port Multiplier not supported ahcich0: at channel 0 on ahci0 ahcich0: [ITHREAD] ahcich1: at channel 1 on ahci0 ahcich1: [ITHREAD] ahcich2: at channel 4 on ahci0 ahcich2: [ITHREAD] ahcich3: at channel 5 on ahci0 ahcich3: [ITHREAD] pci0: at device 31.3 (no driver attached) pcib9: on acpi0 pci255: on pcib9 acpi_acad0: on acpi0 battery0: on acpi0 acpi_lid0: on acpi0 acpi_button0: on acpi0 acpi_button1: on acpi0 acpi_tz0: on acpi0 acpi_hpet0: iomem 0xfed00000-0xfed003ff irq 0,8 on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900 atrtc0: port 0x70-0x77 on acpi0 atrtc0: Warning: Couldn't map I/O. atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: flags 0x1000 irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model Generic PS/2 mouse, device ID 0 pmtimer0 on isa0 orm0: at iomem 0xc0000-0xcf7ff,0xcf800-0xd07ff pnpid ORM0000 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ata0 at port 0x1f0-0x1f7,0x3f6 irq 14 on isa0 ata0: [ITHREAD] ata1 at port 0x170-0x177,0x376 irq 15 on isa0 ata1: [ITHREAD] ppc0: parallel port not found. est0: on cpu0 p4tcc0: on cpu0 est1: on cpu1 p4tcc1: on cpu1 est2: on cpu2 p4tcc2: on cpu2 est3: on cpu3 p4tcc3: on cpu3 ZFS NOTICE: Prefetch is disabled by default on i386 -- to enable, add "vfs.zfs.prefetch_disable=0" to /boot/loader.conf. ZFS WARNING: Recommended minimum kmem_size is 512MB; expect unstable behavior. Consider tuning vm.kmem_size and vm.kmem_size_max in /boot/loader.conf. ZFS filesystem version 4 ZFS storage pool version 15 Timecounters tick every 1.000 msec usbus0: 480Mbps High Speed USB v2.0 usbus1: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ATA-8 SATA 2.x device ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 305245MB (625142448 512 byte sectors: 16H 63S/T 16383C) cd0 at ahcich1 bus 0 scbus1 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 150.000MB/s transfers (SATA 1.x, UDMA5, ATAPI 12bytes, PIO 8192bytes) cd0: Attempt to query device size failed: NOT READY, Medium not present - tray closed SMP: AP CPU #1 Launched! SMP: AP CPU #3 Launched! SMP: AP CPU #2 Launched! Root mount waiting for: usbus1 usbus0 uhub0: 3 ports with 3 removable, self powered uhub1: 3 ports with 3 removable, self powered Root mount waiting for: usbus1 usbus0 ugen0.2: at usbus0 uhub2: on usbus0 ugen1.2: at usbus1 uhub3: on usbus1 uhub2: 6 ports with 6 removable, self powered Root mount waiting for: usbus1 uhub3: 8 ports with 8 removable, self powered Trying to mount root from ufs:/dev/label/rootfs0 hdac0: mem 0xf0800000-0xf0803fff irq 22 at device 27.0 on pci0 hdac0: HDA Driver Revision: 20100226_0142 hdac0: [ITHREAD] hdac0: HDA Codec #0: Realtek ALC269 hdac1: mem 0xcfeec000-0xcfeeffff irq 17 at device 0.1 on pci1 hdac1: HDA Driver Revision: 20100226_0142 hdac1: [ITHREAD] hdac1: HDA Codec #0: ATI R6xx HDMI pcm0: at cad 0 nid 1 on hdac0 pcm1: at cad 0 nid 1 on hdac0 pcm2: at cad 0 nid 1 on hdac1 drm0: on vgapci0 info: [drm] MSI enabled 1 message(s) vgapci0: child drm0 requested pci_enable_busmaster info: [drm] Initialized radeon 1.31.0 20080613 info: [drm] Setting GART location based on new memory map info: [drm] Loading RV710 Microcode info: [drm] Resetting GPU info: [drm] writeback test succeeded in 1 usecs drm0: [ITHREAD] * uname -a:* FreeBSD spartan 8.2-RELEASE FreeBSD 8.2-RELEASE #7: Wed Feb 16 12:19:08 PST 2011 root@build8x32.pcbsd.org:/usr/obj/usr/local_storage/pcbsd-build82/fbsd-source/8.2/sys/PCBSD i386 -- John R Davis Jr From owner-freebsd-stable@FreeBSD.ORG Mon Feb 28 21:01:30 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 775D8106566B for ; Mon, 28 Feb 2011 21:01:30 +0000 (UTC) (envelope-from john.r.davis.jr@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 2A99C8FC13 for ; Mon, 28 Feb 2011 21:01:29 +0000 (UTC) Received: by gxk7 with SMTP id 7so1965703gxk.13 for ; Mon, 28 Feb 2011 13:01:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:from:date:message-id:subject:to :content-type; bh=1fTgRgJ8qhsXLlbT6cqfjq/sdULDIT7xETtYhmQbEAc=; b=MQG1x5THuSoozeUeOsEnSRhkRPtOw8b3rKRhtf7QbxDBQr1WpxDJy7n/6+unuUUWhe kd5CBhzqRMpc4VAl+zbJxnrn9yU0S4p0DSrJ5L+n/Qws7IAKps74iqPwnZx88frkFsXC gNC6O9Yj5RIbtyAtIhhU9ZViCVqxwy+ZcXrwk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; b=uLh6QnUfWorq6qqMcQdwvVV29GFv/PZ1GmyIYvZzYQwL4xYMvL1SMQsVEclDtpOrjP yvcvuwlV590EcTkKWvrEbOq6h/4sVaxjqmyruofmm+9q1W1GaIoN1/RvBwlLp28ggbSx rCuliWhiFBPkptjrrknoMZLEhNUXHIZut5ano= Received: by 10.90.29.18 with SMTP id c18mr8052199agc.142.1298926888122; Mon, 28 Feb 2011 13:01:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.91.50.33 with HTTP; Mon, 28 Feb 2011 13:01:08 -0800 (PST) From: John Davis Date: Mon, 28 Feb 2011 16:01:08 -0500 Message-ID: To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Possible dri kernel 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: Mon, 28 Feb 2011 21:01:30 -0000 To whom it may concern: I am an avid Linux user and recent BSD convert. I have a Lenovo Thinkpad L412 with an Intel i3 370M & ATI HD 5145(rebadged HD4570) graphics. I recently tried Fedora 14 and had the same problem that I have had with PC-BSD, the underside of the laptop got HOT! When I was running on the radeon driver it was ridiculously hot, then when i switched to the catalyst it was managable. I found out that the following link worked in Fedora 14: http://forums.fedoraforum.org/showthread.php?t=155503. In PC-BSD I was using the radeon driver with DynamicPM, Clockgating, and ForceLowPowerMode all on and it was still hot. After careful consideration and diagnosis, with thanks to Dru and Martin, we believe that this might be a dri problem on the kernel side, possibly linked to the Intel Core i3. I am willing to do testing for you on PC-BSD 8.2 if you would like to help everyone. Let me know what I can do to help! Thought I would list the repo link: http://download1.rpmfusion.org/nonfree/fedora/updates/testing/14/i386/repoview/index.html BEFORE SENDING FINISH THIS! pciconf -lv: hostb0@pci0:0:0:0: class=0x060000 card=0x218317aa chip=0x00448086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' class = bridge subclass = HOST-PCI pcib1@pci0:0:1:0: class=0x060400 card=0x218417aa chip=0x00458086 rev=0x02 hdr=0x01 vendor = 'Intel Corporation' class = bridge subclass = PCI-PCI none0@pci0:0:22:0: class=0x078000 card=0x215f17aa chip=0x3b648086 rev=0x06 hdr=0x00 vendor = 'Intel Corporation' class = simple comms ehci0@pci0:0:26:0: class=0x0c0320 card=0x216317aa chip=0x3b3c8086 rev=0x06 hdr=0x00 vendor = 'Intel Corporation' class = serial bus subclass = USB hdac0@pci0:0:27:0: class=0x040300 card=0x215e17aa chip=0x3b568086 rev=0x06 hdr=0x00 vendor = 'Intel Corporation' class = multimedia subclass = HDA pcib2@pci0:0:28:0: class=0x060400 card=0x216417aa chip=0x3b428086 rev=0x06 hdr=0x01 vendor = 'Intel Corporation' class = bridge subclass = PCI-PCI pcib3@pci0:0:28:1: class=0x060400 card=0x216417aa chip=0x3b448086 rev=0x06 hdr=0x01 vendor = 'Intel Corporation' class = bridge subclass = PCI-PCI pcib4@pci0:0:28:2: class=0x060400 card=0x216417aa chip=0x3b468086 rev=0x06 hdr=0x01 vendor = 'Intel Corporation' class = bridge subclass = PCI-PCI pcib5@pci0:0:28:3: class=0x060400 card=0x216417aa chip=0x3b488086 rev=0x06 hdr=0x01 vendor = 'Intel Corporation' class = bridge subclass = PCI-PCI pcib6@pci0:0:28:4: class=0x060400 card=0x216417aa chip=0x3b4a8086 rev=0x06 hdr=0x01 vendor = 'Intel Corporation' class = bridge subclass = PCI-PCI pcib7@pci0:0:28:5: class=0x060400 card=0x216417aa chip=0x3b4c8086 rev=0x06 hdr=0x01 vendor = 'Intel Corporation' class = bridge subclass = PCI-PCI ehci1@pci0:0:29:0: class=0x0c0320 card=0x216317aa chip=0x3b348086 rev=0x06 hdr=0x00 vendor = 'Intel Corporation' class = serial bus subclass = USB pcib8@pci0:0:30:0: class=0x060401 card=0x216517aa chip=0x24488086 rev=0xa6 hdr=0x01 vendor = 'Intel Corporation' device = '82801 Family (ICH2/3/4/5/6/7/8/9-M) Hub Interface to PCI Bridge' class = bridge subclass = PCI-PCI isab0@pci0:0:31:0: class=0x060100 card=0x216617aa chip=0x3b098086 rev=0x06 hdr=0x00 vendor = 'Intel Corporation' class = bridge subclass = PCI-ISA ahci0@pci0:0:31:2: class=0x010601 card=0x216817aa chip=0x3b298086 rev=0x06 hdr=0x00 vendor = 'Intel Corporation' device = 'IBEX AHCI Controller(4Port)' class = mass storage subclass = SATA none1@pci0:0:31:3: class=0x0c0500 card=0x216717aa chip=0x3b308086 rev=0x06 hdr=0x00 vendor = 'Intel Corporation' class = serial bus subclass = SMBus vgapci0@pci0:1:0:0: class=0x030000 card=0x21bb17aa chip=0x95531002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' device = 'ATI Mobility Radeon HD 4570 Series (M92)' class = display subclass = VGA hdac1@pci0:1:0:1: class=0x040300 card=0x21bb17aa chip=0xaa381002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' class = multimedia subclass = HDA none2@pci0:2:0:0: class=0x088000 card=0x212e17aa chip=0x2382197b rev=0x00 hdr=0x00 vendor = 'JMicron Technology Corp.' device = 'JMB38X SD/MMC Host Controller (JMB38X)' class = base peripheral sdhci0@pci0:2:0:2: class=0x080501 card=0x212d17aa chip=0x2381197b rev=0x00 hdr=0x00 vendor = 'JMicron Technology Corp.' class = base peripheral subclass = SD host controller none3@pci0:2:0:3: class=0x088000 card=0x212f17aa chip=0x2383197b rev=0x00 hdr=0x00 vendor = 'JMicron Technology Corp.' device = 'JMB38X MS Host Controller (JMB38X)' class = base peripheral none4@pci0:2:0:4: class=0x088000 card=0x213017aa chip=0x2384197b rev=0x00 hdr=0x00 vendor = 'JMicron Technology Corp.' device = 'JMB38X xD Host Controller (JMB38X)' class = base peripheral none5@pci0:3:0:0: class=0x028000 card=0xe02010ec chip=0x817210ec rev=0x10 hdr=0x00 vendor = 'Realtek Semiconductor' device = 'Realtek RTL8191SE wireless LAN 802.11N PCI-E NIC (RTL8191SE ?)' class = network re0@pci0:4:0:0: class=0x020000 card=0x213117aa chip=0x816810ec rev=0x03 hdr=0x00 vendor = 'Realtek Semiconductor' device = 'Gigabit Ethernet NIC(NDIS 6.0) (RTL8168/8111/8111c)' class = network subclass = ethernet hostb1@pci0:255:0:0: class=0x060000 card=0x219617aa chip=0x2c628086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' class = bridge subclass = HOST-PCI hostb2@pci0:255:0:1: class=0x060000 card=0x219617aa chip=0x2d018086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' class = bridge subclass = HOST-PCI hostb3@pci0:255:2:0: class=0x060000 card=0x219617aa chip=0x2d108086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' class = bridge subclass = HOST-PCI hostb4@pci0:255:2:1: class=0x060000 card=0x219617aa chip=0x2d118086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' class = bridge subclass = HOST-PCI hostb5@pci0:255:2:2: class=0x060000 card=0x219617aa chip=0x2d128086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' class = bridge subclass = HOST-PCI hostb6@pci0:255:2:3: class=0x060000 card=0x219617aa chip=0x2d138086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' class = bridge subclass = HOST-PCI dmesg: Copyright (c) 1992-2011 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.2-RELEASE #7: Wed Feb 16 12:19:08 PST 2011 root@build8x32.pcbsd.org:/usr/obj/usr/local_storage/pcbsd-build82/fbsd-source/8.2/sys/PCBSD i386 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM) i3 CPU M 370 @ 2.40GHz (2394.01-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x20655 Family = 6 Model = 25 Stepping = 5 Features=0xbfebfbff Features2=0x9ae3bd AMD Features=0x28100000 AMD Features2=0x1 TSC: P-state invariant real memory = 4294967296 (4096 MB) avail memory = 3129618432 (2984 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) x 2 SMT threads cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 4 cpu3 (AP): APIC ID: 5 ioapic0 irqs 0-23 on motherboard Cuse4BSD v0.1.13 @ /dev/cuse kbd1 at kbdmux0 cryptosoft0: on motherboard acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 cpu0: on acpi0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 acpi_ec0: port 0x62,0x66 on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 16 at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0x2000-0x20ff mem 0xd0000000-0xdfffffff,0xcfef0000-0xcfefffff irq 16 at device 0.0 on pci1 pci1: at device 0.1 (no driver attached) pci0: at device 22.0 (no driver attached) ehci0: mem 0xf0806000-0xf08063ff irq 16 at device 26.0 on pci0 ehci0: [ITHREAD] usbus0: EHCI version 1.0 usbus0: on ehci0 pci0: at device 27.0 (no driver attached) pcib2: irq 16 at device 28.0 on pci0 pci2: on pcib2 pci2: at device 0.0 (no driver attached) sdhci0: mem 0xf0301000-0xf03010ff irq 16 at device 0.2 on pci2 sdhci0: 1 slot(s) allocated sdhci0: [ITHREAD] pci2: at device 0.3 (no driver attached) pci2: at device 0.4 (no driver attached) pcib3: irq 17 at device 28.1 on pci0 pci3: on pcib3 pci3: at device 0.0 (no driver attached) pcib4: irq 18 at device 28.2 on pci0 pci4: on pcib4 re0: port 0x4000-0x40ff mem 0xf0204000-0xf0204fff,0xf0200000-0xf0203fff irq 18 at device 0.0 on pci4 re0: Using 1 MSI messages re0: Chip rev. 0x28000000 re0: MAC rev. 0x00000000 miibus0: on re0 rgephy0: PHY 1 on miibus0 rgephy0: 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow re0: Ethernet address: c8:0a:a9:a5:e4:48 re0: [FILTER] pcib5: irq 19 at device 28.3 on pci0 pci5: on pcib5 pcib6: irq 16 at device 28.4 on pci0 pci8: on pcib6 pcib7: irq 17 at device 28.5 on pci0 pci9: on pcib7 ehci1: mem 0xf0807000-0xf08073ff irq 23 at device 29.0 on pci0 ehci1: [ITHREAD] usbus1: EHCI version 1.0 usbus1: on ehci1 pcib8: at device 30.0 on pci0 pci12: on pcib8 isab0: at device 31.0 on pci0 isa0: on isab0 ahci0: port 0x1830-0x1837,0x1824-0x1827,0x1828-0x182f,0x1820-0x1823,0x1800-0x181f mem 0xf0808000-0xf08087ff irq 19 at device 31.2 on pci0 ahci0: [ITHREAD] ahci0: AHCI v1.30 with 4 3Gbps ports, Port Multiplier not supported ahcich0: at channel 0 on ahci0 ahcich0: [ITHREAD] ahcich1: at channel 1 on ahci0 ahcich1: [ITHREAD] ahcich2: at channel 4 on ahci0 ahcich2: [ITHREAD] ahcich3: at channel 5 on ahci0 ahcich3: [ITHREAD] pci0: at device 31.3 (no driver attached) pcib9: on acpi0 pci255: on pcib9 acpi_acad0: on acpi0 battery0: on acpi0 acpi_lid0: on acpi0 acpi_button0: on acpi0 acpi_button1: on acpi0 acpi_tz0: on acpi0 acpi_hpet0: iomem 0xfed00000-0xfed003ff irq 0,8 on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900 atrtc0: port 0x70-0x77 on acpi0 atrtc0: Warning: Couldn't map I/O. atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: flags 0x1000 irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model Generic PS/2 mouse, device ID 0 pmtimer0 on isa0 orm0: at iomem 0xc0000-0xcf7ff,0xcf800-0xd07ff pnpid ORM0000 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ata0 at port 0x1f0-0x1f7,0x3f6 irq 14 on isa0 ata0: [ITHREAD] ata1 at port 0x170-0x177,0x376 irq 15 on isa0 ata1: [ITHREAD] ppc0: parallel port not found. est0: on cpu0 p4tcc0: on cpu0 est1: on cpu1 p4tcc1: on cpu1 est2: on cpu2 p4tcc2: on cpu2 est3: on cpu3 p4tcc3: on cpu3 ZFS NOTICE: Prefetch is disabled by default on i386 -- to enable, add "vfs.zfs.prefetch_disable=0" to /boot/loader.conf. ZFS WARNING: Recommended minimum kmem_size is 512MB; expect unstable behavior. Consider tuning vm.kmem_size and vm.kmem_size_max in /boot/loader.conf. ZFS filesystem version 4 ZFS storage pool version 15 Timecounters tick every 1.000 msec usbus0: 480Mbps High Speed USB v2.0 usbus1: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ATA-8 SATA 2.x device ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 305245MB (625142448 512 byte sectors: 16H 63S/T 16383C) cd0 at ahcich1 bus 0 scbus1 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 150.000MB/s transfers (SATA 1.x, UDMA5, ATAPI 12bytes, PIO 8192bytes) cd0: Attempt to query device size failed: NOT READY, Medium not present - tray closed SMP: AP CPU #1 Launched! SMP: AP CPU #3 Launched! SMP: AP CPU #2 Launched! Root mount waiting for: usbus1 usbus0 uhub0: 3 ports with 3 removable, self powered uhub1: 3 ports with 3 removable, self powered Root mount waiting for: usbus1 usbus0 ugen0.2: at usbus0 uhub2: on usbus0 ugen1.2: at usbus1 uhub3: on usbus1 uhub2: 6 ports with 6 removable, self powered Root mount waiting for: usbus1 uhub3: 8 ports with 8 removable, self powered Trying to mount root from ufs:/dev/label/rootfs0 hdac0: mem 0xf0800000-0xf0803fff irq 22 at device 27.0 on pci0 hdac0: HDA Driver Revision: 20100226_0142 hdac0: [ITHREAD] hdac0: HDA Codec #0: Realtek ALC269 hdac1: mem 0xcfeec000-0xcfeeffff irq 17 at device 0.1 on pci1 hdac1: HDA Driver Revision: 20100226_0142 hdac1: [ITHREAD] hdac1: HDA Codec #0: ATI R6xx HDMI pcm0: at cad 0 nid 1 on hdac0 pcm1: at cad 0 nid 1 on hdac0 pcm2: at cad 0 nid 1 on hdac1 drm0: on vgapci0 info: [drm] MSI enabled 1 message(s) vgapci0: child drm0 requested pci_enable_busmaster info: [drm] Initialized radeon 1.31.0 20080613 info: [drm] Setting GART location based on new memory map info: [drm] Loading RV710 Microcode info: [drm] Resetting GPU info: [drm] writeback test succeeded in 1 usecs drm0: [ITHREAD] uname -a: FreeBSD spartan 8.2-RELEASE FreeBSD 8.2-RELEASE #7: Wed Feb 16 12:19:08 PST 2011 root@build8x32.pcbsd.org:/usr/obj/usr/local_storage/pcbsd-build82/fbsd-source/8.2/sys/PCBSD i386 -- John R Davis Jr From owner-freebsd-stable@FreeBSD.ORG Mon Feb 28 22:39:27 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4AD9B106564A for ; Mon, 28 Feb 2011 22:39:27 +0000 (UTC) (envelope-from jhellenthal@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 F2E218FC0C for ; Mon, 28 Feb 2011 22:39:26 +0000 (UTC) Received: by vws16 with SMTP id 16so4187878vws.13 for ; Mon, 28 Feb 2011 14:39:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:date:from:to:cc:subject:in-reply-to :message-id:references:user-agent:x-openpgp-key-id :x-openpgp-key-fingerprint:mime-version:content-type; bh=N8SwOsBIZ0KE7VI1yacJwkApvzNIgnK0N1Q4zSZ8UUk=; b=hp/N/MJyIXmFXx5ifVgBPUtYukK4SAakYQODY5ZOeN3wzbiGpGIcl6TYhYjfow5jgL Z8a4Gkb8FRKMl50Z2q1gNseB5tcUAj5Fn2hnzam0GcuXxW3QZmfhsJloyt/kS3DovTUL nY//SvmgSDAEj2SQMgVurjnVppR9EWcV8vGrg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:x-openpgp-key-id:x-openpgp-key-fingerprint:mime-version :content-type; b=Y1BDuh2hrKmfG4ghMLSdI4pcpGKrnzwywKOxSh04qqSbKBkpC3boDjdzW3rl6NkPGB aP0bRznNw86NpuK2r2SjfRGQBQka/r4nMvRd0zT3b2cQZR5qNIAdyYB4Xb+6/JD3Myrj zpp1kZ9uZk+ZnGgu9U5SRaBnND8rxq9MIwBdM= Received: by 10.52.68.44 with SMTP id s12mr4991669vdt.74.1298932766258; Mon, 28 Feb 2011 14:39:26 -0800 (PST) Received: from disbatch.dataix.local ([99.181.159.74]) by mx.google.com with ESMTPS id w26sm1877382vcf.21.2011.02.28.14.39.12 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 28 Feb 2011 14:39:25 -0800 (PST) Sender: "J. Hellenthal" Date: Mon, 28 Feb 2011 17:39:10 -0500 From: jhell To: Stephen Montgomery-Smith In-Reply-To: <4D6BD83B.3040609@missouri.edu> Message-ID: References: <4D6BD83B.3040609@missouri.edu> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-OpenPGP-Key-Id: 0x89D8547E X-OpenPGP-Key-Fingerprint: 85EF E26B 07BB 3777 76BE B12A 9057 8789 89D8 547E MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD Stable Subject: Re: Change in behavior to stat(1) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 28 Feb 2011 22:39:27 -0000 On Mon, 28 Feb 2011 12:15, stephen@ wrote: > I had a little script that would remove broken links. I used to do it like > this: > > if ! stat -L $link > /dev/null; then rm $link; fi > > But recently (some time in February according to the CVS records) stat was > changed so that stat -L would use lstat(2) if the link is broken. > > So I had to change it to > > if stat -L $link | awk '{print $3}' | grep l > /dev/null; > then rm $link; fi > > but it is a lot less elegant. > > What is the proper accepted way to remove broken links? > > Stephen > You might find sysutils/symlinks interesting. I have been using it a long time and have not had to consider adjusting much in the way of shell scripting to remove dirty links. -c == change absolute/messy links to relative -d == delete dangling links -o == warn about links across file systems -r == recurse into subdirs -s == shorten lengthy links -t == show what would be done by -c -v == verbose (show all symlinks) Quite interesting though how such a little tweak has caused a massive expansion of your command line and required utils. Good luck, -- jhell From owner-freebsd-stable@FreeBSD.ORG Mon Feb 28 23:09:19 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3E46B1065672 for ; Mon, 28 Feb 2011 23:09:19 +0000 (UTC) (envelope-from ronald-freebsd8@klop.yi.org) Received: from smtp-out1.tiscali.nl (smtp-out1.tiscali.nl [195.241.79.176]) by mx1.freebsd.org (Postfix) with ESMTP id F15B58FC0A for ; Mon, 28 Feb 2011 23:09:18 +0000 (UTC) Received: from [212.123.145.58] (helo=sjakie.klop.ws) by smtp-out1.tiscali.nl with esmtp (Exim) (envelope-from ) id 1PuC2N-0004I2-7L; Mon, 28 Feb 2011 23:57:55 +0100 Received: from 212-123-145-58.ip.telfort.nl (localhost [127.0.0.1]) by sjakie.klop.ws (Postfix) with ESMTP id 1937114E67; Mon, 28 Feb 2011 23:57:45 +0100 (CET) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes To: "Stephen Montgomery-Smith" , jhell References: <4D6BD83B.3040609@missouri.edu> Date: Mon, 28 Feb 2011 23:57:44 +0100 MIME-Version: 1.0 From: "Ronald Klop" Message-ID: In-Reply-To: User-Agent: Opera Mail/11.01 (FreeBSD) Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Stable Subject: Re: Change in behavior to stat(1) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 28 Feb 2011 23:09:19 -0000 On Mon, 28 Feb 2011 23:39:10 +0100, jhell wrote: > > On Mon, 28 Feb 2011 12:15, stephen@ wrote: >> I had a little script that would remove broken links. I used to do it= =20 >> like this: >> >> if ! stat -L $link > /dev/null; then rm $link; fi >> >> But recently (some time in February according to the CVS records) stat= =20 >> was changed so that stat -L would use lstat(2) if the link is broken. >> >> So I had to change it to >> >> if stat -L $link | awk '{print $3}' | grep l > /dev/null; >> then rm $link; fi >> >> but it is a lot less elegant. >> >> What is the proper accepted way to remove broken links? >> >> Stephen >> > > You might find sysutils/symlinks interesting. I have been using it a =20 > long time and have not had to consider adjusting much in the way of =20 > shell scripting to remove dirty links. > > -c =3D=3D change absolute/messy links to relative > -d =3D=3D delete dangling links > -o =3D=3D warn about links across file systems > -r =3D=3D recurse into subdirs > -s =3D=3D shorten lengthy links > -t =3D=3D show what would be done by -c > -v =3D=3D verbose (show all symlinks) > > > Quite interesting though how such a little tweak has caused a massive =20 > expansion of your command line and required utils. > > > Good luck, > Find has some voodoo for handling links also. Ronald. From owner-freebsd-stable@FreeBSD.ORG Mon Feb 28 23:32:14 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EC72D106566B for ; Mon, 28 Feb 2011 23:32:14 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta06.emeryville.ca.mail.comcast.net (qmta06.emeryville.ca.mail.comcast.net [76.96.30.56]) by mx1.freebsd.org (Postfix) with ESMTP id CE9E98FC1C for ; Mon, 28 Feb 2011 23:32:14 +0000 (UTC) Received: from omta23.emeryville.ca.mail.comcast.net ([76.96.30.90]) by qmta06.emeryville.ca.mail.comcast.net with comcast id DbCm1g0031wfjNsA6bYEU3; Mon, 28 Feb 2011 23:32:14 +0000 Received: from koitsu.dyndns.org ([98.248.33.18]) by omta23.emeryville.ca.mail.comcast.net with comcast id DbY81g00D0PUQVN8jbY9AW; Mon, 28 Feb 2011 23:32:11 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id D7A619B427; Mon, 28 Feb 2011 15:32:07 -0800 (PST) Date: Mon, 28 Feb 2011 15:32:07 -0800 From: Jeremy Chadwick To: Stephen Montgomery-Smith Message-ID: <20110228233207.GA33800@icarus.home.lan> References: <4D6BD83B.3040609@missouri.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D6BD83B.3040609@missouri.edu> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: FreeBSD Stable Subject: Re: Change in behavior to stat(1) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 28 Feb 2011 23:32:15 -0000 On Mon, Feb 28, 2011 at 11:15:39AM -0600, Stephen Montgomery-Smith wrote: > I had a little script that would remove broken links. I used to do > it like this: > > if ! stat -L $link > /dev/null; then rm $link; fi > > But recently (some time in February according to the CVS records) > stat was changed so that stat -L would use lstat(2) if the link is > broken. > > So I had to change it to > > if stat -L $link | awk '{print $3}' | grep l > /dev/null; > then rm $link; fi > > but it is a lot less elegant. > > What is the proper accepted way to remove broken links? If your complaint is the literal length of the line, you should be able to change your one-liner to: if stat -L -f %Sp $link | grep l > /dev/null; then rm $link; fi Though I agree this is less elegant. Unrelated (but worth noting), be aware your one-liner will break horribly with files that contains spaces; use "$link" instead. Possibly you could use the example from the find(1) man page: find -L /usr/ports/packages -type l -exec rm -- {} + Delete all broken symbolic links in /usr/ports/packages. (Note that the "+" on the end is not a typo, see the man page) Otherwise, possibly someone should add a flag to stat(1) that inhibits falling back on lstat(2). -- | 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 Feb 28 23:33:54 2011 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 2C4F5106564A for ; Mon, 28 Feb 2011 23:33:54 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 9E40E8FC16 for ; Mon, 28 Feb 2011 23:33:53 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 1C8D046B35 for ; Mon, 28 Feb 2011 18:33:53 -0500 (EST) Date: Mon, 28 Feb 2011 23:33:53 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: stable@FreeBSD.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Subject: FYI: Userspace DTrace MFC to stable/8 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2011 23:33:54 -0000 Dear all: Just an FYI that I've gone ahead and merged userspace DTrace support to FreeBSD 8.x from 9.x. While it appeared to pass build tests locally, boot and run, etc, this is a non-trivial merge, and it's possible I've messed up. If so, apologies in advance, and I'll try to resolve any problems as quickly as I can! And of course, many thanks go to Rui Paulo, who did the port of userspace DTrace to FreeBSD 9.x with support from the FreeBSD Foundation! Thanks, Robert N M Watson Computer Laboratory University of Cambridge ---------- Forwarded message ---------- Date: Mon, 28 Feb 2011 23:28:35 +0000 (UTC) From: Robert Watson To: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-stable@freebsd.org, svn-src-stable-8@freebsd.org Subject: svn commit: r219107 - in stable/8/sys: amd64/amd64 amd64/include boot/common cddl/compat/opensolaris/kern cddl/compat/opensolaris/sys cddl/contrib/opensolaris/uts/common/dtrace cddl/contrib/opensol... Author: rwatson Date: Mon Feb 28 23:28:35 2011 New Revision: 219107 URL: http://svn.freebsd.org/changeset/base/219107 Log: Merge userspace DTrace support from head to stable/8: r209721: Merge from vendor-sys/opensolaris: * add fasttrap files r209731: Introduce USD_{SET,GET}{BASE,LIMIT}. These help setting up the user segment descriptor hi and lo values. Idea from Solaris. Reviewed by: kib r209763: Fix style issues with the previous commit, namely use-tab-instead-of-space and don't use underscores in macro variables. Pointed out by: bde r210292: Fix typo in comment. r210357: MFamd64: Add USD_GETBASE(), USD_SETBASE(), USD_GETLIMIT() and USD_SETLIMIT(). r210611: Bump the witness pendlist to 768 to accomodate the increased number of spinlocks. r211553: Add sysname to struct opensolaris_utsname. This is needed by one DTrace test. r211566: Add a sysname char * to struct opensolaris_utsname. r211606: Add the FreeBSD definition for the fasttrap ioctls. r211607: Add a function compatibility function dtrace_instr_size_isa() that on FreeBSD does the same as dtrace_dis_isize(). r211608: Kernel DTrace support for: o uregs (sson@) o ustack (sson@) o /dev/dtrace/helper device (needed for USDT probes) r211610: Add more compatibility structure members needed by the upcoming fasttrap DTrace device. r211611: Destroy the helper device when unloading. r211613: Fix style issues. r211614: Bump KDTRACE_THREAD_ZERO and use M_ZERO as a malloc flag instead of calling bzero. r211615: Remove an elif and add an or-clause. r211616: Add an extra comment to the SDT probes definition. This allows us to get use '-' in probe names, matching the probe names in Solaris. Add userland SDT probes definitions to sys/sdt.h. r211617: Call the systrace_probe_func() when the error value. r211618: Port this to FreeBSD. We miss some suword functions, so we use copyout. r211738: Port the fasttrap provider to FreeBSD. This provider is responsible for injecting debugging probes in the userland programs and is the basis for the pid provider and the usdt provider. r211744: MD fasttrap implementation. r211745: Replace a pksignal() call with tdksignal(). Pointed out by: kib r211746: Update for the recent location of the fasttrap code. r211747: Replace structure assignments with explicity memcpy calls. This allows Clang to compile this file: it was using the builtin memcpy and we want to use the memcpy defined in gptboot.c. (Clang can't compile boot2 yet). Submitted by: Dimitry Andric Reviewed by: jhb r211751: Add a trap code for DTrace induced traps. r211752: Add two DTrace trap type values. Used by fasttrap. r211753: Enable fasttrap and make dtraceall depend on fasttrap when building i386 or amd64. r211804: Call the necessary DTrace function pointers when we have different kinds of traps. r211813: Add the necessary DTrace function pointers. r211839: Sync DTrace bits with amd64 and fix the build. r211924: Register an interrupt vector for DTrace return probes. There is some code missing in lapic to make sure that we don't overwrite this entry, but this will be done on a sequent commit. r211925: Replace a memory barrier with a mutex barrier. r211926: Add the path necessary to find fasttrap_isa.h to CFLAGS. r211929: Remove debugging. r212004: When DTrace is enabled, make sure we don't overwrite the IDT_DTRACE_RET entry with an IRQ for some hardware component. Reviewed by: jhb r212093: Make the /dev/dtrace/helper node have the mode 0660. This allows programs that refuse to run as root (pgsql) to install probes when their user is part of the wheel group. r212357: Fix two bugs in DTrace: * when the process exits, remove the associated USDT probes * when the process forks, duplicate the USDT probes. r212465: Avoid a LOR (sleepable after non-sleepable) in fasttrap_tracepoint_enable(). r212494: Revamp locking a bit. This fixes three problems: * processes now can't go away while we are inserting probes (fixes a panic) * if a trap happens, we won't be holding the process lock (fixes a hang) * fix a LOR between the process lock and the fasttrap bucket list lock Thanks to kib for pointing some problems. r212568: Bump __FreeBSD_version to reflect the userland DTrace changes Sponsored by: The FreeBSD Foundation Userspace DTrace work by: rpaulo Added: stable/8/sys/cddl/contrib/opensolaris/uts/common/sys/fasttrap_impl.h - copied, changed from r209721, head/sys/cddl/contrib/opensolaris/uts/common/sys/fasttrap_impl.h stable/8/sys/cddl/contrib/opensolaris/uts/intel/dtrace/ - copied from r209721, head/sys/cddl/contrib/opensolaris/uts/intel/dtrace/ stable/8/sys/cddl/contrib/opensolaris/uts/sparc/dtrace/ - copied from r209721, head/sys/cddl/contrib/opensolaris/uts/sparc/dtrace/ stable/8/sys/cddl/dev/dtrace/amd64/regset.h - copied unchanged from r211608, head/sys/cddl/dev/dtrace/amd64/regset.h stable/8/sys/cddl/dev/dtrace/i386/regset.h - copied unchanged from r211608, head/sys/cddl/dev/dtrace/i386/regset.h Modified: stable/8/sys/amd64/amd64/exception.S stable/8/sys/amd64/amd64/machdep.c stable/8/sys/amd64/amd64/trap.c stable/8/sys/amd64/include/segments.h stable/8/sys/amd64/include/trap.h stable/8/sys/boot/common/ufsread.c stable/8/sys/cddl/compat/opensolaris/kern/opensolaris_misc.c stable/8/sys/cddl/compat/opensolaris/sys/misc.h stable/8/sys/cddl/contrib/opensolaris/uts/common/dtrace/dtrace.c stable/8/sys/cddl/contrib/opensolaris/uts/common/dtrace/fasttrap.c stable/8/sys/cddl/contrib/opensolaris/uts/common/sys/dtrace.h stable/8/sys/cddl/contrib/opensolaris/uts/common/sys/dtrace_impl.h stable/8/sys/cddl/contrib/opensolaris/uts/common/sys/fasttrap.h stable/8/sys/cddl/contrib/opensolaris/uts/intel/dtrace/fasttrap_isa.c stable/8/sys/cddl/dev/dtrace/amd64/dtrace_isa.c stable/8/sys/cddl/dev/dtrace/amd64/instr_size.c stable/8/sys/cddl/dev/dtrace/dtrace_cddl.h stable/8/sys/cddl/dev/dtrace/dtrace_ioctl.c stable/8/sys/cddl/dev/dtrace/dtrace_load.c stable/8/sys/cddl/dev/dtrace/dtrace_unload.c stable/8/sys/cddl/dev/dtrace/i386/dtrace_isa.c stable/8/sys/cddl/dev/dtrace/i386/instr_size.c stable/8/sys/cddl/dev/systrace/systrace.c stable/8/sys/i386/i386/exception.s stable/8/sys/i386/i386/machdep.c stable/8/sys/i386/i386/trap.c stable/8/sys/i386/include/segments.h stable/8/sys/i386/include/trap.h stable/8/sys/kern/kern_dtrace.c stable/8/sys/kern/kern_exec.c stable/8/sys/kern/kern_exit.c stable/8/sys/kern/kern_fork.c stable/8/sys/kern/kern_priv.c stable/8/sys/kern/kern_proc.c stable/8/sys/kern/kern_sig.c stable/8/sys/kern/kern_timeout.c stable/8/sys/kern/subr_trap.c stable/8/sys/kern/subr_witness.c stable/8/sys/kern/vfs_cache.c stable/8/sys/kern/vfs_lookup.c stable/8/sys/kern/vfs_syscalls.c stable/8/sys/modules/dtrace/Makefile stable/8/sys/modules/dtrace/dtrace/Makefile stable/8/sys/modules/dtrace/dtraceall/dtraceall.c stable/8/sys/modules/dtrace/fasttrap/Makefile stable/8/sys/net/vnet.c stable/8/sys/opencrypto/deflate.c stable/8/sys/security/mac/mac_framework.c stable/8/sys/security/mac/mac_internal.h stable/8/sys/sys/dtrace_bsd.h stable/8/sys/sys/param.h stable/8/sys/sys/priv.h stable/8/sys/sys/sdt.h stable/8/sys/sys/signal.h stable/8/sys/sys/sysent.h stable/8/sys/tools/vnode_if.awk stable/8/sys/x86/x86/local_apic.c Directory Properties: stable/8/sys/ (props changed) stable/8/sys/amd64/include/xen/ (props changed) stable/8/sys/cddl/contrib/opensolaris/ (props changed) stable/8/sys/contrib/dev/acpica/ (props changed) stable/8/sys/contrib/pf/ (props changed) Modified: stable/8/sys/amd64/amd64/exception.S ============================================================================== --- stable/8/sys/amd64/amd64/exception.S Mon Feb 28 21:33:26 2011 (r219106) +++ stable/8/sys/amd64/amd64/exception.S Mon Feb 28 23:28:35 2011 (r219107) @@ -108,6 +108,10 @@ IDTVEC(dbg) TRAP_NOEN(T_TRCTRAP) IDTVEC(bpt) TRAP_NOEN(T_BPTFLT) +#ifdef KDTRACE_HOOKS +IDTVEC(dtrace_ret) + TRAP_NOEN(T_DTRACE_RET) +#endif /* Regular traps; The cpu does not supply tf_err for these. */ #define TRAP(a) \ Modified: stable/8/sys/amd64/amd64/machdep.c ============================================================================== --- stable/8/sys/amd64/amd64/machdep.c Mon Feb 28 21:33:26 2011 (r219106) +++ stable/8/sys/amd64/amd64/machdep.c Mon Feb 28 23:28:35 2011 (r219107) @@ -54,6 +54,7 @@ __FBSDID("$FreeBSD$"); #include "opt_msgbuf.h" #include "opt_perfmon.h" #include "opt_sched.h" +#include "opt_kdtrace.h" #include #include @@ -1094,6 +1095,9 @@ extern inthand_t IDTVEC(tss), IDTVEC(missing), IDTVEC(stk), IDTVEC(prot), IDTVEC(page), IDTVEC(mchk), IDTVEC(rsvd), IDTVEC(fpu), IDTVEC(align), IDTVEC(xmm), IDTVEC(dblfault), +#ifdef KDTRACE_HOOKS + IDTVEC(dtrace_ret), +#endif IDTVEC(fast_syscall), IDTVEC(fast_syscall32); #ifdef DDB @@ -1624,6 +1628,9 @@ hammer_time(u_int64_t modulep, u_int64_t setidt(IDT_AC, &IDTVEC(align), SDT_SYSIGT, SEL_KPL, 0); setidt(IDT_MC, &IDTVEC(mchk), SDT_SYSIGT, SEL_KPL, 0); setidt(IDT_XF, &IDTVEC(xmm), SDT_SYSIGT, SEL_KPL, 0); +#ifdef KDTRACE_HOOKS + setidt(IDT_DTRACE_RET, &IDTVEC(dtrace_ret), SDT_SYSIGT, SEL_UPL, 0); +#endif r_idt.rd_limit = sizeof(idt0) - 1; r_idt.rd_base = (long) idt; Modified: stable/8/sys/amd64/amd64/trap.c ============================================================================== --- stable/8/sys/amd64/amd64/trap.c Mon Feb 28 21:33:26 2011 (r219106) +++ stable/8/sys/amd64/amd64/trap.c Mon Feb 28 23:28:35 2011 (r219107) @@ -113,6 +113,13 @@ dtrace_doubletrap_func_t dtrace_doubletr * implementation opaque. */ systrace_probe_func_t systrace_probe_func; + +/* + * These hooks are necessary for the pid, usdt and fasttrap providers. + */ +dtrace_fasttrap_probe_ptr_t dtrace_fasttrap_probe_ptr; +dtrace_pid_probe_ptr_t dtrace_pid_probe_ptr; +dtrace_return_probe_ptr_t dtrace_return_probe_ptr; #endif extern void trap(struct trapframe *frame); @@ -243,6 +250,55 @@ trap(struct trapframe *frame) if (dtrace_trap_func != NULL) if ((*dtrace_trap_func)(frame, type)) goto out; + if (type == T_DTRACE_PROBE || type == T_DTRACE_RET || + type == T_BPTFLT) { + struct reg regs; + + regs.r_r15 = frame->tf_r15; + regs.r_r14 = frame->tf_r14; + regs.r_r13 = frame->tf_r13; + regs.r_r12 = frame->tf_r12; + regs.r_r11 = frame->tf_r11; + regs.r_r10 = frame->tf_r10; + regs.r_r9 = frame->tf_r9; + regs.r_r8 = frame->tf_r8; + regs.r_rdi = frame->tf_rdi; + regs.r_rsi = frame->tf_rsi; + regs.r_rbp = frame->tf_rbp; + regs.r_rbx = frame->tf_rbx; + regs.r_rdx = frame->tf_rdx; + regs.r_rcx = frame->tf_rcx; + regs.r_rax = frame->tf_rax; + regs.r_rip = frame->tf_rip; + regs.r_cs = frame->tf_cs; + regs.r_rflags = frame->tf_rflags; + regs.r_rsp = frame->tf_rsp; + regs.r_ss = frame->tf_ss; + if (frame->tf_flags & TF_HASSEGS) { + regs.r_ds = frame->tf_ds; + regs.r_es = frame->tf_es; + regs.r_fs = frame->tf_fs; + regs.r_gs = frame->tf_gs; + } else { + regs.r_ds = 0; + regs.r_es = 0; + regs.r_fs = 0; + regs.r_gs = 0; + } + if (type == T_DTRACE_PROBE && + dtrace_fasttrap_probe_ptr != NULL && + dtrace_fasttrap_probe_ptr(®s) == 0) + goto out; + if (type == T_BPTFLT && + dtrace_pid_probe_ptr != NULL && + dtrace_pid_probe_ptr(®s) == 0) + goto out; + if (type == T_DTRACE_RET && + dtrace_return_probe_ptr != NULL && + dtrace_return_probe_ptr(®s) == 0) + goto out; + + } #endif if ((frame->tf_rflags & PSL_I) == 0) { Modified: stable/8/sys/amd64/include/segments.h ============================================================================== --- stable/8/sys/amd64/include/segments.h Mon Feb 28 21:33:26 2011 (r219106) +++ stable/8/sys/amd64/include/segments.h Mon Feb 28 23:28:35 2011 (r219107) @@ -74,6 +74,13 @@ struct user_segment_descriptor { u_int64_t sd_hibase:8; /* segment base address (msb) */ } __packed; +#define USD_GETBASE(sd) (((sd)->sd_lobase) | (sd)->sd_hibase << 24) +#define USD_SETBASE(sd, b) (sd)->sd_lobase = (b); \ + (sd)->sd_hibase = ((b) >> 24); +#define USD_GETLIMIT(sd) (((sd)->sd_lolimit) | (sd)->sd_hilimit << 16) +#define USD_SETLIMIT(sd, l) (sd)->sd_lolimit = (l); \ + (sd)->sd_hilimit = ((l) >> 16); + /* * System segment descriptors (128 bit wide) */ @@ -207,6 +214,7 @@ struct region_descriptor { #define IDT_XF 19 /* #XF: SIMD Floating-Point Exception */ #define IDT_IO_INTS NRSVIDT /* Base of IDT entries for I/O interrupts. */ #define IDT_SYSCALL 0x80 /* System Call Interrupt Vector */ +#define IDT_DTRACE_RET 0x92 /* DTrace pid provider Interrupt Vector */ /* * Entries in the Global Descriptor Table (GDT) Modified: stable/8/sys/amd64/include/trap.h ============================================================================== --- stable/8/sys/amd64/include/trap.h Mon Feb 28 21:33:26 2011 (r219106) +++ stable/8/sys/amd64/include/trap.h Mon Feb 28 23:28:35 2011 (r219107) @@ -62,6 +62,8 @@ #define T_MCHK 28 /* machine check trap */ #define T_XMMFLT 29 /* SIMD floating-point exception */ #define T_RESERVED 30 /* reserved (unknown) */ +#define T_DTRACE_RET 31 /* DTrace pid return */ +#define T_DTRACE_PROBE 32 /* DTrace fasttrap probe */ /* XXX most of the following codes aren't used, but could be. */ Modified: stable/8/sys/boot/common/ufsread.c ============================================================================== --- stable/8/sys/boot/common/ufsread.c Mon Feb 28 21:33:26 2011 (r219106) +++ stable/8/sys/boot/common/ufsread.c Mon Feb 28 23:28:35 2011 (r219107) @@ -223,14 +223,19 @@ fsread(ino_t inode, void *buf, size_t nb return -1; n = INO_TO_VBO(n, inode); #if defined(UFS1_ONLY) - dp1 = ((struct ufs1_dinode *)blkbuf)[n]; + memcpy(&dp1, (struct ufs1_dinode *)blkbuf + n, + sizeof(struct ufs1_dinode)); #elif defined(UFS2_ONLY) - dp2 = ((struct ufs2_dinode *)blkbuf)[n]; + memcpy(&dp2, (struct ufs2_dinode *)blkbuf + n, + sizeof(struct ufs2_dinode)); #else if (fs->fs_magic == FS_UFS1_MAGIC) - dp1 = ((struct ufs1_dinode *)blkbuf)[n]; + memcpy(&dp1, (struct ufs1_dinode *)blkbuf + n, + sizeof(struct ufs1_dinode)); else - dp2 = ((struct ufs2_dinode *)blkbuf)[n]; + memcpy(&dp2, (struct ufs2_dinode *)blkbuf + n, + sizeof(struct ufs2_dinode)); + #endif inomap = inode; fs_off = 0; Modified: stable/8/sys/cddl/compat/opensolaris/kern/opensolaris_misc.c ============================================================================== --- stable/8/sys/cddl/compat/opensolaris/kern/opensolaris_misc.c Mon Feb 28 21:33:26 2011 (r219106) +++ stable/8/sys/cddl/compat/opensolaris/kern/opensolaris_misc.c Mon Feb 28 23:28:35 2011 (r219107) @@ -38,7 +38,8 @@ __FBSDID("$FreeBSD$"); char hw_serial[11] = "0"; struct opensolaris_utsname utsname = { - .nodename = "unset" + .nodename = "unset", + .sysname = "SunOS" }; int Modified: stable/8/sys/cddl/compat/opensolaris/sys/misc.h ============================================================================== --- stable/8/sys/cddl/compat/opensolaris/sys/misc.h Mon Feb 28 21:33:26 2011 (r219106) +++ stable/8/sys/cddl/compat/opensolaris/sys/misc.h Mon Feb 28 23:28:35 2011 (r219107) @@ -46,6 +46,7 @@ #ifdef _KERNEL struct opensolaris_utsname { char *nodename; + char *sysname; }; extern char hw_serial[11]; Modified: stable/8/sys/cddl/contrib/opensolaris/uts/common/dtrace/dtrace.c ============================================================================== --- stable/8/sys/cddl/contrib/opensolaris/uts/common/dtrace/dtrace.c Mon Feb 28 21:33:26 2011 (r219106) +++ stable/8/sys/cddl/contrib/opensolaris/uts/common/dtrace/dtrace.c Mon Feb 28 23:28:35 2011 (r219107) @@ -551,20 +551,16 @@ static void dtrace_enabling_provide(dtra static int dtrace_enabling_match(dtrace_enabling_t *, int *); static void dtrace_enabling_matchall(void); static dtrace_state_t *dtrace_anon_grab(void); -#if defined(sun) static uint64_t dtrace_helper(int, dtrace_mstate_t *, dtrace_state_t *, uint64_t, uint64_t); static dtrace_helpers_t *dtrace_helpers_create(proc_t *); -#endif static void dtrace_buffer_drop(dtrace_buffer_t *); static intptr_t dtrace_buffer_reserve(dtrace_buffer_t *, size_t, size_t, dtrace_state_t *, dtrace_mstate_t *); static int dtrace_state_option(dtrace_state_t *, dtrace_optid_t, dtrace_optval_t); static int dtrace_ecb_create_enable(dtrace_probe_t *, void *); -#if defined(sun) static void dtrace_helper_provider_destroy(dtrace_helper_provider_t *); -#endif uint16_t dtrace_load16(uintptr_t); uint32_t dtrace_load32(uintptr_t); uint64_t dtrace_load64(uintptr_t); @@ -2784,6 +2780,21 @@ dtrace_dif_variable(dtrace_mstate_t *mst return (dtrace_getreg(lwp->lwp_regs, ndx)); return (0); } +#else + case DIF_VAR_UREGS: { + struct trapframe *tframe; + + if (!dtrace_priv_proc(state)) + return (0); + + if ((tframe = curthread->td_frame) == NULL) { + DTRACE_CPUFLAG_SET(CPU_DTRACE_BADADDR); + cpu_core[curcpu].cpuc_dtrace_illval = 0; + return (0); + } + + return (dtrace_getreg(tframe, ndx)); + } #endif case DIF_VAR_CURTHREAD: @@ -2839,7 +2850,6 @@ dtrace_dif_variable(dtrace_mstate_t *mst } return (mstate->dtms_stackdepth); -#if defined(sun) case DIF_VAR_USTACKDEPTH: if (!dtrace_priv_proc(state)) return (0); @@ -2859,7 +2869,6 @@ dtrace_dif_variable(dtrace_mstate_t *mst mstate->dtms_present |= DTRACE_MSTATE_USTACKDEPTH; } return (mstate->dtms_ustackdepth); -#endif case DIF_VAR_CALLER: if (!dtrace_priv_kernel(state)) @@ -2896,7 +2905,6 @@ dtrace_dif_variable(dtrace_mstate_t *mst } return (mstate->dtms_caller); -#if defined(sun) case DIF_VAR_UCALLER: if (!dtrace_priv_proc(state)) return (0); @@ -2920,7 +2928,6 @@ dtrace_dif_variable(dtrace_mstate_t *mst } return (mstate->dtms_ucaller); -#endif case DIF_VAR_PROBEPROV: ASSERT(mstate->dtms_present & DTRACE_MSTATE_PROBE); @@ -5736,7 +5743,6 @@ dtrace_action_chill(dtrace_mstate_t *mst cpu->cpu_dtrace_chilled += val; } -#if defined(sun) static void dtrace_action_ustack(dtrace_mstate_t *mstate, dtrace_state_t *state, uint64_t *buf, uint64_t arg) @@ -5849,7 +5855,6 @@ dtrace_action_ustack(dtrace_mstate_t *ms out: mstate->dtms_scratch_ptr = old; } -#endif /* * If you're looking for the epicenter of DTrace, you just found it. This @@ -6172,7 +6177,6 @@ dtrace_probe(dtrace_id_t id, uintptr_t a (uint32_t *)arg0); continue; -#if defined(sun) case DTRACEACT_JSTACK: case DTRACEACT_USTACK: if (!dtrace_priv_proc(state)) @@ -6214,7 +6218,6 @@ dtrace_probe(dtrace_id_t id, uintptr_t a DTRACE_USTACK_NFRAMES(rec->dtrd_arg) + 1); DTRACE_CPUFLAG_CLEAR(CPU_DTRACE_NOFAULT); continue; -#endif default: break; @@ -8141,7 +8144,6 @@ dtrace_helper_provide(dof_helper_t *dhp, dtrace_enabling_matchall(); } -#if defined(sun) static void dtrace_helper_provider_remove_one(dof_helper_t *dhp, dof_sec_t *sec, pid_t pid) { @@ -8189,7 +8191,6 @@ dtrace_helper_provider_remove(dof_helper dtrace_helper_provider_remove_one(dhp, sec, pid); } } -#endif /* * DTrace Meta Provider-to-Framework API Functions @@ -8729,7 +8730,6 @@ dtrace_difo_validate(dtrace_difo_t *dp, return (err); } -#if defined(sun) /* * Validate a DTrace DIF object that it is to be used as a helper. Helpers * are much more constrained than normal DIFOs. Specifically, they may @@ -8887,7 +8887,6 @@ dtrace_difo_validate_helper(dtrace_difo_ return (err); } -#endif /* * Returns 1 if the expression in the DIF object can be cached on a per-thread @@ -9219,7 +9218,6 @@ dtrace_difo_init(dtrace_difo_t *dp, dtra dtrace_difo_hold(dp); } -#if defined(sun) static dtrace_difo_t * dtrace_difo_duplicate(dtrace_difo_t *dp, dtrace_vstate_t *vstate) { @@ -9263,7 +9261,6 @@ dtrace_difo_duplicate(dtrace_difo_t *dp, dtrace_difo_init(new, vstate); return (new); } -#endif static void dtrace_difo_destroy(dtrace_difo_t *dp, dtrace_vstate_t *vstate) @@ -13791,7 +13788,6 @@ dtrace_anon_property(void) } } -#if defined(sun) /* * DTrace Helper Functions */ @@ -13855,9 +13851,7 @@ dtrace_helper_trace(dtrace_helper_action ((uint64_t *)(uintptr_t)svar->dtsv_data)[curcpu]; } } -#endif -#if defined(sun) static uint64_t dtrace_helper(int which, dtrace_mstate_t *mstate, dtrace_state_t *state, uint64_t arg0, uint64_t arg1) @@ -13865,7 +13859,7 @@ dtrace_helper(int which, dtrace_mstate_t uint16_t *flags = &cpu_core[curcpu].cpuc_dtrace_flags; uint64_t sarg0 = mstate->dtms_arg[0]; uint64_t sarg1 = mstate->dtms_arg[1]; - uint64_t rval; + uint64_t rval = 0; dtrace_helpers_t *helpers = curproc->p_dtrace_helpers; dtrace_helper_action_t *helper; dtrace_vstate_t *vstate; @@ -14056,9 +14050,7 @@ dtrace_helper_destroygen(int gen) return (0); } -#endif -#if defined(sun) static int dtrace_helper_validate(dtrace_helper_action_t *helper) { @@ -14073,9 +14065,7 @@ dtrace_helper_validate(dtrace_helper_act return (err == 0); } -#endif -#if defined(sun) static int dtrace_helper_action_add(int which, dtrace_ecbdesc_t *ep) { @@ -14622,12 +14612,17 @@ dtrace_helpers_create(proc_t *p) return (help); } -static void -dtrace_helpers_destroy(void) +#if defined(sun) +static +#endif +void +dtrace_helpers_destroy(proc_t *p) { dtrace_helpers_t *help; dtrace_vstate_t *vstate; +#if defined(sun) proc_t *p = curproc; +#endif int i; mutex_enter(&dtrace_lock); @@ -14714,7 +14709,10 @@ dtrace_helpers_destroy(void) mutex_exit(&dtrace_lock); } -static void +#if defined(sun) +static +#endif +void dtrace_helpers_duplicate(proc_t *from, proc_t *to) { dtrace_helpers_t *help, *newhelp; @@ -14795,7 +14793,6 @@ dtrace_helpers_duplicate(proc_t *from, p if (hasprovs) dtrace_helper_provider_register(to, newhelp, NULL); } -#endif #if defined(sun) /* @@ -16466,6 +16463,7 @@ _fini(void) #else static d_ioctl_t dtrace_ioctl; +static d_ioctl_t dtrace_ioctl_helper; static void dtrace_load(void *); static int dtrace_unload(void); #if __FreeBSD_version < 800039 @@ -16474,6 +16472,7 @@ static struct clonedevs *dtrace_clones; static eventhandler_tag eh_tag; /* Event handler tag. */ #else static struct cdev *dtrace_dev; +static struct cdev *helper_dev; #endif void dtrace_invop_init(void); @@ -16488,6 +16487,13 @@ static struct cdevsw dtrace_cdevsw = { .d_name = "dtrace", }; +static struct cdevsw helper_cdevsw = { + .d_version = D_VERSION, + .d_flags = D_TRACKCLOSE | D_NEEDMINOR, + .d_ioctl = dtrace_ioctl_helper, + .d_name = "helper", +}; + #include #if __FreeBSD_version < 800039 #include Modified: stable/8/sys/cddl/contrib/opensolaris/uts/common/dtrace/fasttrap.c ============================================================================== --- stable/8/sys/cddl/contrib/opensolaris/uts/common/dtrace/fasttrap.c Mon Feb 28 21:33:26 2011 (r219106) +++ stable/8/sys/cddl/contrib/opensolaris/uts/common/dtrace/fasttrap.c Mon Feb 28 23:28:35 2011 (r219107) @@ -17,6 +17,10 @@ * information: Portions Copyright [yyyy] [name of copyright owner] * * CDDL HEADER END + * + * Portions Copyright 2010 The FreeBSD Foundation + * + * $FreeBSD$ */ /* @@ -24,7 +28,9 @@ * Use is subject to license terms. */ +#if defined(sun) #pragma ident "%Z%%M% %I% %E% SMI" +#endif #include #include @@ -32,11 +38,15 @@ #include #include #include +#if defined(sun) #include +#endif #include #include #include +#if defined(sun) #include +#endif #include #include #include @@ -44,9 +54,17 @@ #include #include #include -#include #include +#if defined(sun) #include +#endif +#include +#include +#if !defined(sun) +#include +#include +#include +#endif /* * User-Land Trap-Based Tracing @@ -125,11 +143,20 @@ * never hold the provider lock and creation lock simultaneously */ -static dev_info_t *fasttrap_devi; +static d_open_t fasttrap_open; +static d_ioctl_t fasttrap_ioctl; + +static struct cdevsw fasttrap_cdevsw = { + .d_version = D_VERSION, + .d_open = fasttrap_open, + .d_ioctl = fasttrap_ioctl, + .d_name = "fasttrap", +}; +static struct cdev *fasttrap_cdev; static dtrace_meta_provider_id_t fasttrap_meta_id; -static timeout_id_t fasttrap_timeout; -static kmutex_t fasttrap_cleanup_mtx; +static struct callout fasttrap_timeout; +static struct mtx fasttrap_cleanup_mtx; static uint_t fasttrap_cleanup_work; /* @@ -181,6 +208,10 @@ static void fasttrap_proc_release(fasttr #define FASTTRAP_PROCS_INDEX(pid) ((pid) & fasttrap_procs.fth_mask) +#if !defined(sun) +static kmutex_t fasttrap_cpuc_pid_lock[MAXCPU]; +#endif + static int fasttrap_highbit(ulong_t i) { @@ -229,6 +260,7 @@ fasttrap_hash_str(const char *p) void fasttrap_sigtrap(proc_t *p, kthread_t *t, uintptr_t pc) { +#if defined(sun) sigqueue_t *sqp = kmem_zalloc(sizeof (sigqueue_t), KM_SLEEP); sqp->sq_info.si_signo = SIGTRAP; @@ -241,6 +273,17 @@ fasttrap_sigtrap(proc_t *p, kthread_t *t if (t != NULL) aston(t); +#else + ksiginfo_t *ksi = kmem_zalloc(sizeof (ksiginfo_t), KM_SLEEP); + + ksiginfo_init(ksi); + ksi->ksi_signo = SIGTRAP; + ksi->ksi_code = TRAP_DTRACE; + ksi->ksi_addr = (caddr_t)pc; + PROC_LOCK(p); + (void) tdksignal(t, SIGTRAP, ksi); + PROC_UNLOCK(p); +#endif } /* @@ -257,9 +300,9 @@ fasttrap_mod_barrier(uint64_t gen) fasttrap_mod_gen++; - for (i = 0; i < NCPU; i++) { - mutex_enter(&cpu_core[i].cpuc_pid_lock); - mutex_exit(&cpu_core[i].cpuc_pid_lock); + CPU_FOREACH(i) { + mutex_enter(&fasttrap_cpuc_pid_lock[i]); + mutex_exit(&fasttrap_cpuc_pid_lock[i]); } } @@ -274,16 +317,15 @@ fasttrap_pid_cleanup_cb(void *data) fasttrap_provider_t **fpp, *fp; fasttrap_bucket_t *bucket; dtrace_provider_id_t provid; - int i, later; + int i, later = 0; static volatile int in = 0; ASSERT(in == 0); in = 1; - mutex_enter(&fasttrap_cleanup_mtx); while (fasttrap_cleanup_work) { fasttrap_cleanup_work = 0; - mutex_exit(&fasttrap_cleanup_mtx); + mtx_unlock(&fasttrap_cleanup_mtx); later = 0; @@ -349,10 +391,12 @@ fasttrap_pid_cleanup_cb(void *data) mutex_exit(&bucket->ftb_mtx); } - mutex_enter(&fasttrap_cleanup_mtx); + mtx_lock(&fasttrap_cleanup_mtx); } +#if 0 ASSERT(fasttrap_timeout != 0); +#endif /* * If we were unable to remove a retired provider, try again after @@ -364,14 +408,17 @@ fasttrap_pid_cleanup_cb(void *data) * get a chance to do that work if and when the timeout is reenabled * (if detach fails). */ - if (later > 0 && fasttrap_timeout != (timeout_id_t)1) - fasttrap_timeout = timeout(&fasttrap_pid_cleanup_cb, NULL, hz); + if (later > 0 && callout_active(&fasttrap_timeout)) + callout_reset(&fasttrap_timeout, hz, &fasttrap_pid_cleanup_cb, + NULL); else if (later > 0) fasttrap_cleanup_work = 1; - else - fasttrap_timeout = 0; + else { +#if !defined(sun) + /* Nothing to be done for FreeBSD */ +#endif + } - mutex_exit(&fasttrap_cleanup_mtx); in = 0; } @@ -381,11 +428,11 @@ fasttrap_pid_cleanup_cb(void *data) static void fasttrap_pid_cleanup(void) { - mutex_enter(&fasttrap_cleanup_mtx); + + mtx_lock(&fasttrap_cleanup_mtx); fasttrap_cleanup_work = 1; - if (fasttrap_timeout == 0) - fasttrap_timeout = timeout(&fasttrap_pid_cleanup_cb, NULL, 1); - mutex_exit(&fasttrap_cleanup_mtx); + callout_reset(&fasttrap_timeout, 1, &fasttrap_pid_cleanup_cb, NULL); + mtx_unlock(&fasttrap_cleanup_mtx); } /* @@ -400,9 +447,35 @@ fasttrap_fork(proc_t *p, proc_t *cp) pid_t ppid = p->p_pid; int i; +#if defined(sun) ASSERT(curproc == p); ASSERT(p->p_proc_flag & P_PR_LOCK); +#else + PROC_LOCK_ASSERT(p, MA_OWNED); +#endif +#if defined(sun) ASSERT(p->p_dtrace_count > 0); +#else + if (p->p_dtrace_helpers) { + /* + * dtrace_helpers_duplicate() allocates memory. + */ + _PHOLD(cp); + PROC_UNLOCK(p); + PROC_UNLOCK(cp); + dtrace_helpers_duplicate(p, cp); + PROC_LOCK(cp); + PROC_LOCK(p); + _PRELE(cp); + } + /* + * This check is purposely here instead of in kern_fork.c because, + * for legal resons, we cannot include the dtrace_cddl.h header + * inside kern_fork.c and insert if-clause there. + */ + if (p->p_dtrace_count == 0) + return; +#endif ASSERT(cp->p_dtrace_count == 0); /* @@ -419,9 +492,13 @@ fasttrap_fork(proc_t *p, proc_t *cp) * We don't have to worry about the child process disappearing * because we're in fork(). */ - mutex_enter(&cp->p_lock); +#if defined(sun) + mtx_lock_spin(&cp->p_slock); sprlock_proc(cp); - mutex_exit(&cp->p_lock); + mtx_unlock_spin(&cp->p_slock); +#else + _PHOLD(cp); +#endif /* * Iterate over every tracepoint looking for ones that belong to the @@ -451,8 +528,12 @@ fasttrap_fork(proc_t *p, proc_t *cp) mutex_exit(&bucket->ftb_mtx); } +#if defined(sun) mutex_enter(&cp->p_lock); sprunlock(cp); +#else + _PRELE(cp); +#endif } /* @@ -463,24 +544,30 @@ fasttrap_fork(proc_t *p, proc_t *cp) static void fasttrap_exec_exit(proc_t *p) { +#if defined(sun) ASSERT(p == curproc); - ASSERT(MUTEX_HELD(&p->p_lock)); - - mutex_exit(&p->p_lock); +#endif + PROC_LOCK_ASSERT(p, MA_OWNED); + _PHOLD(p); + PROC_UNLOCK(p); /* * We clean up the pid provider for this process here; user-land * static probes are handled by the meta-provider remove entry point. */ fasttrap_provider_retire(p->p_pid, FASTTRAP_PID_NAME, 0); - - mutex_enter(&p->p_lock); +#if !defined(sun) + if (p->p_dtrace_helpers) + dtrace_helpers_destroy(p); +#endif + PROC_LOCK(p); + _PRELE(p); } /*ARGSUSED*/ static void -fasttrap_pid_provide(void *arg, const dtrace_probedesc_t *desc) +fasttrap_pid_provide(void *arg, dtrace_probedesc_t *desc) { /* * There are no "default" pid probes. @@ -504,7 +591,9 @@ fasttrap_tracepoint_enable(proc_t *p, fa ASSERT(probe->ftp_tps[index].fit_tp->ftt_pid == pid); +#if defined(sun) ASSERT(!(p->p_flag & SVFORK)); +#endif /* * Before we make any modifications, make sure we've imposed a barrier @@ -610,7 +699,9 @@ again: * Increment the count of the number of tracepoints active in * the victim process. */ +#if defined(sun) ASSERT(p->p_proc_flag & P_PR_LOCK); +#endif p->p_dtrace_count++; return (rc); @@ -666,7 +757,7 @@ fasttrap_tracepoint_disable(proc_t *p, f fasttrap_bucket_t *bucket; fasttrap_provider_t *provider = probe->ftp_prov; fasttrap_tracepoint_t **pp, *tp; - fasttrap_id_t *id, **idp; + fasttrap_id_t *id, **idp = NULL; pid_t pid; uintptr_t pc; @@ -800,7 +891,9 @@ fasttrap_tracepoint_disable(proc_t *p, f * Decrement the count of the number of tracepoints active * in the victim process. */ +#if defined(sun) ASSERT(p->p_proc_flag & P_PR_LOCK); +#endif p->p_dtrace_count--; } @@ -851,26 +944,31 @@ fasttrap_enable_callbacks(void) static void fasttrap_disable_callbacks(void) { +#if defined(sun) ASSERT(MUTEX_HELD(&cpu_lock)); +#endif + mutex_enter(&fasttrap_count_mtx); ASSERT(fasttrap_pid_count > 0); fasttrap_pid_count--; if (fasttrap_pid_count == 0) { +#if defined(sun) cpu_t *cur, *cpu = CPU; for (cur = cpu->cpu_next_onln; cur != cpu; cur = cur->cpu_next_onln) { rw_enter(&cur->cpu_ft_lock, RW_WRITER); } - +#endif dtrace_pid_probe_ptr = NULL; dtrace_return_probe_ptr = NULL; - +#if defined(sun) for (cur = cpu->cpu_next_onln; cur != cpu; cur = cur->cpu_next_onln) { rw_exit(&cur->cpu_ft_lock); } +#endif } mutex_exit(&fasttrap_count_mtx); } @@ -880,13 +978,16 @@ static void fasttrap_pid_enable(void *arg, dtrace_id_t id, void *parg) { fasttrap_probe_t *probe = parg; - proc_t *p; + proc_t *p = NULL; int i, rc; + ASSERT(probe != NULL); ASSERT(!probe->ftp_enabled); ASSERT(id == probe->ftp_id); +#if defined(sun) ASSERT(MUTEX_HELD(&cpu_lock)); +#endif /* * Increment the count of enabled probes on this probe's provider; @@ -911,6 +1012,7 @@ fasttrap_pid_enable(void *arg, dtrace_id * a fork in which the traced process is being born and we're copying * USDT probes. Otherwise, the process is gone so bail. */ +#if defined(sun) if ((p = sprlock(probe->ftp_pid)) == NULL) { if ((curproc->p_flag & SFORKING) == 0) return; @@ -934,12 +1036,23 @@ fasttrap_pid_enable(void *arg, dtrace_id ASSERT(!(p->p_flag & SVFORK)); mutex_exit(&p->p_lock); +#else + if ((p = pfind(probe->ftp_pid)) == NULL) + return; +#endif /* * We have to enable the trap entry point before any user threads have * the chance to execute the trap instruction we're about to place * in their process's text. */ +#ifdef __FreeBSD__ + /* + * pfind() returns a locked process. + */ + _PHOLD(p); + PROC_UNLOCK(p); +#endif fasttrap_enable_callbacks(); /* @@ -967,8 +1080,12 @@ fasttrap_pid_enable(void *arg, dtrace_id i--; } +#if defined(sun) mutex_enter(&p->p_lock); sprunlock(p); +#else + PRELE(p); +#endif /* * Since we're not actually enabling this probe, @@ -978,9 +1095,12 @@ fasttrap_pid_enable(void *arg, dtrace_id return; } } - +#if defined(sun) mutex_enter(&p->p_lock); sprunlock(p); +#else + PRELE(p); +#endif probe->ftp_enabled = 1; } @@ -996,18 +1116,22 @@ fasttrap_pid_disable(void *arg, dtrace_i ASSERT(id == probe->ftp_id); + mutex_enter(&provider->ftp_mtx); + /* * We won't be able to acquire a /proc-esque lock on the process * iff the process is dead and gone. In this case, we rely on the * provider lock as a point of mutual exclusion to prevent other * DTrace consumers from disabling this probe. */ - if ((p = sprlock(probe->ftp_pid)) != NULL) { - ASSERT(!(p->p_flag & SVFORK)); - mutex_exit(&p->p_lock); + if ((p = pfind(probe->ftp_pid)) == NULL) { + mutex_exit(&provider->ftp_mtx); + return; } - - mutex_enter(&provider->ftp_mtx); +#ifdef __FreeBSD__ + _PHOLD(p); + PROC_UNLOCK(p); +#endif /* * Disable all the associated tracepoints (for fully enabled probes). @@ -1030,9 +1154,6 @@ fasttrap_pid_disable(void *arg, dtrace_i if (provider->ftp_retired && !provider->ftp_marked) whack = provider->ftp_marked = 1; mutex_exit(&provider->ftp_mtx); - - mutex_enter(&p->p_lock); - sprunlock(p); } else { /* * If the process is dead, we're just waiting for the @@ -1046,12 +1167,17 @@ fasttrap_pid_disable(void *arg, dtrace_i if (whack) fasttrap_pid_cleanup(); +#ifdef __FreeBSD__ + PRELE(p); +#endif if (!probe->ftp_enabled) return; probe->ftp_enabled = 0; +#if defined(sun) ASSERT(MUTEX_HELD(&cpu_lock)); +#endif fasttrap_disable_callbacks(); } @@ -1163,6 +1289,7 @@ fasttrap_proc_lookup(pid_t pid) fasttrap_bucket_t *bucket; fasttrap_proc_t *fprc, *new_fprc; + bucket = &fasttrap_procs.fth_table[FASTTRAP_PROCS_INDEX(pid)]; mutex_enter(&bucket->ftb_mtx); @@ -1189,6 +1316,10 @@ fasttrap_proc_lookup(pid_t pid) new_fprc->ftpc_pid = pid; new_fprc->ftpc_rcount = 1; new_fprc->ftpc_acount = 1; +#if !defined(sun) + mutex_init(&new_fprc->ftpc_mtx, "fasttrap proc mtx", MUTEX_DEFAULT, + NULL); +#endif *** DIFF OUTPUT TRUNCATED AT 1000 LINES *** From owner-freebsd-stable@FreeBSD.ORG Mon Feb 28 23:48:00 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 04ECC1065672 for ; Mon, 28 Feb 2011 23:48:00 +0000 (UTC) (envelope-from stephen@missouri.edu) Received: from mxnip01-missouri-out.um.umsystem.edu (mxnip01-missouri-out.um.umsystem.edu [209.106.229.53]) by mx1.freebsd.org (Postfix) with ESMTP id BB1BC8FC17 for ; Mon, 28 Feb 2011 23:47:59 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEADrDa03RauQ0/2dsb2JhbACmR3SyXohqhWEEhRKKSwY Received: from um-nsmtpin1.um.umsystem.edu ([209.106.228.52]) by mxnip01-mizzou-out.um.umsystem.edu with ESMTP; 28 Feb 2011 17:47:58 -0600 Received: from um-nsmtpout1.um.umsystem.edu ([209.106.228.53]) by um-nsmtpin1.um.umsystem.edu with Microsoft SMTPSVC(6.0.3790.4675); Mon, 28 Feb 2011 17:47:58 -0600 Received: from [192.168.1.69] ([173.202.227.194]) by um-nsmtpout1.um.umsystem.edu with Microsoft SMTPSVC(6.0.3790.4675); Mon, 28 Feb 2011 17:47:58 -0600 Message-ID: <4D6C342C.4030709@missouri.edu> Date: Mon, 28 Feb 2011 17:47:56 -0600 From: Stephen Montgomery-Smith User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.16) Gecko/20101206 SeaMonkey/2.0.11 MIME-Version: 1.0 To: Jeremy Chadwick References: <4D6BD83B.3040609@missouri.edu> <20110228233207.GA33800@icarus.home.lan> In-Reply-To: <20110228233207.GA33800@icarus.home.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Feb 2011 23:47:58.0095 (UTC) FILETIME=[ED4A09F0:01CBD7A1] Cc: FreeBSD Stable Subject: Re: Change in behavior to stat(1) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 28 Feb 2011 23:48:00 -0000 Jeremy Chadwick wrote: > Possibly you could use the example from the find(1) man page: > > find -L /usr/ports/packages -type l -exec rm -- {} + > Delete all broken symbolic links in /usr/ports/packages. > > (Note that the "+" on the end is not a typo, see the man page) Brilliant! Since this is *precisely* the purpose of my script, I think I will use this code instead, From owner-freebsd-stable@FreeBSD.ORG Tue Mar 1 06:48:08 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 59972106564A for ; Tue, 1 Mar 2011 06:48:08 +0000 (UTC) (envelope-from ml@netfence.it) Received: from cp-out7.libero.it (cp-out7.libero.it [212.52.84.107]) by mx1.freebsd.org (Postfix) with ESMTP id DBCA48FC08 for ; Tue, 1 Mar 2011 06:48:07 +0000 (UTC) X-CTCH-Spam: Unknown X-CTCH-RefID: str=0001.0A0B0201.4D6C96A6.00B7,ss=1,re=0.000,fgs=0 X-libjamoibt: 1555 Received: from soth.ventu (151.51.54.55) by cp-out7.libero.it (8.5.133) id 4D63CB8F00E8E55E for freebsd-stable@freebsd.org; Tue, 1 Mar 2011 07:48:06 +0100 Received: from alamar.ventu (alamar.ventu [10.1.2.18]) by soth.ventu (8.14.4/8.14.4) with ESMTP id p216lcGM067184 for ; Tue, 1 Mar 2011 07:47:38 +0100 (CET) (envelope-from ml@netfence.it) Message-ID: <4D6C968A.3040400@netfence.it> Date: Tue, 01 Mar 2011 07:47:38 +0100 From: Andrea Venturoli User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; it-IT; rv:1.9.2.13) Gecko/20101211 Thunderbird/3.1.7 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <201102091420.p19EKJ5u001268@m5p.com> <20110217032858.GA17686@icarus.home.lan> <4D5D8DF0.8080900@netfence.it> In-Reply-To: <4D5D8DF0.8080900@netfence.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.1.2.13 Subject: Re: statd/lockd startup failure X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2011 06:48:08 -0000 On 02/17/11 22:06, Andrea Venturoli wrote: >> I >>> seem to remember a similar problem I had a long time ago. I opted to >>> use a consistent, not-used port and haven't seen the problem since >>> (this was years ago, so I can't remember if the error you're seeing >>> was identical to mine). >>> >>> /etc/rc.conf: >>> rpc_statd_flags="-p 898" >>> rpc_lockd_flags="-p 4045" > > I have: > rpc_statd_flags="-p 918" > rpc_lockd_flags="-p 868" > > > Still statd occasionally fails to start. > > It might be that something else has already bound to port 918, though I > don't know what. > I'll check as soon as I have the chance. It happened this morning: lockd could not start and I verified it was an NFS mount which used port 868 as a client. Now I'm trying the noresvport to mount_nfs... bye av. From owner-freebsd-stable@FreeBSD.ORG Tue Mar 1 07:39:26 2011 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 6987F106566B for ; Tue, 1 Mar 2011 07:39:26 +0000 (UTC) (envelope-from cperciva@freebsd.org) Received: from xps.daemonology.net (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx2.freebsd.org (Postfix) with SMTP id 19CC5152129 for ; Tue, 1 Mar 2011 07:39:26 +0000 (UTC) Received: (qmail 16952 invoked from network); 1 Mar 2011 07:39:35 -0000 Received: from unknown (HELO xps.daemonology.net) (127.0.0.1) by localhost with SMTP; 1 Mar 2011 07:39:35 -0000 Message-ID: <4D6CA2B6.3020000@freebsd.org> Date: Mon, 28 Feb 2011 23:39:34 -0800 From: FreeBSD Security Officer Organization: FreeBSD Project User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.16) Gecko/20101220 Thunderbird/3.0.11 MIME-Version: 1.0 To: freebsd security , FreeBSD Stable X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: FreeBSD supported branches update 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: Tue, 01 Mar 2011 07:39:26 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello Everyone, The branches supported by the FreeBSD Security Officer have been updated to reflect the EoL (end-of-life) of FreeBSD 7.1. The new list of supported branches is below and at < http://security.freebsd.org/ >. Users of FreeBSD 7.1 are advised to upgrade promptly to a newer release (most likely the recently announced FreeBSD 7.4) either by downloading an updated source tree and building updates manually, or (for i386 and amd64 systems) using the FreeBSD Update utility as described in the relevant release announcement. The current supported branches and expected EoL dates are: +---------------------------------------------------------------------+ | Branch | Release | Type | Release date | Estimated EoL | |-----------+------------+--------+-----------------+-----------------| |RELENG_7 |n/a |n/a |n/a |February 28, 2013| |-----------+------------+--------+-----------------+-----------------| |RELENG_7_3 |7.3-RELEASE |Extended|March 23, 2010 |March 31, 2012 | |-----------+------------+--------+-----------------+-----------------| |RELENG_7_4 |7.4-RELEASE |Extended|February 24, 2011|February 28, 2013| |-----------+------------+--------+-----------------+-----------------| |RELENG_8 |n/a |n/a |n/a |last release + 2y| |-----------+------------+--------+-----------------+-----------------| |RELENG_8_1 |8.1-RELEASE |Extended|July 23, 2010 |July 31, 2012 | |-----------+------------+--------+-----------------+-----------------| |RELENG_8_2 |8.2-RELEASE |Normal |February 24, 2011|February 29, 2012| +---------------------------------------------------------------------+ - -- 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.11 (FreeBSD) iEYEARECAAYFAk1sorYACgkQFdaIBMps37IgAgCePHsPcwZ/3mvoBzB3yvvo5txo bDcAn0ze3I/h6fz90GVCEYm0cqBMFeOL =DopZ -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Tue Mar 1 09:28:26 2011 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 2BF8B106566B; Tue, 1 Mar 2011 09:28:26 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: from mail-ew0-f54.google.com (mail-ew0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 896A28FC17; Tue, 1 Mar 2011 09:28:25 +0000 (UTC) Received: by ewy28 with SMTP id 28so1764605ewy.13 for ; Tue, 01 Mar 2011 01:28:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=Eq2zzYD9dsMSLBenKSHzJw8Rr0breA8Ma5gyG/R85MQ=; b=pfcRbolBFLpgFoOUkLboE4JmXEarVFtk11TUJa8KTwNIDWoCuWASE1UvnAlSZikoG6 SsTZHzGY0OVwsX60OgmRd884Wk4YyisX9SfRCloYfB0+YywzvW/0HLhMAMWZPdaijfQp yDqm2X4PEM3wBQsryRf1umidMMwhoYl/na5os= 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=iH7jnLkERmRO8Rp/7pd98P5rc+sYIMnhMJPlghWQnKvBvt49qH+AZPbTzLw5eKOYCw mTidwROyIAwRXmfCxwi8SWhtiwYBzU7dzP4ZWeeVWo0XcmDjVa01OYU/uVoZ32hyFJH+ A4HiHTVttf0Aju3bS9k3s+lDTBDSO0CdWIjU4= Received: by 10.213.16.78 with SMTP id n14mr2455879eba.99.1298970192016; Tue, 01 Mar 2011 01:03:12 -0800 (PST) Received: from mytaht-2.totalterror.net (93-152-151-19.ddns.onlinedirect.bg [93.152.151.19]) by mx.google.com with ESMTPS id b52sm3982647eei.13.2011.03.01.01.03.10 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 01 Mar 2011 01:03:11 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Nikolay Denev In-Reply-To: Date: Tue, 1 Mar 2011 11:03:07 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Robert Watson X-Mailer: Apple Mail (2.1082) Cc: stable@FreeBSD.org Subject: Re: FYI: Userspace DTrace MFC to stable/8 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 09:28:26 -0000 On 1 Mar, 2011, at 01:33 , Robert Watson wrote: > Dear all: >=20 > Just an FYI that I've gone ahead and merged userspace DTrace support = to FreeBSD 8.x from 9.x. While it appeared to pass build tests locally, = boot and run, etc, this is a non-trivial merge, and it's possible I've = messed up. If so, apologies in advance, and I'll try to resolve any = problems as quickly as I can! >=20 > And of course, many thanks go to Rui Paulo, who did the port of = userspace DTrace to FreeBSD 9.x with support from the FreeBSD = Foundation! >=20 > Thanks, >=20 > Robert N M Watson > Computer Laboratory > University of Cambridge >=20 That's great news! Many thanks to all that made this possible! I have a quick question though, now do I have to rebuild my world with = "WITH_CTF" ? I'm asking because I did that by mistake some months ago on a RELENG_8 = machine, and the world that was built had some problems, like gcc giving segfault 11 = while compiling world or some ports. Regards, Nikolay From owner-freebsd-stable@FreeBSD.ORG Tue Mar 1 09:42:00 2011 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 61E70106564A for ; Tue, 1 Mar 2011 09:42:00 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta10.emeryville.ca.mail.comcast.net (qmta10.emeryville.ca.mail.comcast.net [76.96.30.17]) by mx1.freebsd.org (Postfix) with ESMTP id 43DB28FC23 for ; Tue, 1 Mar 2011 09:41:59 +0000 (UTC) Received: from omta08.emeryville.ca.mail.comcast.net ([76.96.30.12]) by qmta10.emeryville.ca.mail.comcast.net with comcast id Dlhz1g0010FhH24AAlhzdB; Tue, 01 Mar 2011 09:41:59 +0000 Received: from koitsu.dyndns.org ([98.248.33.18]) by omta08.emeryville.ca.mail.comcast.net with comcast id Dlhy1g0070PUQVN8UlhyV3; Tue, 01 Mar 2011 09:41:59 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 7D87D9B422; Tue, 1 Mar 2011 01:41:58 -0800 (PST) Date: Tue, 1 Mar 2011 01:41:58 -0800 From: Jeremy Chadwick To: Nikolay Denev Message-ID: <20110301094158.GA35235@icarus.home.lan> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: stable@FreeBSD.org, Robert Watson Subject: Re: FYI: Userspace DTrace MFC to stable/8 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 09:42:00 -0000 On Tue, Mar 01, 2011 at 11:03:07AM +0200, Nikolay Denev wrote: > On 1 Mar, 2011, at 01:33 , Robert Watson wrote: > > > Dear all: > > > > Just an FYI that I've gone ahead and merged userspace DTrace support to FreeBSD 8.x from 9.x. While it appeared to pass build tests locally, boot and run, etc, this is a non-trivial merge, and it's possible I've messed up. If so, apologies in advance, and I'll try to resolve any problems as quickly as I can! > > > > And of course, many thanks go to Rui Paulo, who did the port of userspace DTrace to FreeBSD 9.x with support from the FreeBSD Foundation! > > > > Thanks, > > > > Robert N M Watson > > Computer Laboratory > > University of Cambridge > > > > That's great news! Many thanks to all that made this possible! > > I have a quick question though, now do I have to rebuild my world with "WITH_CTF" ? > I'm asking because I did that by mistake some months ago on a RELENG_8 machine, and > the world that was built had some problems, like gcc giving segfault 11 while compiling world or some ports. I wasn't able to reproduce such a problem back then, nor am I now. sig11 during builds usually indicates a hardware issue (RAM going bad, system overheating, or maybe some crazy compiler options you've specified in make.conf). Please be aware on RELENG_8 you need to do this: cd /usr/src make buildworld WITH_CTF=1 make buildkernel WITH_CTF=1 make installkernel {...the rest is normal per src/Makefile...} The WITH_CTF=1 portion cannot be put into /etc/src.conf or /etc/make.conf; it must be entered manually. To reiterate and make it extra clear: this is for RELENG_8. HEAD/CURRENT is a completely different story. All of this is documented, albeit in a roundabout way (please be sure to read EVERYTHING SLOWLY and do not skim), here: http://wiki.freebsd.org/DTrace -- | 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 Mar 1 09:42:01 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D26981065678 for ; Tue, 1 Mar 2011 09:42:01 +0000 (UTC) (envelope-from patfbsd@davenulle.org) Received: from smtp.lamaiziere.net (net.lamaiziere.net [91.121.44.19]) by mx1.freebsd.org (Postfix) with ESMTP id 9BC8A8FC15 for ; Tue, 1 Mar 2011 09:42:01 +0000 (UTC) Received: from mr129041.univ-rennes1.fr (mr129041.cri.univ-rennes1.fr [129.20.129.41]) by smtp.lamaiziere.net (Postfix) with ESMTPA id 6292863307B; Tue, 1 Mar 2011 10:26:08 +0100 (CET) Received: from mr129041.univ-rennes1.fr (localhost [127.0.0.1]) by mr129041.univ-rennes1.fr (Postfix) with ESMTP id 213D0B874; Tue, 1 Mar 2011 10:26:08 +0100 (CET) Date: Tue, 1 Mar 2011 10:26:07 +0100 From: Patrick Lamaiziere To: Ken Smith Message-ID: <20110301102607.7f27aa34@mr129041.univ-rennes1.fr> In-Reply-To: <4D66CCFF.9020903@buffalo.edu> References: <4D66CCFF.9020903@buffalo.edu> X-Mailer: Claws Mail 3.7.6 (GTK+ 2.20.1; i386-portbld-freebsd8.1) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: freebsd-stable@freebsd.org Subject: Re: 8.2/7.4-RELEASEs Announced... X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2011 09:42:01 -0000 Le Thu, 24 Feb 2011 16:26:23 -0500, Ken Smith a crit : Hello, > 8.2-RELEASE and 7.4-RELEASE have been announced. The announcement > messages are available here: > > http://www.freebsd.org/releases/8.2R/announce.html There is a small typo in the name of the usb image: memstick This can be written to an USB memory stick (flash drive) and used to do an install on machines capable of booting off USB drives. It also supports booting into a "livefs" based rescue mode. The documentation packages are provided but no other packages. ... # dd if=8.2-RELEASE-amd64-memstick.img of=/dev/da0 bs=10240 conv=sync should be "FreeBSD-8.2-RELEASE-amd64-memstick.img" > Enjoy. :-) Thanks! Regards. From owner-freebsd-stable@FreeBSD.ORG Tue Mar 1 10:05:41 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E45FB106564A for ; Tue, 1 Mar 2011 10:05:41 +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 A59678FC19 for ; Tue, 1 Mar 2011 10:05:41 +0000 (UTC) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta02.westchester.pa.mail.comcast.net with comcast id Dm5b1g0011YDfWL52m5h8B; Tue, 01 Mar 2011 10:05:41 +0000 Received: from koitsu.dyndns.org ([98.248.33.18]) by omta20.westchester.pa.mail.comcast.net with comcast id Dm5f1g0080PUQVN3gm5gM0; Tue, 01 Mar 2011 10:05:41 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 70A2E9B422; Tue, 1 Mar 2011 02:05:38 -0800 (PST) Date: Tue, 1 Mar 2011 02:05:38 -0800 From: Jeremy Chadwick To: Patrick Lamaiziere Message-ID: <20110301100538.GA35711@icarus.home.lan> References: <4D66CCFF.9020903@buffalo.edu> <20110301102607.7f27aa34@mr129041.univ-rennes1.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20110301102607.7f27aa34@mr129041.univ-rennes1.fr> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@freebsd.org, Ken Smith Subject: Re: 8.2/7.4-RELEASEs Announced... X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2011 10:05:42 -0000 On Tue, Mar 01, 2011 at 10:26:07AM +0100, Patrick Lamaiziere wrote: > Le Thu, 24 Feb 2011 16:26:23 -0500, > Ken Smith a crit : > > Hello, > > > 8.2-RELEASE and 7.4-RELEASE have been announced. The announcement > > messages are available here: > > > > http://www.freebsd.org/releases/8.2R/announce.html > > There is a small typo in the name of the usb image: > > memstick > > This can be written to an USB memory stick (flash drive) and used > to do an install on machines capable of booting off USB drives. It > also supports booting into a "livefs" based rescue mode. The > documentation packages are provided but no other packages. > ... > # dd if=8.2-RELEASE-amd64-memstick.img of=/dev/da0 bs=10240 > conv=sync > > should be "FreeBSD-8.2-RELEASE-amd64-memstick.img" Not to mention, the block size specified doesn't jibe with what's in the FreeBSD Handbook (which uses bs=64k): http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/install-pre.html Other users have pointed this out to me on my blog, wondering exactly where bs=10240 came from. So, the release notes going forward should probably use bs=64k. -- | 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 Mar 1 10:10:20 2011 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 E5F61106566B; Tue, 1 Mar 2011 10:10:20 +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 63A3C8FC13; Tue, 1 Mar 2011 10:10:19 +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 p21AAFAn032074 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 Mar 2011 12:10:16 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id p21AAFXp030032; Tue, 1 Mar 2011 12:10:15 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id p21AAFRY030031; Tue, 1 Mar 2011 12:10:15 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 1 Mar 2011 12:10:15 +0200 From: Kostik Belousov To: Nikolay Denev Message-ID: <20110301101015.GN78089@deviant.kiev.zoral.com.ua> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="TF5tnWOuabrXJ+rg" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-3.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, 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: stable@freebsd.org, Robert Watson Subject: Re: FYI: Userspace DTrace MFC to stable/8 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 10:10:21 -0000 --TF5tnWOuabrXJ+rg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Mar 01, 2011 at 11:03:07AM +0200, Nikolay Denev wrote: > On 1 Mar, 2011, at 01:33 , Robert Watson wrote: >=20 > > Dear all: > >=20 > > Just an FYI that I've gone ahead and merged userspace DTrace support to= FreeBSD 8.x from 9.x. While it appeared to pass build tests locally, boot= and run, etc, this is a non-trivial merge, and it's possible I've messed u= p. If so, apologies in advance, and I'll try to resolve any problems as qu= ickly as I can! > >=20 > > And of course, many thanks go to Rui Paulo, who did the port of userspa= ce DTrace to FreeBSD 9.x with support from the FreeBSD Foundation! > >=20 > > Thanks, > >=20 > > Robert N M Watson > > Computer Laboratory > > University of Cambridge > >=20 >=20 > That's great news! Many thanks to all that made this possible! >=20 > I have a quick question though, now do I have to rebuild my world with "W= ITH_CTF" ? > I'm asking because I did that by mistake some months ago on a RELENG_8 ma= chine, and > the world that was built had some problems, like gcc giving segfault 11 w= hile compiling world or some ports. >=20 It was a known issue that ctfconvert (I think it is ctfconvert) damages statically linked binaries. Most likely, it was not fixed yet. --TF5tnWOuabrXJ+rg Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk1sxgcACgkQC3+MBN1Mb4hZ7wCePEddEFlD3cPe1Fhz6ysndc7B KAwAoMAoTbjy+wsw3bfC4aCmsyb6ysRy =TSjC -----END PGP SIGNATURE----- --TF5tnWOuabrXJ+rg-- From owner-freebsd-stable@FreeBSD.ORG Tue Mar 1 14:02:49 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8C04C106564A for ; Tue, 1 Mar 2011 14:02:49 +0000 (UTC) (envelope-from kensmith@buffalo.edu) Received: from localmailA.acsu.buffalo.edu (localmailA.acsu.buffalo.edu [128.205.5.196]) by mx1.freebsd.org (Postfix) with ESMTP id 5A8128FC08 for ; Tue, 1 Mar 2011 14:02:49 +0000 (UTC) Received: from localmailA.acsu.buffalo.edu (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 30CF6CA45; Tue, 1 Mar 2011 09:02:38 -0500 (EST) Received: from localmailA.acsu.buffalo.edu (localhost [127.0.0.1]) by localmailA.acsu.buffalo.edu (Postfix) with ESMTP id 47659CA43; Tue, 1 Mar 2011 09:02:35 -0500 (EST) Received: from mweb2.acsu.buffalo.edu (mweb2.acsu.buffalo.edu [128.205.5.239]) by localmailA.acsu.buffalo.edu (Prefixe) with ESMTP id 3F512B2BF; Tue, 1 Mar 2011 09:02:35 -0500 (EST) Received: from [128.205.32.76] (bauer.cse.buffalo.edu [128.205.32.76]) by mweb2.acsu.buffalo.edu (Postfix) with ESMTP id 2E790207B6; Tue, 1 Mar 2011 09:02:35 -0500 (EST) From: Ken Smith To: Patrick Lamaiziere In-Reply-To: <20110301102607.7f27aa34@mr129041.univ-rennes1.fr> References: <4D66CCFF.9020903@buffalo.edu> <20110301102607.7f27aa34@mr129041.univ-rennes1.fr> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-6415I+UpRWSdsdqS6ygf" Date: Tue, 01 Mar 2011 09:02:26 -0500 Message-ID: <1298988146.78083.3.camel@bauer.cse.buffalo.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.28.2 FreeBSD GNOME Team Port X-PM-EL-Spam-Prob: : 8% Cc: freebsd-stable@freebsd.org Subject: Re: 8.2/7.4-RELEASEs Announced... X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2011 14:02:49 -0000 --=-6415I+UpRWSdsdqS6ygf Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable On Tue, 2011-03-01 at 10:26 +0100, Patrick Lamaiziere wrote: > Le Thu, 24 Feb 2011 16:26:23 -0500, > Ken Smith a =E9crit : >=20 > Hello, >=20 > > 8.2-RELEASE and 7.4-RELEASE have been announced. The announcement > > messages are available here: > >=20 > > http://www.freebsd.org/releases/8.2R/announce.html >=20 > There is a small typo in the name of the usb image: > =AB > memstick >=20 > This can be written to an USB memory stick (flash drive) and used > to do an install on machines capable of booting off USB drives. It > also supports booting into a "livefs" based rescue mode. The > documentation packages are provided but no other packages. > ... > # dd if=3D8.2-RELEASE-amd64-memstick.img of=3D/dev/da0 bs=3D10240 > conv=3Dsync > =BB > should be "FreeBSD-8.2-RELEASE-amd64-memstick.img" >=20 > > Enjoy. :-) >=20 > Thanks! > Regards. >=20 >=20 Hmm, it's right in the message sent to announce@ but not in the Web version. I had made that typo in previous announcements but corrected it with 8.2's announcement. I'll see if it can be fixed in the Web version. --=20 Ken Smith - From there to here, from here to | kensmith@buffalo.edu there, funny things are everywhere. | - Theodor Geisel | --=-6415I+UpRWSdsdqS6ygf Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEABECAAYFAk1s/GkACgkQ/G14VSmup/YrxwCeMiOS7dcEjYr0au2vqy9IDd00 7XEAn26kbZv+QWtB4kiDw2VxUPn65dip =bOKz -----END PGP SIGNATURE----- --=-6415I+UpRWSdsdqS6ygf-- From owner-freebsd-stable@FreeBSD.ORG Tue Mar 1 14:07:23 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A3FCB106566C for ; Tue, 1 Mar 2011 14:07:23 +0000 (UTC) (envelope-from kensmith@buffalo.edu) Received: from localmailC.acsu.buffalo.edu (localmailC.acsu.buffalo.edu [128.205.5.204]) by mx1.freebsd.org (Postfix) with ESMTP id 712EE8FC19 for ; Tue, 1 Mar 2011 14:07:21 +0000 (UTC) Received: from localmailC.acsu.buffalo.edu (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id E04791DD7B; Tue, 1 Mar 2011 09:07:20 -0500 (EST) Received: from localmailC.acsu.buffalo.edu (localhost [127.0.0.1]) by localmailC.acsu.buffalo.edu (Postfix) with ESMTP id 1E8A01DDB9; Tue, 1 Mar 2011 09:07:20 -0500 (EST) Received: from mweb3.acsu.buffalo.edu (mweb3.acsu.buffalo.edu [128.205.5.240]) by localmailC.acsu.buffalo.edu (Prefixe) with ESMTP id 1587F97D2; Tue, 1 Mar 2011 09:07:20 -0500 (EST) Received: from [128.205.32.76] (bauer.cse.buffalo.edu [128.205.32.76]) by mweb3.acsu.buffalo.edu (Postfix) with ESMTP id F1846309453; Tue, 1 Mar 2011 09:07:19 -0500 (EST) From: Ken Smith To: Jeremy Chadwick In-Reply-To: <20110301100538.GA35711@icarus.home.lan> References: <4D66CCFF.9020903@buffalo.edu> <20110301102607.7f27aa34@mr129041.univ-rennes1.fr> <20110301100538.GA35711@icarus.home.lan> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-vxOP+qhOkhwUeeticsfq" Date: Tue, 01 Mar 2011 09:07:19 -0500 Message-ID: <1298988439.78083.8.camel@bauer.cse.buffalo.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.28.2 FreeBSD GNOME Team Port X-PM-EL-Spam-Prob: : 8% Cc: freebsd-stable@freebsd.org, Patrick Lamaiziere Subject: Re: 8.2/7.4-RELEASEs Announced... X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2011 14:07:23 -0000 --=-vxOP+qhOkhwUeeticsfq Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Tue, 2011-03-01 at 02:05 -0800, Jeremy Chadwick wrote: > Not to mention, the block size specified doesn't jibe with what's in the > FreeBSD Handbook (which uses bs=3D64k): >=20 > http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/install-pre.htm= l >=20 > Other users have pointed this out to me on my blog, wondering exactly > where bs=3D10240 came from. So, the release notes going forward should > probably use bs=3D64k. I'll try to remember to adjust that for 8.3. I started off suggesting the 10240 value because that's what gets used in the script that builds the memstick images (and the block size there is used for some mathematics to determine file sizes so a larger size would potentially waste more space...). But as people with less patience than me have noticed 64k results in a much faster transfer... ;-) --=20 Ken Smith - From there to here, from here to | kensmith@buffalo.edu there, funny things are everywhere. | - Theodor Geisel | --=-vxOP+qhOkhwUeeticsfq Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEABECAAYFAk1s/ZcACgkQ/G14VSmup/bvzwCfUz+ztOgQ52zK0CAgAszuHgYf H6AAnRcBNSAAIFWQzzRCDjm1bbI5gMw9 =wJuo -----END PGP SIGNATURE----- --=-vxOP+qhOkhwUeeticsfq-- From owner-freebsd-stable@FreeBSD.ORG Tue Mar 1 14:21:12 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B8AD71065670; Tue, 1 Mar 2011 14:21:12 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1-6.sentex.ca [IPv6:2607:f3e0:0:1::12]) by mx1.freebsd.org (Postfix) with ESMTP id 6BF158FC15; Tue, 1 Mar 2011 14:21:12 +0000 (UTC) Received: from [IPv6:2607:f3e0:0:4:70a2:fcc4:61cd:a28a] ([IPv6:2607:f3e0:0:4:70a2:fcc4:61cd:a28a]) by smarthost1.sentex.ca (8.14.4/8.14.4) with ESMTP id p21EL80d025829 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 1 Mar 2011 09:21:08 -0500 (EST) (envelope-from mike@sentex.net) Message-ID: <4D6D00C1.1040805@sentex.net> Date: Tue, 01 Mar 2011 09:20:49 -0500 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: =?UTF-8?B?w5Z6a2FuIEtJUklL?= , Jan Koum References: <1975926365.20110223121637@serebryakov.spb.ru> <4D64EC8C.2080007@sentex.net> <1004451940.20110223143607@serebryakov.spb.ru> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.67 on IPv6:2607:f3e0:0:1::12 Cc: freebsd-net@freebsd.org, Jack Vogel , freebsd-stable@freebsd.org Subject: Re: em0 with latest driver hangs again and again (without "Watchdog timeout" message!) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2011 14:21:12 -0000 I have been running with 7.2.2 and so far so good. However, its hard to say in my case as the box I would only periodically see the issue. Jan, have you had a chance to try 7.2.2 ? You seemed to hit the issue the most frequently. There are also some alternate patches in http://www.freebsd.org/cgi/query-pr.cgi?pr=150516 But I think Jack said 7.2.2 takes a similar strategy ? ---Mike On 2/24/2011 3:03 AM, Özkan KIRIK wrote: > Thank you. I'll test and share my experiences with you. > > On Wed, Feb 23, 2011 at 7:47 PM, Jack Vogel wrote: >> Here is the 7.2.2 tarball. IMPORTANT: if you use this DO NOT try and put it >> into your kernel source tree, it will break that. What you must do is config >> the >> em driver OUT of your kernel, then untar this, build it standalone, and then >> load it. >> >> This is just a temporary thing, once I have data to decide on this change vs >> the earlier one it will get integrated. >> >> Jack >> >> >> 2011/2/23 Özkan KIRIK >>> >>> Hi, >>> >>> How can we get 7.2.2. version of if_em driver ? >>> I wanna test it. >>> >>> I can help you for testing changes to em drivers. >>> >>> >>> Regards, >>> Ozkan KIRIK >>> >>> On Wed, Feb 23, 2011 at 1:36 PM, Lev Serebryakov >>> wrote: >>>> Hello, Mike. >>>> You wrote 23 февраля 2011 г., 14:16:28: >>>> >>>>>> Driver from "em driver, 82574L chip, and possibly ASPM" thread >>>>>> doesn't help, really: it seems, that it decrease frequincy of hangs, >>>>> Looking at your sysctl output, you are not using the test drivers >>>>> posted >>>>> in that thread. >>>> Yes, as it doesn't help, I've reverted to "stock" one. >>>> >>>>> If you want to try 7.1.9-test, you can download it at >>>>> http://www.tancsa.com/if_em-8.c for releng_8. >>>> I've tried it. It has worked without hangs for 7-8 days, and after >>>> that hangs 2 times in 3 days with "7.1.9-test" :( >>>> >>>> -- >>>> // Black Lion AKA Lev Serebryakov >>>> >>>> _______________________________________________ >>>> 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" >>>> >> >> > > -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From owner-freebsd-stable@FreeBSD.ORG Tue Mar 1 19:58:10 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 42961106566C; Tue, 1 Mar 2011 19:58:10 +0000 (UTC) (envelope-from lev@serebryakov.spb.ru) Received: from ftp.translate.ru (ftp.translate.ru [80.249.188.42]) by mx1.freebsd.org (Postfix) with ESMTP id EBE068FC0A; Tue, 1 Mar 2011 19:58:09 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (89.112.15.178.pppoe.eltel.net [89.112.15.178]) (Authenticated sender: lev@serebryakov.spb.ru) by ftp.translate.ru (Postfix) with ESMTPA id CA78F13DF42; Tue, 1 Mar 2011 22:52:25 +0300 (MSK) Date: Tue, 1 Mar 2011 22:52:15 +0300 From: Lev Serebryakov X-Priority: 3 (Normal) Message-ID: <1416421652.20110301225215@serebryakov.spb.ru> To: Mike Tancsa In-Reply-To: <4D6D00C1.1040805@sentex.net> References: <1975926365.20110223121637@serebryakov.spb.ru> <4D64EC8C.2080007@sentex.net> <1004451940.20110223143607@serebryakov.spb.ru> <4D6D00C1.1040805@sentex.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org, =?utf-8?Q?=C3=96zkan_KIRIK?= , Jan Koum , Jack Vogel Subject: Re: em0 with latest driver hangs again and again (without "Watchdog timeout" message!) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2011 19:58:10 -0000 Hello, Mike. You wrote 1 =D0=BC=D0=B0=D1=80=D1=82=D0=B0 2011 =D0=B3., 17:20:49: > I have been running with 7.2.2 and so far so good. However, its hard to > say in my case as the box I would only periodically see the issue. As I wrote to Jack, my NIC hangs today with 7.2.2 --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-stable@FreeBSD.ORG Wed Mar 2 01:50:14 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 04318106566B for ; Wed, 2 Mar 2011 01:50:14 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1-6.sentex.ca [IPv6:2607:f3e0:0:1::12]) by mx1.freebsd.org (Postfix) with ESMTP id B57F38FC0C for ; Wed, 2 Mar 2011 01:50:13 +0000 (UTC) Received: from [IPv6:2607:f3e0:0:4:b465:c134:204f:fc84] ([IPv6:2607:f3e0:0:4:b465:c134:204f:fc84]) by smarthost1.sentex.ca (8.14.4/8.14.4) with ESMTP id p221oBkW034915 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Tue, 1 Mar 2011 20:50:12 -0500 (EST) (envelope-from mike@sentex.net) Message-ID: <4D6DA259.4050307@sentex.net> Date: Tue, 01 Mar 2011 20:50:17 -0500 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: FreeBSD-STABLE Mailing List X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on IPv6:2607:f3e0:0:1::12 Subject: CPU0: local APIC error 0x40 CPU1: local APIC error 0x40 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2011 01:50:14 -0000 I had a machine deadlock just now and the only thing on the serial console was CPU0: local APIC error 0x40 CPU1: local APIC error 0x40 prior to it hanging. Anyone know what that error is ? Googling didnt really show much definitive. Someone suggested bad hardware ? Is there a way to narrow that down ? Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(R) CPU 3050 @ 2.13GHz (2128.01-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x6f6 Family = 6 Model = f Stepping = 6 Features=0xbfebfbff Features2=0xe3bd AMD Features=0x20100000 AMD Features2=0x1 TSC: P-state invariant real memory = 4294967296 (4096 MB) avail memory = 3676545024 (3506 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 irqs 0-23 on motherboard ioapic1 irqs 24-47 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) 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 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 16 at device 1.0 on pci0 pci1: on pcib1 pcib2: irq 17 at device 28.0 on pci0 pci9: on pcib2 pcib3: at device 0.0 on pci9 pci10: on pcib3 em0: port 0x4000-0x403f mem 0xe0240000-0xe025ffff,0xe0200000-0xe023ffff irq 24 at device 1.0 on pci10 em0: [FILTER] em0: Ethernet address: 00:1b:21:08:32:a8 em1: port 0x4040-0x407f mem 0xe0260000-0xe027ffff,0xe0280000-0xe02bffff irq 25 at device 1.1 on pci10 em1: [FILTER] em1: Ethernet address: 00:1b:21:08:32:a9 pcib4: irq 17 at device 28.4 on pci0 pci13: on pcib4 ---Mike -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From owner-freebsd-stable@FreeBSD.ORG Wed Mar 2 02:04:15 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BEB2E106566B for ; Wed, 2 Mar 2011 02:04:15 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [76.96.59.228]) by mx1.freebsd.org (Postfix) with ESMTP id 66A938FC12 for ; Wed, 2 Mar 2011 02:04:14 +0000 (UTC) Received: from omta13.westchester.pa.mail.comcast.net ([76.96.62.52]) by qmta15.westchester.pa.mail.comcast.net with comcast id E20z1g00617dt5G5F24FSn; Wed, 02 Mar 2011 02:04:15 +0000 Received: from koitsu.dyndns.org ([98.248.33.18]) by omta13.westchester.pa.mail.comcast.net with comcast id E24D1g01M0PUQVN3Z24EqR; Wed, 02 Mar 2011 02:04:15 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 46CEE9B422; Tue, 1 Mar 2011 18:04:12 -0800 (PST) Date: Tue, 1 Mar 2011 18:04:12 -0800 From: Jeremy Chadwick To: Mike Tancsa Message-ID: <20110302020412.GA50962@icarus.home.lan> References: <4D6DA259.4050307@sentex.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D6DA259.4050307@sentex.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: FreeBSD-STABLE Mailing List Subject: Re: CPU0: local APIC error 0x40 CPU1: local APIC error 0x40 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2011 02:04:15 -0000 On Tue, Mar 01, 2011 at 08:50:17PM -0500, Mike Tancsa wrote: > I had a machine deadlock just now and the only thing on the serial > console was > > CPU0: local APIC error 0x40 > CPU1: local APIC error 0x40 > > prior to it hanging. Anyone know what that error is ? Googling didnt > really show much definitive. Someone suggested bad hardware ? Is there > a way to narrow that down ? The error in question I'm not familiar with, but the code in src/sys/x86/x86/local_apic.c indicates that 0x40 is the contents of the LAPIC ESR (error status register). Please provide full output from a verbose boot. -- | 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 Mar 2 02:32:56 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9FF731065670 for ; Wed, 2 Mar 2011 02:32:56 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1-6.sentex.ca [IPv6:2607:f3e0:0:1::12]) by mx1.freebsd.org (Postfix) with ESMTP id 0E24A8FC14 for ; Wed, 2 Mar 2011 02:32:55 +0000 (UTC) Received: from [IPv6:2607:f3e0:0:4:b465:c134:204f:fc84] ([IPv6:2607:f3e0:0:4:b465:c134:204f:fc84]) by smarthost1.sentex.ca (8.14.4/8.14.4) with ESMTP id p222Wqag036902 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 1 Mar 2011 21:32:53 -0500 (EST) (envelope-from mike@sentex.net) Message-ID: <4D6DAC5A.6080904@sentex.net> Date: Tue, 01 Mar 2011 21:32:58 -0500 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Jeremy Chadwick References: <4D6DA259.4050307@sentex.net> <20110302020412.GA50962@icarus.home.lan> In-Reply-To: <20110302020412.GA50962@icarus.home.lan> X-Enigmail-Version: 1.1.1 Content-Type: multipart/mixed; boundary="------------000907060408030108000302" X-Scanned-By: MIMEDefang 2.67 on IPv6:2607:f3e0:0:1::12 Cc: FreeBSD-STABLE Mailing List Subject: Re: CPU0: local APIC error 0x40 CPU1: local APIC error 0x40 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2011 02:32:56 -0000 This is a multi-part message in MIME format. --------------000907060408030108000302 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 3/1/2011 9:04 PM, Jeremy Chadwick wrote: > On Tue, Mar 01, 2011 at 08:50:17PM -0500, Mike Tancsa wrote: >> I had a machine deadlock just now and the only thing on the serial >> console was >> >> CPU0: local APIC error 0x40 >> CPU1: local APIC error 0x40 > > The error in question I'm not familiar with, but the code in > src/sys/x86/x86/local_apic.c indicates that 0x40 is the contents of the > LAPIC ESR (error status register). > > Please provide full output from a verbose boot. Attached as a .txt file -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ --------------000907060408030108000302 Content-Type: text/plain; name="dmesg.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="dmesg.txt" Preloaded elf kernel "/boot/kernel/kernel" at 0xc0af0000. Preloaded elf module "/boot/kernel/if_disc.ko" at 0xc0af01b0. Preloaded elf module "/boot/kernel/coretemp.ko" at 0xc0af025c. Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 2128015344 Hz CPU: Intel(R) Xeon(R) CPU 3050 @ 2.13GHz (2128.02-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x6f6 Family = 6 Model = f Stepping = 6 Features=0xbfebfbff Features2=0xe3bd AMD Features=0x20100000 AMD Features2=0x1 TSC: P-state invariant Instruction TLB: 4 KB Pages, 4-way set associative, 128 entries 2nd-level cache: 2-MB, 8-way set associative, 64-byte line size 1st-level instruction cache: 32 KB, 8-way set associative, 64 byte line size 1st-level data cache: 32 KB, 8-way set associative, 64 byte line size L2 cache: 2048 kbytes, 8-way associative, 64 bytes/line real memory = 4294967296 (4096 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009bfff, 634880 bytes (155 pages) 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) 0x0000000000c26000 - 0x00000000dbf7ffff, 3677724672 bytes (897882 pages) avail memory = 3676545024 (3506 MB) Table 'FACP' at 0xdfee8e51 Table 'MCFG' at 0xdfee8ec5 Table 'APIC' at 0xdfee8f01 APIC: Found table at 0xdfee8f01 MP Configuration Table version 1.4 found at 0xc009d5a1 APIC: Using the MADT enumerator. MADT: Found CPU APIC ID 0 ACPI ID 0: enabled SMP: Added CPU 0 (AP) MADT: Found CPU APIC ID 1 ACPI ID 1: enabled SMP: Added CPU 1 (AP) ACPI APIC Table: INTR: Adding local APIC 1 as a target FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 bios32: Found BIOS32 Service Directory header at 0xc00f5e90 bios32: Entry = 0xfd470 (c00fd470) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xfd470+0x29e pnpbios: Found PnP BIOS data at 0xc00f5ee0 pnpbios: Entry = f0000:b19b Rev = 1.0 Other BIOS signatures found: x86bios: IVT 0x000000-0x0004ff at 0xc0000000 x86bios: SSEG 0x010000-0x01ffff at 0xc6988000 x86bios: EBDA 0x09d000-0x09ffff at 0xc009d000 x86bios: ROM 0x0a0000-0x0effff at 0xc00a0000 APIC: CPU 0 has ACPI ID 0 APIC: CPU 1 has ACPI ID 1 ULE: setup cpu 0 ULE: setup cpu 1 ACPI: RSDP 0xf5e40 00014 (v00 PTLTD ) ACPI: RSDT 0xdfee25c4 0003C (v01 PTLTD RSDT 06040000 LTP 00000000) ACPI: FACP 0xdfee8e51 00074 (v01 INTEL 06040000 PTL 00000003) ACPI: DSDT 0xdfee39ec 05465 (v01 INTEL GLENWOOD 06040000 MSFT 0100000E) ACPI: FACS 0xdfee9fc0 00040 ACPI: MCFG 0xdfee8ec5 0003C (v01 PTLTD MCFG 06040000 LTP 00000000) ACPI: APIC 0xdfee8f01 00074 (v01 PTLTD ? APIC 06040000 LTP 00000000) ACPI: BOOT 0xdfee8f75 00028 (v01 PTLTD $SBFTBL$ 06040000 LTP 00000001) ACPI: ASF! 0xdfee8f9d 00063 (v32 CETP CETP 06040000 PTL 00000001) ACPI: SSDT 0xdfee2600 013EC (v01 PmRef CpuPm 00003000 INTL 20050228) MADT: Found IO APIC ID 2, Interrupt 0 at 0xfec00000 ioapic0: Routing external 8259A's -> intpin 0 MADT: Found IO APIC ID 3, Interrupt 24 at 0xfec10000 MADT: Interrupt override: source 0, irq 2 ioapic0: Routing IRQ 0 -> intpin 2 MADT: Interrupt override: source 9, irq 9 ioapic0: intpin 9 trigger: level lapic0: Routing NMI -> LINT1 lapic0: LINT1 trigger: edge lapic0: LINT1 polarity: high lapic1: Routing NMI -> LINT1 lapic1: LINT1 trigger: edge lapic1: LINT1 polarity: high ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-47 on motherboard cpu0 BSP: ID: 0x00000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00000200 err: 0x000000f0 pmc: 0x00010400 nfslock: pseudo-device null: random: io: kbd: new array size 4 kbd1 at kbdmux0 mem: Pentium Pro MTRR support enabled acpi0: on motherboard PCIe: Memory Mapped configuration base @ 0xf0000000 pcibios: BIOS version 2.10 ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 0 vector 48 acpi0: [MPSAFE] acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: wakeup code va 0xc6982000 pa 0x1000 ACPI timer: 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 -> 10 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 cpu0: on acpi0 cpu0: switching to generic Cx mode cpu1: on acpi0 pci_link0: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 10 11 14 15 Validation 0 11 N 0 3 10 11 14 15 After Disable 0 255 N 0 3 10 11 14 15 pci_link1: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 10 11 14 15 Validation 0 11 N 0 3 10 11 14 15 After Disable 0 255 N 0 3 10 11 14 15 pci_link2: Index IRQ Rtd Ref IRQs Initial Probe 0 5 N 0 3 10 11 14 15 Validation 0 255 N 0 3 10 11 14 15 After Disable 0 255 N 0 3 10 11 14 15 pci_link3: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 10 11 14 15 Validation 0 11 N 0 3 10 11 14 15 After Disable 0 255 N 0 3 10 11 14 15 pci_link4: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 10 11 14 15 Validation 0 255 N 0 3 10 11 14 15 After Disable 0 255 N 0 3 10 11 14 15 pci_link5: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 10 11 14 15 Validation 0 255 N 0 3 10 11 14 15 After Disable 0 255 N 0 3 10 11 14 15 pci_link6: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 10 11 14 15 Validation 0 255 N 0 3 10 11 14 15 After Disable 0 255 N 0 3 10 11 14 15 pci_link7: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 3 10 11 14 15 Validation 0 10 N 0 3 10 11 14 15 After Disable 0 255 N 0 3 10 11 14 15 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: domain=0, physical bus=0 found-> vendor=0x8086, dev=0x2778, revid=0xc0 domain=0, bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0106, statreg=0x2090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2779, revid=0xc0 domain=0, bus=0, slot=1, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0107, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x45 (17250 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.1.INTA pcib0: slot 1 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x27d0, revid=0x01 domain=0, bus=0, slot=28, func=0 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTA pcib0: slot 28 INTA hardwired to IRQ 17 found-> vendor=0x8086, dev=0x27e0, revid=0x01 domain=0, bus=0, slot=28, func=4 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTA pcib0: slot 28 INTA hardwired to IRQ 17 found-> vendor=0x8086, dev=0x27e2, revid=0x01 domain=0, bus=0, slot=28, func=5 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) intpin=b, irq=11 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTB pcib0: slot 28 INTB hardwired to IRQ 16 found-> vendor=0x8086, dev=0x27c8, revid=0x01 domain=0, bus=0, slot=29, func=0 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 map[20]: type I/O Port, range 32, base 0x3000, size 5, enabled pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 23 unknown: Reserved 0x20 bytes for rid 0x20 type 4 at 0x3000 found-> vendor=0x8086, dev=0x27c9, revid=0x01 domain=0, bus=0, slot=29, func=1 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=11 map[20]: type I/O Port, range 32, base 0x3020, size 5, enabled pcib0: matched entry for 0.29.INTB pcib0: slot 29 INTB hardwired to IRQ 19 unknown: Reserved 0x20 bytes for rid 0x20 type 4 at 0x3020 found-> vendor=0x8086, dev=0x27ca, revid=0x01 domain=0, bus=0, slot=29, func=2 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=5 map[20]: type I/O Port, range 32, base 0x3040, size 5, enabled pcib0: matched entry for 0.29.INTC pcib0: slot 29 INTC hardwired to IRQ 18 unknown: Reserved 0x20 bytes for rid 0x20 type 4 at 0x3040 found-> vendor=0x8086, dev=0x27cb, revid=0x01 domain=0, bus=0, slot=29, func=3 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=d, irq=11 map[20]: type I/O Port, range 32, base 0x3060, size 5, enabled pcib0: matched entry for 0.29.INTD pcib0: slot 29 INTD hardwired to IRQ 16 unknown: Reserved 0x20 bytes for rid 0x20 type 4 at 0x3060 found-> vendor=0x8086, dev=0x27cc, revid=0x01 domain=0, bus=0, slot=29, func=7 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0106, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xe0000000, size 10, enabled pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 23 unknown: Reserved 0x400 bytes for rid 0x10 type 3 at 0xe0000000 found-> vendor=0x8086, dev=0x244e, revid=0xe1 domain=0, bus=0, slot=30, func=0 class=06-04-01, hdrtype=0x01, mfdev=0 cmdreg=0x0107, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x0c (3000 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x27b8, revid=0x01 domain=0, bus=0, slot=31, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x27c0, revid=0x01 domain=0, bus=0, slot=31, func=2 class=01-01-80, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x02b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=255 powerspec 2 supports D0 D3 current D0 map[20]: type I/O Port, range 32, base 0x30b0, size 4, enabled found-> vendor=0x8086, dev=0x27da, revid=0x01 domain=0, bus=0, slot=31, func=3 class=0c-05-00, hdrtype=0x00, mfdev=0 cmdreg=0x0101, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=11 map[20]: type I/O Port, range 32, base 0x1100, size 5, enabled pcib0: matched entry for 0.31.INTB pcib0: slot 31 INTB hardwired to IRQ 19 pcib1: irq 16 at device 1.0 on pci0 pcib1: domain 0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0xf000-0xfff pcib1: no prefetched decode pci1: on pcib1 pci1: domain=0, physical bus=1 pcib2: irq 17 at device 28.0 on pci0 pcib2: domain 0 pcib2: secondary bus 9 pcib2: subordinate bus 10 pcib2: I/O decode 0x4000-0x4fff pcib2: memory decode 0xe0100000-0xe02fffff pcib2: no prefetched decode pci9: on pcib2 pci9: domain=0, physical bus=9 found-> vendor=0x8086, dev=0x032c, revid=0x09 domain=0, bus=9, slot=0, func=0 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0107, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit found-> vendor=0x8086, dev=0x0326, revid=0x09 domain=0, bus=9, slot=0, func=1 class=08-00-20, hdrtype=0x00, mfdev=1 cmdreg=0x0106, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xe0100000, size 12, enabled pcib2: requested memory range 0xe0100000-0xe0100fff: good pcib3: at device 0.0 on pci9 pcib3: domain 0 pcib3: secondary bus 10 pcib3: subordinate bus 10 pcib3: I/O decode 0x4000-0x4fff pcib3: memory decode 0xe0200000-0xe02fffff pcib3: no prefetched decode pci10: on pcib3 pci10: domain=0, physical bus=10 found-> vendor=0x8086, dev=0x1079, revid=0x03 domain=0, bus=10, slot=1, func=0 class=02-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0117, statreg=0x0230, cachelnsz=8 (dwords) lattimer=0x34 (1560 ns), mingnt=0xff (63750 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 64, base 0xe0240000, size 17, enabled pcib3: requested memory range 0xe0240000-0xe025ffff: good pcib2: requested memory range 0xe0240000-0xe025ffff: good map[18]: type Memory, range 64, base 0xe0200000, size 18, enabled pcib3: requested memory range 0xe0200000-0xe023ffff: good pcib2: requested memory range 0xe0200000-0xe023ffff: good map[20]: type I/O Port, range 32, base 0x4000, size 6, enabled pcib3: requested I/O range 0x4000-0x403f: in range pcib2: requested I/O range 0x4000-0x403f: in range pcib3: matched entry for 10.1.INTA pcib3: slot 1 INTA hardwired to IRQ 24 found-> vendor=0x8086, dev=0x1079, revid=0x03 domain=0, bus=10, slot=1, func=1 class=02-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0117, statreg=0x0230, cachelnsz=8 (dwords) lattimer=0x34 (1560 ns), mingnt=0xff (63750 ns), maxlat=0x00 (0 ns) intpin=b, irq=11 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 64, base 0xe0260000, size 17, enabled pcib3: requested memory range 0xe0260000-0xe027ffff: good pcib2: requested memory range 0xe0260000-0xe027ffff: good map[18]: type Memory, range 64, base 0xe0280000, size 18, enabled pcib3: requested memory range 0xe0280000-0xe02bffff: good pcib2: requested memory range 0xe0280000-0xe02bffff: good map[20]: type I/O Port, range 32, base 0x4040, size 6, enabled pcib3: requested I/O range 0x4040-0x407f: in range pcib2: requested I/O range 0x4040-0x407f: in range pcib3: matched entry for 10.1.INTB pcib3: slot 1 INTB hardwired to IRQ 25 em0: port 0x4000-0x403f mem 0xe0240000-0xe025ffff,0xe0200000-0xe023ffff irq 24 at device 1.0 on pci10 em0: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xe0240000 em0: Reserved 0x40 bytes for rid 0x20 type 4 at 0x4000 ioapic1: routing intpin 0 (PCI IRQ 24) to lapic 0 vector 49 em0: [FILTER] em0: bpf attached em0: Ethernet address: 00:1b:21:08:32:a8 em1: port 0x4040-0x407f mem 0xe0260000-0xe027ffff,0xe0280000-0xe02bffff irq 25 at device 1.1 on pci10 em1: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xe0260000 em1: Reserved 0x40 bytes for rid 0x20 type 4 at 0x4040 ioapic1: routing intpin 1 (PCI IRQ 25) to lapic 0 vector 50 em1: [FILTER] em1: bpf attached em1: Ethernet address: 00:1b:21:08:32:a9 pcib4: irq 17 at device 28.4 on pci0 pcib4: domain 0 pcib4: secondary bus 13 pcib4: subordinate bus 13 pcib4: I/O decode 0x5000-0x5fff pcib4: memory decode 0xe0300000-0xe03fffff pcib4: no prefetched decode pci13: on pcib4 pci13: domain=0, physical bus=13 found-> vendor=0x8086, dev=0x108c, revid=0x03 domain=0, bus=13, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0107, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 32, base 0xe0300000, size 17, enabled pcib4: requested memory range 0xe0300000-0xe031ffff: good map[18]: type I/O Port, range 32, base 0x5000, size 5, enabled pcib4: requested I/O range 0x5000-0x501f: in range pcib4: matched entry for 13.0.INTA pcib4: slot 0 INTA hardwired to IRQ 16 em2: port 0x5000-0x501f mem 0xe0300000-0xe031ffff irq 16 at device 0.0 on pci13 em2: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xe0300000 em2: attempting to allocate 1 MSI vectors (1 supported) msi: routing MSI IRQ 256 to local APIC 0 vector 51 em2: using IRQ 256 for MSI em2: Using an MSI interrupt em2: [FILTER] em2: bpf attached em2: Ethernet address: 00:30:48:8d:ba:50 pcib5: irq 16 at device 28.5 on pci0 pcib5: domain 0 pcib5: secondary bus 14 pcib5: subordinate bus 14 pcib5: I/O decode 0x6000-0x6fff pcib5: memory decode 0xe0400000-0xe04fffff pcib5: no prefetched decode pci14: on pcib5 pci14: domain=0, physical bus=14 found-> vendor=0x8086, dev=0x109a, revid=0x00 domain=0, bus=14, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0107, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 32, base 0xe0400000, size 17, enabled pcib5: requested memory range 0xe0400000-0xe041ffff: good map[18]: type I/O Port, range 32, base 0x6000, size 5, enabled pcib5: requested I/O range 0x6000-0x601f: in range pcib5: matched entry for 14.0.INTA pcib5: slot 0 INTA hardwired to IRQ 17 em3: port 0x6000-0x601f mem 0xe0400000-0xe041ffff irq 17 at device 0.0 on pci14 em3: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xe0400000 em3: attempting to allocate 1 MSI vectors (1 supported) msi: routing MSI IRQ 257 to local APIC 0 vector 52 em3: using IRQ 257 for MSI em3: Using an MSI interrupt em3: [FILTER] em3: bpf attached em3: Ethernet address: 00:30:48:8d:ba:51 uhci0: port 0x3000-0x301f irq 23 at device 29.0 on pci0 ioapic0: routing intpin 23 (PCI IRQ 23) to lapic 0 vector 53 uhci0: [MPSAFE] uhci0: [ITHREAD] usbus0: on uhci0 uhci1: port 0x3020-0x303f irq 19 at device 29.1 on pci0 ioapic0: routing intpin 19 (PCI IRQ 19) to lapic 0 vector 54 uhci1: [MPSAFE] uhci1: [ITHREAD] usbus1: on uhci1 uhci2: port 0x3040-0x305f irq 18 at device 29.2 on pci0 ioapic0: routing intpin 18 (PCI IRQ 18) to lapic 0 vector 55 uhci2: [MPSAFE] uhci2: [ITHREAD] usbus2: on uhci2 uhci3: port 0x3060-0x307f irq 16 at device 29.3 on pci0 ioapic0: routing intpin 16 (PCI IRQ 16) to lapic 0 vector 56 uhci3: [MPSAFE] uhci3: [ITHREAD] usbus3: on uhci3 ehci0: mem 0xe0000000-0xe00003ff irq 23 at device 29.7 on pci0 ehci0: [MPSAFE] ehci0: [ITHREAD] usbus4: EHCI version 1.0 usbus4: on ehci0 pcib6: at device 30.0 on pci0 pcib6: domain 0 pcib6: secondary bus 15 pcib6: subordinate bus 15 pcib6: I/O decode 0x7000-0x7fff pcib6: memory decode 0xe0500000-0xe05fffff pcib6: prefetched decode 0xe8000000-0xefffffff pcib6: Subtractively decoded bridge. pci15: on pcib6 pci15: domain=0, physical bus=15 found-> vendor=0x1002, dev=0x515e, revid=0x02 domain=0, bus=15, slot=0, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0387, statreg=0x0290, cachelnsz=8 (dwords) lattimer=0x42 (1980 ns), mingnt=0x08 (2000 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Prefetchable Memory, range 32, base 0xe8000000, size 27, enabled pcib6: requested memory range 0xe8000000-0xefffffff: good map[14]: type I/O Port, range 32, base 0x7000, size 8, enabled pcib6: requested I/O range 0x7000-0x70ff: in range map[18]: type Memory, range 32, base 0xe0500000, size 16, enabled pcib6: requested memory range 0xe0500000-0xe050ffff: good pcib6: matched entry for 15.0.INTA pcib6: slot 0 INTA hardwired to IRQ 16 vgapci0: port 0x7000-0x70ff mem 0xe8000000-0xefffffff,0xe0500000-0xe050ffff irq 16 at device 0.0 on pci15 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x30b0-0x30bf at device 31.2 on pci0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0x30b0 ata0: on atapci0 atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 atapci0: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 ata0: reset tp1 mask=03 ostat0=50 ostat1=00 ata0: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 ata0: stat1=0x00 err=0x01 lsb=0x00 msb=0x00 ata0: reset tp2 stat0=50 stat1=00 devices=0x1 ioapic0: routing intpin 14 (ISA IRQ 14) to lapic 0 vector 57 ata0: [MPSAFE] ata0: [ITHREAD] ata1: on atapci0 atapci0: Reserved 0x8 bytes for rid 0x18 type 4 at 0x170 atapci0: Reserved 0x1 bytes for rid 0x1c type 4 at 0x376 ata1: reset tp1 mask=03 ostat0=50 ostat1=00 ata1: stat0=0xd0 err=0xd0 lsb=0xd0 msb=0xd0 ata1: stat0=0x00 err=0x01 lsb=0x14 msb=0xeb ata1: stat1=0x00 err=0x00 lsb=0x00 msb=0x00 ata1: reset tp2 stat0=00 stat1=00 devices=0x10000 ioapic0: routing intpin 15 (ISA IRQ 15) to lapic 0 vector 58 ata1: [MPSAFE] ata1: [ITHREAD] pci0: at device 31.3 (no driver attached) acpi_button0: on acpi0 atrtc0: port 0x70-0x71 irq 8 on acpi0 atrtc0: registered as a time-of-day clock (resolution 1000000us) atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0067 atkbd: keyboard ID 0x41ab (2) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 ioapic0: routing intpin 1 (ISA IRQ 1) to lapic 0 vector 59 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: unable to allocate IRQ psmcpnp0: irq 12 on acpi0 psm0: current command byte:0067 psm0: failed to reset the aux device. uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 ioapic0: routing intpin 4 (ISA IRQ 4) to lapic 0 vector 60 uart0: [FILTER] uart0: fast interrupt uart0: console (115200,n,8,1) uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 ioapic0: routing intpin 3 (ISA IRQ 3) to lapic 0 vector 61 uart1: [FILTER] uart1: fast interrupt fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: ic_type 90 part_id 80 ioapic0: routing intpin 6 (ISA IRQ 6) to lapic 0 vector 62 fdc0: [FILTER] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 ppc0: using extended I/O port range ppc0: SPP ECP ECP+EPP ppc0: port 0x378-0x37f,0x778-0x77f irq 7 drq 3 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/9 bytes threshold ioapic0: routing intpin 7 (ISA IRQ 7) to lapic 0 vector 63 ppc0: [MPSAFE] ppc0: [ITHREAD] ppbus0: on ppc0 lpt0: on ppbus0 lpt0: [MPSAFE] lpt0: [ITHREAD] lpt0: Interrupt-driven port pnp_identify: Trying Read_Port at 203 pnp_identify: Trying Read_Port at 243 pnp_identify: Trying Read_Port at 283 pnp_identify: Trying Read_Port at 2c3 pnp_identify: Trying Read_Port at 303 pnp_identify: Trying Read_Port at 343 pnp_identify: Trying Read_Port at 383 pnp_identify: Trying Read_Port at 3c3 PNP Identify complete isa_probe_children: disabling PnP devices pmtimer0 on isa0 ata: ata0 already exists; skipping it ata: ata1 already exists; skipping it atkbdc: atkbdc0 already exists; skipping it atrtc: atrtc0 already exists; skipping it fdc: fdc0 already exists; skipping it ppc: ppc0 already exists; skipping it sc: sc0 already exists; skipping it uart: uart0 already exists; skipping it uart: uart1 already exists; skipping it isa_probe_children: probing non-PnP devices orm0: at iomem 0xc0000-0xcafff pnpid ORM0000 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd1, terminal emulator: scteken (teken terminal) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 isa_probe_children: probing PnP devices coretemp0: on cpu0 coretemp0: Setting TjMax=85 est0: enabling SpeedStep est0: on cpu0 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 828082806000828 device_attach: est0 attach returned 6 p4tcc0: on cpu0 coretemp1: on cpu1 coretemp1: Setting TjMax=85 est1: on cpu1 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 828082806000828 device_attach: est1 attach returned 6 p4tcc1: on cpu1 Device configuration finished. procfs registered lapic: Divisor 2, Frequency 133000964 Hz Timecounter "TSC" frequency 2128015344 Hz quality -100 Timecounters tick every 1.000 msec vlan: initialized, using hash tables with chaining lo0: bpf attached ata0: Identifying devices: 00000001 ata0: New devices: 00000001 usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 12Mbps Full Speed USB v1.0 usbus4: 480Mbps High Speed USB v2.0 ata0-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire ad0: setting UDMA100 ad0: 239429MB at ata0-master UDMA100 SATA ad0: 490350672 sectors [486459C/16H/63S] 16 sectors/interrupt 1 depth queue ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 ugen3.1: at usbus3 uhub3: on usbus3 ugen4.1: at usbus4 uhub4: on usbus4 ad0: Intel check1 failed ad0: Adaptec check1 failed ad0: LSI (v3) check1 failed ad0: LSI (v2) check1 failed ad0: FreeBSD check1 failed ata1: Identifying devices: 00010000 ata1: New devices: 00010000 ata1-master: pio=PIO4 wdma=WDMA2 udma=UDMA33 cable=40 wire acd0: setting UDMA33 acd0: CDROM drive at ata1 as master acd0: read 4134KB/s (4134KB/s), 256KB buffer, UDMA33 acd0: Reads: CDR, CDRW, CDDA stream, packet acd0: Writes: acd0: Audio: play, 256 volume levels acd0: Mechanism: ejectable tray, unlocked acd0: Medium: no/blank disc ATA PseudoRAID loaded SMP: AP CPU #1 Launched! cpu1 AP: ID: 0x01000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 ioapic0: routing intpin 3 (ISA IRQ 3) to lapic 1 vector 48 ioapic0: routing intpin 6 (ISA IRQ 6) to lapic 1 vector 49 ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 1 vector 50 ioapic0: routing intpin 15 (ISA IRQ 15) to lapic 1 vector 51 ioapic0: routing intpin 18 (PCI IRQ 18) to lapic 1 vector 52 ioapic0: routing intpin 23 (PCI IRQ 23) to lapic 1 vector 53 ioapic1: routing intpin 1 (PCI IRQ 25) to lapic 1 vector 54 msi: Assigning MSI IRQ 257 to local APIC 1 vector 55 uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered uhub3: 2 ports with 2 removable, self powered GEOM: new disk ad0 Root mount waiting for: usbus4 Root mount waiting for: usbus4 uhub4: 8 ports with 8 removable, self powered Trying to mount root from ufs:/dev/ad0s1a start_init: trying /sbin/init disc0: bpf attached em0: Link is up 1000 Mbps Full Duplex em1: Link is up 1000 Mbps Full Duplex ipfw2 (+ipv6) initialized, divert loadable, nat loadable, rule-based forwarding disabled, default to deny, logging disabled ipfw0: bpf attached --------------000907060408030108000302-- From owner-freebsd-stable@FreeBSD.ORG Wed Mar 2 03:02:20 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D8CAF106564A for ; Wed, 2 Mar 2011 03:02:20 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [76.96.59.227]) by mx1.freebsd.org (Postfix) with ESMTP id 83EEC8FC17 for ; Wed, 2 Mar 2011 03:02:20 +0000 (UTC) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta12.westchester.pa.mail.comcast.net with comcast id E2wH1g00E1ZXKqc5C32Lzc; Wed, 02 Mar 2011 03:02:20 +0000 Received: from koitsu.dyndns.org ([98.248.33.18]) by omta21.westchester.pa.mail.comcast.net with comcast id E3261g0170PUQVN3h32FHu; Wed, 02 Mar 2011 03:02:18 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 809AD9B422; Tue, 1 Mar 2011 19:02:05 -0800 (PST) Date: Tue, 1 Mar 2011 19:02:05 -0800 From: Jeremy Chadwick To: Mike Tancsa Message-ID: <20110302030205.GA51668@icarus.home.lan> References: <4D6DA259.4050307@sentex.net> <20110302020412.GA50962@icarus.home.lan> <4D6DAC5A.6080904@sentex.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D6DAC5A.6080904@sentex.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: FreeBSD-STABLE Mailing List , John Baldwin Subject: Re: CPU0: local APIC error 0x40 CPU1: local APIC error 0x40 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2011 03:02:20 -0000 On Tue, Mar 01, 2011 at 09:32:58PM -0500, Mike Tancsa wrote: > On 3/1/2011 9:04 PM, Jeremy Chadwick wrote: > > On Tue, Mar 01, 2011 at 08:50:17PM -0500, Mike Tancsa wrote: > >> I had a machine deadlock just now and the only thing on the serial > >> console was > >> > >> CPU0: local APIC error 0x40 > >> CPU1: local APIC error 0x40 > > > > The error in question I'm not familiar with, but the code in > > src/sys/x86/x86/local_apic.c indicates that 0x40 is the contents of the > > LAPIC ESR (error status register). > > > > Please provide full output from a verbose boot. > > Attached as a .txt file Thanks -- this will probably be helpful to other folks, not so much me. :-) I lack familiarity with I/O and local APIC configuration. The error strings in question aren't shown in the attached text file, strangely enough. Maybe only visible on VGA console? Based on what I can find in Intel specifications, bit 6 (0x40) of the ESR is defined as: Bit 6: Receive Illegal Vector Set when the local APIC detects an illegal vector (one in the range 0 to 15) in an interrupt message it receives or in an interrupt generated locally from the local vector table or via a self IPI. Such interrupts are not be delivered to the processor; the local APIC will never set an IRR bit in the range 0 to 15. I got this from Section 10.5.3 of Intel's IA-32 Intel Architecture Software Developer's Manual, Volume 3A: http://developer.intel.com/design/processor/manuals/253668.pdf The motherboard looks like a Supermicro X7SBA or something along those lines (I can tell from the ACPI string). A workaround might be to disable multiprocessor support in the BIOS (specifically Advanced -> Advanced Processor Options -> Core-Multi-Processing = Disabled). If this does work, note that I agree it's not an acceptable permanent solution. CC'ing John who might have some ideas about the LAPIC stuff. -- | 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 Mar 2 07:21:39 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 35F53106564A for ; Wed, 2 Mar 2011 07:21:39 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id E96CC8FC0A for ; Wed, 2 Mar 2011 07:21:38 +0000 (UTC) Received: by iyj12 with SMTP id 12so5374416iyj.13 for ; Tue, 01 Mar 2011 23:21:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Rgb5Oc55zloDeFUUUJLdJlLMtjV9+kY4BsnqaPu6K7Y=; b=iVr09my21hpBlf64PJCN0yL5Cv22zMRHMqBE8T24/3n3Hc0JGp2AnYxRxGg5tRnqGt D8c4dAz5w14kxfxqUTAl0wF1x+0/uuocM+UoBHtjuCXcW9pg3SyBiBwySa1y0QOVgw+C 0mant4aDrJw5TxUA8CtrWfp0ZdLkWDG54PxUs= 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=fhZtrhtoEGCAy2jGr2DR0nLf3wd1llZHUiOyKdPj/OUowQ4divKcoIVtrwkt76lScp nxJzsibDk3ekB8KJFLs7NmJciHgHe/0/vBqkurPjeuVQ8eXBNvc2SBR8/IZvxTeX3N6i nDnVKhUIBX0aztbozU4KNltCJEgQN+onf2dAo= MIME-Version: 1.0 Received: by 10.42.123.204 with SMTP id t12mr7801017icr.457.1299048950890; Tue, 01 Mar 2011 22:55:50 -0800 (PST) Received: by 10.42.165.135 with HTTP; Tue, 1 Mar 2011 22:55:50 -0800 (PST) In-Reply-To: <1416421652.20110301225215@serebryakov.spb.ru> References: <1975926365.20110223121637@serebryakov.spb.ru> <4D64EC8C.2080007@sentex.net> <1004451940.20110223143607@serebryakov.spb.ru> <4D6D00C1.1040805@sentex.net> <1416421652.20110301225215@serebryakov.spb.ru> Date: Wed, 2 Mar 2011 01:55:50 -0500 Message-ID: From: Arnaud Lacombe To: Lev Serebryakov Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org, Jack Vogel , Jan Koum Subject: Re: em0 with latest driver hangs again and again (without "Watchdog timeout" message!) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2011 07:21:39 -0000 Hi, On Tue, Mar 1, 2011 at 2:52 PM, Lev Serebryakov wr= ote: > Hello, Mike. > You wrote 1 =D0=BC=D0=B0=D1=80=D1=82=D0=B0 2011 =D0=B3., 17:20:49: > >> I have been running with 7.2.2 and so far so good. =C2=A0However, its ha= rd to >> say in my case as the box I would only periodically see the issue. > =C2=A0As I wrote to Jack, my NIC hangs today with 7.2.2 > Do you have any detailed error ? What the output of sysctl "dev.em.X" where X is the index of the hung interface ? Thanks, - Arnaud > -- > // Black Lion AKA Lev Serebryakov > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Wed Mar 2 12:42:50 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A76E7106566B for ; Wed, 2 Mar 2011 12:42:50 +0000 (UTC) (envelope-from erob@gthcfoundation.org) Received: from relais.videotron.ca (relais.videotron.ca [24.201.245.36]) by mx1.freebsd.org (Postfix) with ESMTP id 7F94C8FC28 for ; Wed, 2 Mar 2011 12:42:50 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=ISO-8859-1 Received: from [192.168.0.100] ([184.162.50.38]) by VL-MR-MRZ22.ip.videotron.ca (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTP id <0LHF000H1KNDU070@VL-MR-MRZ22.ip.videotron.ca> for freebsd-stable@freebsd.org; Wed, 02 Mar 2011 07:42:49 -0500 (EST) Message-id: <4D6E3B49.9040209@gthcfoundation.org> Date: Wed, 02 Mar 2011 07:42:49 -0500 From: Etienne Robillard Organization: Green Tea Hackers Club User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.16) Gecko/20101227 Icedove/3.0.11 To: "Agarwal, Mayank" , freebsd-stable@freebsd.org References: <201103021100.p22B0M5C031918@freefall.freebsd.org> In-reply-to: <201103021100.p22B0M5C031918@freefall.freebsd.org> X-Enigmail-Version: 1.0.1 Cc: Subject: Re: amd64/117186: [modules] kldload Unsupported file type on STABLE amd64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: erob@gthcfoundation.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 12:42:50 -0000 On 02/03/11 06:00 AM, Agarwal, Mayank wrote: > The following reply was made to PR amd64/117186; it has been noted by GNATS. > > From: "Agarwal, Mayank" > To: , > Cc: > Subject: Re: amd64/117186: [modules] kldload Unsupported file type on STABLE amd64 > Date: Wed, 2 Mar 2011 15:54:00 +0530 > > This is a multi-part message in MIME format. > > ------_=_NextPart_001_01CBD8C3.F2859328 > Content-Type: text/plain; > charset="us-ascii" > Content-Transfer-Encoding: quoted-printable > > Hi,=20 > > =20 > > I am running a FreeBSD 7.2 amd64 machine. While I am trying to load a=20 > kernel module I got following error:=20 > > =20 > > kldload: ./modules/base_kmod.ko: Unsupported file type=20 > > After this error kernel panicked with following message:=20 > > =20 > > Fatal trap 12: page fault while in kernel mode=20 > > cpuid =3D 0; apic id =3D 00=20 > > fault virtual address =3D 0xfffffffe80556000=20 > > fault code =3D supervisor read instruction, page not = > present=20 > > instruction pointer =3D 0x8:0xfffffffe80556000=20 > > stack pointer =3D 0x10:0xfffffffe8a88c710=20 > > frame pointer =3D 0x10:0xfffffffe8a88c760=20 > > code segment =3D base 0x0, limit 0xfffff, type 0x1b=20 > > =3D DPL 0, pres 1, long 1, def32 0, gran 1=20 > > processor eflags =3D interrupt enabled, resume, IOPL =3D 0=20 > > current process =3D 1009 (kldload)=20 > > =20 > > Machine information's are as follows:=20 > > FreeBSD 7.2-RELEASE #0: Wed Feb 23 23:34:05 IST 2011 amd64=20 > > =20 > > =20 > > -Mayank > > > ------_=_NextPart_001_01CBD8C3.F2859328 > Content-Type: text/html; > charset="us-ascii" > Content-Transfer-Encoding: quoted-printable > > xmlns:o=3D"urn:schemas-microsoft-com:office:office" = > xmlns:w=3D"urn:schemas-microsoft-com:office:word" = > xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" = > xmlns=3D"http://www.w3.org/TR/REC-html40"> > > > charset=3Dus-ascii"> > > > > > > > >
> >

Hi,
>
>  
>
> I am running a FreeBSD 7.2 amd64 machine. = > While I am > trying to load a
> kernel module  I got following error:
>
>  
>
> kldload: ./modules/base_kmod.ko: Unsupported file type
>
> After this error kernel panicked with following = > message:
>
>  
>
> Fatal trap 12: page fault while in kernel mode
>
> cpuid =3D 0; apic id =3D 00
>
> fault virtual address   =3D 0xfffffffe80556000
>
> fault code              =3D = > supervisor read > instruction, page not present
>
> instruction pointer     =3D 0x8:0xfffffffe80556000
>
> stack pointer           =3D = > 0x10:0xfffffffe8a88c710
>
> frame pointer           =3D = > 0x10:0xfffffffe8a88c760
>
> 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 1009 (kldload)
>
>  
>
> Machine information's are as follows:
>
> FreeBSD 7.2-RELEASE #0: Wed Feb 23 23:34:05 IST 2011     = > amd64 >
>
>  
>
>  
>
> -Mayank

> >
> > > > > > ------_=_NextPart_001_01CBD8C3.F2859328-- > _______________________________________________ > freebsd-amd64@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 > To unsubscribe, send any mail to "freebsd-amd64-unsubscribe@freebsd.org" > X-UID: 11127 > Status: > X-Keywords: > Content-Length: 0 > > Hi Agarwal, seems like your kernel is missing support to load this kind of binaries. Is that a native ELF module or was it compiled with on another machine? also please send relevant tracebacks messages in plain as opposed to html formatted messages! Thanks, -- Etienne Robillard Company: Green Tea Hackers Club Occupation: Software Developer (and CEO) E-mail: erob@gthcfoundation.org Work phone: 450-936-2123 Website (Company): https://gthc.org/ Website (Blog): https://gthc.org/blog/ PGP public key fingerprint: F2A9 32EA 8E7C 460F 1728 A1A7 649C 7F17 A086 DDEC During times of universal deceit, telling the truth becomes a revolutionary act. -- George Orwell If a free society cannot help the many who are poor, it cannot save the few who are rich. -- John F. Kennedy From owner-freebsd-stable@FreeBSD.ORG Wed Mar 2 12:56:47 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 369F71065674 for ; Wed, 2 Mar 2011 12:56:47 +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 0C5748FC1A for ; Wed, 2 Mar 2011 12:56:47 +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 B385746B94; Wed, 2 Mar 2011 07:56:46 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.10]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 5677C8A02B; Wed, 2 Mar 2011 07:56:46 -0500 (EST) From: John Baldwin To: freebsd-stable@freebsd.org Date: Wed, 2 Mar 2011 07:55:53 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.4-CBSD-20110107; KDE/4.4.5; amd64; ; ) References: <4D6DA259.4050307@sentex.net> <20110302020412.GA50962@icarus.home.lan> <4D6DAC5A.6080904@sentex.net> In-Reply-To: <4D6DAC5A.6080904@sentex.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201103020755.54147.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Wed, 02 Mar 2011 07:56:46 -0500 (EST) Cc: Jeremy Chadwick Subject: Re: CPU0: local APIC error 0x40 CPU1: local APIC error 0x40 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2011 12:56:47 -0000 On Tuesday, March 01, 2011 9:32:58 pm Mike Tancsa wrote: > On 3/1/2011 9:04 PM, Jeremy Chadwick wrote: > > On Tue, Mar 01, 2011 at 08:50:17PM -0500, Mike Tancsa wrote: > >> I had a machine deadlock just now and the only thing on the serial > >> console was > >> > >> CPU0: local APIC error 0x40 > >> CPU1: local APIC error 0x40 > > > > The error in question I'm not familiar with, but the code in > > src/sys/x86/x86/local_apic.c indicates that 0x40 is the contents of the > > LAPIC ESR (error status register). > > > > Please provide full output from a verbose boot. > > > Attached as a .txt file Hmm, the interrupt pins on the each lapic look fine (they all either have a legal vector, are using NMI delivery, or are masked). All of the places that send IPIs have the interrupt vectors hard-coded as constant values in the code. Unfortunately there is no register that tells us which illegal vector was posted. Were you doing anything related to changing the state of device interrupts (cpuset -x, kldload, kldunload, etc.) when this happened? -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Wed Mar 2 13:07:58 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3EA00106566B; Wed, 2 Mar 2011 13:07:58 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1-6.sentex.ca [IPv6:2607:f3e0:0:1::12]) by mx1.freebsd.org (Postfix) with ESMTP id EBF768FC0A; Wed, 2 Mar 2011 13:07:57 +0000 (UTC) Received: from [IPv6:2607:f3e0:0:4:b465:c134:204f:fc84] ([IPv6:2607:f3e0:0:4:b465:c134:204f:fc84]) by smarthost1.sentex.ca (8.14.4/8.14.4) with ESMTP id p22D7twR065572 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 2 Mar 2011 08:07:55 -0500 (EST) (envelope-from mike@sentex.net) Message-ID: <4D6E412F.6080208@sentex.net> Date: Wed, 02 Mar 2011 08:07:59 -0500 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: John Baldwin References: <4D6DA259.4050307@sentex.net> <20110302020412.GA50962@icarus.home.lan> <4D6DAC5A.6080904@sentex.net> <201103020755.54147.jhb@freebsd.org> In-Reply-To: <201103020755.54147.jhb@freebsd.org> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on IPv6:2607:f3e0:0:1::12 Cc: freebsd-stable@freebsd.org, Jeremy Chadwick Subject: Re: CPU0: local APIC error 0x40 CPU1: local APIC error 0x40 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2011 13:07:58 -0000 On 3/2/2011 7:55 AM, John Baldwin wrote: > > Hmm, the interrupt pins on the each lapic look fine (they all either have a > legal vector, are using NMI delivery, or are masked). > > All of the places that send IPIs have the interrupt vectors hard-coded as > constant values in the code. > > Unfortunately there is no register that tells us which illegal vector was > posted. > > Were you doing anything related to changing the state of device interrupts > (cpuset -x, kldload, kldunload, etc.) when this happened? Hi, No, nothing at all. I checked the logs again and nothing unusual leading up to it, nor was anything recorded on the serial console other than that error. Do you think its just a hardware issue? ---Mike -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From owner-freebsd-stable@FreeBSD.ORG Wed Mar 2 14:19:20 2011 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 27028106564A; Wed, 2 Mar 2011 14:19:20 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [IPv6:2607:f3e0:0:3::6502:9b]) by mx1.freebsd.org (Postfix) with ESMTP id CDBF78FC08; Wed, 2 Mar 2011 14:19:19 +0000 (UTC) Received: from freebsd-stable.sentex.ca (localhost [127.0.0.1]) by freebsd-stable.sentex.ca (8.14.4/8.14.4) with ESMTP id p22EJI34072134; Wed, 2 Mar 2011 14:19:18 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-stable.sentex.ca (8.14.4/8.14.4/Submit) id p22EJI9n072095; Wed, 2 Mar 2011 14:19:18 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 2 Mar 2011 14:19:18 GMT Message-Id: <201103021419.p22EJI9n072095@freebsd-stable.sentex.ca> X-Authentication-Warning: freebsd-stable.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_8 tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 14:19:20 -0000 TB --- 2011-03-02 12:07:12 - tinderbox 2.6 running on freebsd-stable.sentex.ca TB --- 2011-03-02 12:07:12 - starting RELENG_8 tinderbox run for amd64/amd64 TB --- 2011-03-02 12:07:12 - cleaning the object tree TB --- 2011-03-02 12:07:44 - cvsupping the source tree TB --- 2011-03-02 12:07:44 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8/amd64/amd64/supfile TB --- 2011-03-02 12:09:13 - building world TB --- 2011-03-02 12:09:13 - MAKEOBJDIRPREFIX=/obj TB --- 2011-03-02 12:09:13 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-03-02 12:09:13 - TARGET=amd64 TB --- 2011-03-02 12:09:13 - TARGET_ARCH=amd64 TB --- 2011-03-02 12:09:13 - TZ=UTC TB --- 2011-03-02 12:09:13 - __MAKE_CONF=/dev/null TB --- 2011-03-02 12:09:13 - cd /src TB --- 2011-03-02 12:09:13 - /usr/bin/make -B buildworld >>> World build started on Wed Mar 2 12:09:14 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Wed Mar 2 14:01:53 UTC 2011 TB --- 2011-03-02 14:01:53 - generating LINT kernel config TB --- 2011-03-02 14:01:53 - cd /src/sys/amd64/conf TB --- 2011-03-02 14:01:53 - /usr/bin/make -B LINT TB --- 2011-03-02 14:01:53 - building LINT kernel TB --- 2011-03-02 14:01:53 - MAKEOBJDIRPREFIX=/obj TB --- 2011-03-02 14:01:53 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-03-02 14:01:53 - TARGET=amd64 TB --- 2011-03-02 14:01:53 - TARGET_ARCH=amd64 TB --- 2011-03-02 14:01:53 - TZ=UTC TB --- 2011-03-02 14:01:53 - __MAKE_CONF=/dev/null TB --- 2011-03-02 14:01:53 - cd /src TB --- 2011-03-02 14:01:53 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Mar 2 14:01:54 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/amd64/linux32/linux32_sysvec.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/compat/linux/linux_emul.c /src/sys/compat/linux/linux_emul.c: In function 'linux_proc_exec': /src/sys/compat/linux/linux_emul.c:265: error: dereferencing pointer to incomplete type /src/sys/compat/linux/linux_emul.c:265: error: 'SV_ABI_MASK' undeclared (first use in this function) /src/sys/compat/linux/linux_emul.c:265: error: (Each undeclared identifier is reported only once /src/sys/compat/linux/linux_emul.c:265: error: for each function it appears in.) /src/sys/compat/linux/linux_emul.c:265: error: 'SV_ABI_LINUX' undeclared (first use in this function) *** Error code 1 Stop in /obj/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-03-02 14:19:18 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-03-02 14:19:18 - ERROR: failed to build lint kernel TB --- 2011-03-02 14:19:18 - 5193.60 user 720.49 system 7926.30 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-amd64-amd64.full From owner-freebsd-stable@FreeBSD.ORG Wed Mar 2 15:17:26 2011 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 6C7431065672; Wed, 2 Mar 2011 15:17:26 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [IPv6:2607:f3e0:0:3::6502:9b]) by mx1.freebsd.org (Postfix) with ESMTP id 0815F8FC14; Wed, 2 Mar 2011 15:17:25 +0000 (UTC) Received: from freebsd-stable.sentex.ca (localhost [127.0.0.1]) by freebsd-stable.sentex.ca (8.14.4/8.14.4) with ESMTP id p22FHPFL010921; Wed, 2 Mar 2011 15:17:25 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-stable.sentex.ca (8.14.4/8.14.4/Submit) id p22FHPtm010920; Wed, 2 Mar 2011 15:17:25 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 2 Mar 2011 15:17:25 GMT Message-Id: <201103021517.p22FHPtm010920@freebsd-stable.sentex.ca> X-Authentication-Warning: freebsd-stable.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_8 tinderbox] failure on i386/i386 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 15:17:26 -0000 TB --- 2011-03-02 13:39:20 - tinderbox 2.6 running on freebsd-stable.sentex.ca TB --- 2011-03-02 13:39:20 - starting RELENG_8 tinderbox run for i386/i386 TB --- 2011-03-02 13:39:20 - cleaning the object tree TB --- 2011-03-02 13:39:38 - cvsupping the source tree TB --- 2011-03-02 13:39:38 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8/i386/i386/supfile TB --- 2011-03-02 13:40:37 - building world TB --- 2011-03-02 13:40:37 - MAKEOBJDIRPREFIX=/obj TB --- 2011-03-02 13:40:37 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-03-02 13:40:37 - TARGET=i386 TB --- 2011-03-02 13:40:37 - TARGET_ARCH=i386 TB --- 2011-03-02 13:40:37 - TZ=UTC TB --- 2011-03-02 13:40:37 - __MAKE_CONF=/dev/null TB --- 2011-03-02 13:40:37 - cd /src TB --- 2011-03-02 13:40:37 - /usr/bin/make -B buildworld >>> World build started on Wed Mar 2 13:40:38 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Wed Mar 2 14:59:01 UTC 2011 TB --- 2011-03-02 14:59:01 - generating LINT kernel config TB --- 2011-03-02 14:59:01 - cd /src/sys/i386/conf TB --- 2011-03-02 14:59:01 - /usr/bin/make -B LINT TB --- 2011-03-02 14:59:01 - building LINT kernel TB --- 2011-03-02 14:59:01 - MAKEOBJDIRPREFIX=/obj TB --- 2011-03-02 14:59:01 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-03-02 14:59:01 - TARGET=i386 TB --- 2011-03-02 14:59:01 - TARGET_ARCH=i386 TB --- 2011-03-02 14:59:01 - TZ=UTC TB --- 2011-03-02 14:59:01 - __MAKE_CONF=/dev/null TB --- 2011-03-02 14:59:01 - cd /src TB --- 2011-03-02 14:59:01 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Mar 2 14:59:02 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/compat/linsysfs/linsysfs.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/compat/linux/linux_emul.c /src/sys/compat/linux/linux_emul.c: In function 'linux_proc_exec': /src/sys/compat/linux/linux_emul.c:265: error: dereferencing pointer to incomplete type /src/sys/compat/linux/linux_emul.c:265: error: 'SV_ABI_MASK' undeclared (first use in this function) /src/sys/compat/linux/linux_emul.c:265: error: (Each undeclared identifier is reported only once /src/sys/compat/linux/linux_emul.c:265: error: for each function it appears in.) /src/sys/compat/linux/linux_emul.c:265: error: 'SV_ABI_LINUX' undeclared (first use in this function) *** Error code 1 Stop in /obj/i386/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-03-02 15:17:25 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-03-02 15:17:25 - ERROR: failed to build lint kernel TB --- 2011-03-02 15:17:25 - 3864.35 user 506.41 system 5884.84 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-i386-i386.full From owner-freebsd-stable@FreeBSD.ORG Wed Mar 2 15:17:49 2011 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 80BB51065787; Wed, 2 Mar 2011 15:17:49 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [IPv6:2607:f3e0:0:3::6502:9b]) by mx1.freebsd.org (Postfix) with ESMTP id 1C8918FC14; Wed, 2 Mar 2011 15:17:49 +0000 (UTC) Received: from freebsd-stable.sentex.ca (localhost [127.0.0.1]) by freebsd-stable.sentex.ca (8.14.4/8.14.4) with ESMTP id p22FHmus012302; Wed, 2 Mar 2011 15:17:48 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-stable.sentex.ca (8.14.4/8.14.4/Submit) id p22FHm9g012298; Wed, 2 Mar 2011 15:17:48 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 2 Mar 2011 15:17:48 GMT Message-Id: <201103021517.p22FHm9g012298@freebsd-stable.sentex.ca> X-Authentication-Warning: freebsd-stable.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_8 tinderbox] failure on i386/pc98 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 15:17:49 -0000 TB --- 2011-03-02 13:43:15 - tinderbox 2.6 running on freebsd-stable.sentex.ca TB --- 2011-03-02 13:43:15 - starting RELENG_8 tinderbox run for i386/pc98 TB --- 2011-03-02 13:43:15 - cleaning the object tree TB --- 2011-03-02 13:43:34 - cvsupping the source tree TB --- 2011-03-02 13:43:34 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8/i386/pc98/supfile TB --- 2011-03-02 13:44:09 - building world TB --- 2011-03-02 13:44:09 - MAKEOBJDIRPREFIX=/obj TB --- 2011-03-02 13:44:09 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-03-02 13:44:09 - TARGET=pc98 TB --- 2011-03-02 13:44:09 - TARGET_ARCH=i386 TB --- 2011-03-02 13:44:09 - TZ=UTC TB --- 2011-03-02 13:44:09 - __MAKE_CONF=/dev/null TB --- 2011-03-02 13:44:09 - cd /src TB --- 2011-03-02 13:44:09 - /usr/bin/make -B buildworld >>> World build started on Wed Mar 2 13:44:10 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Wed Mar 2 15:01:36 UTC 2011 TB --- 2011-03-02 15:01:36 - generating LINT kernel config TB --- 2011-03-02 15:01:36 - cd /src/sys/pc98/conf TB --- 2011-03-02 15:01:36 - /usr/bin/make -B LINT TB --- 2011-03-02 15:01:36 - building LINT kernel TB --- 2011-03-02 15:01:36 - MAKEOBJDIRPREFIX=/obj TB --- 2011-03-02 15:01:36 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-03-02 15:01:36 - TARGET=pc98 TB --- 2011-03-02 15:01:36 - TARGET_ARCH=i386 TB --- 2011-03-02 15:01:36 - TZ=UTC TB --- 2011-03-02 15:01:36 - __MAKE_CONF=/dev/null TB --- 2011-03-02 15:01:36 - cd /src TB --- 2011-03-02 15:01:36 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Mar 2 15:01:36 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/compat/linsysfs/linsysfs.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/compat/linux/linux_emul.c /src/sys/compat/linux/linux_emul.c: In function 'linux_proc_exec': /src/sys/compat/linux/linux_emul.c:265: error: dereferencing pointer to incomplete type /src/sys/compat/linux/linux_emul.c:265: error: 'SV_ABI_MASK' undeclared (first use in this function) /src/sys/compat/linux/linux_emul.c:265: error: (Each undeclared identifier is reported only once /src/sys/compat/linux/linux_emul.c:265: error: for each function it appears in.) /src/sys/compat/linux/linux_emul.c:265: error: 'SV_ABI_LINUX' undeclared (first use in this function) *** Error code 1 Stop in /obj/pc98/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-03-02 15:17:48 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-03-02 15:17:48 - ERROR: failed to build lint kernel TB --- 2011-03-02 15:17:48 - 3737.83 user 504.72 system 5673.30 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-i386-pc98.full From owner-freebsd-stable@FreeBSD.ORG Wed Mar 2 15:19:49 2011 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 5EC7C106564A for ; Wed, 2 Mar 2011 15:19:49 +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 EFA348FC08 for ; Wed, 2 Mar 2011 15:19:48 +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 p22FJjDo064893 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Mar 2011 17:19:45 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id p22FJj65040484; Wed, 2 Mar 2011 17:19:45 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id p22FJjOZ040483; Wed, 2 Mar 2011 17:19:45 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 2 Mar 2011 17:19:45 +0200 From: Kostik Belousov To: current@freebsd.org, stable@freebsd.org Message-ID: <20110302151945.GC78089@deviant.kiev.zoral.com.ua> References: <201103021456.p22EuwNf016650@svn.freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="4FwjdDQe+x6SiBx9" Content-Disposition: inline In-Reply-To: <201103021456.p22EuwNf016650@svn.freebsd.org> User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-3.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, 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: Subject: Re: svn commit: r219178 - head/sys/crypto/aesni X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2011 15:19:49 -0000 --4FwjdDQe+x6SiBx9 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 02, 2011 at 02:56:58PM +0000, Konstantin Belousov wrote: > Author: kib > Date: Wed Mar 2 14:56:58 2011 > New Revision: 219178 > URL: http://svn.freebsd.org/changeset/base/219178 >=20 > Log: > Fix a bug in the result of manual assembly. > =20 > Reported by: Stefan Grundmann > PR: kern/155118 > MFC after: 3 days The end result of this bug should affect only AES256 variants, causing wrong keyschedule calculation. If you have a geli partition with 256bit key that worked with previous version of aesni(4), best strategy is backup, reinitialize geli volume with the new driver, then restore. Sorry. >=20 > Modified: > head/sys/crypto/aesni/aeskeys_amd64.S > head/sys/crypto/aesni/aeskeys_i386.S >=20 > Modified: head/sys/crypto/aesni/aeskeys_amd64.S > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > --- head/sys/crypto/aesni/aeskeys_amd64.S Wed Mar 2 14:39:26 2011 (r2191= 77) > +++ head/sys/crypto/aesni/aeskeys_amd64.S Wed Mar 2 14:56:58 2011 (r2191= 78) > @@ -162,7 +162,7 @@ ENTRY(aesni_set_enckey) > .byte 0x66,0x0f,0x3a,0xdf,0xc8,0x20 > call _key_expansion_256b > // aeskeygenassist $0x40,%xmm2,%xmm1 # round 7 > - .byte 0x66,0x0f,0x3a,0xdf,0xca,0x20 > + .byte 0x66,0x0f,0x3a,0xdf,0xca,0x40 > call _key_expansion_256a > retq > .Lenc_key192: >=20 > Modified: head/sys/crypto/aesni/aeskeys_i386.S > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > --- head/sys/crypto/aesni/aeskeys_i386.S Wed Mar 2 14:39:26 2011 (r21917= 7) > +++ head/sys/crypto/aesni/aeskeys_i386.S Wed Mar 2 14:56:58 2011 (r21917= 8) > @@ -167,7 +167,7 @@ ENTRY(aesni_set_enckey) > .byte 0x66,0x0f,0x3a,0xdf,0xc8,0x20 > call _key_expansion_256b > // aeskeygenassist $0x40,%xmm2,%xmm1 # round 7 > - .byte 0x66,0x0f,0x3a,0xdf,0xca,0x20 > + .byte 0x66,0x0f,0x3a,0xdf,0xca,0x40 > call _key_expansion_256a > .cfi_adjust_cfa_offset -4 > leave --4FwjdDQe+x6SiBx9 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk1uYBAACgkQC3+MBN1Mb4g7cQCcCBJiEGwEbfHJErv1Ux7joFQy PqcAoOOB5A57jmCcbt/VbTMKN9cddAlf =aNlH -----END PGP SIGNATURE----- --4FwjdDQe+x6SiBx9-- From owner-freebsd-stable@FreeBSD.ORG Wed Mar 2 16:47:52 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1C3561065670 for ; Wed, 2 Mar 2011 16:47:52 +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 E43A78FC13 for ; Wed, 2 Mar 2011 16:47:51 +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 9747646B2E; Wed, 2 Mar 2011 11:47:51 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.10]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 2C41D8A02A; Wed, 2 Mar 2011 11:47:51 -0500 (EST) From: John Baldwin To: Mike Tancsa Date: Wed, 2 Mar 2011 10:18:52 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.4-CBSD-20110107; KDE/4.4.5; amd64; ; ) References: <4D6DA259.4050307@sentex.net> <201103020755.54147.jhb@freebsd.org> <4D6E412F.6080208@sentex.net> In-Reply-To: <4D6E412F.6080208@sentex.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201103021018.52403.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Wed, 02 Mar 2011 11:47:51 -0500 (EST) Cc: freebsd-stable@freebsd.org, Jeremy Chadwick Subject: Re: CPU0: local APIC error 0x40 CPU1: local APIC error 0x40 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2011 16:47:52 -0000 On Wednesday, March 02, 2011 8:07:59 am Mike Tancsa wrote: > On 3/2/2011 7:55 AM, John Baldwin wrote: > > > > Hmm, the interrupt pins on the each lapic look fine (they all either have a > > legal vector, are using NMI delivery, or are masked). > > > > All of the places that send IPIs have the interrupt vectors hard-coded as > > constant values in the code. > > > > Unfortunately there is no register that tells us which illegal vector was > > posted. > > > > Were you doing anything related to changing the state of device interrupts > > (cpuset -x, kldload, kldunload, etc.) when this happened? > > Hi, > No, nothing at all. I checked the logs again and nothing unusual > leading up to it, nor was anything recorded on the serial console other > than that error. Do you think its just a hardware issue? No, was trying to think if there was a scenario where an I/O APIC pin or MSI message could specify an illegal vector. Can you reproduce this at all? -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Wed Mar 2 19:25:33 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AD2AA106564A; Wed, 2 Mar 2011 19:25:33 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1-6.sentex.ca [IPv6:2607:f3e0:0:1::12]) by mx1.freebsd.org (Postfix) with ESMTP id 66ABC8FC13; Wed, 2 Mar 2011 19:25:33 +0000 (UTC) Received: from [IPv6:2607:f3e0:0:4:b465:c134:204f:fc84] ([IPv6:2607:f3e0:0:4:b465:c134:204f:fc84]) by smarthost1.sentex.ca (8.14.4/8.14.4) with ESMTP id p22JPUr5029495 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 2 Mar 2011 14:25:31 -0500 (EST) (envelope-from mike@sentex.net) Message-ID: <4D6E99AE.7080409@sentex.net> Date: Wed, 02 Mar 2011 14:25:34 -0500 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: John Baldwin References: <4D6DA259.4050307@sentex.net> <201103020755.54147.jhb@freebsd.org> <4D6E412F.6080208@sentex.net> <201103021018.52403.jhb@freebsd.org> In-Reply-To: <201103021018.52403.jhb@freebsd.org> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on IPv6:2607:f3e0:0:1::12 Cc: freebsd-stable@freebsd.org, Jeremy Chadwick Subject: Re: CPU0: local APIC error 0x40 CPU1: local APIC error 0x40 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2011 19:25:33 -0000 On 3/2/2011 10:18 AM, John Baldwin wrote: >> >> Hi, >> No, nothing at all. I checked the logs again and nothing unusual >> leading up to it, nor was anything recorded on the serial console other >> than that error. Do you think its just a hardware issue? > > No, was trying to think if there was a scenario where an I/O APIC pin or MSI > message could specify an illegal vector. > > Can you reproduce this at all? Not sure. Its the first time I have ever seen this error. In the past, the box would be crashing for other reasons after 2-5 days. However, with the fixes from glebius and mlaier all seemed to have been fixed. The box was up 11 days when it hung with that error. I could not even break into the debugger. Hence, I was thinking perhaps the hardware is all of a sudden showing an issue. The two active NICs are using the legacy interrupts interrupt total rate irq1: atkbd0 3 0 irq4: uart0 29974 0 irq6: fdc0 5 0 irq14: ata0 125592 2 irq15: ata1 48 0 irq24: em0 93380742 1529 irq25: em1 96506206 1580 cpu0: timer 117681138 1927 cpu1: timer 117682130 1927 Total 425405838 6967 ---Mike > -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From owner-freebsd-stable@FreeBSD.ORG Wed Mar 2 21:26:24 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0FB601065677 for ; Wed, 2 Mar 2011 21:26:24 +0000 (UTC) (envelope-from xxjack12xx@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 953438FC15 for ; Wed, 2 Mar 2011 21:26:23 +0000 (UTC) Received: by eyg7 with SMTP id 7so176907eyg.13 for ; Wed, 02 Mar 2011 13:26:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=genEehRdhTQyTaVIZQCczJlFPHtQoNRRiaA4BYaS6ko=; b=VxOiAFx/dKXPtVpW/o0gy4LlrOy1Qxo1JI56vRk//cLLpgmrwvGWJ/5Tj+ZRyS9Vzm TwyhxVwvOl47gCiBJl5yOH6p7KBRRTNtThSmIJsHujmSGKJ2XlVuidHFKAGvwRpWjREw r2uP6OLmLLqONsLpNAK87BGalcJooc0wQv254= 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 :cc:content-type:content-transfer-encoding; b=efDOPgPXOPyyQlYlFbS6BHCWosoJW8eT845o3iH/57F4HxxTHNobTWnJOt1/FLqDle zFHvZa3dZQEh/Q3V1nnN621IwPWQuCoSLF962IaDJAhgIZi9uAqghYKY1B+r3YUj+t+p gdmQKe/bEiexOzO+vXMxfwuEakCh1bgusjnCM= Received: by 10.213.114.14 with SMTP id c14mr635638ebq.54.1299099809126; Wed, 02 Mar 2011 13:03:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.14.31.161 with HTTP; Wed, 2 Mar 2011 13:03:09 -0800 (PST) In-Reply-To: <4D6DA259.4050307@sentex.net> References: <4D6DA259.4050307@sentex.net> From: "Jack L." Date: Wed, 2 Mar 2011 13:03:09 -0800 Message-ID: To: Mike Tancsa Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD-STABLE Mailing List Subject: Re: CPU0: local APIC error 0x40 CPU1: local APIC error 0x40 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2011 21:26:24 -0000 On Tue, Mar 1, 2011 at 5:50 PM, Mike Tancsa wrote: > I had a machine deadlock just now and the only thing on the serial > console was > > CPU0: local APIC error 0x40 > CPU1: local APIC error 0x40 > > prior to it hanging. =C2=A0Anyone know what that error is ? Googling didn= t > really show much definitive. =C2=A0Someone suggested bad hardware ? Is th= ere > a way to narrow that down ? I too get this error all the time on my AMD 6400+ Dual Core with an ASUS motherboard. I'll post some feedback when it happens again. Problem is everytime it happens, the system completely locks up and a power cycle is needed. From owner-freebsd-stable@FreeBSD.ORG Thu Mar 3 01:09:43 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A7321106566C for ; Thu, 3 Mar 2011 01:09:43 +0000 (UTC) (envelope-from shen.elf@gmail.com) Received: from mail-yi0-f54.google.com (mail-yi0-f54.google.com [209.85.218.54]) by mx1.freebsd.org (Postfix) with ESMTP id 5F32C8FC0C for ; Thu, 3 Mar 2011 01:09:43 +0000 (UTC) Received: by yie12 with SMTP id 12so211329yie.13 for ; Wed, 02 Mar 2011 17:09:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=Hx7LlW2DyFerzdmSTV6NjB8n4LcGQLI26byFzICTROU=; b=XXMv2CrT3gc/Pv+5pf5lqfRSTygZJumCEnnFnocVsQSkNSC4nY/jJq17lwAXyVix+0 3V/kvXnG4MnAT6k0SbR13jlzJO5rPfLM1TQmIuLORwaJ1g/jkcsrazFlD7aa4nUzEUiv L5eeKJX2msYKhL4fOF66hBFmwZ2+9a0r+uqOw= 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=jezwmXwM+4Vgrf2ZKuVgqdiaimt7+Yjzsct0HxyDXSkTPqTfBnmBN2p1pmswqKpG27 gzxqjWjLr3VMKJWRcbosHyO/IPuE3EoXOBiyaXMcgsaOQZl11spWbQpYcSMCe81Apr4R ADcaSq/yP5KcX5TDUNjLxm12B4KbEtfL3hZkA= MIME-Version: 1.0 Received: by 10.150.47.3 with SMTP id u3mr913304ybu.389.1299112796453; Wed, 02 Mar 2011 16:39:56 -0800 (PST) Received: by 10.147.38.4 with HTTP; Wed, 2 Mar 2011 16:39:56 -0800 (PST) In-Reply-To: References: <4D6DA259.4050307@sentex.net> Date: Thu, 3 Mar 2011 08:39:56 +0800 Message-ID: From: Yanhui Shen To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: CPU0: local APIC error 0x40 CPU1: local APIC error 0x40 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2011 01:09:43 -0000 `CPU0: local APIC error 0x40" I get this error on my ThinkPad R400(Intel Core2 T6570). -- Best regards, Yanhui From owner-freebsd-stable@FreeBSD.ORG Thu Mar 3 02:16:08 2011 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 50EF5106564A; Thu, 3 Mar 2011 02:16:08 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [IPv6:2607:f3e0:0:3::6502:9b]) by mx1.freebsd.org (Postfix) with ESMTP id E27048FC13; Thu, 3 Mar 2011 02:16:07 +0000 (UTC) Received: from freebsd-stable.sentex.ca (localhost [127.0.0.1]) by freebsd-stable.sentex.ca (8.14.4/8.14.4) with ESMTP id p232G7ef098976; Thu, 3 Mar 2011 02:16:07 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-stable.sentex.ca (8.14.4/8.14.4/Submit) id p232G7CG098972; Thu, 3 Mar 2011 02:16:07 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 3 Mar 2011 02:16:07 GMT Message-Id: <201103030216.p232G7CG098972@freebsd-stable.sentex.ca> X-Authentication-Warning: freebsd-stable.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_8 tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 02:16:08 -0000 TB --- 2011-03-03 00:03:15 - tinderbox 2.6 running on freebsd-stable.sentex.ca TB --- 2011-03-03 00:03:15 - starting RELENG_8 tinderbox run for amd64/amd64 TB --- 2011-03-03 00:03:15 - cleaning the object tree TB --- 2011-03-03 00:03:46 - cvsupping the source tree TB --- 2011-03-03 00:03:46 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8/amd64/amd64/supfile TB --- 2011-03-03 00:04:29 - building world TB --- 2011-03-03 00:04:29 - MAKEOBJDIRPREFIX=/obj TB --- 2011-03-03 00:04:29 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-03-03 00:04:29 - TARGET=amd64 TB --- 2011-03-03 00:04:29 - TARGET_ARCH=amd64 TB --- 2011-03-03 00:04:29 - TZ=UTC TB --- 2011-03-03 00:04:29 - __MAKE_CONF=/dev/null TB --- 2011-03-03 00:04:29 - cd /src TB --- 2011-03-03 00:04:29 - /usr/bin/make -B buildworld >>> World build started on Thu Mar 3 00:04:30 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Thu Mar 3 01:58:10 UTC 2011 TB --- 2011-03-03 01:58:10 - generating LINT kernel config TB --- 2011-03-03 01:58:10 - cd /src/sys/amd64/conf TB --- 2011-03-03 01:58:10 - /usr/bin/make -B LINT TB --- 2011-03-03 01:58:10 - building LINT kernel TB --- 2011-03-03 01:58:10 - MAKEOBJDIRPREFIX=/obj TB --- 2011-03-03 01:58:10 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-03-03 01:58:10 - TARGET=amd64 TB --- 2011-03-03 01:58:10 - TARGET_ARCH=amd64 TB --- 2011-03-03 01:58:10 - TZ=UTC TB --- 2011-03-03 01:58:10 - __MAKE_CONF=/dev/null TB --- 2011-03-03 01:58:10 - cd /src TB --- 2011-03-03 01:58:10 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Mar 3 01:58:10 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/compat/linux/linux_getcwd.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/compat/linux/linux_ioctl.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/compat/linux/linux_ipc.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/compat/linux/linux_mib.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/compat/linux/linux_misc.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/compat/linux/linux_signal.c /src/sys/compat/linux/linux_signal.c: In function 'linux_do_tkill': /src/sys/compat/linux/linux_signal.c:589: error: void value not ignored as it ought to be *** Error code 1 Stop in /obj/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-03-03 02:16:07 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-03-03 02:16:07 - ERROR: failed to build lint kernel TB --- 2011-03-03 02:16:07 - 5216.11 user 721.27 system 7971.29 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-amd64-amd64.full From owner-freebsd-stable@FreeBSD.ORG Thu Mar 3 02:23:53 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ABA93106564A for ; Thu, 3 Mar 2011 02:23:53 +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 588CB8FC17 for ; Thu, 3 Mar 2011 02:23:52 +0000 (UTC) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta02.westchester.pa.mail.comcast.net with comcast id ESJ21g0031swQuc52SPsSZ; Thu, 03 Mar 2011 02:23:52 +0000 Received: from koitsu.dyndns.org ([98.248.33.18]) by omta15.westchester.pa.mail.comcast.net with comcast id ESPq1g0180PUQVN3bSPrSl; Thu, 03 Mar 2011 02:23:52 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 033509B427; Wed, 2 Mar 2011 18:23:49 -0800 (PST) Date: Wed, 2 Mar 2011 18:23:48 -0800 From: Jeremy Chadwick To: dchagin@freebsd.org Message-ID: <20110303022348.GA13569@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@freebsd.org Subject: Fwd: [releng_8 tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 02:23:53 -0000 The commits you've applied in the past ~6 hours have broken the buildkernel piece of the RELENG_8 branch. Please address this ASAP. 2152 03/02 14:19 FreeBSD Tinderbox (4.8K) [releng_8 tinderbox] failure on amd64/amd64 2153 03/02 15:17 FreeBSD Tinderbox (4.6K) [releng_8 tinderbox] failure on i386/i386 2154 03/02 15:17 FreeBSD Tinderbox (4.6K) [releng_8 tinderbox] failure on i386/pc98 2156 03/03 02:16 FreeBSD Tinderbox (7.5K) [releng_8 tinderbox] failure on amd64/amd64 ----- Forwarded message from FreeBSD Tinderbox ----- > From: FreeBSD Tinderbox > To: FreeBSD Tinderbox , stable@freebsd.org, amd64@freebsd.org > Date: Thu, 3 Mar 2011 02:16:07 GMT > Cc: > Subject: [releng_8 tinderbox] failure on amd64/amd64 > > TB --- 2011-03-03 00:03:15 - tinderbox 2.6 running on freebsd-stable.sentex.ca > TB --- 2011-03-03 00:03:15 - starting RELENG_8 tinderbox run for amd64/amd64 > TB --- 2011-03-03 00:03:15 - cleaning the object tree > TB --- 2011-03-03 00:03:46 - cvsupping the source tree > TB --- 2011-03-03 00:03:46 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8/amd64/amd64/supfile > TB --- 2011-03-03 00:04:29 - building world > TB --- 2011-03-03 00:04:29 - MAKEOBJDIRPREFIX=/obj > TB --- 2011-03-03 00:04:29 - PATH=/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2011-03-03 00:04:29 - TARGET=amd64 > TB --- 2011-03-03 00:04:29 - TARGET_ARCH=amd64 > TB --- 2011-03-03 00:04:29 - TZ=UTC > TB --- 2011-03-03 00:04:29 - __MAKE_CONF=/dev/null > TB --- 2011-03-03 00:04:29 - cd /src > TB --- 2011-03-03 00:04:29 - /usr/bin/make -B buildworld > >>> World build started on Thu Mar 3 00:04:30 UTC 2011 > >>> Rebuilding the temporary build tree > >>> stage 1.1: legacy release compatibility shims > >>> stage 1.2: bootstrap tools > >>> stage 2.1: cleaning up the object tree > >>> stage 2.2: rebuilding the object tree > >>> stage 2.3: build tools > >>> stage 3: cross tools > >>> stage 4.1: building includes > >>> stage 4.2: building libraries > >>> stage 4.3: make dependencies > >>> stage 4.4: building everything > >>> stage 5.1: building 32 bit shim libraries > >>> World build completed on Thu Mar 3 01:58:10 UTC 2011 > TB --- 2011-03-03 01:58:10 - generating LINT kernel config > TB --- 2011-03-03 01:58:10 - cd /src/sys/amd64/conf > TB --- 2011-03-03 01:58:10 - /usr/bin/make -B LINT > TB --- 2011-03-03 01:58:10 - building LINT kernel > TB --- 2011-03-03 01:58:10 - MAKEOBJDIRPREFIX=/obj > TB --- 2011-03-03 01:58:10 - PATH=/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2011-03-03 01:58:10 - TARGET=amd64 > TB --- 2011-03-03 01:58:10 - TARGET_ARCH=amd64 > TB --- 2011-03-03 01:58:10 - TZ=UTC > TB --- 2011-03-03 01:58:10 - __MAKE_CONF=/dev/null > TB --- 2011-03-03 01:58:10 - cd /src > TB --- 2011-03-03 01:58:10 - /usr/bin/make -B buildkernel KERNCONF=LINT > >>> Kernel build for LINT started on Thu Mar 3 01:58:10 UTC 2011 > >>> stage 1: configuring the kernel > >>> stage 2.1: cleaning up the object tree > >>> stage 2.2: rebuilding the object tree > >>> stage 2.3: build tools > >>> stage 3.1: making dependencies > >>> stage 3.2: building everything > [...] > cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/compat/linux/linux_getcwd.c > cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/compat/linux/linux_ioctl.c > cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/compat/linux/linux_ipc.c > cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/compat/linux/linux_mib.c > cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/compat/linux/linux_misc.c > cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/compat/linux/linux_signal.c > /src/sys/compat/linux/linux_signal.c: In function 'linux_do_tkill': > /src/sys/compat/linux/linux_signal.c:589: error: void value not ignored as it ought to be > *** Error code 1 > > Stop in /obj/src/sys/LINT. > *** Error code 1 > > Stop in /src. > *** Error code 1 > > Stop in /src. > TB --- 2011-03-03 02:16:07 - WARNING: /usr/bin/make returned exit code 1 > TB --- 2011-03-03 02:16:07 - ERROR: failed to build lint kernel > TB --- 2011-03-03 02:16:07 - 5216.11 user 721.27 system 7971.29 real > > > http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-amd64-amd64.full > _______________________________________________ > 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" ----- End forwarded message ----- -- | 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 Mar 3 03:15:53 2011 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 880EF106566C; Thu, 3 Mar 2011 03:15:53 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [IPv6:2607:f3e0:0:3::6502:9b]) by mx1.freebsd.org (Postfix) with ESMTP id DFAA08FC13; Thu, 3 Mar 2011 03:15:52 +0000 (UTC) Received: from freebsd-stable.sentex.ca (localhost [127.0.0.1]) by freebsd-stable.sentex.ca (8.14.4/8.14.4) with ESMTP id p233FqXv034102; Thu, 3 Mar 2011 03:15:52 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-stable.sentex.ca (8.14.4/8.14.4/Submit) id p233Fq1i034096; Thu, 3 Mar 2011 03:15:52 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 3 Mar 2011 03:15:52 GMT Message-Id: <201103030315.p233Fq1i034096@freebsd-stable.sentex.ca> X-Authentication-Warning: freebsd-stable.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_8 tinderbox] failure on i386/pc98 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 03:15:53 -0000 TB --- 2011-03-03 01:39:04 - tinderbox 2.6 running on freebsd-stable.sentex.ca TB --- 2011-03-03 01:39:04 - starting RELENG_8 tinderbox run for i386/pc98 TB --- 2011-03-03 01:39:04 - cleaning the object tree TB --- 2011-03-03 01:39:23 - cvsupping the source tree TB --- 2011-03-03 01:39:23 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8/i386/pc98/supfile TB --- 2011-03-03 01:40:08 - building world TB --- 2011-03-03 01:40:08 - MAKEOBJDIRPREFIX=/obj TB --- 2011-03-03 01:40:08 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-03-03 01:40:08 - TARGET=pc98 TB --- 2011-03-03 01:40:08 - TARGET_ARCH=i386 TB --- 2011-03-03 01:40:08 - TZ=UTC TB --- 2011-03-03 01:40:08 - __MAKE_CONF=/dev/null TB --- 2011-03-03 01:40:08 - cd /src TB --- 2011-03-03 01:40:08 - /usr/bin/make -B buildworld >>> World build started on Thu Mar 3 01:40:08 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Thu Mar 3 02:58:13 UTC 2011 TB --- 2011-03-03 02:58:13 - generating LINT kernel config TB --- 2011-03-03 02:58:13 - cd /src/sys/pc98/conf TB --- 2011-03-03 02:58:13 - /usr/bin/make -B LINT TB --- 2011-03-03 02:58:13 - building LINT kernel TB --- 2011-03-03 02:58:13 - MAKEOBJDIRPREFIX=/obj TB --- 2011-03-03 02:58:13 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-03-03 02:58:13 - TARGET=pc98 TB --- 2011-03-03 02:58:13 - TARGET_ARCH=i386 TB --- 2011-03-03 02:58:13 - TZ=UTC TB --- 2011-03-03 02:58:13 - __MAKE_CONF=/dev/null TB --- 2011-03-03 02:58:13 - cd /src TB --- 2011-03-03 02:58:13 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Mar 3 02:58:13 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/compat/linux/linux_getcwd.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/compat/linux/linux_ioctl.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/compat/linux/linux_ipc.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/compat/linux/linux_mib.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/compat/linux/linux_misc.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/compat/linux/linux_signal.c /src/sys/compat/linux/linux_signal.c: In function 'linux_do_tkill': /src/sys/compat/linux/linux_signal.c:589: error: void value not ignored as it ought to be *** Error code 1 Stop in /obj/pc98/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-03-03 03:15:52 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-03-03 03:15:52 - ERROR: failed to build lint kernel TB --- 2011-03-03 03:15:52 - 3714.50 user 500.89 system 5807.53 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-i386-pc98.full From owner-freebsd-stable@FreeBSD.ORG Thu Mar 3 03:16:17 2011 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 CBFB210657BC; Thu, 3 Mar 2011 03:16:17 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [IPv6:2607:f3e0:0:3::6502:9b]) by mx1.freebsd.org (Postfix) with ESMTP id 7FF778FC18; Thu, 3 Mar 2011 03:16:17 +0000 (UTC) Received: from freebsd-stable.sentex.ca (localhost [127.0.0.1]) by freebsd-stable.sentex.ca (8.14.4/8.14.4) with ESMTP id p233GGoE034931; Thu, 3 Mar 2011 03:16:16 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-stable.sentex.ca (8.14.4/8.14.4/Submit) id p233GGEn034924; Thu, 3 Mar 2011 03:16:16 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 3 Mar 2011 03:16:16 GMT Message-Id: <201103030316.p233GGEn034924@freebsd-stable.sentex.ca> X-Authentication-Warning: freebsd-stable.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_8 tinderbox] failure on i386/i386 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 03:16:17 -0000 TB --- 2011-03-03 01:36:21 - tinderbox 2.6 running on freebsd-stable.sentex.ca TB --- 2011-03-03 01:36:21 - starting RELENG_8 tinderbox run for i386/i386 TB --- 2011-03-03 01:36:21 - cleaning the object tree TB --- 2011-03-03 01:36:32 - cvsupping the source tree TB --- 2011-03-03 01:36:32 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8/i386/i386/supfile TB --- 2011-03-03 01:37:27 - building world TB --- 2011-03-03 01:37:27 - MAKEOBJDIRPREFIX=/obj TB --- 2011-03-03 01:37:27 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-03-03 01:37:27 - TARGET=i386 TB --- 2011-03-03 01:37:27 - TARGET_ARCH=i386 TB --- 2011-03-03 01:37:27 - TZ=UTC TB --- 2011-03-03 01:37:27 - __MAKE_CONF=/dev/null TB --- 2011-03-03 01:37:27 - cd /src TB --- 2011-03-03 01:37:27 - /usr/bin/make -B buildworld >>> World build started on Thu Mar 3 01:37:28 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Thu Mar 3 02:56:09 UTC 2011 TB --- 2011-03-03 02:56:09 - generating LINT kernel config TB --- 2011-03-03 02:56:09 - cd /src/sys/i386/conf TB --- 2011-03-03 02:56:09 - /usr/bin/make -B LINT TB --- 2011-03-03 02:56:09 - building LINT kernel TB --- 2011-03-03 02:56:09 - MAKEOBJDIRPREFIX=/obj TB --- 2011-03-03 02:56:09 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-03-03 02:56:09 - TARGET=i386 TB --- 2011-03-03 02:56:09 - TARGET_ARCH=i386 TB --- 2011-03-03 02:56:09 - TZ=UTC TB --- 2011-03-03 02:56:09 - __MAKE_CONF=/dev/null TB --- 2011-03-03 02:56:09 - cd /src TB --- 2011-03-03 02:56:09 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Mar 3 02:56:09 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/compat/linux/linux_getcwd.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/compat/linux/linux_ioctl.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/compat/linux/linux_ipc.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/compat/linux/linux_mib.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/compat/linux/linux_misc.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/compat/linux/linux_signal.c /src/sys/compat/linux/linux_signal.c: In function 'linux_do_tkill': /src/sys/compat/linux/linux_signal.c:589: error: void value not ignored as it ought to be *** Error code 1 Stop in /obj/i386/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-03-03 03:16:16 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-03-03 03:16:16 - ERROR: failed to build lint kernel TB --- 2011-03-03 03:16:16 - 3841.94 user 499.44 system 5995.78 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-i386-i386.full From owner-freebsd-stable@FreeBSD.ORG Thu Mar 3 08:07:22 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A53F2106566B for ; Thu, 3 Mar 2011 08:07:22 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: from mail-ew0-f54.google.com (mail-ew0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 31DBB8FC1A for ; Thu, 3 Mar 2011 08:07:21 +0000 (UTC) Received: by ewy28 with SMTP id 28so308354ewy.13 for ; Thu, 03 Mar 2011 00:07:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=JiBBTsY0LOQtXO/935G//TNMD9iwmygWsH9CtpVJ0bY=; b=MafWGbJ67aihZ2ReldGynEsPkNn8Cz4WV0JXQBWSr7Wcei9AgyrxXLRgl6fr3VzxeB lvu31qUmmdnY0b0cbac1TDZfhM6NYNjRkSG1UHhwroGd2ysNFh9rnmXjP7Z8xAPIHz30 Q8C34O4m3JxsWb3+h7IuqxXhONH5nuQivhIeQ= 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=qka17S6Z/279a/As8Qw6h8v1U3i0pRd182ASEcdRn0t5jzvUWWxDrjPVHu8aJg9T5o HdzzmBh0BSION4tpP/Q/SqJXrAxyBR6RMWJWuVFR4cBNm3rd8bKPQRXn+TYmkLqSo2uz 9NZqzNHbKp1qAFfF1VlXOMAb12NxClyq4Wn+Q= Received: by 10.213.3.74 with SMTP id 10mr163546ebm.97.1299138180277; Wed, 02 Mar 2011 23:43:00 -0800 (PST) Received: from [10.0.69.6] ([78.90.209.87]) by mx.google.com with ESMTPS id q53sm689359eeh.22.2011.03.02.23.42.45 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 02 Mar 2011 23:42:57 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Nikolay Denev In-Reply-To: Date: Thu, 3 Mar 2011 09:42:41 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: <4D6DA259.4050307@sentex.net> To: Yanhui Shen X-Mailer: Apple Mail (2.1082) Cc: freebsd-stable@freebsd.org Subject: Re: CPU0: local APIC error 0x40 CPU1: local APIC error 0x40 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2011 08:07:22 -0000 On 3 Mar, 2011, at 02:39 , Yanhui Shen wrote: > `CPU0: local APIC error 0x40" > > I get this error on my ThinkPad R400(Intel Core2 T6570). > > > -- > Best regards, > Yanhui > _______________________________________________ > 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 saw this error too a few days ago, it was wen I plugged a USB keyboard to a HP EX470 machine. From owner-freebsd-stable@FreeBSD.ORG Thu Mar 3 08:11:04 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7B08E106564A; Thu, 3 Mar 2011 08:11:04 +0000 (UTC) (envelope-from lev@serebryakov.spb.ru) Received: from ftp.translate.ru (ftp.translate.ru [80.249.188.42]) by mx1.freebsd.org (Postfix) with ESMTP id A2C198FC1C; Thu, 3 Mar 2011 08:11:03 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (89.112.15.178.pppoe.eltel.net [89.112.15.178]) (Authenticated sender: lev@serebryakov.spb.ru) by ftp.translate.ru (Postfix) with ESMTPA id 8BE8413DF42; Thu, 3 Mar 2011 11:11:01 +0300 (MSK) Date: Thu, 3 Mar 2011 11:10:46 +0300 From: Lev Serebryakov X-Priority: 3 (Normal) Message-ID: <1627628072.20110303111046@serebryakov.spb.ru> To: Arnaud Lacombe In-Reply-To: References: <1975926365.20110223121637@serebryakov.spb.ru> <4D64EC8C.2080007@sentex.net> <1004451940.20110223143607@serebryakov.spb.ru> <4D6D00C1.1040805@sentex.net> <1416421652.20110301225215@serebryakov.spb.ru> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----------51A718D33013DCD" Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org, Jack Vogel , Jan Koum Subject: Re: em0 with latest driver hangs again and again (without "Watchdog timeout" message!) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2011 08:11:04 -0000 ------------51A718D33013DCD Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello, Arnaud. You wrote 2 =D0=BC=D0=B0=D1=80=D1=82=D0=B0 2011 =D0=B3., 9:55:50: >>> I have been running with 7.2.2 and so far so good. =C2=A0However, its h= ard to >>> say in my case as the box I would only periodically see the issue. >> =C2=A0As I wrote to Jack, my NIC hangs today with 7.2.2 > Do you have any detailed error ? What the output of sysctl "dev.em.X" > where X is the index of the hung interface ? One more hang. Two logs are attached. --=20 // Black Lion AKA Lev Serebryakov ------------51A718D33013DCD Content-Type: application/octet-stream; name="em0.7.2.2.hang1.log" Content-transfer-encoding: base64 Content-Disposition: attachment; filename="em0.7.2.2.hang1.log" Pj4+IGlmY29uZmlnIGVtMAplbTA6IGZsYWdzPThjNDM8VVAsQlJPQURDQVNULFJVTk5JTkcs T0FDVElWRSxTSU1QTEVYLE1VTFRJQ0FTVD4gbWV0cmljIDAgbXR1IDE1MDAKCW9wdGlvbnM9 MjE5YjxSWENTVU0sVFhDU1VNLFZMQU5fTVRVLFZMQU5fSFdUQUdHSU5HLFZMQU5fSFdDU1VN LFRTTzQsV09MX01BR0lDPgoJZXRoZXIgMDA6MWU6OGM6NzU6MDM6MGQKCWluZXQgMTkyLjE2 OC4xMzQuMyBuZXRtYXNrIDB4ZmZmZmZmMDAgYnJvYWRjYXN0IDE5Mi4xNjguMTM0LjI1NQoJ bWVkaWE6IEV0aGVybmV0IDEwMDBiYXNlVCA8ZnVsbC1kdXBsZXg+CglzdGF0dXM6IGFjdGl2 ZQo8PDwgaWZjb25maWcgZW0wCj4+PiB2bXN0YXQgLW0KICAgICAgICAgVHlwZSBJblVzZSBN ZW1Vc2UgSGlnaFVzZSBSZXF1ZXN0cyAgU2l6ZShzKQogICAgICAgbW9kdWxlICAgMTUyICAg IDE5SyAgICAgICAtICAgICAgMTUyICAxMjgKICAgICAgICAgIFVTQiAgICA3NiAgICA2Nksg ICAgICAgLSAgICAgICA4MCAgMTYsMzIsNjQsMTI4LDI1NiwxMDI0LDIwNDgsNDA5NgogICAg IG10eF9wb29sICAgICAyICAgIDE2SyAgICAgICAtICAgICAgICAyICAKICAgICBhY3BpdGFz ayAgICAgMSAgICAgMksgICAgICAgLSAgICAgICAgMSAgMjA0OAogICBDQU0gcGVyaXBoICAg IDIyICAgICA2SyAgICAgICAtICAgICAgIDQ0ICAxNiwzMiw2NCwyNTYKICAgICAgc3VicHJv YyAgIDQ2MSAgIDQwOUsgICAgICAgLSAgICA0MTA5MSAgNTEyLDQwOTYKICAgICAgICAgcHJv YyAgICAgMiAgICAxNksgICAgICAgLSAgICAgICAgMiAgCiAgICAgIHNlc3Npb24gICAgMjUg ICAgIDRLICAgICAgIC0gICAgIDI2ODcgIDEyOAogICAgICAgICBwZ3JwICAgIDI3ICAgICA0 SyAgICAgICAtICAgICAyNzY5ICAxMjgKICAgICAgICAgY3JlZCAgICA2NiAgICAxMUsgICAg ICAgLSAgMjAzMTg3MiAgNjQsMjU2CiAgICAgIHVpZGluZm8gICAgIDggICAgIDNLICAgICAg IC0gICAzMzg4MTIgIDEyOCwyMDQ4CiAgICAgICBwbGltaXQgICAgMTEgICAgIDNLICAgICAg IC0gICAgMzQ0MTggIDI1NgogICAgIHBjaV9saW5rICAgIDE2ICAgICAySyAgICAgICAtICAg ICAgIDE2ICA2NCwxMjgKICAgICAgYWNwaXNlbSAgICAxOSAgICAgM0sgICAgICAgLSAgICAg ICAxOSAgMTI4CiAgICAgICBERVZGUzEgICAxNDMgICAgNzJLICAgICAgIC0gICAgICAxNTIg IDUxMgogICAgc3lzY3RsdG1wICAgICAwICAgICAwSyAgICAgICAtICAgICAgOTE0ICAxNiwz Miw2NCwxMjgKICAgIHN5c2N0bG9pZCAgMzI1MiAgIDE2MUsgICAgICAgLSAgICAgMzM4NiAg MTYsMzIsNjQsMTI4CiAgICAgICBzeXNjdGwgICAgIDAgICAgIDBLICAgICAgIC0gICAgMTU4 MDIgIDE2LDMyLDY0CiAgICAgIGNhbGxvdXQgICAgIDEgICA1MTJLICAgICAgIC0gICAgICAg IDEgIAogICAgICAgICB1bXR4ICAgNDg5ICAgIDYySyAgICAgICAtICAgICAgNDg5ICAxMjgK ICAgICBwMTAwMy4xYiAgICAgMSAgICAgMUsgICAgICAgLSAgICAgICAgMSAgMTYKICAgICAg ICAgU1dBUCAgICAgMiAgIDU0OUsgICAgICAgLSAgICAgICAgMiAgNjQKICAgICAgIERFVkZT MyAgIDE2OSAgICA0M0sgICAgICAgLSAgICAgIDE3OSAgMjU2CiAgICAgICBidXMtc2MgICAg NjMgICAzNzNLICAgICAgIC0gICAgIDEyNzEgIDE2LDMyLDY0LDEyOCwyNTYsNTEyLDIwNDgs NDA5NgogICAgICAgICAgYnVzICAgNjA5ICAgIDYySyAgICAgICAtICAgICAzNTkzICAxNiwz Miw2NCwxMjgsMjU2LDUxMiwxMDI0CiAgICAgIGRldnN0YXQgICAgMTQgICAgMjlLICAgICAg IC0gICAgICAgMTQgIDMyLDQwOTYKIGV2ZW50aGFuZGxlciAgICA2NyAgICAgNksgICAgICAg LSAgICAgICA2NyAgNjQsMTI4CiAgICAgICAgIGtvYmogICAgOTMgICAzNzJLICAgICAgIC0g ICAgICAxMjEgIDQwOTYKICAgICAgUGVyLWNwdSAgICAgMSAgICAgMUsgICAgICAgLSAgICAg ICAgMSAgMzIKICAgICAgICBERVZGUyAgICAyMCAgICAgMUsgICAgICAgLSAgICAgICAyMSAg MTYsMTI4CiAgICAgICAgIHJtYW4gICAxNzcgICAgMjJLICAgICAgIC0gICAgICA2MDEgIDE2 LDMyLDEyOAogICAgICAgREVWRlNQICAgICAxICAgICAxSyAgICAgICAtICAgICAgICAxICA2 NAogICAgICAgICBzYnVmICAgICAwICAgICAwSyAgICAgICAtICAgICAxMzEyICAxNiwzMiw2 NCwxMjgsMjU2LDUxMiwxMDI0LDIwNDgsNDA5NgogICAgcGZzX25vZGVzICAgIDIxICAgICA2 SyAgICAgICAtICAgICAgIDIxICAyNTYKICAgICAgQ0FNIFhQVCAgIDI5MiAgIDQyM0sgICAg ICAgLSAgICAgIDQxMyAgMTYsMzIsNjQsMTI4LDI1NiwxMDI0LDIwNDgKICAgICAgICBzdGFj ayAgICAgMCAgICAgMEsgICAgICAgLSAgICAgICAgMiAgMjU2CiAgICB0YXNrcXVldWUgICAg MTUgICAgIDJLICAgICAgIC0gICAgICAgMTUgIDE2LDMyLDEyOAogICAgICAgVW5pdG5vICAg IDEyICAgICAxSyAgICAgICAtICAgICAgIDU0ICAzMiw2NAogICAgICAgICAgaW92ICAgICAw ICAgICAwSyAgICAgICAtICAgMjUwMzYzICAxNiwzMiw2NCwxMjgsMjU2LDUxMgogICAgICAg c2VsZWN0ICAgMTUwICAgIDE5SyAgICAgICAtIDk0NDczMjYyMTUgIDEyOCw1MTIsMTAyNAog ICAgIGlvY3Rsb3BzICAgICAwICAgICAwSyAgICAgICAtIDE3MjkxNTQyMCAgMTYsMzIsNjQs MTI4LDI1Niw1MTIsMTAyNCwyMDQ4LDQwOTYKICAgICAgICAgIG1zZyAgICAgNCAgICAzMEsg ICAgICAgLSAgICAgICAgNCAgMjA0OCw0MDk2CiAgICAgICAgICBzZW0gICAgIDQgICAgMTFL ICAgICAgIC0gICAgICAgIDQgIDUxMiwxMDI0CiAgICAgICAgICBzaG0gICAgIDEgICAgMjBL ICAgICAgIC0gICAgICAgIDEgIAogICAgICAgICAgdHR5ICAgIDIxICAgIDIxSyAgICAgICAt ICAgICAgIDI2ICAxMDI0LDIwNDgKICAgICAgICAgIHB0cyAgICAgMSAgICAgMUsgICAgICAg LSAgICAgICAgNCAgMjU2CiAgICAgbWJ1Zl90YWcgICAgIDAgICAgIDBLICAgICAgIC0gICAg ICAgMzMgIDMyCiAgICAgICAgc2htZmQgICAgIDEgICAgIDhLICAgICAgIC0gICAgICAgIDEg IAogICAgICAgICBHRU9NICAgMTc1ICAgIDM4SyAgICAgICAtICAgICAgODcxICAxNiwzMiw2 NCwxMjgsMjU2LDUxMiwxMDI0CiAgICAgICAgICBwY2IgICAgOTUgICAgMTVLICAgICAgIC0g IDQ2NzU5NDggIDE2LDMyLDEwMjQsMjA0OCw0MDk2CiAgICAgICBzb25hbWUgICAgIDcgICAg IDFLICAgICAgIC0gMTgxMzkxNzYgIDE2LDMyLDEyOAogICAgICAgICAgYWNsICAgICAwICAg ICAwSyAgICAgICAtICAgICAxNDE5ICA0MDk2CiAgICAgICBiaW9idWYgICAgIDAgICAgIDBL ICAgICAgIC0gICAgICAxOTQgIDIwNDgKICAgICB2ZnNjYWNoZSAgICAgMSAgMTAyNEsgICAg ICAgLSAgICAgICAgMSAgCiAgIGNsX3NhdmVidWYgICAgIDAgICAgIDBLICAgICAgIC0gICAg NDYzNzIgIDY0LDEyOAogIGV4cG9ydF9ob3N0ICAgICAyICAgICAxSyAgICAgICAtICAgICAg ICAyICAyNTYKICAgICB2ZnNfaGFzaCAgICAgMSAgIDUxMksgICAgICAgLSAgICAgICAgMSAg CiAgICAgICB2bm9kZXMgICAgIDIgICAgIDFLICAgICAgIC0gICAgICAgIDIgIDI1NgogIHZu b2RlbWFya2VyICAgICAwICAgICAwSyAgICAgICAtICAgMTY3OTY1ICA1MTIKICAgICAgICBt b3VudCAgIDEwNCAgICAgNksgICAgICAgLSAgICAgIDMwNCAgMTYsMzIsNjQsMTI4LDI1Niw1 MTIKICAgICAgICAgIEJQRiAgICAgNyAgICAgOUsgICAgICAgLSAgICAgICAgNyAgMTI4LDUx Miw0MDk2CiAgZXRoZXJfbXVsdGkgICAgMTIgICAgIDFLICAgICAgIC0gICAgICAgMjYgIDE2 LDY0CiAgICAgICBpZmFkZHIgICAgMTQgICAgIDdLICAgICAgIC0gICAgICAgMTUgIDMyLDUx Miw0MDk2CiAgICAgICAgaWZuZXQgICAgIDMgICAgIDVLICAgICAgIC0gICAgICAgIDMgIDEy OCwyMDQ4CiAgICAgICAgY2xvbmUgICAgIDIgICAgIDhLICAgICAgIC0gICAgICAgIDIgIDQw OTYKICAgICAgIGFycGNvbSAgICAgMSAgICAgMUsgICAgICAgLSAgICAgICAgMSAgMTYKICAg ICAgbGx0YWJsZSAgICAgMyAgICAgMksgICAgICAgLSAgICAgICAzMSAgMjU2LDUxMgogICAg ICAga2JkbXV4ICAgICA2ICAgIDEwSyAgICAgICAtICAgICAgICA2ICAxNiw1MTIsMTAyNCwy MDQ4LDQwOTYKICAgICAgICAgIExFRCAgICAgMSAgICAgMUsgICAgICAgLSAgICAgICAgMSAg MTI4CiAgICAgICBpc2FkZXYgICAgIDYgICAgIDFLICAgICAgIC0gICAgICAgIDYgIDEyOAog ICAgIHJvdXRldGJsICAgIDE0ICAgICA0SyAgICAgICAtICAgMTI1NTM3ICAzMiw2NCwxMjgs MjU2LDUxMgogICAgICAgICBpZ21wICAgICAyICAgICAxSyAgICAgICAtICAgICAgICAyICAy NTYKICAgICAgc2NzaV9kYSAgICAgMCAgICAgMEsgICAgICAgLSAgICAgICAxNiAgMTYKQ0FN IGRldiBxdWV1ZSAgICAgOCAgICAgMUsgICAgICAgLSAgICAgICAgOCAgMTI4CiAgaXBfbW9w dGlvbnMgICAgIDQgICAgIDFLICAgICAgIC0gICAgICAgIDggIDY0LDI1NgogICAgIGluX211 bHRpICAgICAzICAgICAxSyAgICAgICAtICAgICAgICA1ICAyNTYKICAgaW5fbWZpbHRlciAg ICAgMiAgICAgMksgICAgICAgLSAgICAgICAgNCAgMTAyNAogICAgaG9zdGNhY2hlICAgICAx ICAgIDI4SyAgICAgICAtICAgICAgICAxICAKICAgICBzeW5jYWNoZSAgICAgMSAgICA5Nksg ICAgICAgLSAgICAgICAgMSAgCiAgICAgIE5GUyBGSEEgICAgIDEgICAgIDJLICAgICAgIC0g ICAgICAyODUgIDY0LDIwNDgKICAgICAgICAgIHJwYyAgIDI5NCAgIDE1MksgICAgICAgLSAg ICAgIDkyMyAgMzIsNjQsMTI4LDI1Niw1MTIsMjA0OAphdWRpdF9ldmNsYXNzICAgMTcyICAg ICA2SyAgICAgICAtICAgICAgMjExICAzMgogICAgIHNhdmVkaW5vICAgICAwICAgICAwSyAg ICAgICAtICAgIDI3MDc2ICAyNTYKICAgIG5ld2RpcmJsayAgICAgMCAgICAgMEsgICAgICAg LSAgICAgICAgNSAgNjQKICAgICAgIGRpcnJlbSAgICAgMCAgICAgMEsgICAgICAgLSAgIDE0 NjAwOSAgNjQKICAgICAgICBta2RpciAgICAgMSAgICAgMUsgICAgICAgLSAgICAgIDQ2MiAg NjQKICAgICAgIGRpcmFkZCAgICAgMyAgICAgMUsgICAgICAgLSAgIDE0Nzc3NiAgNjQKICAg ICBmcmVlZmlsZSAgICAgMSAgICAgMUsgICAgICAgLSAgICA2OTk4MiAgNjQKICAgICBmcmVl YmxrcyAgICAgMSAgICAgMUsgICAgICAgLSAgICA3MDA3NCAgMjU2CiAgICAgZnJlZWZyYWcg ICAgIDAgICAgIDBLICAgICAgIC0gICAxMzQwNDQgIDY0CiAgIGFsbG9jaW5kaXIgICAgIDAg ICAgIDBLICAgICAgIC0gICAyODY4MDAgIDEyOAogICAgIGluZGlyZGVwICAgICAwICAgICAw SyAgICAgICAtICAgICAzNDgxICA2NAogIGFsbG9jZGlyZWN0ICAgICAzICAgICAxSyAgICAg ICAtICAgMzIxNTI5ICAyNTYKICAgIGJtc2FmZW1hcCAgICAgMiAgICAgMUsgICAgICAgLSAg ICA4MjgyNyAgMTI4CiAgICAgICBuZXdibGsgICAgIDEgICAgIDFLICAgICAgIC0gICA2MDgz MzAgIDY0LDUxMgogICAgIGlub2RlZGVwICAgICA2ICAgNTE0SyAgICAgICAtICAgMTY2NDc5 ICAyNTYKICAgICAgcGFnZWRlcCAgICAgNCAgIDEyOUsgICAgICAgLSAgICAyNTg2MyAgMTI4 CiAgdWZzX2Rpcmhhc2ggICAyMzAgICAxMDVLICAgICAgIC0gICA0MTY4NzQgIDE2LDMyLDY0 LDEyOCwyNTYsNTEyLDEwMjQKICAgIHVmc19tb3VudCAgICAxNSAgIDEyN0sgICAgICAgLSAg ICAgICAxNSAgNTEyLDIwNDgsNDA5NgogICAgICBVTUFIYXNoICAgICAzICAgICA3SyAgICAg ICAtICAgICAgICA5ICA1MTIsMTAyNCwyMDQ4LDQwOTYKICAgIENBTSBxdWV1ZSAgICA0MyAg ICAgM0sgICAgICAgLSAgICAgIDE0OCAgMTYsMzIsNjQsMjU2CiAgICAgIENBTSBTSU0gICAg IDggICAgIDJLICAgICAgIC0gICAgICAgIDggIDI1NgogICAgICAgICBjZGV2ICAgICA4ICAg ICAySyAgICAgICAtICAgICAgICA4ICAyNTYKICAgIHZtX3BnZGF0YSAgICAgMiAgIDEyOUsg ICAgICAgLSAgICAgICAgMiAgMTI4CiAgZGRiX2NhcHR1cmUgICAgIDEgICAgNDhLICAgICAg IC0gICAgICAgIDEgIAogICAgICAgYWNwaWNhICAzNzcwICAgMzg2SyAgICAgICAtICAgIDkw MzM2ICAxNiwzMiw2NCwxMjgsMjU2LDUxMiwxMDI0LDIwNDgKICAgICAgICBzaWdpbyAgICAg MSAgICAgMUsgICAgICAgLSAgICAgICAgMSAgNjQKICAgICBmaWxlZGVzYyAgICA2MyAgICA3 OEsgICAgICAgLSAgICA2MzQyOSAgMTYsMzIsNjQsMTI4LDI1Niw1MTIsMTAyNCwyMDQ4LDQw OTYKICAgICAgICAga2VudiAgICA3NiAgICAxMUsgICAgICAgLSAgICAgICA4MCAgMTYsMzIs NjQsMTI4CiAgICAgIGlvX2FwaWMgICAgIDEgICAgIDJLICAgICAgIC0gICAgICAgIDEgIDIw NDgKICAgICAgIGtxdWV1ZSAgICAgMiAgICAxM0sgICAgICAgLSAgIDE4NTQwNyAgMjU2LDIw NDgsNDA5NgogICAgICBtZW1kZXNjICAgICAxICAgICA0SyAgICAgICAtICAgICAgICAxICA0 MDk2CiAgICAgIGFjcGlkZXYgICAgNzggICAgIDVLICAgICAgIC0gICAgICAgNzggIDY0CiAg ICBwcm9jLWFyZ3MgICAgMzAgICAgIDJLICAgICAgIC0gICAxMTQ1MDUgIDE2LDMyLDY0LDEy OCwyNTYKICAgICBhdGtiZGRldiAgICAgMiAgICAgMUsgICAgICAgLSAgICAgICAgMiAgNjQK ICAgICAgaXRocmVhZCAgICA3MiAgICAxMksgICAgICAgLSAgICAgICA3MiAgMzIsMTI4LDI1 NgogICAgICBlbnRyb3B5ICAxMDI0ICAgIDY0SyAgICAgICAtICAgICAxMDI0ICA2NAogICAg ICAgICBVQVJUICAgICAzICAgICAySyAgICAgICAtICAgICAgICAzICAxNiw1MTIsMTAyNAog ICAgICAgS1RSQUNFICAgMTAwICAgIDEzSyAgICAgICAtICAgICAgMTAwICAxMjgKICAgICAg IGxpbmtlciAgICA2MyAgICAgN0sgICAgICAgLSAgICAgICA3NSAgMTYsMzIsNjQsMTI4LDUx MgogICAgICAgIGxvY2tmICAgIDUzICAgICA2SyAgICAgICAtICAzNDQ1OTY5ICA2NCwxMjgK ICAgICAgICAgdGVtcCAgICAyMCAgIDQwMUsgICAgICAgLSAgIDM3OTc2NiAgMTYsMzIsNjQs MTI4LDI1Niw1MTIsMTAyNCwyMDQ4LDQwOTYKICAgICAgIGRldmJ1ZiAxOTk5OSAzNDg3N0sg ICAgICAgLSAgICAyMDEwMiAgMTYsMzIsNjQsMTI4LDI1Niw1MTIsMTAyNCwyMDQ4LDQwOTYK ICAgICAgIFVTQmRldiAgICA0NyAgICAxMksgICAgICAgLSAgICAgICA0NyAgNjQsMTI4LDEw MjQKICAgICBuZXh1c2RldiAgICAgMyAgICAgMUsgICAgICAgLSAgICAgICAgMyAgMTYKICAg cmFpZDVfZGF0YSAgICAxNyAgNDA3M0sgICAgICAgLSAxNTk4NjY2NDYgIDE2LDY0LDUxMiw0 MDk2Cjw8PCB2bXN0YXQgLW0KPj4+IG5ldHN0YXQgLW0KMzgwOC82MzAyLzEwMTEwIG1idWZz IGluIHVzZSAoY3VycmVudC9jYWNoZS90b3RhbCkKMTYwMC82MzgwLzc5ODAvMjA0ODAwIG1i dWYgY2x1c3RlcnMgaW4gdXNlIChjdXJyZW50L2NhY2hlL3RvdGFsL21heCkKMTUwNC81ODE2 IG1idWYrY2x1c3RlcnMgb3V0IG9mIHBhY2tldCBzZWNvbmRhcnkgem9uZSBpbiB1c2UgKGN1 cnJlbnQvY2FjaGUpCjIvMjY2LzI2OC8xOTIwMDAgNGsgKHBhZ2Ugc2l6ZSkganVtYm8gY2x1 c3RlcnMgaW4gdXNlIChjdXJyZW50L2NhY2hlL3RvdGFsL21heCkKMC8wLzAvNjQwMCA5ayBq dW1ibyBjbHVzdGVycyBpbiB1c2UgKGN1cnJlbnQvY2FjaGUvdG90YWwvbWF4KQowLzAvMC8z MjAwIDE2ayBqdW1ibyBjbHVzdGVycyBpbiB1c2UgKGN1cnJlbnQvY2FjaGUvdG90YWwvbWF4 KQo0MTYwSy8xNTM5OUsvMTk1NTlLIGJ5dGVzIGFsbG9jYXRlZCB0byBuZXR3b3JrIChjdXJy ZW50L2NhY2hlL3RvdGFsKQowLzAvMCByZXF1ZXN0cyBmb3IgbWJ1ZnMgZGVuaWVkIChtYnVm cy9jbHVzdGVycy9tYnVmK2NsdXN0ZXJzKQowLzAvMCByZXF1ZXN0cyBmb3IganVtYm8gY2x1 c3RlcnMgZGVuaWVkICg0ay85ay8xNmspCjAvMC8wIHNmYnVmcyBpbiB1c2UgKGN1cnJlbnQv cGVhay9tYXgpCjAgcmVxdWVzdHMgZm9yIHNmYnVmcyBkZW5pZWQKMCByZXF1ZXN0cyBmb3Ig c2ZidWZzIGRlbGF5ZWQKMCByZXF1ZXN0cyBmb3IgSS9PIGluaXRpYXRlZCBieSBzZW5kZmls ZQowIGNhbGxzIHRvIHByb3RvY29sIGRyYWluIHJvdXRpbmVzCjw8PCBuZXRzdGF0IC1tCj4+ PiB0b3AgLVNuZCAxCmxhc3QgcGlkOiA0MDY4MTsgIGxvYWQgYXZlcmFnZXM6ICAwLjAyLCAg MC4wMiwgIDAuMDAgIHVwIDUrMTI6NTQ6NDAgICAgMTE6MzA6NDEKMTE0IHByb2Nlc3Nlczog MyBydW5uaW5nLCA5NCBzbGVlcGluZywgMTcgd2FpdGluZwoKTWVtOiA3Mk0gQWN0aXZlLCAx MzA4TSBJbmFjdCwgNDM0TSBXaXJlZCwgOTZNIENhY2hlLCAyMTNNIEJ1ZiwgNjZNIEZyZWUK U3dhcDogNDA5Nk0gVG90YWwsIDI3MksgVXNlZCwgNDA5Nk0gRnJlZQoKCiAgUElEIFVTRVJO QU1FICAgICAgVEhSIFBSSSBOSUNFICAgU0laRSAgICBSRVMgU1RBVEUgICBDICAgVElNRSAg IFdDUFUgQ09NTUFORAogICAxMSByb290ICAgICAgICAgICAgMiAxNzEga2kzMSAgICAgMEsg ICAgMzJLIENQVTAgICAgMCAxODYuNEggMjAwLjAwJSBpZGxlCiAgIDEyIHJvb3QgICAgICAg ICAgIDE3IC02MCAgICAtICAgICAwSyAgIDI3MksgV0FJVCAgICAwIDE0MDowMiAgMS4zNyUg aW50cgozMzk2NyBydG9ycmVudCAgICAgICAgMyAgNDQgICAgMCA3NzU2MEsgNjE0NDhLIHNl bGVjdCAgMCAyOTI6MTQgIDAuMDAlIHRyYW5zbWlzc2lvbi1kYWVtb24KICAgIDAgcm9vdCAg ICAgICAgICAgIDkgLTY4ICAgIDAgICAgIDBLICAgMTI4SyAtICAgICAgIDAgIDM3OjM1ICAw LjAwJSBrZXJuZWwKICAgMTkgcm9vdCAgICAgICAgICAgIDIgIC04ICAgIC0gICAgIDBLICAg IDMySyBncjVkbyAgIDEgIDE5OjAzICAwLjAwJSBnX3JhaWQ1CiAgIDE0IHJvb3QgICAgICAg ICAgIDMzIC00MCAgICAtICAgICAwSyAgIDUyOEsgLSAgICAgICAxICAxNjoxMiAgMC4wMCUg dXNiCiAgICA0IHJvb3QgICAgICAgICAgICAxICAtOCAgICAtICAgICAwSyAgICAxNksgLSAg ICAgICAxICAxNTo0MyAgMC4wMCUgZ19kb3duCiAgICAzIHJvb3QgICAgICAgICAgICAxICAt OCAgICAtICAgICAwSyAgICAxNksgLSAgICAgICAwICAxMjowNSAgMC4wMCUgZ191cAogICAx MyByb290ICAgICAgICAgICAgMSAtMTYgICAgLSAgICAgMEsgICAgMTZLIC0gICAgICAgMCAg IDc6MjQgIDAuMDAlIHlhcnJvdwogICAxNyByb290ICAgICAgICAgICAgMSAgMjAgICAgLSAg ICAgMEsgICAgMTZLIHN5bmNlciAgMSAgIDc6MDAgIDAuMDAlIHN5bmNlcgogICAgNiByb290 ICAgICAgICAgICAgMSAtMTYgICAgLSAgICAgMEsgICAgMTZLIHBzbGVlcCAgMSAgIDM6NTIg IDAuMDAlIHBhZ2VkYWVtb24KICA5MTAgdXVjcCAgICAgICAgICAgIDEgIDQ0ICAgIDAgIDY5 MTZLICAxMzI4SyBzZWxlY3QgIDEgICAwOjM4ICAwLjAwJSBtZWdhdGVjCiAgNzg1IHJvb3Qg ICAgICAgICAgICAxICA0NCAgICAwIDIxMDUySyAgMjc5Mksgc2VsZWN0ICAwICAgMDoxNyAg MC4wMCUgbm1iZAogIDkxMiB1dWNwICAgICAgICAgICAgMSAgNDQgICAgMCAxMDkyOEsgIDIx NjhLIHNlbGVjdCAgMSAgIDA6MTcgIDAuMDAlIHVwc2QKICAgIDIgcm9vdCAgICAgICAgICAg IDEgIC04ICAgIC0gICAgIDBLICAgIDE2SyAtICAgICAgIDAgICAwOjE1ICAwLjAwJSBnX2V2 ZW50CiAgODU3IHJvb3QgICAgICAgICAgICAxICA0NCAgICAwIDExNzg4SyAgMjAyNEsgc2Vs ZWN0ICAxICAgMDoxNCAgMC4wMCUgbnRwZAogICAxNiByb290ICAgICAgICAgICAgMSAgNDQg ICAgLSAgICAgMEsgICAgMTZLIHZscnV3dCAgMCAgIDA6MTMgIDAuMDAlIHZubHJ1CiAxMDI2 IHJvb3QgICAgICAgICAgICAxICA0NCAgICAwIDEyMDE2SyAgMzAyOEsgc2VsZWN0ICAxICAg MDowNiAgMC4wMCUgc2VuZG1haWwKCjw8PCB0b3AgLVNuZCAxCj4+PiBzeXNjdGwgZGV2LmVt LjAKZGV2LmVtLjAuJWRlc2M6IEludGVsKFIpIFBSTy8xMDAwIE5ldHdvcmsgQ29ubmVjdGlv biA3LjIuMgpkZXYuZW0uMC4lZHJpdmVyOiBlbQpkZXYuZW0uMC4lbG9jYXRpb246IHNsb3Q9 MjUgZnVuY3Rpb249MCBoYW5kbGU9XF9TQl8uUENJMC5HQkVDCmRldi5lbS4wLiVwbnBpbmZv OiB2ZW5kb3I9MHg4MDg2IGRldmljZT0weDEwYmQgc3VidmVuZG9yPTB4MTA0MyBzdWJkZXZp Y2U9MHg4MjY4IGNsYXNzPTB4MDIwMDAwCmRldi5lbS4wLiVwYXJlbnQ6IHBjaTAKZGV2LmVt LjAubnZtOiAtMQpkZXYuZW0uMC5kZWJ1ZzogLTEKZGV2LmVtLjAucnhfaW50X2RlbGF5OiAw CmRldi5lbS4wLnR4X2ludF9kZWxheTogNjYKZGV2LmVtLjAucnhfYWJzX2ludF9kZWxheTog NjYKZGV2LmVtLjAudHhfYWJzX2ludF9kZWxheTogNjYKZGV2LmVtLjAucnhfcHJvY2Vzc2lu Z19saW1pdDogMTAwCmRldi5lbS4wLmZsb3dfY29udHJvbDogMwpkZXYuZW0uMC5lZWVfY29u dHJvbDogMApkZXYuZW0uMC5saW5rX2lycTogMApkZXYuZW0uMC5tYnVmX2FsbG9jX2ZhaWw6 IDAKZGV2LmVtLjAuY2x1c3Rlcl9hbGxvY19mYWlsOiAwCmRldi5lbS4wLmRyb3BwZWQ6IDAK ZGV2LmVtLjAudHhfZG1hX2ZhaWw6IDAKZGV2LmVtLjAucnhfb3ZlcnJ1bnM6IDAKZGV2LmVt LjAud2F0Y2hkb2dfdGltZW91dHM6IDAKZGV2LmVtLjAuZGV2aWNlX2NvbnRyb2w6IDE0Nzc0 NDQxNjAKZGV2LmVtLjAucnhfY29udHJvbDogNjcxNDE2MzQKZGV2LmVtLjAuZmNfaGlnaF93 YXRlcjogODE5MgpkZXYuZW0uMC5mY19sb3dfd2F0ZXI6IDY2OTIKZGV2LmVtLjAucXVldWUw LnR4ZF9oZWFkOiAyMjcKZGV2LmVtLjAucXVldWUwLnR4ZF90YWlsOiAxOTAKZGV2LmVtLjAu cXVldWUwLnR4X2lycTogMApkZXYuZW0uMC5xdWV1ZTAubm9fZGVzY19hdmFpbDogMApkZXYu ZW0uMC5xdWV1ZTAucnhkX2hlYWQ6IDI4OApkZXYuZW0uMC5xdWV1ZTAucnhkX3RhaWw6IDI4 NwpkZXYuZW0uMC5xdWV1ZTAucnhfaXJxOiAwCmRldi5lbS4wLm1hY19zdGF0cy5leGNlc3Nf Y29sbDogMApkZXYuZW0uMC5tYWNfc3RhdHMuc2luZ2xlX2NvbGw6IDAKZGV2LmVtLjAubWFj X3N0YXRzLm11bHRpcGxlX2NvbGw6IDAKZGV2LmVtLjAubWFjX3N0YXRzLmxhdGVfY29sbDog MApkZXYuZW0uMC5tYWNfc3RhdHMuY29sbGlzaW9uX2NvdW50OiAwCmRldi5lbS4wLm1hY19z dGF0cy5zeW1ib2xfZXJyb3JzOiAwCmRldi5lbS4wLm1hY19zdGF0cy5zZXF1ZW5jZV9lcnJv cnM6IDAKZGV2LmVtLjAubWFjX3N0YXRzLmRlZmVyX2NvdW50OiAxMzExCmRldi5lbS4wLm1h Y19zdGF0cy5taXNzZWRfcGFja2V0czogMjM5NQpkZXYuZW0uMC5tYWNfc3RhdHMucmVjdl9u b19idWZmOiAwCmRldi5lbS4wLm1hY19zdGF0cy5yZWN2X3VuZGVyc2l6ZTogMApkZXYuZW0u MC5tYWNfc3RhdHMucmVjdl9mcmFnbWVudGVkOiA0CmRldi5lbS4wLm1hY19zdGF0cy5yZWN2 X292ZXJzaXplOiAwCmRldi5lbS4wLm1hY19zdGF0cy5yZWN2X2phYmJlcjogMApkZXYuZW0u MC5tYWNfc3RhdHMucmVjdl9lcnJzOiAxNDcKZGV2LmVtLjAubWFjX3N0YXRzLmNyY19lcnJz OiAxNTYKZGV2LmVtLjAubWFjX3N0YXRzLmFsaWdubWVudF9lcnJzOiAwCmRldi5lbS4wLm1h Y19zdGF0cy5jb2xsX2V4dF9lcnJzOiAxCmRldi5lbS4wLm1hY19zdGF0cy54b25fcmVjdmQ6 IDEzNDQKZGV2LmVtLjAubWFjX3N0YXRzLnhvbl90eGQ6IDAKZGV2LmVtLjAubWFjX3N0YXRz LnhvZmZfcmVjdmQ6IDMxNTAKZGV2LmVtLjAubWFjX3N0YXRzLnhvZmZfdHhkOiAwCmRldi5l bS4wLm1hY19zdGF0cy50b3RhbF9wa3RzX3JlY3ZkOiAzNTQ4NDE0ODMKZGV2LmVtLjAubWFj X3N0YXRzLmdvb2RfcGt0c19yZWN2ZDogMzU0ODM0NDI5CmRldi5lbS4wLm1hY19zdGF0cy5i Y2FzdF9wa3RzX3JlY3ZkOiAxMjA3NwpkZXYuZW0uMC5tYWNfc3RhdHMubWNhc3RfcGt0c19y ZWN2ZDogMApkZXYuZW0uMC5tYWNfc3RhdHMucnhfZnJhbWVzXzY0OiAwCmRldi5lbS4wLm1h Y19zdGF0cy5yeF9mcmFtZXNfNjVfMTI3OiAwCmRldi5lbS4wLm1hY19zdGF0cy5yeF9mcmFt ZXNfMTI4XzI1NTogMApkZXYuZW0uMC5tYWNfc3RhdHMucnhfZnJhbWVzXzI1Nl81MTE6IDAK ZGV2LmVtLjAubWFjX3N0YXRzLnJ4X2ZyYW1lc181MTJfMTAyMzogMApkZXYuZW0uMC5tYWNf c3RhdHMucnhfZnJhbWVzXzEwMjRfMTUyMjogMApkZXYuZW0uMC5tYWNfc3RhdHMuZ29vZF9v Y3RldHNfcmVjdmQ6IDMzMDYwNDMxMzA1CmRldi5lbS4wLm1hY19zdGF0cy5nb29kX29jdGV0 c190eGQ6IDg4ODE5NTg4MTgxNQpkZXYuZW0uMC5tYWNfc3RhdHMudG90YWxfcGt0c190eGQ6 IDY3OTkzMjk4OQpkZXYuZW0uMC5tYWNfc3RhdHMuZ29vZF9wa3RzX3R4ZDogNjc5OTMyOTg5 CmRldi5lbS4wLm1hY19zdGF0cy5iY2FzdF9wa3RzX3R4ZDogMjQzMgpkZXYuZW0uMC5tYWNf c3RhdHMubWNhc3RfcGt0c190eGQ6IDE0OTM5CmRldi5lbS4wLm1hY19zdGF0cy50eF9mcmFt ZXNfNjQ6IDAKZGV2LmVtLjAubWFjX3N0YXRzLnR4X2ZyYW1lc182NV8xMjc6IDAKZGV2LmVt LjAubWFjX3N0YXRzLnR4X2ZyYW1lc18xMjhfMjU1OiAwCmRldi5lbS4wLm1hY19zdGF0cy50 eF9mcmFtZXNfMjU2XzUxMTogMApkZXYuZW0uMC5tYWNfc3RhdHMudHhfZnJhbWVzXzUxMl8x MDIzOiAwCmRldi5lbS4wLm1hY19zdGF0cy50eF9mcmFtZXNfMTAyNF8xNTIyOiAwCmRldi5l bS4wLm1hY19zdGF0cy50c29fdHhkOiAyMDgxNzY2OTEKZGV2LmVtLjAubWFjX3N0YXRzLnRz b19jdHhfZmFpbDogMApkZXYuZW0uMC5pbnRlcnJ1cHRzLmFzc2VydHM6IDQ5NTU4NzAzNwpk ZXYuZW0uMC5pbnRlcnJ1cHRzLnJ4X3BrdF90aW1lcjogMApkZXYuZW0uMC5pbnRlcnJ1cHRz LnJ4X2Fic190aW1lcjogMApkZXYuZW0uMC5pbnRlcnJ1cHRzLnR4X3BrdF90aW1lcjogMApk ZXYuZW0uMC5pbnRlcnJ1cHRzLnR4X2Fic190aW1lcjogMApkZXYuZW0uMC5pbnRlcnJ1cHRz LnR4X3F1ZXVlX2VtcHR5OiAwCmRldi5lbS4wLmludGVycnVwdHMudHhfcXVldWVfbWluX3Ro cmVzaDogMApkZXYuZW0uMC5pbnRlcnJ1cHRzLnJ4X2Rlc2NfbWluX3RocmVzaDogMApkZXYu ZW0uMC5pbnRlcnJ1cHRzLnJ4X292ZXJydW46IDAKZGV2LmVtLjAud2FrZTogMAo8PDwgc3lz Y3RsIGRldi5lbS4wCg== ------------51A718D33013DCD Content-Type: application/octet-stream; name="em0.7.2.2.hang2.log" Content-transfer-encoding: base64 Content-Disposition: attachment; filename="em0.7.2.2.hang2.log" Pj4+IGlmY29uZmlnIGVtMAplbTA6IGZsYWdzPThjNDM8VVAsQlJPQURDQVNULFJVTk5JTkcs T0FDVElWRSxTSU1QTEVYLE1VTFRJQ0FTVD4gbWV0cmljIDAgbXR1IDE1MDAKCW9wdGlvbnM9 MjE5YjxSWENTVU0sVFhDU1VNLFZMQU5fTVRVLFZMQU5fSFdUQUdHSU5HLFZMQU5fSFdDU1VN LFRTTzQsV09MX01BR0lDPgoJZXRoZXIgMDA6MWU6OGM6NzU6MDM6MGQKCWluZXQgMTkyLjE2 OC4xMzQuMyBuZXRtYXNrIDB4ZmZmZmZmMDAgYnJvYWRjYXN0IDE5Mi4xNjguMTM0LjI1NQoJ bWVkaWE6IEV0aGVybmV0IDEwMDBiYXNlVCA8ZnVsbC1kdXBsZXg+CglzdGF0dXM6IGFjdGl2 ZQo8PDwgaWZjb25maWcgZW0wCj4+PiB2bXN0YXQgLW0KICAgICAgICAgVHlwZSBJblVzZSBN ZW1Vc2UgSGlnaFVzZSBSZXF1ZXN0cyAgU2l6ZShzKQogICAgICAgbW9kdWxlICAgMTUyICAg IDE5SyAgICAgICAtICAgICAgMTUyICAxMjgKICAgICAgICAgIFVTQiAgICA3NiAgICA2Nksg ICAgICAgLSAgICAgICA4MCAgMTYsMzIsNjQsMTI4LDI1NiwxMDI0LDIwNDgsNDA5NgogICAg IG10eF9wb29sICAgICAyICAgIDE2SyAgICAgICAtICAgICAgICAyICAKICAgICBhY3BpdGFz ayAgICAgMSAgICAgMksgICAgICAgLSAgICAgICAgMSAgMjA0OAogICBDQU0gcGVyaXBoICAg IDIyICAgICA2SyAgICAgICAtICAgICAgIDQ0ICAxNiwzMiw2NCwyNTYKICAgICAgc3VicHJv YyAgIDQ1OCAgIDM5N0sgICAgICAgLSAgICA1NDc3NyAgNTEyLDQwOTYKICAgICAgICAgcHJv YyAgICAgMiAgICAxNksgICAgICAgLSAgICAgICAgMiAgCiAgICAgIHNlc3Npb24gICAgMjMg ICAgIDNLICAgICAgIC0gICAgIDM2NDAgIDEyOAogICAgICAgICBwZ3JwICAgIDI1ICAgICA0 SyAgICAgICAtICAgICAzNzQ2ICAxMjgKICAgICAgICAgY3JlZCAgICA2MiAgICAxMEsgICAg ICAgLSAgMjU4ODA1OCAgNjQsMjU2CiAgICAgIHVpZGluZm8gICAgIDggICAgIDNLICAgICAg IC0gICA0MjMxNzUgIDEyOCwyMDQ4CiAgICAgICBwbGltaXQgICAgMTIgICAgIDNLICAgICAg IC0gICAgNDY3MjMgIDI1NgogICAgIHBjaV9saW5rICAgIDE2ICAgICAySyAgICAgICAtICAg ICAgIDE2ICA2NCwxMjgKICAgICAgYWNwaXNlbSAgICAxOSAgICAgM0sgICAgICAgLSAgICAg ICAxOSAgMTI4CiAgICAgICBERVZGUzEgICAxNDIgICAgNzFLICAgICAgIC0gICAgICAxNTIg IDUxMgogICAgc3lzY3RsdG1wICAgICAwICAgICAwSyAgICAgICAtICAgICAxMTQ4ICAxNiwz Miw2NCwxMjgKICAgIHN5c2N0bG9pZCAgMzI1MiAgIDE2MUsgICAgICAgLSAgICAgMzM4NiAg MTYsMzIsNjQsMTI4CiAgICAgICBzeXNjdGwgICAgIDAgICAgIDBLICAgICAgIC0gICAgMjA5 MjcgIDE2LDMyLDY0CiAgICAgIGNhbGxvdXQgICAgIDEgICA1MTJLICAgICAgIC0gICAgICAg IDEgIAogICAgICAgICB1bXR4ICAgNDg5ICAgIDYySyAgICAgICAtICAgICAgNDg5ICAxMjgK ICAgICBwMTAwMy4xYiAgICAgMSAgICAgMUsgICAgICAgLSAgICAgICAgMSAgMTYKICAgICAg ICAgU1dBUCAgICAgMiAgIDU0OUsgICAgICAgLSAgICAgICAgMiAgNjQKICAgICAgIERFVkZT MyAgIDE2OCAgICA0MksgICAgICAgLSAgICAgIDE3OSAgMjU2CiAgICAgICBidXMtc2MgICAg NjMgICAzNzNLICAgICAgIC0gICAgIDEyNzEgIDE2LDMyLDY0LDEyOCwyNTYsNTEyLDIwNDgs NDA5NgogICAgICAgICAgYnVzICAgNjA5ICAgIDYySyAgICAgICAtICAgICAzNTk5ICAxNiwz Miw2NCwxMjgsMjU2LDUxMiwxMDI0CiAgICAgIGRldnN0YXQgICAgMTQgICAgMjlLICAgICAg IC0gICAgICAgMTQgIDMyLDQwOTYKIGV2ZW50aGFuZGxlciAgICA2NyAgICAgNksgICAgICAg LSAgICAgICA2NyAgNjQsMTI4CiAgICAgICAgIGtvYmogICAgOTMgICAzNzJLICAgICAgIC0g ICAgICAxMjEgIDQwOTYKICAgICAgUGVyLWNwdSAgICAgMSAgICAgMUsgICAgICAgLSAgICAg ICAgMSAgMzIKICAgICAgICBERVZGUyAgICAyMCAgICAgMUsgICAgICAgLSAgICAgICAyMSAg MTYsMTI4CiAgICAgICAgIHJtYW4gICAxNzcgICAgMjJLICAgICAgIC0gICAgICA2MDEgIDE2 LDMyLDEyOAogICAgICAgREVWRlNQICAgICAxICAgICAxSyAgICAgICAtICAgICAgICAyICA2 NAogICAgICAgICBzYnVmICAgICAwICAgICAwSyAgICAgICAtICAgICAxMzQwICAxNiwzMiw2 NCwxMjgsMjU2LDUxMiwxMDI0LDIwNDgsNDA5NgogICAgcGZzX25vZGVzICAgIDIxICAgICA2 SyAgICAgICAtICAgICAgIDIxICAyNTYKICAgICAgQ0FNIFhQVCAgIDI5MiAgIDQyM0sgICAg ICAgLSAgICAgIDQxMyAgMTYsMzIsNjQsMTI4LDI1NiwxMDI0LDIwNDgKICAgICAgICBzdGFj ayAgICAgMCAgICAgMEsgICAgICAgLSAgICAgICAgMiAgMjU2CiAgICB0YXNrcXVldWUgICAg MTUgICAgIDJLICAgICAgIC0gICAgICAgMTUgIDE2LDMyLDEyOAogICAgICAgVW5pdG5vICAg IDEwICAgICAxSyAgICAgICAtICAgICAgIDU4ICAzMiw2NAogICAgICAgICAgaW92ICAgICAw ICAgICAwSyAgICAgICAtICAgMzI5NjM0ICAxNiwzMiw2NCwxMjgsMjU2LDUxMgogICAgICAg c2VsZWN0ICAgMTY4ICAgIDIxSyAgICAgICAtIDEwMTUwNjE1NzMwICAxMjgsNTEyLDEwMjQK ICAgICBpb2N0bG9wcyAgICAgMCAgICAgMEsgICAgICAgLSAyMTQ5Mjk2ODEgIDE2LDMyLDY0 LDEyOCwyNTYsNTEyLDEwMjQsMjA0OCw0MDk2CiAgICAgICAgICBtc2cgICAgIDQgICAgMzBL ICAgICAgIC0gICAgICAgIDQgIDIwNDgsNDA5NgogICAgICAgICAgc2VtICAgICA0ICAgIDEx SyAgICAgICAtICAgICAgICA0ICA1MTIsMTAyNAogICAgICAgICAgc2htICAgICAxICAgIDIw SyAgICAgICAtICAgICAgICAxICAKICAgICAgICAgIHR0eSAgICAyMCAgICAyMEsgICAgICAg LSAgICAgICAyNiAgMTAyNCwyMDQ4CiAgICAgICAgICBwdHMgICAgIDAgICAgIDBLICAgICAg IC0gICAgICAgIDQgIDI1NgogICAgIG1idWZfdGFnICAgICAwICAgICAwSyAgICAgICAtICAg ICAgIDU3ICAzMgogICAgICAgIHNobWZkICAgICAxICAgICA4SyAgICAgICAtICAgICAgICAx ICAKICAgICAgICAgR0VPTSAgIDE3NSAgICAzOEsgICAgICAgLSAgICAgIDg3MSAgMTYsMzIs NjQsMTI4LDI1Niw1MTIsMTAyNAogICAgICAgICAgcGNiICAgIDU1ICAgIDE0SyAgICAgICAt ICA2MDg5ODY3ICAxNiwzMiwxMDI0LDIwNDgsNDA5NgogICAgICAgc29uYW1lICAgICA2ICAg ICAxSyAgICAgICAtIDIzMzUzNjU1ICAxNiwzMiwxMjgKICAgICAgICAgIGFjbCAgICAgMCAg ICAgMEsgICAgICAgLSAgICAgMTU4OCAgNDA5NgogICAgICAgYmlvYnVmICAgICAwICAgICAw SyAgICAgICAtICAgICAgMjAzICAyMDQ4CiAgICAgdmZzY2FjaGUgICAgIDEgIDEwMjRLICAg ICAgIC0gICAgICAgIDEgIAogICBjbF9zYXZlYnVmICAgICAwICAgICAwSyAgICAgICAtICAg IDU2NjIyICA2NCwxMjgKICBleHBvcnRfaG9zdCAgICAgMiAgICAgMUsgICAgICAgLSAgICAg ICAgMiAgMjU2CiAgICAgdmZzX2hhc2ggICAgIDEgICA1MTJLICAgICAgIC0gICAgICAgIDEg IAogICAgICAgdm5vZGVzICAgICAyICAgICAxSyAgICAgICAtICAgICAgICAyICAyNTYKICB2 bm9kZW1hcmtlciAgICAgMCAgICAgMEsgICAgICAgLSAgIDIyNzUzNCAgNTEyCiAgICAgICAg bW91bnQgICAxMDQgICAgIDZLICAgICAgIC0gICAgICAzMDQgIDE2LDMyLDY0LDEyOCwyNTYs NTEyCiAgICAgICAgICBCUEYgICAgIDcgICAgIDlLICAgICAgIC0gICAgICAgMTIgIDEyOCw1 MTIsNDA5NgogIGV0aGVyX211bHRpICAgIDEyICAgICAxSyAgICAgICAtICAgICAgIDI2ICAx Niw2NAogICAgICAgaWZhZGRyICAgIDE0ICAgICA3SyAgICAgICAtICAgICAgIDE2ICAzMiw1 MTIsNDA5NgogICAgICAgIGlmbmV0ICAgICAzICAgICA1SyAgICAgICAtICAgICAgICAzICAx MjgsMjA0OAogICAgICAgIGNsb25lICAgICAyICAgICA4SyAgICAgICAtICAgICAgICAyICA0 MDk2CiAgICAgICBhcnBjb20gICAgIDEgICAgIDFLICAgICAgIC0gICAgICAgIDEgIDE2CiAg ICAgIGxsdGFibGUgICAgIDMgICAgIDJLICAgICAgIC0gICAgICAgMzcgIDI1Niw1MTIKICAg ICAgIGtiZG11eCAgICAgNiAgICAxMEsgICAgICAgLSAgICAgICAgNiAgMTYsNTEyLDEwMjQs MjA0OCw0MDk2CiAgICAgICAgICBMRUQgICAgIDEgICAgIDFLICAgICAgIC0gICAgICAgIDEg IDEyOAogICAgICAgaXNhZGV2ICAgICA2ICAgICAxSyAgICAgICAtICAgICAgICA2ICAxMjgK ICAgICByb3V0ZXRibCAgICAxNCAgICAgNEsgICAgICAgLSAgIDE1NzYzMyAgMzIsNjQsMTI4 LDI1Niw1MTIKICAgICAgICAgaWdtcCAgICAgMiAgICAgMUsgICAgICAgLSAgICAgICAgMiAg MjU2CiAgICAgIHNjc2lfZGEgICAgIDAgICAgIDBLICAgICAgIC0gICAgICAgMTYgIDE2CkNB TSBkZXYgcXVldWUgICAgIDggICAgIDFLICAgICAgIC0gICAgICAgIDggIDEyOAogIGlwX21v cHRpb25zICAgICA0ICAgICAxSyAgICAgICAtICAgICAgICA4ICA2NCwyNTYKICAgICBpbl9t dWx0aSAgICAgMyAgICAgMUsgICAgICAgLSAgICAgICAgNSAgMjU2CiAgIGluX21maWx0ZXIg ICAgIDIgICAgIDJLICAgICAgIC0gICAgICAgIDQgIDEwMjQKICAgIGhvc3RjYWNoZSAgICAg MSAgICAyOEsgICAgICAgLSAgICAgICAgMSAgCiAgICAgc3luY2FjaGUgICAgIDEgICAgOTZL ICAgICAgIC0gICAgICAgIDEgIAogICAgICBORlMgRkhBICAgICAxICAgICAySyAgICAgICAt ICAgICAgNDk4ICA2NCwyMDQ4CiAgICAgICAgICBycGMgICA1MDcgICAyNThLICAgICAgIC0g ICAgIDE2MzIgIDMyLDY0LDEyOCwyNTYsNTEyLDIwNDgKYXVkaXRfZXZjbGFzcyAgIDE3MiAg ICAgNksgICAgICAgLSAgICAgIDIxMSAgMzIKICAgICBzYXZlZGlubyAgICAgMCAgICAgMEsg ICAgICAgLSAgICAzNTA1NSAgMjU2CiAgICBuZXdkaXJibGsgICAgIDAgICAgIDBLICAgICAg IC0gICAgICAgIDUgIDY0CiAgICAgICBkaXJyZW0gICAgIDAgICAgIDBLICAgICAgIC0gICAx ODc3MjIgIDY0CiAgICAgICAgbWtkaXIgICAgIDAgICAgIDBLICAgICAgIC0gICAgICA0ODIg IDY0CiAgICAgICBkaXJhZGQgICAgIDMgICAgIDFLICAgICAgIC0gICAxODk1NzYgIDY0CiAg ICAgZnJlZWZpbGUgICAgIDAgICAgIDBLICAgICAgIC0gICAgOTAwMjIgIDY0CiAgICAgZnJl ZWJsa3MgICAgIDAgICAgIDBLICAgICAgIC0gICAgOTAxMTggIDI1NgogICAgIGZyZWVmcmFn ICAgICAwICAgICAwSyAgICAgICAtICAgMTY1MjUzICA2NAogICBhbGxvY2luZGlyICAgICAw ICAgICAwSyAgICAgICAtICAgMzE5OTc5ICAxMjgKICAgICBpbmRpcmRlcCAgICAgMCAgICAg MEsgICAgICAgLSAgICAgMzkxNSAgNjQKICBhbGxvY2RpcmVjdCAgICAgMyAgICAgMUsgICAg ICAgLSAgIDM5Nzk3OSAgMjU2CiAgICBibXNhZmVtYXAgICAgIDEgICAgIDFLICAgICAgIC0g ICAxMDkxNjQgIDEyOAogICAgICAgbmV3YmxrICAgICAxICAgICAxSyAgICAgICAtICAgNzE3 OTU5ICA2NCw1MTIKICAgICBpbm9kZWRlcCAgICAgNSAgIDUxM0sgICAgICAgLSAgIDIxMTMw NSAgMjU2CiAgICAgIHBhZ2VkZXAgICAgIDQgICAxMjlLICAgICAgIC0gICAgMzExMDcgIDEy OAogIHVmc19kaXJoYXNoICAgOTIxICAgNDUySyAgICAgICAtICAgNDQ3OTk5ICAxNiwzMiw2 NCwxMjgsMjU2LDUxMiwxMDI0CiAgICB1ZnNfbW91bnQgICAgMTUgICAxMjdLICAgICAgIC0g ICAgICAgMTUgIDUxMiwyMDQ4LDQwOTYKICAgICAgVU1BSGFzaCAgICAgMyAgICAgN0sgICAg ICAgLSAgICAgICAgOSAgNTEyLDEwMjQsMjA0OCw0MDk2CiAgICBDQU0gcXVldWUgICAgNDMg ICAgIDNLICAgICAgIC0gICAgICAxNDggIDE2LDMyLDY0LDI1NgogICAgICBDQU0gU0lNICAg ICA4ICAgICAySyAgICAgICAtICAgICAgICA4ICAyNTYKICAgICAgICAgY2RldiAgICAgOCAg ICAgMksgICAgICAgLSAgICAgICAgOCAgMjU2CiAgICB2bV9wZ2RhdGEgICAgIDIgICAxMjlL ICAgICAgIC0gICAgICAgIDIgIDEyOAogIGRkYl9jYXB0dXJlICAgICAxICAgIDQ4SyAgICAg ICAtICAgICAgICAxICAKICAgICAgIGFjcGljYSAgMzc3MCAgIDM4NksgICAgICAgLSAgICA5 MDMzNiAgMTYsMzIsNjQsMTI4LDI1Niw1MTIsMTAyNCwyMDQ4CiAgICAgICAgc2lnaW8gICAg IDEgICAgIDFLICAgICAgIC0gICAgICAgIDEgIDY0CiAgICAgZmlsZWRlc2MgICAgNjAgICAg NzdLICAgICAgIC0gICAgODUxMzIgIDE2LDMyLDY0LDEyOCwyNTYsNTEyLDEwMjQsMjA0OCw0 MDk2CiAgICAgICAgIGtlbnYgICAgNzYgICAgMTFLICAgICAgIC0gICAgICAgODAgIDE2LDMy LDY0LDEyOAogICAgICBpb19hcGljICAgICAxICAgICAySyAgICAgICAtICAgICAgICAxICAy MDQ4CiAgICAgICBrcXVldWUgICAgIDIgICAgMTNLICAgICAgIC0gICAyNDc1NTYgIDI1Niwy MDQ4LDQwOTYKICAgICAgbWVtZGVzYyAgICAgMSAgICAgNEsgICAgICAgLSAgICAgICAgMSAg NDA5NgogICAgICBhY3BpZGV2ICAgIDc4ICAgICA1SyAgICAgICAtICAgICAgIDc4ICA2NAog ICAgcHJvYy1hcmdzICAgIDI3ICAgICAySyAgICAgICAtICAgMTU0ODE4ICAxNiwzMiw2NCwx MjgsMjU2CiAgICAgYXRrYmRkZXYgICAgIDIgICAgIDFLICAgICAgIC0gICAgICAgIDIgIDY0 CiAgICAgIGl0aHJlYWQgICAgNzIgICAgMTJLICAgICAgIC0gICAgICAgNzIgIDMyLDEyOCwy NTYKICAgICAgZW50cm9weSAgMTAyNCAgICA2NEsgICAgICAgLSAgICAgMTAyNCAgNjQKICAg ICAgICAgVUFSVCAgICAgMyAgICAgMksgICAgICAgLSAgICAgICAgMyAgMTYsNTEyLDEwMjQK ICAgICAgIEtUUkFDRSAgIDEwMCAgICAxM0sgICAgICAgLSAgICAgIDEwMCAgMTI4CiAgICAg ICBsaW5rZXIgICAgNjMgICAgIDdLICAgICAgIC0gICAgICAgNzUgIDE2LDMyLDY0LDEyOCw1 MTIKICAgICAgICBsb2NrZiAgICA1MyAgICAgNksgICAgICAgLSAgNDY1MDA0NyAgNjQsMTI4 CiAgICAgICAgIHRlbXAgICAgMjAgICA0MDFLICAgICAgIC0gICA0OTE1NDMgIDE2LDMyLDY0 LDEyOCwyNTYsNTEyLDEwMjQsMjA0OCw0MDk2CiAgICAgICBkZXZidWYgMTk5OTkgMzQ4NzdL ICAgICAgIC0gICAgMjAxMDIgIDE2LDMyLDY0LDEyOCwyNTYsNTEyLDEwMjQsMjA0OCw0MDk2 CiAgICAgICBVU0JkZXYgICAgNDcgICAgMTJLICAgICAgIC0gICAgICAgNDcgIDY0LDEyOCwx MDI0CiAgICAgbmV4dXNkZXYgICAgIDMgICAgIDFLICAgICAgIC0gICAgICAgIDMgIDE2CiAg IHJhaWQ1X2RhdGEgICAgIDYgIDUzODlLICAgICAgIC0gMTk4ODIxOTY2ICAxNiw2NCw1MTIs NDA5Ngo8PDwgdm1zdGF0IC1tCj4+PiBuZXRzdGF0IC1tCjM3MDMvMzcyMi83NDI1IG1idWZz IGluIHVzZSAoY3VycmVudC9jYWNoZS90b3RhbCkKMTI3NS80MDQ3LzUzMjIvMjA0ODAwIG1i dWYgY2x1c3RlcnMgaW4gdXNlIChjdXJyZW50L2NhY2hlL3RvdGFsL21heCkKMTE1MS8zMDMy IG1idWYrY2x1c3RlcnMgb3V0IG9mIHBhY2tldCBzZWNvbmRhcnkgem9uZSBpbiB1c2UgKGN1 cnJlbnQvY2FjaGUpCjExLzYzOS82NTAvMTkyMDAwIDRrIChwYWdlIHNpemUpIGp1bWJvIGNs dXN0ZXJzIGluIHVzZSAoY3VycmVudC9jYWNoZS90b3RhbC9tYXgpCjAvMC8wLzY0MDAgOWsg anVtYm8gY2x1c3RlcnMgaW4gdXNlIChjdXJyZW50L2NhY2hlL3RvdGFsL21heCkKMC8wLzAv MzIwMCAxNmsganVtYm8gY2x1c3RlcnMgaW4gdXNlIChjdXJyZW50L2NhY2hlL3RvdGFsL21h eCkKMzUxOUsvMTE1ODBLLzE1MTAwSyBieXRlcyBhbGxvY2F0ZWQgdG8gbmV0d29yayAoY3Vy cmVudC9jYWNoZS90b3RhbCkKMC8wLzAgcmVxdWVzdHMgZm9yIG1idWZzIGRlbmllZCAobWJ1 ZnMvY2x1c3RlcnMvbWJ1ZitjbHVzdGVycykKMC8wLzAgcmVxdWVzdHMgZm9yIGp1bWJvIGNs dXN0ZXJzIGRlbmllZCAoNGsvOWsvMTZrKQowLzAvMCBzZmJ1ZnMgaW4gdXNlIChjdXJyZW50 L3BlYWsvbWF4KQowIHJlcXVlc3RzIGZvciBzZmJ1ZnMgZGVuaWVkCjAgcmVxdWVzdHMgZm9y IHNmYnVmcyBkZWxheWVkCjAgcmVxdWVzdHMgZm9yIEkvTyBpbml0aWF0ZWQgYnkgc2VuZGZp bGUKMCBjYWxscyB0byBwcm90b2NvbCBkcmFpbiByb3V0aW5lcwo8PDwgbmV0c3RhdCAtbQo+ Pj4gdG9wIC1TbmQgMQpsYXN0IHBpZDogNTQzNjc7ICBsb2FkIGF2ZXJhZ2VzOiAgMC4wMywg IDAuMDEsICAwLjAwICB1cCA3KzEyOjMxOjQzICAgIDExOjA3OjQ0CjExMSBwcm9jZXNzZXM6 IDMgcnVubmluZywgOTEgc2xlZXBpbmcsIDE3IHdhaXRpbmcKCk1lbTogODBNIEFjdGl2ZSwg MTMzOE0gSW5hY3QsIDQzMU0gV2lyZWQsIDUzTSBDYWNoZSwgMjEzTSBCdWYsIDczTSBGcmVl ClN3YXA6IDQwOTZNIFRvdGFsLCAyNDhLIFVzZWQsIDQwOTZNIEZyZWUKCgogIFBJRCBVU0VS TkFNRSAgICAgIFRIUiBQUkkgTklDRSAgIFNJWkUgICAgUkVTIFNUQVRFICAgQyAgIFRJTUUg ICBXQ1BVIENPTU1BTkQKICAgMTEgcm9vdCAgICAgICAgICAgIDIgMTcxIGtpMzEgICAgIDBL ICAgIDMySyBDUFUwICAgIDAgMjczLjlIIDIwMC4wMCUgaWRsZQogICAxMiByb290ICAgICAg ICAgICAxNyAtNjAgICAgLSAgICAgMEsgICAyNzJLIFdBSVQgICAgMCAxODM6MjcgIDEuNDYl IGludHIKMzM5NjcgcnRvcnJlbnQgICAgICAgIDMgIDQ0ICAgIDAgODM3MDRLIDY4MTU2SyBz ZWxlY3QgIDAgNjc1OjA3ICAwLjAwJSB0cmFuc21pc3Npb24tZGFlbW9uCiAgICAwIHJvb3Qg ICAgICAgICAgICA5IC02OCAgICAwICAgICAwSyAgIDEyOEsgLSAgICAgICAwICA0ODo1OCAg MC4wMCUga2VybmVsCiAgIDE5IHJvb3QgICAgICAgICAgICAyICAtOCAgICAtICAgICAwSyAg ICAzMksgZ3I1ZG8gICAxICAyNDowNCAgMC4wMCUgZ19yYWlkNQogICAxNCByb290ICAgICAg ICAgICAzMyAtNDAgICAgLSAgICAgMEsgICA1MjhLIC0gICAgICAgMCAgMjI6MzggIDAuMDAl IHVzYgogICAgNCByb290ICAgICAgICAgICAgMSAgLTggICAgLSAgICAgMEsgICAgMTZLIC0g ICAgICAgMSAgMTk6NDYgIDAuMDAlIGdfZG93bgogICAgMyByb290ICAgICAgICAgICAgMSAg LTggICAgLSAgICAgMEsgICAgMTZLIC0gICAgICAgMCAgMTU6MjUgIDAuMDAlIGdfdXAKICAg MTMgcm9vdCAgICAgICAgICAgIDEgLTE2ICAgIC0gICAgIDBLICAgIDE2SyAtICAgICAgIDAg ICA5OjM3ICAwLjAwJSB5YXJyb3cKICAgMTcgcm9vdCAgICAgICAgICAgIDEgIDIwICAgIC0g ICAgIDBLICAgIDE2SyBzeW5jZXIgIDAgICA5OjM2ICAwLjAwJSBzeW5jZXIKICAgIDYgcm9v dCAgICAgICAgICAgIDEgLTE2ICAgIC0gICAgIDBLICAgIDE2SyBwc2xlZXAgIDAgICA0OjQ3 ICAwLjAwJSBwYWdlZGFlbW9uCiAgNzg1IHJvb3QgICAgICAgICAgICAxICA0NCAgICAwIDIx MDUySyAgMjc2NEsgc2VsZWN0ICAwICAgMDoyNCAgMC4wMCUgbm1iZAogICAgMiByb290ICAg ICAgICAgICAgMSAgLTggICAgLSAgICAgMEsgICAgMTZLIC0gICAgICAgMCAgIDA6MjAgIDAu MDAlIGdfZXZlbnQKICA4NTcgcm9vdCAgICAgICAgICAgIDEgIDQ0ICAgIDAgMTE3ODhLICAx OTkySyBzZWxlY3QgIDEgICAwOjE5ICAwLjAwJSBudHBkCiAgIDE2IHJvb3QgICAgICAgICAg ICAxICA0NCAgICAtICAgICAwSyAgICAxNksgdmxydXd0ICAxICAgMDoxNyAgMC4wMCUgdm5s cnUKNDQwMDkgdXVjcCAgICAgICAgICAgIDEgIDQ0ICAgIDAgIDY5MTZLICAxMzU2SyBzZWxl Y3QgIDEgICAwOjExICAwLjAwJSBtZWdhdGVjCiAxMDI2IHJvb3QgICAgICAgICAgICAxICA0 NCAgICAwIDEyMDE2SyAgMzAyOEsgc2VsZWN0ICAwICAgMDowOCAgMC4wMCUgc2VuZG1haWwK ICAgMTggcm9vdCAgICAgICAgICAgIDEgIDQ0ICAgIC0gICAgIDBLICAgIDE2SyBzZGZsdXMg IDAgICAwOjA4ICAwLjAwJSBzb2Z0ZGVwZmx1c2gKCjw8PCB0b3AgLVNuZCAxCj4+PiBzeXNj dGwgZGV2LmVtLjAKZGV2LmVtLjAuJWRlc2M6IEludGVsKFIpIFBSTy8xMDAwIE5ldHdvcmsg Q29ubmVjdGlvbiA3LjIuMgpkZXYuZW0uMC4lZHJpdmVyOiBlbQpkZXYuZW0uMC4lbG9jYXRp b246IHNsb3Q9MjUgZnVuY3Rpb249MCBoYW5kbGU9XF9TQl8uUENJMC5HQkVDCmRldi5lbS4w LiVwbnBpbmZvOiB2ZW5kb3I9MHg4MDg2IGRldmljZT0weDEwYmQgc3VidmVuZG9yPTB4MTA0 MyBzdWJkZXZpY2U9MHg4MjY4IGNsYXNzPTB4MDIwMDAwCmRldi5lbS4wLiVwYXJlbnQ6IHBj aTAKZGV2LmVtLjAubnZtOiAtMQpkZXYuZW0uMC5kZWJ1ZzogLTEKZGV2LmVtLjAucnhfaW50 X2RlbGF5OiAwCmRldi5lbS4wLnR4X2ludF9kZWxheTogNjYKZGV2LmVtLjAucnhfYWJzX2lu dF9kZWxheTogNjYKZGV2LmVtLjAudHhfYWJzX2ludF9kZWxheTogNjYKZGV2LmVtLjAucnhf cHJvY2Vzc2luZ19saW1pdDogMTAwCmRldi5lbS4wLmZsb3dfY29udHJvbDogMwpkZXYuZW0u MC5lZWVfY29udHJvbDogMApkZXYuZW0uMC5saW5rX2lycTogMApkZXYuZW0uMC5tYnVmX2Fs bG9jX2ZhaWw6IDAKZGV2LmVtLjAuY2x1c3Rlcl9hbGxvY19mYWlsOiAwCmRldi5lbS4wLmRy b3BwZWQ6IDAKZGV2LmVtLjAudHhfZG1hX2ZhaWw6IDAKZGV2LmVtLjAucnhfb3ZlcnJ1bnM6 IDAKZGV2LmVtLjAud2F0Y2hkb2dfdGltZW91dHM6IDAKZGV2LmVtLjAuZGV2aWNlX2NvbnRy b2w6IDEwNzQ3OTA5NzYKZGV2LmVtLjAucnhfY29udHJvbDogNjcxNDE2MzQKZGV2LmVtLjAu ZmNfaGlnaF93YXRlcjogODE5MgpkZXYuZW0uMC5mY19sb3dfd2F0ZXI6IDY2OTIKZGV2LmVt LjAucXVldWUwLnR4ZF9oZWFkOiA1ODkKZGV2LmVtLjAucXVldWUwLnR4ZF90YWlsOiA1NTQK ZGV2LmVtLjAucXVldWUwLnR4X2lycTogMApkZXYuZW0uMC5xdWV1ZTAubm9fZGVzY19hdmFp bDogMApkZXYuZW0uMC5xdWV1ZTAucnhkX2hlYWQ6IDc3NgpkZXYuZW0uMC5xdWV1ZTAucnhk X3RhaWw6IDc3NQpkZXYuZW0uMC5xdWV1ZTAucnhfaXJxOiAwCmRldi5lbS4wLm1hY19zdGF0 cy5leGNlc3NfY29sbDogMApkZXYuZW0uMC5tYWNfc3RhdHMuc2luZ2xlX2NvbGw6IDAKZGV2 LmVtLjAubWFjX3N0YXRzLm11bHRpcGxlX2NvbGw6IDAKZGV2LmVtLjAubWFjX3N0YXRzLmxh dGVfY29sbDogMApkZXYuZW0uMC5tYWNfc3RhdHMuY29sbGlzaW9uX2NvdW50OiAwCmRldi5l bS4wLm1hY19zdGF0cy5zeW1ib2xfZXJyb3JzOiAwCmRldi5lbS4wLm1hY19zdGF0cy5zZXF1 ZW5jZV9lcnJvcnM6IDAKZGV2LmVtLjAubWFjX3N0YXRzLmRlZmVyX2NvdW50OiAxMzExCmRl di5lbS4wLm1hY19zdGF0cy5taXNzZWRfcGFja2V0czogNjE2MQpkZXYuZW0uMC5tYWNfc3Rh dHMucmVjdl9ub19idWZmOiAwCmRldi5lbS4wLm1hY19zdGF0cy5yZWN2X3VuZGVyc2l6ZTog MApkZXYuZW0uMC5tYWNfc3RhdHMucmVjdl9mcmFnbWVudGVkOiA1CmRldi5lbS4wLm1hY19z dGF0cy5yZWN2X292ZXJzaXplOiAwCmRldi5lbS4wLm1hY19zdGF0cy5yZWN2X2phYmJlcjog MApkZXYuZW0uMC5tYWNfc3RhdHMucmVjdl9lcnJzOiAxODMKZGV2LmVtLjAubWFjX3N0YXRz LmNyY19lcnJzOiAxOTIKZGV2LmVtLjAubWFjX3N0YXRzLmFsaWdubWVudF9lcnJzOiAwCmRl di5lbS4wLm1hY19zdGF0cy5jb2xsX2V4dF9lcnJzOiAxCmRldi5lbS4wLm1hY19zdGF0cy54 b25fcmVjdmQ6IDEzNDQKZGV2LmVtLjAubWFjX3N0YXRzLnhvbl90eGQ6IDAKZGV2LmVtLjAu bWFjX3N0YXRzLnhvZmZfcmVjdmQ6IDMxNTAKZGV2LmVtLjAubWFjX3N0YXRzLnhvZmZfdHhk OiAwCmRldi5lbS4wLm1hY19zdGF0cy50b3RhbF9wa3RzX3JlY3ZkOiA0NDU2MDQwMTgKZGV2 LmVtLjAubWFjX3N0YXRzLmdvb2RfcGt0c19yZWN2ZDogNDQ1NTkzMTYwCmRldi5lbS4wLm1h Y19zdGF0cy5iY2FzdF9wa3RzX3JlY3ZkOiAxOTMwMwpkZXYuZW0uMC5tYWNfc3RhdHMubWNh c3RfcGt0c19yZWN2ZDogMTUyNgpkZXYuZW0uMC5tYWNfc3RhdHMucnhfZnJhbWVzXzY0OiAw CmRldi5lbS4wLm1hY19zdGF0cy5yeF9mcmFtZXNfNjVfMTI3OiAwCmRldi5lbS4wLm1hY19z dGF0cy5yeF9mcmFtZXNfMTI4XzI1NTogMApkZXYuZW0uMC5tYWNfc3RhdHMucnhfZnJhbWVz XzI1Nl81MTE6IDAKZGV2LmVtLjAubWFjX3N0YXRzLnJ4X2ZyYW1lc181MTJfMTAyMzogMApk ZXYuZW0uMC5tYWNfc3RhdHMucnhfZnJhbWVzXzEwMjRfMTUyMjogMApkZXYuZW0uMC5tYWNf c3RhdHMuZ29vZF9vY3RldHNfcmVjdmQ6IDQwMzIyMzgxNTI3CmRldi5lbS4wLm1hY19zdGF0 cy5nb29kX29jdGV0c190eGQ6IDExMjgxNDY2MDM2NzYKZGV2LmVtLjAubWFjX3N0YXRzLnRv dGFsX3BrdHNfdHhkOiA4NjE0Mjk0NDcKZGV2LmVtLjAubWFjX3N0YXRzLmdvb2RfcGt0c190 eGQ6IDg2MTQyOTQ0NwpkZXYuZW0uMC5tYWNfc3RhdHMuYmNhc3RfcGt0c190eGQ6IDMyNDkK ZGV2LmVtLjAubWFjX3N0YXRzLm1jYXN0X3BrdHNfdHhkOiAxOTU4OQpkZXYuZW0uMC5tYWNf c3RhdHMudHhfZnJhbWVzXzY0OiAwCmRldi5lbS4wLm1hY19zdGF0cy50eF9mcmFtZXNfNjVf MTI3OiAwCmRldi5lbS4wLm1hY19zdGF0cy50eF9mcmFtZXNfMTI4XzI1NTogMApkZXYuZW0u MC5tYWNfc3RhdHMudHhfZnJhbWVzXzI1Nl81MTE6IDAKZGV2LmVtLjAubWFjX3N0YXRzLnR4 X2ZyYW1lc181MTJfMTAyMzogMApkZXYuZW0uMC5tYWNfc3RhdHMudHhfZnJhbWVzXzEwMjRf MTUyMjogMApkZXYuZW0uMC5tYWNfc3RhdHMudHNvX3R4ZDogMjYzNzk1NjU5CmRldi5lbS4w Lm1hY19zdGF0cy50c29fY3R4X2ZhaWw6IDAKZGV2LmVtLjAuaW50ZXJydXB0cy5hc3NlcnRz OiA2MjQ2MDU2MzUKZGV2LmVtLjAuaW50ZXJydXB0cy5yeF9wa3RfdGltZXI6IDAKZGV2LmVt LjAuaW50ZXJydXB0cy5yeF9hYnNfdGltZXI6IDAKZGV2LmVtLjAuaW50ZXJydXB0cy50eF9w a3RfdGltZXI6IDAKZGV2LmVtLjAuaW50ZXJydXB0cy50eF9hYnNfdGltZXI6IDAKZGV2LmVt LjAuaW50ZXJydXB0cy50eF9xdWV1ZV9lbXB0eTogMApkZXYuZW0uMC5pbnRlcnJ1cHRzLnR4 X3F1ZXVlX21pbl90aHJlc2g6IDAKZGV2LmVtLjAuaW50ZXJydXB0cy5yeF9kZXNjX21pbl90 aHJlc2g6IDAKZGV2LmVtLjAuaW50ZXJydXB0cy5yeF9vdmVycnVuOiAwCmRldi5lbS4wLndh a2U6IDAKPDw8IHN5c2N0bCBkZXYuZW0uMAo= ------------51A718D33013DCD-- From owner-freebsd-stable@FreeBSD.ORG Thu Mar 3 13:00:20 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D46141065677 for ; Thu, 3 Mar 2011 13:00:20 +0000 (UTC) (envelope-from ykirill@yahoo.com) Received: from nm28.bullet.mail.ne1.yahoo.com (nm28.bullet.mail.ne1.yahoo.com [98.138.90.91]) by mx1.freebsd.org (Postfix) with SMTP id B401B8FC08 for ; Thu, 3 Mar 2011 13:00:07 +0000 (UTC) Received: from [98.138.90.54] by nm28.bullet.mail.ne1.yahoo.com with NNFMP; 03 Mar 2011 13:00:07 -0000 Received: from [98.138.89.161] by tm7.bullet.mail.ne1.yahoo.com with NNFMP; 03 Mar 2011 13:00:07 -0000 Received: from [127.0.0.1] by omp1017.mail.ne1.yahoo.com with NNFMP; 03 Mar 2011 13:00:07 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 128701.71196.bm@omp1017.mail.ne1.yahoo.com Received: (qmail 22601 invoked by uid 60001); 3 Mar 2011 13:00:06 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1299157206; bh=CdaDrZLeC3GELmLlYpC2B0L+0LQO7U55enTJ+lcko7k=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=F1TzlBMB4XFUkGuAqy+1olPK7uuU1ScE0HZBx/MsygCjTT5NxcA8Ybc7CadJ8GIXKo1Orv/0K+Zcp4h6U/usfRnRrOkajUH6pT4N84wxE0meir+ykpJj7ga8w4D9MXQxWsCwG/Mp5wVCX+/Al85G87fCiIY3j52X9f/lh1NkQks= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=2XAoCauIUClHoEXZYXza2eGu2eltL2fAneGAnNrVwI52K4xRUHaiaCNE65ELcyzVQhBHi10r9vMC5c0qBwVrKHkcs3oJZ+o6zY2vcB5StGD36UyqVrm5hq7U0X1b4HozWwqaRIEREdW9E3aKUV08lyYhOK1XwLp7ZBblYSbeI3M=; Message-ID: <650248.21751.qm@web120514.mail.ne1.yahoo.com> X-YMail-OSG: hnnfCegVM1nsVjJl5TKT2tSzD7mbQWJyHlHdtrTT6PCH5B6 LaK0yalHk6giKTfRSoWI9AQDVR7gcICQh1_YeljC4Uq8EYhw_Sr9w8oBv1W. YbOKjBGfBdCR3Hy4h66N0S_PAIRLydJUsCxr1U4nhXcVTm55u4THiEeAHFr7 jsi_KufcJ5.5IaNdjUplTNkL.ujuqBKKqh8kTnPc5OGYrB8nnL6OIVVApA7i NpwrK_VCsR1JgHbMbAK6lhlOR7DTP_7p77ccZhgMgUn4hrD.hgPt18UHL2Sz gQB6fcFqQTqBCVDlon6WJ3H0o9w1AdCP6_BhzhJ8yjMmSdlznpMtoH_vqP7T r Received: from [212.74.229.232] by web120514.mail.ne1.yahoo.com via HTTP; Thu, 03 Mar 2011 05:00:01 PST X-Mailer: YahooMailClassic/11.4.20 YahooMailWebService/0.8.109.292656 Date: Thu, 3 Mar 2011 05:00:01 -0800 (PST) From: Kirill Yelizarov To: freebsd-stable@freebsd.org In-Reply-To: <1920317329.229957.1298414128136.JavaMail.root@erie.cs.uoguelph.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: NFS client over udp X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2011 13:00:20 -0000 --- On Wed, 2/23/11, Rick Macklem wrote: > From: Rick Macklem > Subject: Re: NFS client over udp > To: "Kirill Yelizarov" > Cc: freebsd-stable@freebsd.org > Date: Wednesday, February 23, 2011, 1:35 AM > > --- On Tue, 2/22/11, Rick > Macklem > wrote: > > > > > From: Rick Macklem > > > Subject: Re: NFS client over udp > > > To: "Kirill Yelizarov" > > > Cc: freebsd-stable@freebsd.org > > > Date: Tuesday, February 22, 2011, 2:10 AM > > > > --- On Sun, 2/20/11, Rick > > > Macklem > > > wrote: > > > > > > > > > From: Rick Macklem > > > > > Subject: Re: NFS client over udp > > > > > To: "Kirill Yelizarov" > > > > > Cc: freebsd-stable@freebsd.org > > > > > Date: Sunday, February 20, 2011, 9:02 > PM > > > > > > --- On Fri, 2/18/11, Kirill > > > > > Yelizarov > > > > > > > > On Fri, Feb 18, 2011 at > > > 05:27:00AM > > > > > > > > -0800, Kirill Yelizarov > wrote: > > > > > > > > > I have a > reproducible memory > > > leak when > > > > > using nfs > > > > > > > > client with an old > > > > > > > > > nfs server > > > > > > > > > > > > and mbufs used > > > > > > 8193/1722/9915 mbufs in use > > > (current/cache/total) > > > > > > 8192/1264/9456/25600 mbuf clusters > in use > > > > > (current/cache/total/max) > > > > > > 8192/605 mbuf+clusters out of > packet > > > secondary zone in > > > > > use > > > > > > (current/cache) > > > > > > 0/768/768/12800 4k (page size) > jumbo > > > clusters in use > > > > > > (current/cache/total/max) > > > > > > 0/0/0/6400 9k jumbo clusters in > use > > > > > (current/cache/total/max) > > > > > > 0/0/0/3200 16k jumbo clusters in > use > > > > > (current/cache/total/max) > > > > > > 18432K/6030K/24462K bytes > allocated to > > > network > > > > > (current/cache/total) > > > > > > 0/0/0 requests for mbufs denied > > > > > (mbufs/clusters/mbuf+clusters) > > > > > > 0/0/0 requests for jumbo clusters > denied > > > (4k/9k/16k) > > > > > > 0/0/0 sfbufs in use > (current/peak/max) > > > > > > 0 requests for sfbufs denied > > > > > > 0 requests for sfbufs delayed > > > > > > 0 requests for I/O initiated by > sendfile > > > > > > 0 calls to protocol drain > routines > > > > > > > > > > > > Kirill > > > > > > > > > > > You could try the attached patch. It > fixes the > > > only places > > > > > in the > > > > > client side krpc over udp that seems > mights cause > > > a leak. I > > > > > have no > > > > > idea if it will help, since these cases > should > > > rarely, if > > > > > ever, > > > > > happen in practice. > > > > > > > > > > Please let us know if you have the > chance to try > > > the patch > > > > > and > > > > > whether or not it helped. > > > > > > > > > > rick > > > > > > > > > Rick, i tried your patch. Fortunately it > didn't help > > > me. There are no > > > > warnings on console and memory is climbing > up during > > > syncs and not > > > > freed later. I'll try to switch to tcp this > evening. > > > Thanks for help > > > > > > > I'll assume that's unfortunately;-) Since the two > cases > > > patched probably > > > never happen, I'm not surprised. > > > > > > The only other thing I can think of that you > could try is > > > switching to > > > the experimental client. This would identify if > the bug is > > > in the regular > > > client or somewhere further down in the rpc > transport. > > > > > > The mount command would look something like: > > > # mount -t newnfs -o nfsv3,udp > : > > > > > > > > I added options NFSCL to my kernel and tried to mount. > mount shows > > everything is ok: > > 192.168.0.35:/home on /mnt (newnfs) > > but when i try to cd /mnt i get permission denied > > my export allow root and everything is done as root. > What am i doing > > wrong? > > > Try adding the "resvport" option. I don't think it's a > default for > the experimental client at this time. (I have a series of > patches > for the client that will go into head in April that brings > it in > line with the regular client, including same default mount > options.) Rick, I have good news. I upgraded to 8.2-stable and i ran all four different tests (nfs client new and old and over udp and tcp) and found that there is no leak in either. ALl of them behave almost the same, i couldn't find any difference. The speed i achieved on 1Gb link is 52Mb/s. The only difference is that i can't umount new nfs client even if there are no processes using this mount point. Thanks for help Kirill From owner-freebsd-stable@FreeBSD.ORG Thu Mar 3 14:43:57 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4A5F81065678 for ; Thu, 3 Mar 2011 14:43:57 +0000 (UTC) (envelope-from jamesbrandongooch@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 CB3F38FC0C for ; Thu, 3 Mar 2011 14:43:56 +0000 (UTC) Received: by wyb32 with SMTP id 32so1278102wyb.13 for ; Thu, 03 Mar 2011 06:43:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=KMdOiYcF1RnWT6QbXrIsakkboC5LmaKIaMDTxjVat18=; b=la8PtpXJBBjcn8zWXhyaPLWTOAJHXLlRjJDPXWvJZoOUPNJPR3nDENTMvkD7vC9o3z 6E4gf4NlZa6mDSC8xxan9B56sCvxyRlGpXhlrEPkUr7kMjBOha2XAKYLYwcNVJ2Upnwp 8gSp4muesBytNPEvYTEQ7zGIsanIQ1GhIADqQ= 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=T60p9SBxRL5LpGEpmag6N1PWummb9lJBdYWfd3ur7zCXPRsaWZtRWwgTAZU4YxTyC0 161Z9pmTCAmLkhcbYESM4ozhVp3Ommxrv52JG52IAZYlq9qQXCurd6EzxgAUlHth2N03 pHfUP9AFBMfRX2BgkXw9uF2j5GJVLgG6mRxx8= MIME-Version: 1.0 Received: by 10.216.145.222 with SMTP id p72mr881471wej.65.1299161306479; Thu, 03 Mar 2011 06:08:26 -0800 (PST) Received: by 10.216.25.72 with HTTP; Thu, 3 Mar 2011 06:08:26 -0800 (PST) In-Reply-To: <1627628072.20110303111046@serebryakov.spb.ru> References: <1975926365.20110223121637@serebryakov.spb.ru> <4D64EC8C.2080007@sentex.net> <1004451940.20110223143607@serebryakov.spb.ru> <4D6D00C1.1040805@sentex.net> <1416421652.20110301225215@serebryakov.spb.ru> <1627628072.20110303111046@serebryakov.spb.ru> Date: Thu, 3 Mar 2011 08:08:26 -0600 Message-ID: From: Brandon Gooch To: Lev Serebryakov Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org, Jan Koum , freebsd-stable@freebsd.org, Jack Vogel , Arnaud Lacombe Subject: Re: em0 with latest driver hangs again and again (without "Watchdog timeout" message!) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2011 14:43:57 -0000 On Thu, Mar 3, 2011 at 2:10 AM, Lev Serebryakov wr= ote: > Hello, Arnaud. > You wrote 2 =D0=BC=D0=B0=D1=80=D1=82=D0=B0 2011 =D0=B3., 9:55:50: > >>>> I have been running with 7.2.2 and so far so good. =C2=A0However, its = hard to >>>> say in my case as the box I would only periodically see the issue. >>> =C2=A0As I wrote to Jack, my NIC hangs today with 7.2.2 >> Do you have any detailed error ? What the output of sysctl "dev.em.X" >> where X is the index of the hung interface ? > =C2=A0One more hang. Two logs are attached. > > -- > // Black Lion AKA Lev Serebryakov I see that you have CRC errors: dev.em.0.mac_stats.crc_errs: 156 and receive errors: dev.em.0.mac_stats.recv_errs: 147 You probably have a hardware problem. Is this the only machine on which you're experiencing the problem? -Brandon From owner-freebsd-stable@FreeBSD.ORG Thu Mar 3 15:16:42 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 70A2C106567E for ; Thu, 3 Mar 2011 15:16:42 +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 44C428FC1F for ; Thu, 3 Mar 2011 15:16:42 +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 ACF6746B2D; Thu, 3 Mar 2011 10:16:41 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.10]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 4D3D48A027; Thu, 3 Mar 2011 10:16:41 -0500 (EST) From: John Baldwin To: freebsd-stable@freebsd.org Date: Thu, 3 Mar 2011 09:55:23 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.4-CBSD-20110107; KDE/4.4.5; amd64; ; ) References: <4D6DA259.4050307@sentex.net> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201103030955.23620.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Thu, 03 Mar 2011 10:16:41 -0500 (EST) Cc: Yanhui Shen Subject: Re: CPU0: local APIC error 0x40 CPU1: local APIC error 0x40 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2011 15:16:42 -0000 On Wednesday, March 02, 2011 7:39:56 pm Yanhui Shen wrote: > `CPU0: local APIC error 0x40" > > I get this error on my ThinkPad R400(Intel Core2 T6570). Do you get a hang or does the machine keep working fine? -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Thu Mar 3 21:40:28 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3A6A510656A5; Thu, 3 Mar 2011 21:40:28 +0000 (UTC) (envelope-from lev@serebryakov.spb.ru) Received: from ftp.translate.ru (ftp.translate.ru [80.249.188.42]) by mx1.freebsd.org (Postfix) with ESMTP id DE6448FC18; Thu, 3 Mar 2011 21:40:27 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (89.112.15.178.pppoe.eltel.net [89.112.15.178]) (Authenticated sender: lev@serebryakov.spb.ru) by ftp.translate.ru (Postfix) with ESMTPA id 5C61F13DF5F; Fri, 4 Mar 2011 00:40:26 +0300 (MSK) Date: Fri, 4 Mar 2011 00:40:10 +0300 From: Lev Serebryakov X-Priority: 3 (Normal) Message-ID: <595446342.20110304004010@serebryakov.spb.ru> To: Brandon Gooch In-Reply-To: References: <1975926365.20110223121637@serebryakov.spb.ru> <4D64EC8C.2080007@sentex.net> <1004451940.20110223143607@serebryakov.spb.ru> <4D6D00C1.1040805@sentex.net> <1416421652.20110301225215@serebryakov.spb.ru> <1627628072.20110303111046@serebryakov.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org, Jan Koum , freebsd-stable@freebsd.org, Jack Vogel , Arnaud Lacombe Subject: Re: em0 with latest driver hangs again and again (without "Watchdog timeout" message!) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2011 21:40:28 -0000 Hello, Brandon. You wrote 3 =D0=BC=D0=B0=D1=80=D1=82=D0=B0 2011 =D0=B3., 17:08:26: > I see that you have CRC errors: > dev.em.0.mac_stats.crc_errs: 156 > and receive errors: > dev.em.0.mac_stats.recv_errs: 147 > You probably have a hardware problem. Is this the only machine on > which you're experiencing the problem? It is only machine with Intel NIC in my network. I'll try to replace patchcord... --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-stable@FreeBSD.ORG Thu Mar 3 22:26:12 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2B0A7106564A; Thu, 3 Mar 2011 22:26:12 +0000 (UTC) (envelope-from lev@serebryakov.spb.ru) Received: from ftp.translate.ru (ftp.translate.ru [80.249.188.42]) by mx1.freebsd.org (Postfix) with ESMTP id A0E528FC16; Thu, 3 Mar 2011 22:26:11 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (89.112.15.178.pppoe.eltel.net [89.112.15.178]) (Authenticated sender: lev@serebryakov.spb.ru) by ftp.translate.ru (Postfix) with ESMTPA id 8422313DF42; Fri, 4 Mar 2011 01:26:10 +0300 (MSK) Date: Fri, 4 Mar 2011 01:25:54 +0300 From: Lev Serebryakov X-Priority: 3 (Normal) Message-ID: <1894628540.20110304012554@serebryakov.spb.ru> To: Brandon Gooch In-Reply-To: References: <1975926365.20110223121637@serebryakov.spb.ru> <4D64EC8C.2080007@sentex.net> <1004451940.20110223143607@serebryakov.spb.ru> <4D6D00C1.1040805@sentex.net> <1416421652.20110301225215@serebryakov.spb.ru> <1627628072.20110303111046@serebryakov.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Arnaud Lacombe , freebsd-net@freebsd.org, freebsd-stable@freebsd.org, Jack Vogel , Jan Koum Subject: Re: em0 with latest driver hangs again and again (without "Watchdog timeout" message!) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2011 22:26:12 -0000 Hello, Brandon. You wrote 3 =D0=BC=D0=B0=D1=80=D1=82=D0=B0 2011 =D0=B3., 17:08:26: > I see that you have CRC errors: > dev.em.0.mac_stats.crc_errs: 156 > and receive errors: > dev.em.0.mac_stats.recv_errs: 147 It (almost) doesn't change. And it hangs again. It seems, that 7.2.2 hangs more often than 7.1.9 on my hardware :( --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-stable@FreeBSD.ORG Fri Mar 4 02:23:35 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A75E71065673 for ; Fri, 4 Mar 2011 02:23:35 +0000 (UTC) (envelope-from shen.elf@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 616E48FC14 for ; Fri, 4 Mar 2011 02:23:35 +0000 (UTC) Received: by gxk7 with SMTP id 7so700979gxk.13 for ; Thu, 03 Mar 2011 18:23:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=vI3qwWqg9+3/1J9x/uK0ZmVlpcVigWTOnn1O4lMaSuY=; b=ihPETPi32IIXIimo80N8PFzDLpOl1gPneHZYRNK2qU6mLoA3RA7GtEgpQMI8ee6F5H 8H1QKqTogGjBI4WpQjBDKtmIpt+EN20vT/hQEu+B3/O98qi70eWcuZmiKYuxyCusWhFy ANT26SS1pJSPBOMKUthQaowcihR1QrmaPyDFE= 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=GwtR1WINt1H5i2L3zdZD3+XNaaAo1PIf3+GkgHNZRuc0qUYYXRGU8dqg8xFsqhf4Ru hFfpXANp0iGzl+7U8zCc5lE+WQQu1J3c/gt1AWy/47CIhV05cGtn+1S22Q45HuCdpaZb Q8sz6B3FqEChSpWu6l1xL0BgHrIDV0azg79A4= MIME-Version: 1.0 Received: by 10.150.218.10 with SMTP id q10mr2754082ybg.351.1299205414587; Thu, 03 Mar 2011 18:23:34 -0800 (PST) Received: by 10.147.38.4 with HTTP; Thu, 3 Mar 2011 18:23:34 -0800 (PST) In-Reply-To: <201103030955.23620.jhb@freebsd.org> References: <4D6DA259.4050307@sentex.net> <201103030955.23620.jhb@freebsd.org> Date: Fri, 4 Mar 2011 10:23:34 +0800 Message-ID: From: Yanhui Shen To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: CPU0: local APIC error 0x40 CPU1: local APIC error 0x40 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2011 02:23:35 -0000 It works fine. When I grep the dmesg, I can find this message. -- Best regards, Yanhui From owner-freebsd-stable@FreeBSD.ORG Fri Mar 4 15:58:55 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 27E2F106564A for ; Fri, 4 Mar 2011 15:58:55 +0000 (UTC) (envelope-from crwhipp@gmail.com) Received: from mail-gx0-f196.google.com (mail-gx0-f196.google.com [209.85.161.196]) by mx1.freebsd.org (Postfix) with ESMTP id C6AF88FC0C for ; Fri, 4 Mar 2011 15:58:54 +0000 (UTC) Received: by gxk26 with SMTP id 26so382398gxk.7 for ; Fri, 04 Mar 2011 07:58:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:x-spam-checker-version:x-spam-level :x-spam-status:x-mailer:to:reply-to:in-reply-to:references:from :subject:date:content-type:mime-version:message-id :content-transfer-encoding:x-virus-scanned:x-virus-status; bh=OWRXeSJ1yZZJuiu52QmNgwjQU0HhI5BWLDwnrIHxP7c=; b=Q/03aYLDSEys+N9aN0CyBZlW6emBEm/WwfBH0NWFzgQxSEsoRiLlbS5T62XstteaXt 0scswfKQoz7Z0cxtZnnFkwR4I72o+mYeYrbTWokg0tAtxxvCrljvYqtcF0Ki2Qcf722D i7i08ISwvO1sAiJw/DQuIM7c40a0NXtjy7V2g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=x-spam-checker-version:x-spam-level:x-spam-status:x-mailer:to :reply-to:in-reply-to:references:from:subject:date:content-type :mime-version:message-id:content-transfer-encoding:x-virus-scanned :x-virus-status; b=OHSoMo2NNihFxjSunt3djPYFB8y38fTE0W0SnKv+SYK9NMMfnloRaVzCeLONXyk2Oh b0XvYiC2pQ0VHO7ifTUNa7QZ3QLEUMUx0vn5V92FXSWFVb34yPwe4vlDVeRwlCMDwwhB UxB7lKSFockin+sV7HFnJg/gtoT26KN30zWZw= Received: by 10.150.134.4 with SMTP id h4mr1009483ybd.266.1299253590956; Fri, 04 Mar 2011 07:46:30 -0800 (PST) Received: from whipp.no-ip.org (174-26-157-71.phnx.qwest.net [174.26.157.71]) by mx.google.com with ESMTPS id w1sm1788402ybl.9.2011.03.04.07.46.28 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 04 Mar 2011 07:46:30 -0800 (PST) Received: by whipp.no-ip.org (Postfix, from userid 58) id 82554B8052; Fri, 4 Mar 2011 08:46:26 -0700 (MST) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on revo.domain.actdsltmp X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=unavailable version=3.3.1 Received: from mediabox.servebeer.com (localhost [127.0.0.1]) by whipp.no-ip.org (Postfix) with ESMTP id 6BE0EB8021; Fri, 4 Mar 2011 08:46:22 -0700 (MST) X-Mailer: Hastymail2 1.01 To: , Jeremy Chadwick In-Reply-To: <20110227160145.GA1885@icarus.home.lan> References: <20110227160145.GA1885@icarus.home.lan> From: Craig Whipp Date: Fri, 04 Mar 2011 08:46:22 -0700 Content-Type: text/plain; charset=UTF-8; format=fixed MIME-Version: 1.0 Message-id: <55256f87671875469530880cd02d8aa1@mediabox.servebeer.com> Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.97 at revo.domain.actdsltmp X-Virus-Status: Clean Cc: Subject: Re: ath(4) panic + stuck beacon issue X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: cwhipp@whipp.no-ip.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 15:58:55 -0000 On Sun, 27 Feb 2011 08:01:46 -0800 Jeremy Chadwick wrote > > If a workaround or solution isn't plausible, what cards do people > actually recommend that work reliably / have reliable drivers? I was > under the impression Atheros cards were reliable/decent compared to, > say, Broadcom. Is iwn(4) reliable? > > -- > | 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 | > I've had nothing but success with iwn(4) and an Intel 5100 based card. -Craig From owner-freebsd-stable@FreeBSD.ORG Fri Mar 4 16:45:00 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3006F106566B for ; Fri, 4 Mar 2011 16:45:00 +0000 (UTC) (envelope-from jamesbrandongooch@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id B4C9A8FC13 for ; Fri, 4 Mar 2011 16:44:59 +0000 (UTC) Received: by wwb31 with SMTP id 31so3065112wwb.31 for ; Fri, 04 Mar 2011 08:44:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=95JeA7rMX5qY/uxFn14q9mHFxyK4uCHGHwIzFF9LBS0=; b=sTPCMiROU9c3FkPj3YSHqVZZAjk9OImDn5I4HRUVLOl5gl10Vaky4oPaiGvSisiuVz VXlizQQgEG19WpvqQjPPIzeNle0pXeOUJhZejjQGYfnqdcsFJJYBV0rsqef1gUHDeuEQ vuiVBuYQXxlvgbw6EM3woYiZRonOKwq2ubhcE= 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=Qi6gTzIgIFfuRtcbXCuE1oYKpod1oirZQPvdfncPjI0iILEYwCFke+Z15N2bzt2B1s RUMSKQmb9BBynz6O2922IpHh035NqGbPIgM+HcRRgbHvysAiuYpsE+X1RCvJIjwv1JoU TJdJwD0KmG6eI+xjWd4sEWufLvyIqT4jGrJ6M= MIME-Version: 1.0 Received: by 10.216.141.15 with SMTP id f15mr713749wej.80.1299257025075; Fri, 04 Mar 2011 08:43:45 -0800 (PST) Received: by 10.216.25.72 with HTTP; Fri, 4 Mar 2011 08:43:45 -0800 (PST) In-Reply-To: <55256f87671875469530880cd02d8aa1@mediabox.servebeer.com> References: <20110227160145.GA1885@icarus.home.lan> <55256f87671875469530880cd02d8aa1@mediabox.servebeer.com> Date: Fri, 4 Mar 2011 10:43:45 -0600 Message-ID: From: Brandon Gooch To: cwhipp@whipp.no-ip.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Craig Whipp , freebsd-stable@freebsd.org, Jeremy Chadwick Subject: Re: ath(4) panic + stuck beacon 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 Mar 2011 16:45:00 -0000 On Fri, Mar 4, 2011 at 9:46 AM, Craig Whipp wrote: > On Sun, 27 Feb 2011 08:01:46 -0800 Jeremy Chadwick > wrote > > >> >> If a workaround or solution isn't plausible, what cards do people >> actually recommend that work reliably / have reliable drivers? =A0I was >> under the impression Atheros cards were reliable/decent compared to, >> say, Broadcom. =A0Is iwn(4) reliable? >> >> -- >> | Jeremy Chadwick =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 jdc@parodius.com | >> | Parodius Networking =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 http:/= /www.parodius.com/ | >> | UNIX Systems Administrator =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Mountain= View, CA, USA | >> | Making life hard for others since 1977. =A0 =A0 =A0 =A0 =A0 =A0 =A0 PG= P 4BD6C0CB | >> > > > I've had nothing but success with iwn(4) and an Intel 5100 based card. > > -Craig +1 for iwn(4) for general use (as that has been my use). Also, the maintainer of iwn(4), bschmidt@, is knowledgeable and responsive to issues as well... -Brandon From owner-freebsd-stable@FreeBSD.ORG Fri Mar 4 18:55:03 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9AAEF106564A for ; Fri, 4 Mar 2011 18:55:03 +0000 (UTC) (envelope-from hilko.meyer@gmx.de) Received: from kirk.hochpass.uni-hannover.de (kirk.hochpass.uni-hannover.de [130.75.81.215]) by mx1.freebsd.org (Postfix) with ESMTP id 257CC8FC27 for ; Fri, 4 Mar 2011 18:55:02 +0000 (UTC) Received: from ROGERS.hochpass.uni-hannover.de (rogers.hochpass.uni-hannover.de [130.75.81.217]) by kirk.hochpass.uni-hannover.de (8.14.4/8.14.4) with SMTP id p24IHZiP042560 for ; Fri, 4 Mar 2011 19:17:35 +0100 (CET) (envelope-from hilko.meyer@gmx.de) From: Hilko Meyer To: freebsd-stable@freebsd.org Date: Fri, 04 Mar 2011 19:17:20 +0100 Message-ID: <6v82n6934o8p7u4vpbde35dbnc41mjd4a5@4ax.com> X-Mailer: Forte Agent 1.93/32.576 English (American) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: service(8) doesn't list dhcpd startscript X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2011 18:55:03 -0000 Hi, today I played a bit with service(8) and I noticed that it doesn't properly detects the isc-dhcpd-startscript. System is 7.3-RELEASE-p4. 'service -l' lists isc-dhcpd but 'service -e' doesn't lists it: | hilti@kirk:~> service -l | grep dhcp | isc-dhcpd | hilti@kirk:~> service -e | grep dhcp | hilti@kirk:~> /usr/local/etc/rc.d/isc-dhcpd rcvar | # dhcpd | dhcpd_enable=YES Some more info: | hilti@kirk:~> pkg_info -xI dhcp | isc-dhcp31-server-3.1.ESV,1 The ISC Dynamic Host Configuration Protocol server | hilti@kirk:~> ls -l /usr/local/etc/rc.d/ | total 42 | -r-xr-xr-x 1 root wheel 5612 2 Feb 17:21 apache22 | -r-xr-xr-x 1 root wheel 508 25 Feb 17:57 cupsd | -r-xr-xr-x 1 root wheel 1731 2 Feb 17:21 htcacheclean | -r-xr-xr-x 1 root wheel 16875 20 Okt 17:30 isc-dhcpd | -r-xr-xr-x 1 root wheel 713 20 Okt 17:14 mailman | -r-xr-xr-x 1 root wheel 1966 8 Feb 19:49 mysql-server | -r-xr-xr-x 1 root wheel 5037 2 Mr 19:29 samba | -r-xr-xr-x 1 root wheel 529 26 Aug 2009 scanlogd | -r-xr-xr-x 1 root wheel 890 20 Okt 17:13 smartd htcacheclean is not enabled, but all other scripts are enabled. In /var/log/messages I found | Mar 4 18:41:29 kirk hilti: /usr/sbin/service: WARNING: $htcacheclean_enable is not set properly - see rc.conf(5). but it seems unrelated to the dhcpd-problem. I removed the htcacheclean script but 'service -l' stil doesn't lists the dhcpd service. Whar can I do to fix this problem? Thanks, Hilko From owner-freebsd-stable@FreeBSD.ORG Fri Mar 4 19:05:47 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D9C331065678 for ; Fri, 4 Mar 2011 19:05:47 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay02.stack.nl [IPv6:2001:610:1108:5010::104]) by mx1.freebsd.org (Postfix) with ESMTP id 3FFAE8FC1E for ; Fri, 4 Mar 2011 19:05:47 +0000 (UTC) Received: from turtle.stack.nl (turtle.stack.nl [IPv6:2001:610:1108:5010::132]) by mx1.stack.nl (Postfix) with ESMTP id 7B2883593B1; Fri, 4 Mar 2011 20:05:45 +0100 (CET) Received: by turtle.stack.nl (Postfix, from userid 1677) id 6668A1739F; Fri, 4 Mar 2011 20:05:45 +0100 (CET) Date: Fri, 4 Mar 2011 20:05:45 +0100 From: Jilles Tjoelker To: Stephen Montgomery-Smith Message-ID: <20110304190545.GA38881@stack.nl> References: <4D6BD83B.3040609@missouri.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D6BD83B.3040609@missouri.edu> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: FreeBSD Stable Subject: Re: Change in behavior to stat(1) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2011 19:05:47 -0000 On Mon, Feb 28, 2011 at 11:15:39AM -0600, Stephen Montgomery-Smith wrote: > I had a little script that would remove broken links. I used to do it > like this: > if ! stat -L $link > /dev/null; then rm $link; fi > But recently (some time in February according to the CVS records) stat > was changed so that stat -L would use lstat(2) if the link is broken. > So I had to change it to > if stat -L $link | awk '{print $3}' | grep l > /dev/null; > then rm $link; fi > but it is a lot less elegant. > What is the proper accepted way to remove broken links? A better answer to your original question was already given, but for that command, isn't it sufficient to do if ! [ -e $link ]; then rm $link; fi All test(1)'s primaries that test things about files follow symlinks, except for -h/-L. -- Jilles Tjoelker From owner-freebsd-stable@FreeBSD.ORG Fri Mar 4 23:08:45 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 64B50106566B for ; Fri, 4 Mar 2011 23:08:45 +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 22FA58FC0A for ; Fri, 4 Mar 2011 23:08:44 +0000 (UTC) Received: from elsa.codelab.cz (localhost.codelab.cz [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id 5147219E02E; Fri, 4 Mar 2011 23:51:29 +0100 (CET) Received: from [192.168.1.2] (ip-86-49-61-235.net.upcbroadband.cz [86.49.61.235]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id CC74119E02D; Fri, 4 Mar 2011 23:51:26 +0100 (CET) Message-ID: <4D716CEE.7040106@quip.cz> Date: Fri, 04 Mar 2011 23:51:26 +0100 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1.17) Gecko/20110123 SeaMonkey/2.0.12 MIME-Version: 1.0 To: Hilko Meyer References: <6v82n6934o8p7u4vpbde35dbnc41mjd4a5@4ax.com> In-Reply-To: <6v82n6934o8p7u4vpbde35dbnc41mjd4a5@4ax.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: service(8) doesn't list dhcpd startscript X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2011 23:08:45 -0000 Hilko Meyer wrote: > Hi, > > today I played a bit with service(8) and I noticed that it doesn't properly > detects the isc-dhcpd-startscript. System is 7.3-RELEASE-p4. 'service -l' lists > isc-dhcpd but 'service -e' doesn't lists it: > | hilti@kirk:~> service -l | grep dhcp > | isc-dhcpd > | hilti@kirk:~> service -e | grep dhcp > | hilti@kirk:~> /usr/local/etc/rc.d/isc-dhcpd rcvar > | # dhcpd > | dhcpd_enable=YES It works for me on newer version of the FreeBSD (7.4-RELEASE) and with newer dhcpd (isc-dhcp41-server-4.1.2_2,1) ~/# service -l | grep dhcp isc-dhcpd isc-dhcpd6 ~/# service -e | grep dhcp /usr/local/etc/rc.d/isc-dhcpd /usr/local/etc/rc.d/isc-dhcpd6 ~/# /usr/local/etc/rc.d/isc-dhcpd rcvar # dhcpd dhcpd_enable=YES So you can compare rc scripts for those two versions or compare changes in service between these two FreeBSD releases. Miroslav Lachman From owner-freebsd-stable@FreeBSD.ORG Sat Mar 5 00:17:22 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AF0A2106564A; Sat, 5 Mar 2011 00:17:22 +0000 (UTC) (envelope-from prvs=10451ca0e0=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 141298FC0C; Sat, 5 Mar 2011 00:17:21 +0000 (UTC) X-MDAV-Processed: mail1.multiplay.co.uk, Sat, 05 Mar 2011 00:06:14 +0000 X-Spam-Processed: mail1.multiplay.co.uk, Sat, 05 Mar 2011 00:06:14 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail1.multiplay.co.uk X-Spam-Level: X-Spam-Status: No, score=-5.0 required=6.0 tests=USER_IN_WHITELIST shortcircuit=ham autolearn=disabled version=3.2.5 Received: from r2d2 ([188.220.16.49]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50012385947.msg; Sat, 05 Mar 2011 00:06:14 +0000 X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=10451ca0e0=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk Message-ID: <31A99DAA7E5F4095B22B9DD57DD0E19E@multiplay.co.uk> From: "Steven Hartland" To: "Lev Serebryakov" , "Brandon Gooch" References: <1975926365.20110223121637@serebryakov.spb.ru><4D64EC8C.2080007@sentex.net><1004451940.20110223143607@serebryakov.spb.ru><4D6D00C1.1040805@sentex.net><1416421652.20110301225215@serebryakov.spb.ru><1627628072.20110303111046@serebryakov.spb.ru> <1894628540.20110304012554@serebryakov.spb.ru> Date: Sat, 5 Mar 2011 00:06:32 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 Cc: freebsd-net@freebsd.org, Jan Koum , freebsd-stable@freebsd.org, Jack Vogel , Arnaud Lacombe Subject: Re: em0 with latest driver hangs again and again (without "Watchdogtimeout" message!) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2011 00:17:22 -0000 Silly question but have you checked your ram for issues, we had a machine with seemingly unexplained problems and hangs and it turned out to be a duff stick of ram which wasn't being chip killed. ----- Original Message ----- From: "Lev Serebryakov" To: "Brandon Gooch" Cc: "Arnaud Lacombe" ; ; ; "Jack Vogel" ; "Jan Koum" Sent: Thursday, March 03, 2011 10:25 PM Subject: Re: em0 with latest driver hangs again and again (without "Watchdogtimeout" message!) Hello, Brandon. You wrote 3 марта 2011 г., 17:08:26: > I see that you have CRC errors: > dev.em.0.mac_stats.crc_errs: 156 > and receive errors: > dev.em.0.mac_stats.recv_errs: 147 It (almost) doesn't change. And it hangs again. It seems, that 7.2.2 hangs more often than 7.1.9 on my hardware :( -- // Black Lion AKA Lev Serebryakov _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-stable@FreeBSD.ORG Sat Mar 5 08:50:10 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 67B3F106564A for ; Sat, 5 Mar 2011 08:50:10 +0000 (UTC) (envelope-from peterjeremy@acm.org) Received: from mail18.syd.optusnet.com.au (mail18.syd.optusnet.com.au [211.29.132.199]) by mx1.freebsd.org (Postfix) with ESMTP id F09468FC0C for ; Sat, 5 Mar 2011 08:50:09 +0000 (UTC) Received: from server.vk2pj.dyndns.org (c220-239-116-103.belrs4.nsw.optusnet.com.au [220.239.116.103]) by mail18.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id p258o6mZ002990 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 5 Mar 2011 19:50:07 +1100 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.4/8.14.4) with ESMTP id p258o56o082560 for ; Sat, 5 Mar 2011 19:50:05 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.4/8.14.4/Submit) id p258o5S2082559 for freebsd-stable@freebsd.org; Sat, 5 Mar 2011 19:50:05 +1100 (EST) (envelope-from peter) Date: Sat, 5 Mar 2011 19:50:05 +1100 From: Peter Jeremy To: freebsd-stable@freebsd.org Message-ID: <20110305085004.GA70142@server.vk2pj.dyndns.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="WIyZ46R2i8wDzkSu" Content-Disposition: inline X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Linker set issues with ath(4) HALs X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2011 08:50:10 -0000 --WIyZ46R2i8wDzkSu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I have a Atheros AR5424 and so, based on the 8.2-STABLE i386 NOTES and some rummaging in the sources, I tried to build a kernel with: device ath # Atheros pci/cardbus NIC's device ath_ar5212 # HAL for Atheros AR5212 and derived chips device ath_rate_sample # SampleRate tx rate control for ath and this died during the kernel linking with: linking kernel.debug ah.o(.text+0x23c): In function `ath_hal_rfprobe': /usr/src/sys/dev/ath/ath_hal/ah.c:142: undefined reference to `__start_set_= ah_rf s' ah.o(.text+0x241):/usr/src/sys/dev/ath/ath_hal/ah.c:142: undefined referenc= e to `__stop_set_ah_rfs' ah.o(.text+0x25a):/usr/src/sys/dev/ath/ath_hal/ah.c:142: undefined referenc= e to `__stop_set_ah_rfs' Following a suggestion by a friend, I changed that to: device ath # Atheros pci/cardbus NIC's options AH_SUPPORT_AR5416 device ath_hal # Atheros HAL device ath_rate_sample # SampleRate tx rate control for ath and it worked. Normally, I would leave it at that but I'd like to understand what is actually going on... In both cases, ah.o contains the following 4 references: U __start_set_ah_chips U __start_set_ah_rfs U __stop_set_ah_chips U __stop_set_ah_rfs generated by: /* linker set of registered chips */ OS_SET_DECLARE(ah_chips, struct ath_hal_chip); /* linker set of registered RF backends */ OS_SET_DECLARE(ah_rfs, struct ath_hal_rf); These symbols do not appear in any other .o files, though there are a variety of other __{start,stop}_set_* symbols - all of which show up as 'A' (absolule) values in the final kernel. My questions are: How are these linker set references resolved? I can't find anything that defines these symbols - either in .o files or in ldscript files. In the first case, there are 2 pairs of undefined linker set variables but the linker only reports one pair as unresolved. Why don't both sets show up as resolved or unresolved? Why does using the generic "ath_hal", rather than the hardware-specific HAL fix the problem? --=20 Peter Jeremy --WIyZ46R2i8wDzkSu Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (FreeBSD) iEYEARECAAYFAk1x+TwACgkQ/opHv/APuIc9bwCfZlMA9KvNRaAL72TlrtiiUamg /JUAoJLAWxCwhFB6oazoJ3V+ik9KzHQ1 =DrPH -----END PGP SIGNATURE----- --WIyZ46R2i8wDzkSu-- From owner-freebsd-stable@FreeBSD.ORG Sat Mar 5 09:49:02 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E67B21065677 for ; Sat, 5 Mar 2011 09:49:01 +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 80FFF8FC21 for ; Sat, 5 Mar 2011 09:49:01 +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 p259msmc091974 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 5 Mar 2011 11:48:54 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id p259msvw070601; Sat, 5 Mar 2011 11:48:54 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id p259ms5l070600; Sat, 5 Mar 2011 11:48:54 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 5 Mar 2011 11:48:54 +0200 From: Kostik Belousov To: Peter Jeremy Message-ID: <20110305094854.GM78089@deviant.kiev.zoral.com.ua> References: <20110305085004.GA70142@server.vk2pj.dyndns.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="M0Yq1Q+lJysaJ3ln" Content-Disposition: inline In-Reply-To: <20110305085004.GA70142@server.vk2pj.dyndns.org> User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-3.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, 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-stable@freebsd.org Subject: Re: Linker set issues with ath(4) HALs X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2011 09:49:02 -0000 --M0Yq1Q+lJysaJ3ln Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Mar 05, 2011 at 07:50:05PM +1100, Peter Jeremy wrote: > I have a Atheros AR5424 and so, based on the 8.2-STABLE i386 NOTES > and some rummaging in the sources, I tried to build a kernel with: >=20 > device ath # Atheros pci/cardbus NIC's > device ath_ar5212 # HAL for Atheros AR5212 and derived chips > device ath_rate_sample # SampleRate tx rate control for ath >=20 > and this died during the kernel linking with: > linking kernel.debug > ah.o(.text+0x23c): In function `ath_hal_rfprobe': > /usr/src/sys/dev/ath/ath_hal/ah.c:142: undefined reference to `__start_se= t_ah_rf > s' > ah.o(.text+0x241):/usr/src/sys/dev/ath/ath_hal/ah.c:142: undefined refere= nce to `__stop_set_ah_rfs' > ah.o(.text+0x25a):/usr/src/sys/dev/ath/ath_hal/ah.c:142: undefined refere= nce to `__stop_set_ah_rfs' >=20 > Following a suggestion by a friend, I changed that to: >=20 > device ath # Atheros pci/cardbus NIC's > options AH_SUPPORT_AR5416 > device ath_hal # Atheros HAL > device ath_rate_sample # SampleRate tx rate control for ath >=20 > and it worked. Normally, I would leave it at that but I'd like to > understand what is actually going on... >=20 > In both cases, ah.o contains the following 4 references: > U __start_set_ah_chips > U __start_set_ah_rfs > U __stop_set_ah_chips > U __stop_set_ah_rfs > generated by: > /* linker set of registered chips */ > OS_SET_DECLARE(ah_chips, struct ath_hal_chip); > /* linker set of registered RF backends */ > OS_SET_DECLARE(ah_rfs, struct ath_hal_rf); >=20 > These symbols do not appear in any other .o files, though there are a > variety of other __{start,stop}_set_* symbols - all of which show up > as 'A' (absolule) values in the final kernel. >=20 > My questions are: > How are these linker set references resolved? I can't find anything > that defines these symbols - either in .o files or in ldscript files. >=20 > In the first case, there are 2 pairs of undefined linker set variables > but the linker only reports one pair as unresolved. Why don't both > sets show up as resolved or unresolved? Why does using the generic > "ath_hal", rather than the hardware-specific HAL fix the problem? Linker synthesizes the symbols assuming the following two conditions are met: - the symbols are referenced; - there exists an ELF section named `set_ah_rfs'. It assigns the (relocated) start of the section to __start_, and end to __stop_. Most likely, omitting the option causes some SET_ENTRY() macro, which put a symbol into linker set, to be ommitted. Then, no section is created and linker does not synthesizes the missed symbols. --M0Yq1Q+lJysaJ3ln Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk1yBwUACgkQC3+MBN1Mb4htQgCgtjZZsrmuhJ6qcQEGmtySwJv1 acsAoO39NeYz3lDohvc4ftEHLOCbh2dE =7ihQ -----END PGP SIGNATURE----- --M0Yq1Q+lJysaJ3ln-- From owner-freebsd-stable@FreeBSD.ORG Sat Mar 5 10:03:40 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 76E7B1065670; Sat, 5 Mar 2011 10:03:40 +0000 (UTC) (envelope-from lev@serebryakov.spb.ru) Received: from ftp.translate.ru (ftp.translate.ru [80.249.188.42]) by mx1.freebsd.org (Postfix) with ESMTP id 279C68FC0C; Sat, 5 Mar 2011 10:03:39 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (89.112.15.178.pppoe.eltel.net [89.112.15.178]) (Authenticated sender: lev@serebryakov.spb.ru) by ftp.translate.ru (Postfix) with ESMTPA id F222F13DF42; Sat, 5 Mar 2011 13:03:37 +0300 (MSK) Date: Sat, 5 Mar 2011 13:03:20 +0300 From: Lev Serebryakov X-Priority: 3 (Normal) Message-ID: <494278763.20110305130320@serebryakov.spb.ru> To: "Steven Hartland" In-Reply-To: <31A99DAA7E5F4095B22B9DD57DD0E19E@multiplay.co.uk> References: <1975926365.20110223121637@serebryakov.spb.ru><4D64EC8C.2080007@sentex.net><1004451940.20110223143607@serebryakov.spb.ru><4D6D00C1.1040805@sentex.net><1416421652.20110301225215@serebryakov.spb.ru><1627628072.20110303111046@serebryakov.spb.ru> <1894628540.20110304012554@serebryakov.spb.ru> <31A99DAA7E5F4095B22B9DD57DD0E19E@multiplay.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org, Brandon Gooch , freebsd-net@freebsd.org, Jan Koum , Jack Vogel , Arnaud Lacombe Subject: Re: em0 with latest driver hangs again and again (without "Watchdogtimeout" message!) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2011 10:03:40 -0000 Hello, Steven. You wrote 5 =D0=BC=D0=B0=D1=80=D1=82=D0=B0 2011 =D0=B3., 3:06:32: > Silly question but have you checked your ram for issues, we had a machine > with seemingly unexplained problems and hangs and it turned out to be > a duff stick of ram which wasn't being chip killed. Yes, two full days (48h) of memtest86+ -- no problems... --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-stable@FreeBSD.ORG Sat Mar 5 10:50:30 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6E3FC106566B for ; Sat, 5 Mar 2011 10:50:30 +0000 (UTC) (envelope-from peterjeremy@acm.org) Received: from mail12.syd.optusnet.com.au (mail12.syd.optusnet.com.au [211.29.132.193]) by mx1.freebsd.org (Postfix) with ESMTP id 02C668FC0A for ; Sat, 5 Mar 2011 10:50:29 +0000 (UTC) Received: from server.vk2pj.dyndns.org (c220-239-116-103.belrs4.nsw.optusnet.com.au [220.239.116.103]) by mail12.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id p25AoRs7011373 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 5 Mar 2011 21:50:27 +1100 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.4/8.14.4) with ESMTP id p25AoP20015963; Sat, 5 Mar 2011 21:50:25 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.4/8.14.4/Submit) id p25AoPgn015962; Sat, 5 Mar 2011 21:50:25 +1100 (EST) (envelope-from peter) Date: Sat, 5 Mar 2011 21:50:25 +1100 From: Peter Jeremy To: Kostik Belousov Message-ID: <20110305105025.GB70142@server.vk2pj.dyndns.org> References: <20110305085004.GA70142@server.vk2pj.dyndns.org> <20110305094854.GM78089@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="rJwd6BRFiFCcLxzm" Content-Disposition: inline In-Reply-To: <20110305094854.GM78089@deviant.kiev.zoral.com.ua> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org Subject: Re: Linker set issues with ath(4) HALs X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2011 10:50:30 -0000 --rJwd6BRFiFCcLxzm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2011-Mar-05 11:48:54 +0200, Kostik Belousov wrote: >On Sat, Mar 05, 2011 at 07:50:05PM +1100, Peter Jeremy wrote: >> I have a Atheros AR5424 and so, based on the 8.2-STABLE i386 NOTES >> and some rummaging in the sources, I tried to build a kernel with: >>=20 >> device ath # Atheros pci/cardbus NIC's >> device ath_ar5212 # HAL for Atheros AR5212 and derived chips >> device ath_rate_sample # SampleRate tx rate control for ath =2E.. >> These symbols do not appear in any other .o files, though there are a >> variety of other __{start,stop}_set_* symbols - all of which show up >> as 'A' (absolule) values in the final kernel. >>=20 >> My questions are: >> How are these linker set references resolved? I can't find anything >> that defines these symbols - either in .o files or in ldscript files. =2E.. >Linker synthesizes the symbols assuming the following two conditions are >met: >- the symbols are referenced; >- there exists an ELF section named `set_ah_rfs'. >It assigns the (relocated) start of the section to __start_, >and end to __stop_. Thank you for that. Looking through the output of 'objdump -h' showed that it was user error: When using "device ath_arXXXX", it looks like you need to include a "device ath_rfYYYY" as well. After a closer look at my dmesg and available options, I've add "device ath_rf2425" and things seem much happier. --=20 Peter Jeremy --rJwd6BRFiFCcLxzm Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (FreeBSD) iEYEARECAAYFAk1yFXEACgkQ/opHv/APuId4hQCgndggXp++puDl9IBx3564mdF5 nlwAn1ePKNJ1AjcBrDZCSbbfptcn0/Dm =c6JK -----END PGP SIGNATURE----- --rJwd6BRFiFCcLxzm-- From owner-freebsd-stable@FreeBSD.ORG Sat Mar 5 15:04:48 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 44AB41065670 for ; Sat, 5 Mar 2011 15:04:48 +0000 (UTC) (envelope-from vanopen@gmail.com) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by mx1.freebsd.org (Postfix) with ESMTP id F0E478FC15 for ; Sat, 5 Mar 2011 15:04:47 +0000 (UTC) Received: by gwaa18 with SMTP id a18so2632851gwa.17 for ; Sat, 05 Mar 2011 07:04:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:date:from:to:subject:message-id:mime-version :content-type:content-disposition:organization:x-operating-system :user-agent; bh=16n+LXXXYvkQQmJhrO2MXtLgWXIcJWw+GbuWgewlvLk=; b=mOcca9PoqDstHmt/eZoZipd+V7FO8kEovYy3t27kMvk50nBOfPRoW+y+ITE5+XGBwh 7JwpcxIWCCB3rkjo+ua1UnCgH9xw02JKSy3U/g/Zi/GyYukSM/OIv9rvxLx84B02slr/ I6rhVB4ssUltbwSncw4BG6xBxQtumyhNBqOG0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:subject:message-id:mime-version:content-type :content-disposition:organization:x-operating-system:user-agent; b=F+XHwfUnDqNatQBsM5bAMORno7pnoejHFtaNnC7mkREvyVj/n7XcwVoCMqqDJgoNPf I3WXsoHpe4LnV2U4o/Y6aYPEYLoY6O7kdCQu0FLblKXds7yx/5Qi0IGUWc8uRMNftnE+ /vWzMdj6clQ+PzXytuuN7nF1Reohk4nORUtdM= Received: by 10.91.67.12 with SMTP id u12mr2424099agk.112.1299337487120; Sat, 05 Mar 2011 07:04:47 -0800 (PST) Received: from fbsd.t60.cpu ([221.6.39.130]) by mx.google.com with ESMTPS id g31sm357678yhd.26.2011.03.05.07.04.44 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 05 Mar 2011 07:04:46 -0800 (PST) Date: Sat, 5 Mar 2011 23:04:36 +0800 From: Yue Wu To: ml-freebsd-stable Message-ID: <20110305150436.GA2175@fbsd.t60.cpu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Organization: China Pharmaceutical University, Nanjing, China X-Operating-System: FreeBSD 8.2-PRERELEASE i386 User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Question about packages installed via `pkg_add -r` X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2011 15:04:48 -0000 Hi, list, I'm trying to use package instead of ports these day, but a few questions have: 1. How to reserve packages that fetched via `pkg_add -r`? 2. How to know if there are updates for packages, and how to update? -- Regards, Yue Wu Key Laboratory of Modern Chinese Medicines Department of Traditional Chinese Medicine China Pharmaceutical University No.24, Tongjia Xiang Street, Nanjing 210009, China From owner-freebsd-stable@FreeBSD.ORG Sat Mar 5 15:21:57 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B765F1065676 for ; Sat, 5 Mar 2011 15:21:57 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 6AC718FC13 for ; Sat, 5 Mar 2011 15:21:57 +0000 (UTC) Received: by vxc34 with SMTP id 34so3245500vxc.13 for ; Sat, 05 Mar 2011 07:21:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=flm8UtLMfMvfNUuUO+c5oxMyNdyrX7w35FnX5Hqw1nY=; b=PaERe3+63mPiP0S4r0j1zmC0nroPTtAM6e5kxTiQQYLq9KqAdGm5EeGS1LwU2zLoAb wwsflC/zSQaVI0mhDQmLGsmdm4OaP43ks/jzrYml7ZnikGK4sMOpLkdp9WPseA8ztW+a cg3y+FpCAlw3L7kET7SaOj+H28T2eKgBFY3C4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=D0Um+/qdjMs2kq/Rae/8GP3sOOeqJIcafdRYNktMInRAvTBvMmeqiJm0zW6MEHe+VE EWqWV1SfmFf1+NzdSQZ+u7FcFyTEwr0jMYRZ3GFR6yOizzcXbBjwzQr3sB533Zi8tsQt JI2UK/1lOOMh3+NoUkPuu6MwoP4bU7NTy87D8= MIME-Version: 1.0 Received: by 10.52.0.199 with SMTP id 7mr404861vdg.307.1299336695136; Sat, 05 Mar 2011 06:51:35 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.52.167.3 with HTTP; Sat, 5 Mar 2011 06:51:35 -0800 (PST) In-Reply-To: <20110227160145.GA1885@icarus.home.lan> References: <20110227160145.GA1885@icarus.home.lan> Date: Sat, 5 Mar 2011 22:51:35 +0800 X-Google-Sender-Auth: 87J_6o12-rn5IJFJv8e3xolq1Q8 Message-ID: From: Adrian Chadd To: Jeremy Chadwick Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: ath(4) panic + stuck beacon 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 Mar 2011 15:21:57 -0000 I'm the ath maintainer now it seems. "stuck beacon" means a lot of things. Debugging it is going to mean better understanding what is going on in your environment that's being handled incorrectly. A lot of the reasons I've seen stuck beacons creep up is because the radio environment gets periodically noisy and the driver handles that very badly. Step 1 is compiling your kernel with: options ATH_DEBUG options AH_DEBUG options ATH_DIAGAPI Then the next thing to do is to enable calibration debugging: sysctl hw.ath.hal.debug=0x8 That'll spit out some debugging every 30 seconds that reports the noise floor that the card is calibrating against. Then you can try repeating that with the longcal interval tweaked up to say 1 second (it defaults to 30), to see if it's fluctuating: sysctl hw.ath.longcal=1 There's some other things which can help but I need to finish porting some diagnostic code to the ath code in -HEAD. If you feel adventurous, you could try running the -HEAD if_ath code under RELENG_8. I do this as a module for my testing. There's been some changes which MAY make the AR5416 behave better. The AR9280 unfortunately requires some more work. I'm in the process right now of porting over some code from Linux ath9k to try and fix TX stability issues. If it works for you then great, but it's going to be hit and miss. The (more) technical reasons: * The "stuck beacon" can be a variety of reasons, some of which are touched on the madwifi site. But non-RF issues aside (ie, DMA timing, busy bus, etc), almost all of the issues are due to a noisy environment where the card just gets into a state where it thinks it can't transmit. Buying me a card would be nice :) but since it's very likely environmental related, I'd have to somehow determine and reproduce that problem. I've got some diagnostic tools here which log things like channel TX/RX/busy status which helps determine this stuff, but I just don't have the time right now to port all of that over and fix up things for 11n. Sorry. :( * Specifically, ath cards have very sensitive RX. The periodic noise floor calibration sets the CCA threshold for "when the air is too busy to transmit!" which is based on what the calibrated NF level is. (Ie, it establishes what the median noise floor is over successive 30 second samples, then uses this as the CCA threshold.) This can become quite low (lower than -90dBm on the AR5416/AR9160, down to lower than -100dBm on the AR9280.) But if noise then appears that's above a low-set CCA threshold, the radio thinks it can't transmit and it resets with "stuck beacon." The default CCA threshold is higher than what it calibrates down to over time, so that's why you (generally) see the radio work fine for a few minutes before resetting. * I've discovered some AR9280 based cards have different methods of calibrating TX power. We handle the "older" method, but not the "newer" method. It turns out this AR9280 card I have here has the "newer" method. Since there's no easy way for the average user to know what they have (without inspecting the EEPROM contents to see what the manufacturer did), it'll raise its ugly head as "it works for me!" for some, and "it doesn't work stable for me!" for others. * The AR5416 support in ath9k is in no way verified, stable or tested. So it's possible that improvements I bring over from ath9k to fix AR9280 and AR9285 issues will break previous 11n family chips (AR5416/AR9160.) I'm trying to be mindful of this and test where I can, but it's not easy. HTH, Adrian On 28 February 2011 00:01, Jeremy Chadwick wrote: > I have a crash report to provide (for RELENG_8 dated 2010/02/12), but > I'd like to know who's maintaining ath(4) at this point in time. > > I also need to discuss a commonly-reported issue with AR5416 and/or > AR9280 cards (e.g. D-Link DWA-552 running in 802.11g mode w/ WEP) > spitting out "stuck beacon" errors, which are what I was trying to > resolve when the kernel crashed. (I induced the crash, but I'm not sure > exactly why/how). > > Given that the issue has existed for years now... > > http://www.daemonforums.org/showthread.php?t=3388 > http://forums.freebsd.org/showthread.php?t=5983 > http://forum.pfsense.org/index.php?topic=21374.0 > http://forum.pfsense.org/index.php?topic=32041.0 > > http://www.broadbandreports.com/forum/r25070916-FreeBSD-MIPS-dev-Adrian-Chad-on-stuck-beacon-issue > http://forums.freebsd.org/showthread.php?t=22112 (recent & thorough!) > > ...and "bintval 1000" does not solve it, let's work together to find a > solution. If you need hardware I will be more than happy to buy you > (brand new) cards which you can keep. If you have beta/test drivers > and/or can provide *thorough* debugging instructions, I will be more > than happy to do what I can. > > I'll also point out the Linux madwifi folks have an *entire page* > dedicated to this problem, which is quite interesting: > > http://madwifi-project.org/wiki/StuckBeacon > > If a workaround or solution isn't plausible, what cards do people > actually recommend that work reliably / have reliable drivers? I was > under the impression Atheros cards were reliable/decent compared to, > say, Broadcom. Is iwn(4) reliable? > > -- > | 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 | > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Sat Mar 5 16:04:50 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B4053106566B for ; Sat, 5 Mar 2011 16:04:50 +0000 (UTC) (envelope-from byshenknet@byshenk.net) Received: from core.byshenk.net (core.byshenk.net [62.58.73.230]) by mx1.freebsd.org (Postfix) with ESMTP id 417FC8FC08 for ; Sat, 5 Mar 2011 16:04:49 +0000 (UTC) Received: from core.byshenk.net (localhost [127.0.0.1]) by core.byshenk.net (8.14.4/8.14.4) with ESMTP id p25FmH6M081895; Sat, 5 Mar 2011 16:48:17 +0100 (CET) (envelope-from byshenknet@core.byshenk.net) Received: (from byshenknet@localhost) by core.byshenk.net (8.14.4/8.14.4/Submit) id p25FmHoW081894; Sat, 5 Mar 2011 16:48:17 +0100 (CET) (envelope-from byshenknet) Date: Sat, 5 Mar 2011 16:48:17 +0100 From: Greg Byshenk To: Yue Wu Message-ID: <20110305154817.GQ30336@core.byshenk.net> References: <20110305150436.GA2175@fbsd.t60.cpu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110305150436.GA2175@fbsd.t60.cpu> User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on core.byshenk.net Cc: ml-freebsd-stable Subject: Re: Question about packages installed via `pkg_add -r` X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2011 16:04:50 -0000 On Sat, Mar 05, 2011 at 11:04:36PM +0800, Yue Wu wrote: > I'm trying to use package instead of ports these day, but a few > questions have: > > 1. How to reserve packages that fetched via `pkg_add -r`? > > 2. How to know if there are updates for packages, and how to update? For (1), do you mean 'preserve', as in save a copy? If so, then 'portmaster -b [...]' will save a backup copy of installed packages. There may be a better way, but one way to deal with (2) is to have an up-to-date ports tree. Then 'pkg_version -vL=' will show you which of your ports are out of date. Then 'portmaster -PP [...]' will force package use for updates. If you have an up-to-date ports tree, then I think that portmaster -abPP will update all of your ports, using packages, and save a backup copy of the installed versions. -- greg byshenk - gbyshenk@byshenk.net - Leiden, NL From owner-freebsd-stable@FreeBSD.ORG Sat Mar 5 20:43:21 2011 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 DD04F106566C for ; Sat, 5 Mar 2011 20:43:21 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from doug-optiplex.ka9q.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id ADE3A15FF05; Sat, 5 Mar 2011 20:43:21 +0000 (UTC) Message-ID: <4D72A069.90104@FreeBSD.org> Date: Sat, 05 Mar 2011 12:43:21 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.15) Gecko/20110304 Thunderbird/3.1.9 MIME-Version: 1.0 To: Greg Byshenk References: <20110305150436.GA2175@fbsd.t60.cpu> <20110305154817.GQ30336@core.byshenk.net> In-Reply-To: <20110305154817.GQ30336@core.byshenk.net> X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ml-freebsd-stable , Yue Wu Subject: Re: Question about packages installed via `pkg_add -r` X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2011 20:43:22 -0000 On 03/05/2011 07:48, Greg Byshenk wrote: > On Sat, Mar 05, 2011 at 11:04:36PM +0800, Yue Wu wrote: > >> I'm trying to use package instead of ports these day, but a few >> questions have: >> >> 1. How to reserve packages that fetched via `pkg_add -r`? Not sure what you're asking here, can you clarify? >> 2. How to know if there are updates for packages, and how to update? > > There may be a better way, but one way to deal with (2) is to have an > up-to-date ports tree. Then 'pkg_version -vL=' will show you which of > your ports are out of date. Then 'portmaster -PP [...]' will force > package use for updates. > > If you have an up-to-date ports tree, then I think that > > portmaster -abPP The -PP option has to be by itself on the command line, or you can use --packages-only. However portmaster doesn't need a ports tree to operate on packages only. You can use the --index-only --packages-only options and it'll work just fine. You'll want to read the man page before getting started. hth, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-stable@FreeBSD.ORG Sat Mar 5 20:57:51 2011 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 D415B106566C for ; Sat, 5 Mar 2011 20:57:51 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from doug-optiplex.ka9q.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id B3E211525B3; Sat, 5 Mar 2011 20:57:49 +0000 (UTC) Message-ID: <4D72A3CD.2070904@FreeBSD.org> Date: Sat, 05 Mar 2011 12:57:49 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.15) Gecko/20110304 Thunderbird/3.1.9 MIME-Version: 1.0 To: Miroslav Lachman <000.fbsd@quip.cz> References: <6v82n6934o8p7u4vpbde35dbnc41mjd4a5@4ax.com> <4D716CEE.7040106@quip.cz> In-Reply-To: <4D716CEE.7040106@quip.cz> X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Hilko Meyer , freebsd-stable@freebsd.org Subject: Re: service(8) doesn't list dhcpd startscript X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2011 20:57:51 -0000 On 03/04/2011 14:51, Miroslav Lachman wrote: > Hilko Meyer wrote: >> Hi, >> >> today I played a bit with service(8) and I noticed that it doesn't >> properly >> detects the isc-dhcpd-startscript. System is 7.3-RELEASE-p4. 'service >> -l' lists >> isc-dhcpd but 'service -e' doesn't lists it: >> | hilti@kirk:~> service -l | grep dhcp >> | isc-dhcpd >> | hilti@kirk:~> service -e | grep dhcp >> | hilti@kirk:~> /usr/local/etc/rc.d/isc-dhcpd rcvar >> | # dhcpd >> | dhcpd_enable=YES > > It works for me on newer version of the FreeBSD (7.4-RELEASE) and with > newer dhcpd (isc-dhcp41-server-4.1.2_2,1) > > ~/# service -l | grep dhcp > isc-dhcpd > isc-dhcpd6 > > ~/# service -e | grep dhcp > /usr/local/etc/rc.d/isc-dhcpd > /usr/local/etc/rc.d/isc-dhcpd6 > > ~/# /usr/local/etc/rc.d/isc-dhcpd rcvar > # dhcpd > dhcpd_enable=YES > > So you can compare rc scripts for those two versions or compare changes > in service between these two FreeBSD releases. I'm glad to hear that Miroslav was able to make it work. I looked at the code and it's pretty simple, so I'm not sure why it would fail. Hilko, if you can add -x to the end of the #!/bin/sh line in /usr/sbin/service it might give you more of an idea of what's going on. hth, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-stable@FreeBSD.ORG Sat Mar 5 21:15:04 2011 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 6615F106564A for ; Sat, 5 Mar 2011 21:15:04 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from doug-optiplex.ka9q.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 2CD8414E19A; Sat, 5 Mar 2011 21:15:04 +0000 (UTC) Message-ID: <4D72A7D7.4000907@FreeBSD.org> Date: Sat, 05 Mar 2011 13:15:03 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.15) Gecko/20110304 Thunderbird/3.1.9 MIME-Version: 1.0 To: Jilles Tjoelker References: <4D6BD83B.3040609@missouri.edu> <20110304190545.GA38881@stack.nl> In-Reply-To: <20110304190545.GA38881@stack.nl> X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Stable Subject: Re: Change in behavior to stat(1) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2011 21:15:04 -0000 On 03/04/2011 11:05, Jilles Tjoelker wrote: > On Mon, Feb 28, 2011 at 11:15:39AM -0600, Stephen Montgomery-Smith wrote: >> I had a little script that would remove broken links. I used to do it >> like this: > >> if ! stat -L $link> /dev/null; then rm $link; fi > >> But recently (some time in February according to the CVS records) stat >> was changed so that stat -L would use lstat(2) if the link is broken. > >> So I had to change it to > >> if stat -L $link | awk '{print $3}' | grep l> /dev/null; >> then rm $link; fi > >> but it is a lot less elegant. > >> What is the proper accepted way to remove broken links? > > A better answer to your original question was already given, but for > that command, isn't it sufficient to do > > if ! [ -e $link ]; then rm $link; fi > > All test(1)'s primaries that test things about files follow symlinks, > except for -h/-L. I'd do '[ -e "$link" ] || unlink $link' but Jilles is definitely right that simply using 'test -e' is the way to go. Stephen, sorry to hear that the change in behavior to stat(1) was troubling to you. A little bit of the history might be useful. I originally imported stat(1) from NetBSD in 2002, but did not keep up with the improvements that NetBSD made to it. I recently found time to catch up with the work that they've done, and the change to the behavior of readlink seemed like a useful one so I brought it over. hopefully it won't cause too many more problems. :) Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-stable@FreeBSD.ORG Sat Mar 5 22:18:12 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B36DB106566C for ; Sat, 5 Mar 2011 22:18:12 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 74EFA8FC0A for ; Sat, 5 Mar 2011 22:18:12 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEACtFck2DaFvO/2dsb2JhbACEKqMzrW2PdIEng0V2BIUchxQ X-IronPort-AV: E=Sophos;i="4.62,269,1297054800"; d="scan'208";a="113202822" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 05 Mar 2011 17:18:11 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id A860DB3F87; Sat, 5 Mar 2011 17:18:11 -0500 (EST) Date: Sat, 5 Mar 2011 17:18:11 -0500 (EST) From: Rick Macklem To: Kirill Yelizarov Message-ID: <502542028.853830.1299363491630.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <650248.21751.qm@web120514.mail.ne1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.202] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - IE8 (Win)/6.0.10_GA_2692) Cc: freebsd-stable@freebsd.org Subject: Re: NFS client over udp X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2011 22:18:12 -0000 > Rick, > I have good news. I upgraded to 8.2-stable and i ran all four > different tests (nfs client new and old and over udp and tcp) and > found that there is no leak in either. ALl of them behave almost the > same, i couldn't find any difference. The speed i achieved on 1Gb link > is 52Mb/s. The only difference is that i can't umount new nfs client > even if there are no processes using this mount point. Thanks for help > Kirill > Ok, sounds good, although I have no idea what might have plugged the leak. (I looked at the revision log for clnt_dg.c and udp_usrreq.c and I couldn't spot anything that might have fixed an mbuf leak.) As for the "can't unmount", I assume that it reports the mount pt as busy? (I've never seen this for the exp. client, so I have no idea what the cause might be for this. Possibly some "failure" code path that lacks a vput()/vrele() that I've never exercised?) Anyhow, good to hear about the above, rick From owner-freebsd-stable@FreeBSD.ORG Sat Mar 5 23:45:18 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 535FA1065673 for ; Sat, 5 Mar 2011 23:45:18 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [76.96.59.228]) by mx1.freebsd.org (Postfix) with ESMTP id 00D948FC12 for ; Sat, 5 Mar 2011 23:45:17 +0000 (UTC) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta15.westchester.pa.mail.comcast.net with comcast id Fbfp1g00227AodY5FblJxA; Sat, 05 Mar 2011 23:45:18 +0000 Received: from koitsu.dyndns.org ([98.248.33.18]) by omta19.westchester.pa.mail.comcast.net with comcast id FblG1g00C0PUQVN3fblGuk; Sat, 05 Mar 2011 23:45:17 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id C6B459B422; Sat, 5 Mar 2011 15:45:14 -0800 (PST) Date: Sat, 5 Mar 2011 15:45:14 -0800 From: Jeremy Chadwick To: freebsd-stable@freebsd.org Message-ID: <20110305234514.GA34594@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Strange performance issue with grep -r -i as non-root user X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2011 23:45:18 -0000 This is a strange one, and the more I started debugging it (starting with truss, comparing fast vs. slow results, where all that appears different is read() operations are taking a lot longer -- I haven't had time to check with ktrace yet), the more strange it got: that's when I found out the behaviour changes depending on if you're a user or root. Easy to reproduce: - grep -r string /usr/src, as non-root, is fast - grep -r -i string /usr/src, as non-root, is 8x slower than without -i - grep -r string /usr/src, as root, is fast - grep -r -i string /usr/src, as root, is fast $ id uid=1000(jdc) gid=1000(users) groups=1000(users),0(wheel) $ for i in {0..9}; do /usr/bin/time -h grep -r PAE /usr/src/sys/dev > /dev/null ; done 0.17s real 0.11s user 0.05s sys 0.12s real 0.06s user 0.05s sys 0.12s real 0.09s user 0.02s sys 0.12s real 0.07s user 0.04s sys 0.12s real 0.10s user 0.01s sys 0.12s real 0.08s user 0.03s sys 0.12s real 0.07s user 0.04s sys 0.12s real 0.10s user 0.01s sys 0.12s real 0.06s user 0.05s sys 0.12s real 0.07s user 0.04s sys $ for i in {0..9}; do /usr/bin/time -h grep -r -i PAE /usr/src/sys/dev > /dev/null ; done 8.85s real 8.78s user 0.05s sys 8.80s real 8.76s user 0.00s sys 8.82s real 8.77s user 0.01s sys 8.81s real 8.75s user 0.02s sys ^Ctime: command terminated abnormally $ for i in {0..9}; do sudo /usr/bin/time -h grep -r PAE /usr/src/sys/dev > /dev/null ; done 0.19s real 0.11s user 0.08s sys 0.11s real 0.09s user 0.02s sys 0.11s real 0.09s user 0.02s sys 0.11s real 0.07s user 0.04s sys 0.11s real 0.09s user 0.02s sys 0.11s real 0.08s user 0.02s sys 0.11s real 0.07s user 0.04s sys 0.11s real 0.08s user 0.02s sys 0.11s real 0.07s user 0.04s sys 0.11s real 0.07s user 0.04s sys $ for i in {0..9}; do sudo /usr/bin/time -h grep -r -i PAE /usr/src/sys/dev > /dev/null ; done 0.19s real 0.10s user 0.08s sys 0.16s real 0.10s user 0.05s sys 0.13s real 0.08s user 0.05s sys 0.13s real 0.09s user 0.03s sys 0.13s real 0.11s user 0.02s sys 0.13s real 0.10s user 0.03s sys 0.13s real 0.11s user 0.02s sys 0.13s real 0.09s user 0.04s sys 0.13s real 0.09s user 0.03s sys 0.13s real 0.09s user 0.04s sys I can reproduce the issue on 3 different physical machines, with a 4th being completely immune to it (the machine runs a very old 7.0-STABLE, uses i386, and does not use ahci.ko (AHCI->CAM)). It's reproducible at any time (e.g. unrelated to disk I/O), and is unrelated to system uptime. All machines are using UFS2+softupdates for their /usr filesystem, which is where /usr/src lives. All machines use base system gcc and base system grep, which all appear to be gcc version 4.2.1 20070719 and grep (GNU grep) 2.5.1-FreeBSD. Hardware in the machines is slightly different (some with faster CPUs than others, and some use SSDs instead of mechanical HDDs), but the SATA controllers/etc. are all the same (ICH9R). When reading part of the uname string, please trust me when I say that the kernel build time is basically synonymous when with src-all was csup'd. :-) * System #1: FreeBSD 8.2-STABLE #0: Tue Mar 1 00:17:25 PST 2011 amd64 Supermicro X7SBA, 8GB ECC RAM 3:43pm up 1 day, 9:12, 2 users, load averages: 0.06, 0.02, 0.00 ada0: ATA-7 SATA 2.x device Filesystem 1024-blocks Used Avail Capacity Mounted on /dev/ada0s1f 8395622 3376560 4347414 44% /usr make.conf contains: CPUTYPE?=core2 * System #2: FreeBSD 8.2-STABLE #0: Thu Feb 24 22:06:45 PST 2011 amd64 Supermicro PDSMi+, 8GB ECC RAM 3:43pm up 8 days, 15:26, 1 user, load averages: 0.00, 0.00, 0.00 ada0: ATA-8 SATA 2.x device Filesystem 1024-blocks Used Avail Capacity Mounted on /dev/ada0s1f 217798292 2761536 197612894 1% /usr make.conf contains: CPUTYPE?=core2 * System #3: FreeBSD 8.1-STABLE #0: Wed Oct 20 00:54:42 PDT 2010 amd64 Supermicro PDSMi+, 8GB ECC RAM 3:43pm up 136 days, 13:46, 1 user, load averages: 0.02, 0.05, 0.00 ada0: ATA-8 SATA 2.x device Filesystem 1024-blocks Used Avail Capacity Mounted on /dev/ada0s1f 8122126 3043260 4429096 41% /usr make.conf contains: CPUTYPE?=core2 Finally, the box which doesn't exhibit any problems: * System #4: FreeBSD 7.0-STABLE #0: Sat Apr 19 04:52:03 PDT 2008 i386 Supermicro PDSMi+, 8GB ECC RAM (only 4GB usable due to i386) 3:43pm up 341 days, 21:41, 2 users, load averages: 0.00, 0.02, 0.05 ad4: 238475MB at ata2-master SATA300 Filesystem 1024-blocks Used Avail Capacity Mounted on /dev/ad4s1f 32494668 1984234 27910862 7% /usr make.conf contains: CPUTYPE?=nocona There are lots of things I can try to see if I can narrow down the behaviour to a certain piece (such as removing CPUTYPE optimisations), but I wanted to see if others could reproduce this as well. -- | 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 |