From owner-freebsd-current@FreeBSD.ORG Sun Jul 8 00:23:21 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E67C916A400 for ; Sun, 8 Jul 2007 00:23:21 +0000 (UTC) (envelope-from ticso@cicely12.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id 614EC13C480 for ; Sun, 8 Jul 2007 00:23:20 +0000 (UTC) (envelope-from ticso@cicely12.cicely.de) Received: from cicely5.cicely.de ([10.1.1.7]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id l680NJB9019370; Sun, 8 Jul 2007 02:23:19 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (cicely12.cicely.de [10.1.1.14]) by cicely5.cicely.de (8.13.4/8.13.4) with ESMTP id l680NDm2000483 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 8 Jul 2007 02:23:13 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (localhost [127.0.0.1]) by cicely12.cicely.de (8.13.4/8.13.3) with ESMTP id l680NDeZ083275; Sun, 8 Jul 2007 02:23:13 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.13.4/8.13.3/Submit) id l680NCuH083274; Sun, 8 Jul 2007 02:23:12 +0200 (CEST) (envelope-from ticso) Date: Sun, 8 Jul 2007 02:23:12 +0200 From: Bernd Walter To: Volker Message-ID: <20070708002312.GC82285@cicely12.cicely.de> References: <469014E9.5050906@vwsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <469014E9.5050906@vwsoft.com> X-Operating-System: FreeBSD cicely12.cicely.de 5.4-STABLE alpha User-Agent: Mutt/1.5.9i X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED=-1.8, BAYES_00=-2.599 autolearn=ham version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on cicely12.cicely.de Cc: current@freebsd.org Subject: Re: moving a zfs pool X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jul 2007 00:23:22 -0000 On Sun, Jul 08, 2007 at 12:34:17AM +0200, Volker wrote: > Hi, > > this is more likely currently a theoretical question: How does one > move a zfs pool from one machine to another? on old machine: zpool export foo attach disks to new machine on new machine: zpool import foo You can also do zpool import without parameter to list pools available to import. You need to "zpool import -f foo" on the new machine to force the import in case you hadn't exported it on the old machine. > I've done that in the past a lot with ufs filesystems by piping a dump > through an ssh session and restoring on another machine just to move > data to another system. This should also work on a per filesystem > basis when using zfs but isn't there a way to move the whole pool to > another machine (w/o physically moving the hard disk)? > > This would be the case when migrating a machine or migrating hard > disks. The zfs export feature doesn't look promising for this or do I > misread some bits? Please don't tell me, 42 is the answer... ;) You misread :) > I'm missing something I would call 'zpool dump' and 'zpool restore'. There is none :( But you can zfs send/receive at filesystem/volume level. It seems that you can trust the zfs list order on snapshots when copying multiple/all snapshots. Unfortunately things become more complex if you want to save clone data - especially to keep common stored blocks - as well. -- B.Walter http://www.bwct.de http://www.fizon.de bernd@bwct.de info@bwct.de support@fizon.de From owner-freebsd-current@FreeBSD.ORG Sun Jul 8 00:33:25 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 71E0216A468 for ; Sun, 8 Jul 2007 00:33:25 +0000 (UTC) (envelope-from dan@dan.emsphone.com) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.freebsd.org (Postfix) with ESMTP id 3CC2613C468 for ; Sun, 8 Jul 2007 00:33:15 +0000 (UTC) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.14.1/8.13.8) id l680X9NG021777; Sat, 7 Jul 2007 19:33:09 -0500 (CDT) (envelope-from dan) Date: Sat, 7 Jul 2007 19:33:09 -0500 From: Dan Nelson To: Volker Message-ID: <20070708003309.GA58292@dan.emsphone.com> References: <469014E9.5050906@vwsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <469014E9.5050906@vwsoft.com> X-OS: FreeBSD 7.0-CURRENT User-Agent: Mutt/1.5.16 (2007-06-09) Cc: current@freebsd.org Subject: Re: moving a zfs pool X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jul 2007 00:33:25 -0000 In the last episode (Jul 08), Volker said: > this is more likely currently a theoretical question: How does one > move a zfs pool from one machine to another? > > I've done that in the past a lot with ufs filesystems by piping a > dump through an ssh session and restoring on another machine just to > move data to another system. This should also work on a per > filesystem basis when using zfs but isn't there a way to move the > whole pool to another machine (w/o physically moving the hard disk)? > > This would be the case when migrating a machine or migrating hard > disks. The zfs export feature doesn't look promising for this or do I > misread some bits? Please don't tell me, 42 is the answer... ;) > > I'm missing something I would call 'zpool dump' and 'zpool restore'. In zfs, it's actually at the filesystem level: 'zfs send' and 'zfs receive'. Note that it only copies a single filesystem at a time and doesn't copy the properties set via "zfs set", so if you had enabled compression make sure you set it on the new base filesystem before restoring. Those are OpenSolaris bugs 6421958 and 6421959. -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-current@FreeBSD.ORG Sun Jul 8 00:30:15 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5706B16A41F for ; Sun, 8 Jul 2007 00:30:15 +0000 (UTC) (envelope-from xistence@0x58.com) Received: from mailexchange.osnn.net (1e.66.5646.static.theplanet.com [70.86.102.30]) by mx1.freebsd.org (Postfix) with SMTP id 0B2D213C45A for ; Sun, 8 Jul 2007 00:30:14 +0000 (UTC) (envelope-from xistence@0x58.com) Received: (qmail 47700 invoked by uid 0); 7 Jul 2007 23:59:48 -0000 Received: from unknown (HELO ?10.10.10.22?) (xistence@0x58.com@72.208.132.56) by mailexchange.osnn.net with SMTP; 7 Jul 2007 23:59:48 -0000 Mime-Version: 1.0 (Apple Message framework v752.3) To: usb@freebsd.org, hackers@freebsd.org, current@freebsd.org Message-Id: <9496044C-3275-4D9C-8FFF-FD1FCE1F6728@0x58.com> Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-3--612617406; protocol="application/pkcs7-signature" From: Bert JW Regeer Date: Sat, 7 Jul 2007 17:03:32 -0700 X-Mailer: Apple Mail (2.752.3) X-Mailman-Approved-At: Sun, 08 Jul 2007 00:50:52 +0000 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: device rue causes kernel panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jul 2007 00:30:15 -0000 --Apple-Mail-3--612617406 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hello, I have a USB 10/100 FastEthernet device, that is identified as a RealTek device. On 6.2-RELEASE it works without any issues, and some older versions of CURRENT it worked perfectly as well. I csup'ed to CURRENT today (2007-07-07 at 16:30 MST), rebuild my kernel and it failed, so I grabbed the hard drive, made a copy into a VMWare image, recompiled the same CURRENT with debugging enabled, and retrieved the following backtrace from kgdb from a secondary VMWare running FreeBSD 6.2-RELEASE with kgdb: (kgdb) bt #0 kdb_enter (msg=0xc0a90fed "panic") at /usr/src/sys/kern/ subr_kdb.c:310 #1 0xc074b9b4 in panic (fmt=0xc0a94933 "Trying sleep, but thread marked as sleeping prohibited") at /usr/src/sys/kern/kern_shutdown.c:547 #2 0xc077a912 in sleepq_add (wchan=0xc2322c00, lock=0x0, wmesg=0xc0a85dc8 "usbsyn", flags=0, queue=0) at /usr/src/sys/kern/subr_sleepqueue.c:289 #3 0xc0753d33 in _sleep (ident=0xc2322c00, lock=Variable "lock" is not available. ) at /usr/src/sys/kern/kern_synch.c:201 #4 0xc06cc498 in usbd_transfer (xfer=0xc2322c00) at /usr/src/sys/dev/ usb/usbdi.c:333 #5 0xc06cc5e6 in usbd_sync_transfer (xfer=0xc2322c00) at /usr/src/ sys/dev/usb/usbdi.c:406 #6 0xc06cc678 in usbd_do_request_flags_pipe (dev=0xc2275300, pipe=0xc2275100, req=0xcbd46bb8, data=0xcbd46bd3, flags=Variable "flags" is not available. ) at /usr/src/sys/dev/usb/usbdi.c:1098 #7 0xc06cc7cc in usbd_do_request_flags (dev=0xc2275300, req=0xcbd46bb8, data=0xcbd46bd3, flags=Variable "flags" is not available. ) at /usr/src/sys/dev/usb/usbdi.c:1068 #8 0xc06cc807 in usbd_do_request (dev=0xc2275300, req=0xcbd46bb8, data=0xcbd46bd3) at /usr/src/sys/dev/usb/usbdi.c:1060 #9 0xc06ae924 in rue_read_mem (sc=0xc2264d00, addr=Variable "addr" is not available. ) at /usr/src/sys/dev/usb/if_rue.c:227 #10 0xc06ae9cc in rue_csr_read_1 (sc=Variable "sc" is not available. ) at /usr/src/sys/dev/usb/if_rue.c:276 #11 0xc06aea47 in rue_miibus_readreg (dev=0xc2275080, phy=0, reg=311) at /usr/src/sys/dev/usb/if_rue.c:376 #12 0xc05f01eb in miibus_readreg (dev=0xc2274d00, phy=0, reg=311) at miibus_if.h:26 #13 0xc05f5b6e in ruephy_service (sc=0xc2278440, mii=0xc2278d00, cmd=1) at miibus_if.h:26 #14 0xc05efc14 in mii_tick (mii=0xc2278d00) at /usr/src/sys/dev/mii/ mii.c:390 #15 0xc06aef53 in rue_tick (xsc=0xc2264d00) at /usr/src/sys/dev/usb/ if_rue.c:935 #16 0xc075d229 in softclock (dummy=0x0) at /usr/src/sys/kern/ kern_timeout.c:281 #17 0xc0730905 in ithread_loop (arg=0xc21152b0) at /usr/src/sys/kern/ kern_intr.c:1036 #18 0xc072dd88 in fork_exit (callout=0xc0730750 , arg=0xc21152b0, frame=0xcbd46d38) at /usr/src/sys/kern/kern_fork.c:797 #19 0xc09e0820 in fork_trampoline () at /usr/src/sys/i386/i386/ exception.s:205 Steps to reproduce: 1. Plug in a rue device 2. plug in a cable so that it's status is active 3. ifconfig rue0 up 4. Wait for the kernel to panic about a second or so later If there is anything else you guys need me to do, please let me know and I will see what I can do. Bert JW Regeer p.s. I am not on the current@freebsd.org mailling list, please CC all replies to me. --Apple-Mail-3--612617406-- From owner-freebsd-current@FreeBSD.ORG Sun Jul 8 01:21:42 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3F8D116A41F for ; Sun, 8 Jul 2007 01:21:42 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id E81DB13C480 for ; Sun, 8 Jul 2007 01:21:41 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from phobos.samsco.home (phobos.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.8/8.13.8) with ESMTP id l681LWWD069636; Sat, 7 Jul 2007 19:21:34 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <46903C19.2040002@samsco.org> Date: Sat, 07 Jul 2007 19:21:29 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.4) Gecko/20070509 SeaMonkey/1.1.2 MIME-Version: 1.0 To: Kostik Belousov References: <20070703180141.GJ2200@deviant.kiev.zoral.com.ua> <20070705144443.GV2200@deviant.kiev.zoral.com.ua> <20070707160042.GJ2200@deviant.kiev.zoral.com.ua> In-Reply-To: <20070707160042.GJ2200@deviant.kiev.zoral.com.ua> X-Enigmail-Version: 0.95.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (pooker.samsco.org [168.103.85.57]); Sat, 07 Jul 2007 19:21:35 -0600 (MDT) X-Spam-Status: No, score=-1.4 required=5.5 tests=ALL_TRUSTED autolearn=failed version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: Tai-hwa Liang , Jiawei Ye , current@freebsd.org Subject: Re: HEADS UP: destroy_dev_sched() KPI in the tree X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jul 2007 01:21:42 -0000 Kostik Belousov wrote: > On Sat, Jul 07, 2007 at 08:36:23PM +0800, Jiawei Ye wrote: >> On 7/5/07, Kostik Belousov wrote: >>> Today, I reverted the part of commit that tried to transform destroy_dev() >> >from d_close() into destroy_dev_sched(). See kern_conf.c, rev. 1.208. >>> You shall call destroy_dev_sched() explicitely. >>> >>> >> Does this mean that mount_smbfs has to explicitly call it now? It is >> currently stuck in the devdrn state with the latest kernel :( >> >> Jiawei Ye > Exactly. Patch by Tai-hwa Liang is pending. I also remember that sg(4) > had the same problem, but I do not know it current status. Which driver is sg(4)? If you're talking about scsi_sg, it's not affected by the problem. scsi_targ is/was, I haven't checked to see if it was fixed yet. Scott From owner-freebsd-current@FreeBSD.ORG Sun Jul 8 02:04:17 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3C14C16A400; Sun, 8 Jul 2007 02:04:17 +0000 (UTC) (envelope-from scf@FreeBSD.org) Received: from mail.farley.org (farley.org [67.64.95.201]) by mx1.freebsd.org (Postfix) with ESMTP id CF2E513C465; Sun, 8 Jul 2007 02:04:16 +0000 (UTC) (envelope-from scf@FreeBSD.org) Received: from thor.farley.org (thor.farley.org [192.168.1.5]) by mail.farley.org (8.14.1/8.14.1) with ESMTP id l6825QYe084986; Sat, 7 Jul 2007 21:05:26 -0500 (CDT) (envelope-from scf@FreeBSD.org) Date: Sat, 7 Jul 2007 21:03:59 -0500 (CDT) From: "Sean C. Farley" To: Andrey Chernov In-Reply-To: <20070707191835.GA4368@nagual.pp.ru> Message-ID: <20070707205410.B14065@thor.farley.org> References: <20070704180000.GA34042@nagual.pp.ru> <20070704144159.X77978@thor.farley.org> <20070704195939.GA35302@nagual.pp.ru> <20070704235630.GA42227@nagual.pp.ru> <20070704215154.O77978@thor.farley.org> <20070705115816.GA50506@nagual.pp.ru> <20070705105922.F98700@thor.farley.org> <20070707130859.GA96605@nagual.pp.ru> <20070707131359.GB96605@nagual.pp.ru> <20070707133102.C14065@thor.farley.org> <20070707191835.GA4368@nagual.pp.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.1 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on mail.farley.org Cc: freebsd-current , Robert Watson , Michal Mertl Subject: Re: Environment handling broken in /bin/sh with changes to {get,set,put}env() X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jul 2007 02:04:17 -0000 On Sat, 7 Jul 2007, Andrey Chernov wrote: > On Sat, Jul 07, 2007 at 01:51:11PM -0500, Sean C. Farley wrote: >> I agree that it would be faster for a subset of an existing environ. >> On the other hand, in the case of emptying the environment, my method >> would be faster since no deallocation, allocation nor setenv() calls >> would be called assuming putenv() was not used. I could try a few >> tests to see what is faster in which case, but I do not think environ >> changes happen often enough to make speed a factor. > > Well, lets go with that. I ran the tests out of curiosity. All code is here[1]. The dropping was effectively freeing envVars and the environ that getenv.c creates for the program. All other counters were set to zero. The first test (timing-clear.c) cleared the environment by swapping two char ** arrays containing a single NULL pointer. 500000 iterations. x drop/clear-timings.txt + keep/clear-timings.txt N Min Max Median Avg Stddev x 50 1.634899 1.672082 1.656838 1.6567984 0.0093033009 + 50 1.326203 1.348855 1.3296575 1.3323876 0.0062632107 Difference at 95.0% confidence -0.324411 +/- 0.00314674 -19.5806% +/- 0.189929% (Student's t, pooled s = 0.0079303) The second test (timing-merge.c) swapped two duplicates of my environment over 5000 iterations. x drop/merge-timings.txt + keep/merge-timings.txt N Min Max Median Avg Stddev x 50 1.337052 1.406142 1.3663635 1.3634524 0.015210835 + 50 0.889559 0.913354 0.8943785 0.89644634 0.0056274351 Difference at 95.0% confidence -0.467006 +/- 0.00455057 -34.2517% +/- 0.333753% (Student's t, pooled s = 0.0114682) Surprisingly, keeping the pointers saved time even if calling setenv(). Sean 1. http://www.farley.org/freebsd/tmp/setenv/clearenv/ -- scf@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Sun Jul 8 02:04:52 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 79A9B16A41F for ; Sun, 8 Jul 2007 02:04:52 +0000 (UTC) (envelope-from sepherosa@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.240]) by mx1.freebsd.org (Postfix) with ESMTP id 3245F13C45B for ; Sun, 8 Jul 2007 02:04:52 +0000 (UTC) (envelope-from sepherosa@gmail.com) Received: by an-out-0708.google.com with SMTP id c14so132557anc for ; Sat, 07 Jul 2007 19:04:51 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=XfBFffQWwAHChJtZhMf2Z+rcSCHp4d3VoSHXCmaySENraJBOiWxQuCm7Gyqj0o+0YAITTH/1JZDx1XeJEJgsxB7f1mxk/nthX0VQb5qgP5apZhS8er5FdGah5lG9f/uF27wSIs8hQQjA1LeSq877MagGUZbKONaDtHw2SOUbcBk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=a/uV5zDDWMZMuv6T8Acq2nfVnMsu4M/TMkx/s8+LGTCHrm0hyKyDx8BTNopXYahQgYYi7w/CFv0kNnktKh3F1N1YeiQ4mX86Y6OMrgDLnt1Y3Fv1ArqmnE0VcyscccVOPWhLSQ1K0FYhdN6NF9saMscowhx8V5od+8jRGLO61iM= Received: by 10.100.37.4 with SMTP id k4mr1007639ank.1183860291371; Sat, 07 Jul 2007 19:04:51 -0700 (PDT) Received: by 10.100.47.20 with HTTP; Sat, 7 Jul 2007 19:04:51 -0700 (PDT) Message-ID: Date: Sun, 8 Jul 2007 10:04:51 +0800 From: "Sepherosa Ziehau" To: "Kevin Gerry" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <468488B3.7010607@errno.com> <46848C1E.2080404@errno.com> Cc: freebsd-current@freebsd.org Subject: Re: Wireless NICs not obeying 'SSID' setting. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jul 2007 02:04:52 -0000 On 7/5/07, Kevin Gerry wrote: > Weird, one of the issues it appears I'm having is that when it's set to > -bgscan and roaming device, the device will just get stuck on "no carrier" Please leave bgscan and roaming on and run following command: wlandebug -i ral0 +roam wlandebug -i ath0 +roam Post the log, when the AP switching happened. Best Regards, sephe -- Live Free or Die From owner-freebsd-current@FreeBSD.ORG Sun Jul 8 02:09:42 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6839016A473; Sun, 8 Jul 2007 02:09:42 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (nagual.pp.ru [194.87.13.69]) by mx1.freebsd.org (Postfix) with ESMTP id C2E4813C455; Sun, 8 Jul 2007 02:09:41 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.14.1/8.14.1) with ESMTP id l6829e9W080194; Sun, 8 Jul 2007 06:09:40 +0400 (MSD) (envelope-from ache@nagual.pp.ru) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nagual.pp.ru; s=default; t=1183860580; bh=KlHmMIf1IZn4a12ps8Auz8aNb/DDNr7BdZfKrUF dWZg=; l=214; h=Received:Date:From:To:Cc:Subject:Message-ID: Mail-Followup-To:References:MIME-Version:Content-Type: Content-Disposition:In-Reply-To:User-Agent; b=NuJ1kOOW7GAnSUnALsVw o5i6OokFjnrdXxunzCUyHHWUFEIK3EXOcoyMbqcxLE21o/erO5V9ZmcFzSnqapR9+kg grNY9glp5fTAUFjw/EUm87AkBLPfshpjYQjFtH3AmtkKN/QsAtMT6G2MT4xCMMmt9w0 hWmf+bFyiR/0Z6IV0= Received: (from ache@localhost) by nagual.pp.ru (8.14.1/8.14.1/Submit) id l6829eDS080193; Sun, 8 Jul 2007 06:09:40 +0400 (MSD) (envelope-from ache) Date: Sun, 8 Jul 2007 06:09:40 +0400 From: Andrey Chernov To: "Sean C. Farley" Message-ID: <20070708020940.GA80166@nagual.pp.ru> Mail-Followup-To: Andrey Chernov , "Sean C. Farley" , Robert Watson , freebsd-current , Michal Mertl References: <20070704195939.GA35302@nagual.pp.ru> <20070704235630.GA42227@nagual.pp.ru> <20070704215154.O77978@thor.farley.org> <20070705115816.GA50506@nagual.pp.ru> <20070705105922.F98700@thor.farley.org> <20070707130859.GA96605@nagual.pp.ru> <20070707131359.GB96605@nagual.pp.ru> <20070707133102.C14065@thor.farley.org> <20070707191835.GA4368@nagual.pp.ru> <20070707205410.B14065@thor.farley.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070707205410.B14065@thor.farley.org> User-Agent: Mutt/1.5.16 (2007-06-09) Cc: freebsd-current , Robert Watson , Michal Mertl Subject: Re: Environment handling broken in /bin/sh with changes to {get,set,put}env() X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jul 2007 02:09:42 -0000 On Sat, Jul 07, 2007 at 09:03:59PM -0500, Sean C. Farley wrote: > > Surprisingly, keeping the pointers saved time even if calling setenv(). Ok. It feels like time to commit comes :) -- http://ache.pp.ru/ From owner-freebsd-current@FreeBSD.ORG Sun Jul 8 02:19:35 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A010616A400 for ; Sun, 8 Jul 2007 02:19:35 +0000 (UTC) (envelope-from avatar@mmlab.cse.yzu.edu.tw) Received: from www.mmlab.cse.yzu.edu.tw (www.mmlab.cse.yzu.edu.tw [140.138.150.166]) by mx1.freebsd.org (Postfix) with ESMTP id 6370C13C44B for ; Sun, 8 Jul 2007 02:19:35 +0000 (UTC) (envelope-from avatar@mmlab.cse.yzu.edu.tw) Received: by www.mmlab.cse.yzu.edu.tw (qmail, from userid 1000) id CE3098C9D30; Sun, 8 Jul 2007 09:47:41 +0800 (CST) Received: from localhost (localhost [127.0.0.1]) by www.mmlab.cse.yzu.edu.tw (qmail) with ESMTP id 958178C9D1E; Sun, 8 Jul 2007 09:47:41 +0800 (CST) Date: Sun, 8 Jul 2007 09:47:41 +0800 (CST) From: Tai-hwa Liang To: Kostik Belousov In-Reply-To: <20070707160042.GJ2200@deviant.kiev.zoral.com.ua> Message-ID: <07070809441413.59322@www.mmlab.cse.yzu.edu.tw> References: <20070703180141.GJ2200@deviant.kiev.zoral.com.ua> <20070705144443.GV2200@deviant.kiev.zoral.com.ua> <20070707160042.GJ2200@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-288813517-1183859261=:59322" Cc: Jiawei Ye , current@freebsd.org Subject: Re: HEADS UP: destroy_dev_sched() KPI in the tree X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jul 2007 02:19:35 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-288813517-1183859261=:59322 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed On Sat, 7 Jul 2007, Kostik Belousov wrote: > On Sat, Jul 07, 2007 at 08:36:23PM +0800, Jiawei Ye wrote: >> On 7/5/07, Kostik Belousov wrote: >>> >>> Today, I reverted the part of commit that tried to transform destroy_dev() >>> from d_close() into destroy_dev_sched(). See kern_conf.c, rev. 1.208. >>> You shall call destroy_dev_sched() explicitely. >>> >>> >> Does this mean that mount_smbfs has to explicitly call it now? It is >> currently stuck in the devdrn state with the latest kernel :( >> >> Jiawei Ye > Exactly. Patch by Tai-hwa Liang is pending. I also remember that sg(4) I'll ask for re@'s approval tomorrow. Hopefully the new KPI would have more exposure before my patch is committed. > had the same problem, but I do not know it current status. Though it was reviewed before destroy_dev_sched() KPI enters to the tree, I'd be appreciate it if you can reviewed the attached patch again. -- Cheers, Tai-hwa Liang --0-288813517-1183859261=:59322 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=scsi_target.c.patch Content-Transfer-Encoding: BASE64 Content-ID: <070708094741C.59322@www.mmlab.cse.yzu.edu.tw> Content-Description: Content-Disposition: attachment; filename=scsi_target.c.patch LS0tIGNhbS9zY3NpL3Njc2lfdGFyZ2V0LmMub3JpZwlXZWQgTWF5ICAyIDEx OjQyOjQ2IDIwMDcNCisrKyBjYW0vc2NzaS9zY3NpX3RhcmdldC5jCVdlZCBN YXkgIDIgMTE6NDM6MTEgMjAwNw0KQEAgLTIxMCw3ICsyMTAsNyBAQCB0YXJn Y2xvc2Uoc3RydWN0IGNkZXYgKmRldiwgaW50IGZsYWcsIGluDQogCXNvZnRj ID0gKHN0cnVjdCB0YXJnX3NvZnRjICopZGV2LT5zaV9kcnYxOw0KIAlpZiAo KHNvZnRjLT5wZXJpcGggPT0gTlVMTCkgfHwNCiAJICAgIChzb2Z0Yy0+c3Rh dGUgJiBUQVJHX1NUQVRFX0xVTl9FTkFCTEVEKSA9PSAwKSB7DQotCQlkZXN0 cm95X2RldihkZXYpOw0KKwkJZGVzdHJveV9kZXZfc2NoZWQoZGV2KTsNCiAJ CUZSRUUoc29mdGMsIE1fVEFSRyk7DQogCQlyZXR1cm4gKDApOw0KIAl9DQpA QCAtMjI5LDcgKzIyOSw3IEBAIHRhcmdjbG9zZShzdHJ1Y3QgY2RldiAqZGV2 LCBpbnQgZmxhZywgaW4NCiAJCQljYW1fcGVyaXBoX2ludmFsaWRhdGUoc29m dGMtPnBlcmlwaCk7DQogCQkJc29mdGMtPnBlcmlwaCA9IE5VTEw7DQogCQl9 DQotCQlkZXN0cm95X2RldihkZXYpOw0KKwkJZGVzdHJveV9kZXZfc2NoZWQo ZGV2KTsNCiAJCUZSRUUoc29mdGMsIE1fVEFSRyk7DQogCX0NCiAJY2FtX3Bl cmlwaF91bmxvY2socGVyaXBoKTsNCg== --0-288813517-1183859261=:59322-- From owner-freebsd-current@FreeBSD.ORG Sun Jul 8 02:48:29 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5F36D16A400 for ; Sun, 8 Jul 2007 02:48:29 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from relay02.kiev.sovam.com (relay02.kiev.sovam.com [62.64.120.197]) by mx1.freebsd.org (Postfix) with ESMTP id E4DE813C45B for ; Sun, 8 Jul 2007 02:48:28 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from [89.162.146.170] (helo=skuns.kiev.zoral.com.ua) by relay02.kiev.sovam.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1I7Moy-000NeA-R2 for current@freebsd.org; Sun, 08 Jul 2007 05:48:27 +0300 Received: from deviant.kiev.zoral.com.ua (root@[10.1.1.148]) by skuns.kiev.zoral.com.ua (8.14.1/8.14.1) with ESMTP id l682mGXD045293 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 8 Jul 2007 05:48:17 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.1/8.14.1) with ESMTP id l682mGQ1037589; Sun, 8 Jul 2007 05:48:16 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.1/8.14.1/Submit) id l682mFXK037588; Sun, 8 Jul 2007 05:48:15 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 8 Jul 2007 05:48:15 +0300 From: Kostik Belousov To: Tai-hwa Liang Message-ID: <20070708024815.GK2200@deviant.kiev.zoral.com.ua> References: <20070703180141.GJ2200@deviant.kiev.zoral.com.ua> <20070705144443.GV2200@deviant.kiev.zoral.com.ua> <20070707160042.GJ2200@deviant.kiev.zoral.com.ua> <07070809441413.59322@www.mmlab.cse.yzu.edu.tw> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="YhYebsMuj/FQeBW/" Content-Disposition: inline In-Reply-To: <07070809441413.59322@www.mmlab.cse.yzu.edu.tw> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.90.3, clamav-milter version 0.90.3 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.2.1 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on skuns.kiev.zoral.com.ua X-Scanner-Signature: c6fa9c03b00bb8e85b0a425727b89505 X-DrWeb-checked: yes X-SpamTest-Envelope-From: kostikbel@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Header: Not Detected X-SpamTest-Info: Profiles 1190 [July 06 2007] X-SpamTest-Info: helo_type=3 X-SpamTest-Method: none X-SpamTest-Rate: 0 X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0255], KAS30/Release Cc: Kostik Belousov , Jiawei Ye , current@freebsd.org Subject: Re: HEADS UP: destroy_dev_sched() KPI in the tree X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jul 2007 02:48:29 -0000 --YhYebsMuj/FQeBW/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jul 08, 2007 at 09:47:41AM +0800, Tai-hwa Liang wrote: > On Sat, 7 Jul 2007, Kostik Belousov wrote: > >On Sat, Jul 07, 2007 at 08:36:23PM +0800, Jiawei Ye wrote: > >>On 7/5/07, Kostik Belousov wrote: > >>> > >>>Today, I reverted the part of commit that tried to transform=20 > >>>destroy_dev() > >>>from d_close() into destroy_dev_sched(). See kern_conf.c, rev. 1.208. > >>>You shall call destroy_dev_sched() explicitely. > >>> > >>> > >>Does this mean that mount_smbfs has to explicitly call it now? It is > >>currently stuck in the devdrn state with the latest kernel :( > >> > >>Jiawei Ye > >Exactly. Patch by Tai-hwa Liang is pending. I also remember that sg(4) >=20 > I'll ask for re@'s approval tomorrow. Hopefully the new KPI would have > more exposure before my patch is committed. >=20 > >had the same problem, but I do not know it current status. >=20 > Though it was reviewed before destroy_dev_sched() KPI enters to the tre= e, > I'd be appreciate it if you can reviewed the attached patch again. So, this is still the problem for scsi_targ ? It probably make sense to postpone free of softc until all threads finished using it. You may use destroy_dev_sched_cb() to run the function after the device is actually destroyed. It would just call free(). >=20 > --=20 > Cheers, >=20 > Tai-hwa Liang > --- cam/scsi/scsi_target.c.orig Wed May 2 11:42:46 2007 > +++ cam/scsi/scsi_target.c Wed May 2 11:43:11 2007 > @@ -210,7 +210,7 @@ targclose(struct cdev *dev, int flag, in > softc =3D (struct targ_softc *)dev->si_drv1; > if ((softc->periph =3D=3D NULL) || > (softc->state & TARG_STATE_LUN_ENABLED) =3D=3D 0) { > - destroy_dev(dev); > + destroy_dev_sched(dev); > FREE(softc, M_TARG); > return (0); > } > @@ -229,7 +229,7 @@ targclose(struct cdev *dev, int flag, in > cam_periph_invalidate(softc->periph); > softc->periph =3D NULL; > } > - destroy_dev(dev); > + destroy_dev_sched(dev); > FREE(softc, M_TARG); > } > cam_periph_unlock(periph); --YhYebsMuj/FQeBW/ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGkFBuC3+MBN1Mb4gRAqP3AKC2kvzmi5lrEM+BeO/z/5Nb47oW3QCg9KyY q5VX0+uqTTImA6IaXzninaU= =jlIc -----END PGP SIGNATURE----- --YhYebsMuj/FQeBW/-- From owner-freebsd-current@FreeBSD.ORG Sun Jul 8 04:02:43 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 85D1216A47B; Sun, 8 Jul 2007 04:02:42 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 3B09C13C455; Sun, 8 Jul 2007 04:02:42 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.13.8/8.13.4) with ESMTP id l6841Lak099270; Sat, 7 Jul 2007 22:01:21 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sat, 07 Jul 2007 22:02:03 -0600 (MDT) Message-Id: <20070707.220203.776519881.imp@bsdimp.com> To: xistence@0x58.com From: "M. Warner Losh" In-Reply-To: <9496044C-3275-4D9C-8FFF-FD1FCE1F6728@0x58.com> References: <9496044C-3275-4D9C-8FFF-FD1FCE1F6728@0x58.com> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Sat, 07 Jul 2007 22:01:21 -0600 (MDT) Cc: usb@freebsd.org, hackers@freebsd.org, current@freebsd.org Subject: Re: device rue causes kernel panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jul 2007 04:02:44 -0000 In message: <9496044C-3275-4D9C-8FFF-FD1FCE1F6728@0x58.com> Bert JW Regeer writes: : I have a USB 10/100 FastEthernet device, that is identified as a : RealTek device. On 6.2-RELEASE it works without any issues, and some : older versions of CURRENT it worked perfectly as well. I csup'ed to : CURRENT today (2007-07-07 at 16:30 MST), rebuild my kernel and it : failed: : panic (fmt=0xc0a94933 "Trying sleep, but thread marked as sleeping prohibited") : _sleep (ident=0xc2322c00...) at /usr/src/sys/kern/kern_synch.c:201 : usbd_transfer (xfer=0xc2322c00) at /usr/src/sys/dev/usb/usbdi.c:333 : usbd_sync_transfer (xfer=0xc2322c00) at /usr/src/sys/dev/usb/usbdi.c:406 : usbd_do_request_flags_pipe ... at /usr/src/sys/dev/usb/usbdi.c:1098 : usbd_do_request_flags ...at /usr/src/sys/dev/usb/usbdi.c:1068 : usbd_do_request at /usr/src/sys/dev/usb/usbdi.c:1060 : rue_read_mem at /usr/src/sys/dev/usb/if_rue.c:227 : rue_csr_read_1 at /usr/src/sys/dev/usb/if_rue.c:276 : rue_miibus_readreg at /usr/src/sys/dev/usb/if_rue.c:376 ... : ruephy_service at miibus_if.h:26 /* Likely wrong */ : mii_tick at /usr/src/sys/dev/mii/mii.c:390 : rue_tick at /usr/src/sys/dev/usb/if_rue.c:935 : softclock at /usr/src/sys/kern/kern_timeout.c:281 ... This driver needs to be re-written ala aue, axe, kue and udav to use a taskqueue for the mii ticking. It appears to be the only usb driver in the tree to still do stuff directly in a callout. This context can't sleep... Warner From owner-freebsd-current@FreeBSD.ORG Sun Jul 8 04:14:42 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6A04216A421; Sun, 8 Jul 2007 04:14:42 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 1014513C480; Sun, 8 Jul 2007 04:14:41 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.13.8/8.13.4) with ESMTP id l684E2lt099333; Sat, 7 Jul 2007 22:14:02 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sat, 07 Jul 2007 22:14:44 -0600 (MDT) Message-Id: <20070707.221444.-1816826594.imp@bsdimp.com> To: xistence@0x58.com From: "M. Warner Losh" In-Reply-To: <20070707.220203.776519881.imp@bsdimp.com> References: <9496044C-3275-4D9C-8FFF-FD1FCE1F6728@0x58.com> <20070707.220203.776519881.imp@bsdimp.com> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Sat_Jul__7_22_14_44_2007_946)--" Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Sat, 07 Jul 2007 22:14:03 -0600 (MDT) Cc: usb@freebsd.org, hackers@freebsd.org, current@freebsd.org Subject: Re: device rue causes kernel panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jul 2007 04:14:42 -0000 ----Next_Part(Sat_Jul__7_22_14_44_2007_946)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit In message: <20070707.220203.776519881.imp@bsdimp.com> "M. Warner Losh" writes: : In message: <9496044C-3275-4D9C-8FFF-FD1FCE1F6728@0x58.com> : Bert JW Regeer writes: : : I have a USB 10/100 FastEthernet device, that is identified as a : : RealTek device. On 6.2-RELEASE it works without any issues, and some : : older versions of CURRENT it worked perfectly as well. I csup'ed to : : CURRENT today (2007-07-07 at 16:30 MST), rebuild my kernel and it : : failed: : : panic (fmt=0xc0a94933 "Trying sleep, but thread marked as sleeping prohibited") : : _sleep (ident=0xc2322c00...) at /usr/src/sys/kern/kern_synch.c:201 : : usbd_transfer (xfer=0xc2322c00) at /usr/src/sys/dev/usb/usbdi.c:333 : : usbd_sync_transfer (xfer=0xc2322c00) at /usr/src/sys/dev/usb/usbdi.c:406 : : usbd_do_request_flags_pipe ... at /usr/src/sys/dev/usb/usbdi.c:1098 : : usbd_do_request_flags ...at /usr/src/sys/dev/usb/usbdi.c:1068 : : usbd_do_request at /usr/src/sys/dev/usb/usbdi.c:1060 : : rue_read_mem at /usr/src/sys/dev/usb/if_rue.c:227 : : rue_csr_read_1 at /usr/src/sys/dev/usb/if_rue.c:276 : : rue_miibus_readreg at /usr/src/sys/dev/usb/if_rue.c:376 : ... : : ruephy_service at miibus_if.h:26 /* Likely wrong */ : : mii_tick at /usr/src/sys/dev/mii/mii.c:390 : : rue_tick at /usr/src/sys/dev/usb/if_rue.c:935 : : softclock at /usr/src/sys/kern/kern_timeout.c:281 : ... : : This driver needs to be re-written ala aue, axe, kue and udav to use a : taskqueue for the mii ticking. It appears to be the only usb driver : in the tree to still do stuff directly in a callout. This context : can't sleep... You might try this patch. Warner ----Next_Part(Sat_Jul__7_22_14_44_2007_946)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="rue-task.diff" Index: if_rue.c =================================================================== RCS file: /cache/ncvs/src/sys/dev/usb/if_rue.c,v retrieving revision 1.39 diff -u -r1.39 if_rue.c --- if_rue.c 20 Jun 2007 05:10:52 -0000 1.39 +++ if_rue.c 8 Jul 2007 04:13:16 -0000 @@ -142,6 +142,7 @@ static void rue_rxeof(usbd_xfer_handle, usbd_private_handle, usbd_status); static void rue_txeof(usbd_xfer_handle, usbd_private_handle, usbd_status); static void rue_tick(void *); +static void rue_tick_task(void *); static void rue_rxstart(struct ifnet *); static void rue_start(struct ifnet *); static int rue_ioctl(struct ifnet *, u_long, caddr_t); @@ -594,6 +595,8 @@ goto error; } + usb_init_task(&sc->rue_tick_task, rue_tick_task, sc); + err = usbd_device2interface_handle(uaa->device, RUE_IFACE_IDX, &iface); if (err) { device_printf(sc->rue_dev, "getting interface handle failed\n"); @@ -704,6 +707,7 @@ sc->rue_dying = 1; untimeout(rue_tick, sc, sc->rue_stat_ch); + usb_rem_task(sc->rue_udev, &sc->rue_tick_task); ether_ifdetach(ifp); if_free(ifp); @@ -916,6 +920,20 @@ static void rue_tick(void *xsc) { + struct rue_softc *sc = xsc; + + if (sc == NULL) + return; + if (sc->rue_dying) + return; + + /* Perform periodic stuff in process context */ + usb_add_task(sc->rue_udev, &sc->rue_tick_task, USB_TASKQ_DRIVER); +} + +static void +rue_tick_task(void *xsc) +{ struct rue_softc *sc = xsc; struct ifnet *ifp; struct mii_data *mii; Index: if_ruereg.h =================================================================== RCS file: /cache/ncvs/src/sys/dev/usb/if_ruereg.h,v retrieving revision 1.7 diff -u -r1.7 if_ruereg.h --- if_ruereg.h 12 May 2007 05:53:53 -0000 1.7 +++ if_ruereg.h 8 Jul 2007 04:11:39 -0000 @@ -204,6 +204,7 @@ char rue_dying; struct timeval rue_rx_notice; struct usb_qdat rue_qdat; + struct usb_task rue_tick_task; }; #if defined(__FreeBSD__) ----Next_Part(Sat_Jul__7_22_14_44_2007_946)---- From owner-freebsd-current@FreeBSD.ORG Sun Jul 8 05:23:42 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0823516A400 for ; Sun, 8 Jul 2007 05:23:42 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id A33A713C45A for ; Sun, 8 Jul 2007 05:23:41 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.13.8/8.13.4) with ESMTP id l685M9rX099737; Sat, 7 Jul 2007 23:22:10 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sat, 07 Jul 2007 23:22:51 -0600 (MDT) Message-Id: <20070707.232251.514355592.imp@bsdimp.com> To: paul.eskello@gmail.com From: "M. Warner Losh" In-Reply-To: <8cdf6c720707070710k2b7e030v37683e460d983bf9@mail.gmail.com> References: <8cdf6c720707070710k2b7e030v37683e460d983bf9@mail.gmail.com> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Sat, 07 Jul 2007 23:22:10 -0600 (MDT) Cc: freebsd-current@freebsd.org Subject: Re: status of 7.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jul 2007 05:23:42 -0000 In message: <8cdf6c720707070710k2b7e030v37683e460d983bf9@mail.gmail.com> "Paul Eskello" writes: : I was wondering when to expect 7.0 release ? Did I miss the schedule. : Any showstoppers ? when to expect RC1 ? We're in code freeze, waiting to cut our first Beta, due soonish. I'm not sure that dates are nailed down yet. You haven't missed anything. Warner From owner-freebsd-current@FreeBSD.ORG Sun Jul 8 05:46:36 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1FFD216A400 for ; Sun, 8 Jul 2007 05:46:36 +0000 (UTC) (envelope-from SRS0=f55d90be45149520e9e8868af534c1b966808ae0=389=es.net=oberman@es.net) Received: from postal1.es.net (postal1.es.net [198.128.3.205]) by mx1.freebsd.org (Postfix) with ESMTP id 0786C13C44C for ; Sun, 8 Jul 2007 05:46:35 +0000 (UTC) (envelope-from SRS0=f55d90be45149520e9e8868af534c1b966808ae0=389=es.net=oberman@es.net) Received: from ptavv.es.net (ptavv.es.net [198.128.4.29]) by postal1.es.net (Postal Node 1) with ESMTP (SSL) id NMN39028; Sat, 07 Jul 2007 22:31:28 -0700 Received: from ptavv.es.net (ptavv.es.net [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 4EB0245042; Sat, 7 Jul 2007 22:31:28 -0700 (PDT) To: Hans Petter Selasky Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_1183872688_55424P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Sat, 07 Jul 2007 22:31:28 -0700 From: "Kevin Oberman" Message-Id: <20070708053128.4EB0245042@ptavv.es.net> Cc: current@freebsd.org Subject: HPS USB stack on current will not build any longer X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jul 2007 05:46:36 -0000 --==_Exmh_1183872688_55424P Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hans, It seems that, with a recent change to the 802.11 code, your USB code no longer compiles. It dies building if_rum because an additional argument is needed by ieee80211_input. Do you have any patch for this? Thanks, -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 --==_Exmh_1183872688_55424P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) Comment: Exmh version 2.5 06/03/2002 iD8DBQFGkHawkn3rs5h7N1ERAlTgAKCm1/9oU850KoXjE5i+C2q/3LVuqwCfYSni 1/OdFDazcsu/JQsVBU9Ggho= =6gXd -----END PGP SIGNATURE----- --==_Exmh_1183872688_55424P-- From owner-freebsd-current@FreeBSD.ORG Sun Jul 8 07:18:47 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1761716A46B for ; Sun, 8 Jul 2007 07:18:47 +0000 (UTC) (envelope-from paul.eskello@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.246]) by mx1.freebsd.org (Postfix) with ESMTP id CA84813C4B0 for ; Sun, 8 Jul 2007 07:18:46 +0000 (UTC) (envelope-from paul.eskello@gmail.com) Received: by an-out-0708.google.com with SMTP id c14so139206anc for ; Sun, 08 Jul 2007 00:18:46 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=UP+Fl5Ydf1zkSJR3b6GPYAnav9on47ucWyN6+mGutedIosFciTK1U0vMyQm7Cipoo7DVBDZi5ixfQAhaenEIxn/0vmEYjkp1153Q+2/pfcuwtWAo2lcohPZUgwxOIKaIHqQLGcskPwDAjkfHBUXGLhUr70YQSWSgVK+WXw0EpTc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=sfilcE3y3T8soF1SVeIieAubHydPQE06s9fNAnNvZ17FhYK02392mKw7dyunaDG5KuYP42zePLQgHtlUOFujcMf66LbItorMqQ/PpNKbbfaqiDe3OoaZuDnFOfBeTQfkIFUoKf/I7m930Mq+az9XpN7DQIcLi8o+QBbiFDS7/cg= Received: by 10.100.111.16 with SMTP id j16mr1073248anc.1183879126204; Sun, 08 Jul 2007 00:18:46 -0700 (PDT) Received: by 10.100.177.20 with HTTP; Sun, 8 Jul 2007 00:18:46 -0700 (PDT) Message-ID: <8cdf6c720707080018t46e2e9eey3c1eae2c4995eb38@mail.gmail.com> Date: Sun, 8 Jul 2007 09:18:46 +0200 From: "Paul Eskello" To: freebsd-current@freebsd.org In-Reply-To: <8cdf6c720707070710k2b7e030v37683e460d983bf9@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <8cdf6c720707070710k2b7e030v37683e460d983bf9@mail.gmail.com> Subject: Re: status of 7.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jul 2007 07:18:47 -0000 Hi, PJ> No dates have been released yet MWL> We're in code freeze, waiting to cut our first Beta, due soonish. I'm MWL> not sure that dates are nailed down yet. You haven't missed anything. Ok understood. Thanks guys. Paul From owner-freebsd-current@FreeBSD.ORG Sun Jul 8 07:44:15 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CB1F816A400; Sun, 8 Jul 2007 07:44:15 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id A10F913C447; Sun, 8 Jul 2007 07:44:15 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.13.8/8.13.8) with ESMTP id l687iF4S021851; Sun, 8 Jul 2007 03:44:15 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.8/8.13.8) with ESMTP id l687iFYF071707; Sun, 8 Jul 2007 03:44:15 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id C738873068; Sun, 8 Jul 2007 03:44:14 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070708074414.C738873068@freebsd-current.sentex.ca> Date: Sun, 8 Jul 2007 03:44:14 -0400 (EDT) X-Virus-Scanned: ClamAV version devel-20070108, clamav-milter version devel-111206 on news X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jul 2007 07:44:16 -0000 TB --- 2007-07-08 05:44:46 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-07-08 05:44:46 - starting HEAD tinderbox run for i386/pc98 TB --- 2007-07-08 05:44:46 - cleaning the object tree TB --- 2007-07-08 05:45:15 - checking out the source tree TB --- 2007-07-08 05:45:15 - cd /tinderbox/HEAD/i386/pc98 TB --- 2007-07-08 05:45:15 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-07-08 05:54:49 - building world (CFLAGS=-O2 -pipe) TB --- 2007-07-08 05:54:49 - cd /src TB --- 2007-07-08 05:54:49 - /usr/bin/make -B buildworld >>> World build started on Sun Jul 8 05:54:50 UTC 2007 >>> 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 Sun Jul 8 07:09:45 UTC 2007 TB --- 2007-07-08 07:09:45 - generating LINT kernel config TB --- 2007-07-08 07:09:45 - cd /src/sys/pc98/conf TB --- 2007-07-08 07:09:45 - /usr/bin/make -B LINT TB --- 2007-07-08 07:09:45 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-07-08 07:09:45 - cd /src TB --- 2007-07-08 07:09:45 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Jul 8 07:09:46 UTC 2007 >>> 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 >>> Kernel build for LINT completed on Sun Jul 8 07:36:44 UTC 2007 TB --- 2007-07-08 07:36:44 - building GENERIC kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-07-08 07:36:44 - cd /src TB --- 2007-07-08 07:36:44 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Sun Jul 8 07:36:44 UTC 2007 >>> 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 -x assembler-with-cpp -DLOCORE -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/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 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding /src/sys/i386/i386/support.s cc -c -x assembler-with-cpp -DLOCORE -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/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 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding /src/sys/i386/i386/swtch.s cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/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 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding /src/sys/i386/i386/sys_machdep.c /src/sys/i386/i386/sys_machdep.c: In function 'i386_ldt_grow': /src/sys/i386/i386/sys_machdep.c:697: error: 'NULL_LDT_BASE' undeclared (first use in this function) /src/sys/i386/i386/sys_machdep.c:697: error: (Each undeclared identifier is reported only once /src/sys/i386/i386/sys_machdep.c:697: error: for each function it appears in.) /src/sys/i386/i386/sys_machdep.c:751: warning: passing argument 1 of 'set_user_ldt' from incompatible pointer type *** Error code 1 Stop in /obj/pc98/src/sys/GENERIC. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-07-08 07:44:14 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-07-08 07:44:14 - ERROR: failed to build GENERIC kernel TB --- 2007-07-08 07:44:14 - tinderbox aborted TB --- 0.80 user 2.64 system 7168.35 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Sun Jul 8 09:04:13 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7541616A400; Sun, 8 Jul 2007 09:04:13 +0000 (UTC) (envelope-from sem@FreeBSD.org) Received: from mail.ciam.ru (ns.ciam.ru [213.247.195.75]) by mx1.freebsd.org (Postfix) with ESMTP id 3523313C46A; Sun, 8 Jul 2007 09:04:13 +0000 (UTC) (envelope-from sem@FreeBSD.org) Received: from [87.240.16.199] (helo=solem.sem-home.ciam.ru) by mail.ciam.ru with esmtpa (Exim 4.x) id 1I7SMw-000HtO-F6; Sun, 08 Jul 2007 12:43:50 +0400 Message-ID: <4690A363.1050307@FreeBSD.org> Date: Sun, 08 Jul 2007 12:42:11 +0400 From: Sergey Matveychuk User-Agent: Thunderbird 2.0.0.0 (X11/20070602) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: Max Laier , freebsd-current@freebsd.org Subject: iwi loses ssid X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jul 2007 09:04:13 -0000 Hi. After I upgraded to Jul 1 CURRENT my notebook's iwi adapter started work unstable. It loses carrier. When I take a look at ifconfig output I see a strange ssid. After I make ifconfig iwi0 ssid myssid, everything is recovered. Time between ssid losses is accidental. Sometimes minutes, sometimes hours. PS. While I wrote this message it resets ssid again to ZXDSL531BII-1A0EE6. It looks like the ssid is always the same. -- Dixi. Sem. From owner-freebsd-current@FreeBSD.ORG Sun Jul 8 09:31:48 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 45FF616A400 for ; Sun, 8 Jul 2007 09:31:48 +0000 (UTC) (envelope-from marinosi@diogenis.ceid.upatras.gr) Received: from poseidon.ceid.upatras.gr (poseidon.ceid.upatras.gr [150.140.141.169]) by mx1.freebsd.org (Postfix) with ESMTP id EF61413C4BC for ; Sun, 8 Jul 2007 09:31:47 +0000 (UTC) (envelope-from marinosi@diogenis.ceid.upatras.gr) Received: from mail.ceid.upatras.gr (unknown [10.1.0.143]) by poseidon.ceid.upatras.gr (Postfix) with ESMTP id 9069EEB46A6 for ; Sun, 8 Jul 2007 12:31:45 +0300 (EEST) Received: from localhost (europa.ceid.upatras.gr [127.0.0.1]) by mail.ceid.upatras.gr (Postfix) with ESMTP id 431972B9A284 for ; Sun, 8 Jul 2007 12:31:45 +0300 (EEST) X-Virus-Scanned: amavisd-new at ceid.upatras.gr Received: from mail.ceid.upatras.gr ([127.0.0.1]) by localhost (europa.ceid.upatras.gr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eWj8bOa5RhoS for ; Sun, 8 Jul 2007 12:31:45 +0300 (EEST) Received: from diogenis.ceid.upatras.gr (unknown [10.1.0.181]) by mail.ceid.upatras.gr (Postfix) with ESMTP id 096102B9A282 for ; Sun, 8 Jul 2007 12:31:45 +0300 (EEST) Received: by diogenis.ceid.upatras.gr (Postfix, from userid 3149) id C62138FF75; Sun, 8 Jul 2007 12:31:44 +0300 (EEST) Date: Sun, 8 Jul 2007 12:31:44 +0300 From: Marinos Ilias To: freebsd-current@freebsd.org Message-ID: <20070708093144.GA22598@ceid.upatras.gr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.2i Subject: IPW3945ABG -- Support in RELENG 7? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jul 2007 09:31:48 -0000 Hello list, Wondering what's the current state of Intel Pro Wireless Support 3945 ABG support .Anyone knows if there will be support in RELENG_7 , so we can use finally, our laptops' wifi? Have fun ... --Ilias From owner-freebsd-current@FreeBSD.ORG Sun Jul 8 10:15:50 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 40EEA16A46B for ; Sun, 8 Jul 2007 10:15:50 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 1945713C457 for ; Sun, 8 Jul 2007 10:15:50 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 638FB492AF; Sun, 8 Jul 2007 06:15:49 -0400 (EDT) Date: Sun, 8 Jul 2007 11:15:49 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Paul Eskello In-Reply-To: <8cdf6c720707070710k2b7e030v37683e460d983bf9@mail.gmail.com> Message-ID: <20070708111105.C9997@fledge.watson.org> References: <8cdf6c720707070710k2b7e030v37683e460d983bf9@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: status of 7.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jul 2007 10:15:50 -0000 On Sat, 7 Jul 2007, Paul Eskello wrote: > I was wondering when to expect 7.0 release ? Did I miss the schedule. Any > showstoppers ? when to expect RC1 ? > > Just curious. > > Have a great weekend. Ken may respond in a more detailed form, but the current stage is that we are waiting for the feature set to finally settle and some known outstanding issues to resolve themselves, at which point we'll cut a first beta in the next 2-4 weeks. As a precursor to that, monthly snapshots will likely get built and released in the next couple of days. Hopefully testing and feedback from that will allow us to nail down a more specific schedule for the release itself. At this point, the imperative for developers is to wrap up any remaining outstanding features and work on testing and bug fixing. Likewise users :-). We often find that even early adoption sites only really start testing during the RC cycle, and that's far too late to make larger changes that may be required to address some sorts of stability issues. Getting people doing testing the whole way through the cycle makes a big difference in the effectiveness of the test cycle. There are some really great features in 7.0, and it's wonderful to be at the polishing and testing stage finally :-). Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Sun Jul 8 10:21:01 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E37DD16A46C for ; Sun, 8 Jul 2007 10:21:01 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from heff.fud.org.nz (203-109-251-39.static.bliink.ihug.co.nz [203.109.251.39]) by mx1.freebsd.org (Postfix) with ESMTP id 8B18B13C46C for ; Sun, 8 Jul 2007 10:21:01 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: by heff.fud.org.nz (Postfix, from userid 1001) id 9B1B21CC58; Sun, 8 Jul 2007 22:20:59 +1200 (NZST) Date: Sun, 8 Jul 2007 22:20:59 +1200 From: Andrew Thompson To: Sergey Matveychuk Message-ID: <20070708102059.GA65610@heff.fud.org.nz> References: <4690A363.1050307@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4690A363.1050307@FreeBSD.org> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: freebsd-current@freebsd.org Subject: Re: iwi loses ssid X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jul 2007 10:21:02 -0000 On Sun, Jul 08, 2007 at 12:42:11PM +0400, Sergey Matveychuk wrote: > Hi. > > After I upgraded to Jul 1 CURRENT my notebook's iwi adapter started work > unstable. It loses carrier. When I take a look at ifconfig output I > see a strange ssid. After I make ifconfig iwi0 ssid myssid, everything > is recovered. Time between ssid losses is accidental. Sometimes minutes, > sometimes hours. Could you enable logging with 'wlandebug -i iwi0 +roam' and paste the output when it switches access points. > PS. While I wrote this message it resets ssid again to > ZXDSL531BII-1A0EE6. It looks like the ssid is always the same. Is this another AP somewhere? 'ifconfig iwi0 list scan' will show all the access points available. regards, Andrew From owner-freebsd-current@FreeBSD.ORG Sun Jul 8 10:21:19 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A8F4316A41F for ; Sun, 8 Jul 2007 10:21:19 +0000 (UTC) (envelope-from r.c.ladan@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.170]) by mx1.freebsd.org (Postfix) with ESMTP id 3C31A13C447 for ; Sun, 8 Jul 2007 10:21:19 +0000 (UTC) (envelope-from r.c.ladan@gmail.com) Received: by ug-out-1314.google.com with SMTP id o4so1101327uge for ; Sun, 08 Jul 2007 03:21:18 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; b=a+zzU5bjJiJFcQ+1D2c6WBS8/DwqzKyGTPj/yHPYXIzw4zM+X3Kx6D6DYNHXGWLwavc+yIGb4R1LVMaFRz0UA48BEpZmwD2dEJHT/OCTLila7pLoYTZchXdP/Ps5BpRKaUDZrY6KYy9WKjWx7Y2CQcoXUzEgzizTGz1BFIcueQU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; b=XyJ2ErsJauLk705nNam29HCzJeycPMSm49hb2gckpMAbw/ThU+0vyhhrnXiltSi82tkGL8EVk+ioj/ESAEGjVBWdXhlrVWACrvC/AZ0lKJpM8W5JsJl83QZF5CcnoD+35HOkloxCEkE7caz7hButTEkcszbqD39ubC0AVo+l0Vc= Received: by 10.67.19.13 with SMTP id w13mr4226812ugi.1183890078277; Sun, 08 Jul 2007 03:21:18 -0700 (PDT) Received: from 195-241-221-201.dsl.ip.tiscali.nl ( [195.241.221.201]) by mx.google.com with ESMTPS id h57sm698806uga.2007.07.08.03.21.17 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 08 Jul 2007 03:21:17 -0700 (PDT) Message-ID: <4690BA9C.70808@gmail.com> Date: Sun, 08 Jul 2007 12:21:16 +0200 From: Rene Ladan User-Agent: Thunderbird 2.0.0.4 (X11/20070616) MIME-Version: 1.0 To: Marinos Ilias References: <20070708093144.GA22598@ceid.upatras.gr> In-Reply-To: <20070708093144.GA22598@ceid.upatras.gr> X-Enigmail-Version: 0.95.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Benjamin Close Subject: Re: IPW3945ABG -- Support in RELENG 7? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jul 2007 10:21:19 -0000 Marinos Ilias schreef: > Hello list, > Wondering what's the current state of Intel Pro Wireless Support 3945 ABG support .Anyone knows if there will be support in RELENG_7 , so we can use finally, our laptops' wifi? > Keep track of http://perforce.freebsd.org/changeList.cgi?FSPC=%2F%2Fdepot%2Fuser%2Fbenjsc%2Fwpi%2Fsys%2Fdev%2Fwpi%2F...&USERS=benjsc&ignore=GO%21 This page describes the latest updates to the wpi driver. 802.11a could be usable now, 802.11bg not yet. Regards, Rene -- GPG fingerprint = E738 5471 D185 7013 0EE0 4FC8 3C1D 6F83 12E1 84F6 (subkeys.pgp.net) "It won't fit on the line." -- me, 2001 From owner-freebsd-current@FreeBSD.ORG Sun Jul 8 10:50:00 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E613216A400 for ; Sun, 8 Jul 2007 10:50:00 +0000 (UTC) (envelope-from maxx@mobistarmail.be) Received: from mailrelay007.isp.belgacom.be (mailrelay007.isp.belgacom.be [195.238.6.173]) by mx1.freebsd.org (Postfix) with ESMTP id 8016F13C45A for ; Sun, 8 Jul 2007 10:50:00 +0000 (UTC) (envelope-from maxx@mobistarmail.be) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAE9VkEZR8PqQ/2dsb2JhbAA Received: from 144.250-240-81.adsl-fix.isp.belgacom.be (HELO localhost) ([81.240.250.144]) by relay.skynet.be with SMTP; 08 Jul 2007 12:20:22 +0200 Date: Sun, 8 Jul 2007 12:20:21 +0200 From: MaXX To: freebsd-current@freebsd.org Message-Id: <20070708122021.412747c4.maxx@mobistarmail.be> In-Reply-To: <20070708093144.GA22598@ceid.upatras.gr> References: <20070708093144.GA22598@ceid.upatras.gr> X-Mailer: Sylpheed 2.3.1 (GTK+ 2.10.11; i386-portbld-freebsd6.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: IPW3945ABG -- Support in RELENG 7? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jul 2007 10:50:01 -0000 On Sun, 8 Jul 2007 12:31:44 +0300 Marinos Ilias wrote: > Hello list, > Wondering what's the current state of Intel Pro Wireless Support 3945 ABG support .Anyone knows if there will be support in RELENG_7 , so we can use finally, our laptops' wifi? Hi, I'm aware of http://www.clearchain.com/wiki/Wpi which seems to be active and making great progress. But I think we have to be a little more patient to allow the author to finish his work, or I you feel like you can, give him some help. HTH, -- MaXX From owner-freebsd-current@FreeBSD.ORG Sun Jul 8 11:20:24 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5FD1D16A421 for ; Sun, 8 Jul 2007 11:20:24 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from cs1.cs.huji.ac.il (cs1.cs.huji.ac.il [132.65.16.10]) by mx1.freebsd.org (Postfix) with ESMTP id 1AC6313C458 for ; Sun, 8 Jul 2007 11:20:23 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by cs1.cs.huji.ac.il with esmtp id 1I7UoP-000DK7-9C; Sun, 08 Jul 2007 14:20:21 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 08 Jul 2007 14:20:21 +0300 From: Danny Braniss Message-ID: Cc: Pyun YongHyeon Subject: src/UPDATE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jul 2007 11:20:24 -0000 the latest src/UPDATE has bad date: ... 20060612: The i386/amd64 GENERIC kernel now defaults to the nfe(4) driver instead of the nve(4) driver. Please update your configuration accordingly. ... danny From owner-freebsd-current@FreeBSD.ORG Sun Jul 8 11:30:06 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4871316A46C for ; Sun, 8 Jul 2007 11:30:06 +0000 (UTC) (envelope-from ubm@u-boot-man.de) Received: from mail.upper.net (mail.upper.net [62.75.224.33]) by mx1.freebsd.org (Postfix) with ESMTP id DCEB913C458 for ; Sun, 8 Jul 2007 11:30:05 +0000 (UTC) (envelope-from ubm@u-boot-man.de) Received: from ubm.mine.nu (p57AE1F07.dip0.t-ipconnect.de [87.174.31.7]) (authenticated bits=0) by mail.upper.net (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l68BIRPb021699 for ; Sun, 8 Jul 2007 13:18:28 +0200 Date: Sun, 8 Jul 2007 13:25:45 +0200 From: Marc "UBM" Bocklet To: freebsd-current@freebsd.org Message-Id: <20070708132545.5604cbe9.ubm@u-boot-man.de> In-Reply-To: <20070708111105.C9997@fledge.watson.org> References: <8cdf6c720707070710k2b7e030v37683e460d983bf9@mail.gmail.com> <20070708111105.C9997@fledge.watson.org> X-Mailer: Sylpheed 2.4.0 (GTK+ 2.10.12; i386-portbld-freebsd6.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: status of 7.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jul 2007 11:30:06 -0000 On Sun, 8 Jul 2007 11:15:49 +0100 (BST) Robert Watson wrote: > > On Sat, 7 Jul 2007, Paul Eskello wrote: > > > I was wondering when to expect 7.0 release ? Did I miss the > > schedule. Any showstoppers ? when to expect RC1 ? > > > > Just curious. > > > > Have a great weekend. > > Ken may respond in a more detailed form, but the current stage is > that we are waiting for the feature set to finally settle and some > known outstanding issues to resolve themselves, at which point we'll > cut a first beta in the next 2-4 weeks. As a precursor to that, > monthly snapshots will likely get built and released in the next > couple of days. Hopefully testing and feedback from that will allow > us to nail down a more specific schedule for the release itself. > > At this point, the imperative for developers is to wrap up any > remaining outstanding features and work on testing and bug fixing. > Likewise users :-). We often find that even early adoption sites only > really start testing during the RC cycle, and that's far too late to > make larger changes that may be required to address some sorts of > stability issues. Getting people doing testing the whole way through > the cycle makes a big difference in the effectiveness of the test > cycle. I'd like to do some testing, but I'm a little bit afraid of the upgrade procedure 6.2-stable to -current. Is it possible to do a simple upgrade if I follow the guidelines in UPGRADE or are there any hidden caveats? (like "you've to recompile all installed ports", etc. :-)) Bye Marc -- "And what rough beast, its hour come round at last, Slouches towards Bethlehem to be born?" W.B. Yeats, The Second Coming From owner-freebsd-current@FreeBSD.ORG Sun Jul 8 11:51:09 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DC34316A400 for ; Sun, 8 Jul 2007 11:51:09 +0000 (UTC) (envelope-from r.c.ladan@gmail.com) Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.190]) by mx1.freebsd.org (Postfix) with ESMTP id 6BD5A13C448 for ; Sun, 8 Jul 2007 11:51:09 +0000 (UTC) (envelope-from r.c.ladan@gmail.com) Received: by mu-out-0910.google.com with SMTP id w9so389297mue for ; Sun, 08 Jul 2007 04:51:08 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; b=sheNiChjrOIobOq4bqnHHpHyNE+z568gI3KJdiEzcBOi56r7XEtCN0brjQttt+4MlS6vi35o+hEJwBd7w2o1n/J1vB2IDZQVK6MrJge9e41nI0s5iJZYsFxcoeEyDj/aNmW6CbWKQYC7qPHUC/Cqwgw2pwViECaz8RNqYMbHnJg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; b=W7OywUr5CoGR6OMqVj3DhVnM6HqmJgVXgW4TNISJL37IcnVzvXpv+rN7aNPKUPM0S5HayQ3HOnPyoy6c0Rfv0a/2mSHT8MLJQ2JCj66t6Qc4BQIcfaaWMSm2BrjJlwPCTXVld1NcowfFDO0X3Ai42u73D0Wy3Lg+isuCd5QsQq4= Received: by 10.82.146.14 with SMTP id t14mr5640236bud.1183895468351; Sun, 08 Jul 2007 04:51:08 -0700 (PDT) Received: from 195-241-221-201.dsl.ip.tiscali.nl ( [195.241.221.201]) by mx.google.com with ESMTP id f7sm14305046nfh.2007.07.08.04.51.06 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 08 Jul 2007 04:51:07 -0700 (PDT) Message-ID: <4690CFAA.30004@gmail.com> Date: Sun, 08 Jul 2007 13:51:06 +0200 From: Rene Ladan User-Agent: Thunderbird 2.0.0.4 (X11/20070616) MIME-Version: 1.0 To: "Marc \"UBM\" Bocklet" References: <8cdf6c720707070710k2b7e030v37683e460d983bf9@mail.gmail.com> <20070708111105.C9997@fledge.watson.org> <20070708132545.5604cbe9.ubm@u-boot-man.de> In-Reply-To: <20070708132545.5604cbe9.ubm@u-boot-man.de> X-Enigmail-Version: 0.95.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: status of 7.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jul 2007 11:51:09 -0000 Marc UBM Bocklet schreef: > > > I'd like to do some testing, but I'm a little bit afraid of the upgrade > procedure 6.2-stable to -current. Is it possible to do a simple upgrade > if I follow the guidelines in UPGRADE or are there any hidden caveats? > (like "you've to recompile all installed ports", etc. :-)) > [...don't try this on a production box...] Just following the procedure and the changelog entries in /usr/src/UPDATING should do the job. It's probably best to cvsup into a new directory and clean /usr/obj before beginning the update. That's how I updated from RELENG_6 to HEAD back in November 2006. Since we have a misc/compat6x port and a COMPAT_FREEBSD6 kernel configuaration option, it shouldn't be necessary to rebuild all your ports. HTH, Rene -- GPG fingerprint = E738 5471 D185 7013 0EE0 4FC8 3C1D 6F83 12E1 84F6 (subkeys.pgp.net) "It won't fit on the line." -- me, 2001 From owner-freebsd-current@FreeBSD.ORG Sun Jul 8 12:19:06 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id ACBFA16A421 for ; Sun, 8 Jul 2007 12:19:06 +0000 (UTC) (envelope-from sem@FreeBSD.org) Received: from mail.ciam.ru (ns.ciam.ru [213.247.195.75]) by mx1.freebsd.org (Postfix) with ESMTP id 6C0D413C459 for ; Sun, 8 Jul 2007 12:19:06 +0000 (UTC) (envelope-from sem@FreeBSD.org) Received: from [87.240.16.199] (helo=solem.sem-home.ciam.ru) by mail.ciam.ru with esmtpa (Exim 4.x) id 1I7VjF-000KLU-2u; Sun, 08 Jul 2007 16:19:05 +0400 Message-ID: <4690D5D6.1020602@FreeBSD.org> Date: Sun, 08 Jul 2007 16:17:26 +0400 From: Sergey Matveychuk User-Agent: Thunderbird 2.0.0.0 (X11/20070602) MIME-Version: 1.0 To: Andrew Thompson References: <4690A363.1050307@FreeBSD.org> <20070708102059.GA65610@heff.fud.org.nz> In-Reply-To: <20070708102059.GA65610@heff.fud.org.nz> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: iwi loses ssid X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jul 2007 12:19:06 -0000 Andrew Thompson wrote: > On Sun, Jul 08, 2007 at 12:42:11PM +0400, Sergey Matveychuk wrote: >> Hi. >> >> After I upgraded to Jul 1 CURRENT my notebook's iwi adapter started work >> unstable. It loses carrier. When I take a look at ifconfig output I >> see a strange ssid. After I make ifconfig iwi0 ssid myssid, everything >> is recovered. Time between ssid losses is accidental. Sometimes minutes, >> sometimes hours. > > Could you enable logging with 'wlandebug -i iwi0 +roam' and paste the > output when it switches access points. Where can I get it? % which wlandebug wlandebug: Command not found. > >> PS. While I wrote this message it resets ssid again to >> ZXDSL531BII-1A0EE6. It looks like the ssid is always the same. > > Is this another AP somewhere? 'ifconfig iwi0 list scan' will show all > the access points available. Even if there is another AP somewhere, should it reset ssid from the interface? -- Dixi. Sem. From owner-freebsd-current@FreeBSD.ORG Sun Jul 8 12:28:01 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B037C16A41F for ; Sun, 8 Jul 2007 12:28:01 +0000 (UTC) (envelope-from sem@FreeBSD.org) Received: from mail.ciam.ru (ns.ciam.ru [213.247.195.75]) by mx1.freebsd.org (Postfix) with ESMTP id 712C213C447 for ; Sun, 8 Jul 2007 12:28:01 +0000 (UTC) (envelope-from sem@FreeBSD.org) Received: from [87.240.16.199] (helo=solem.sem-home.ciam.ru) by mail.ciam.ru with esmtpa (Exim 4.x) id 1I7Vrs-000KSP-Ke; Sun, 08 Jul 2007 16:28:00 +0400 Message-ID: <4690D7EB.3010305@FreeBSD.org> Date: Sun, 08 Jul 2007 16:26:19 +0400 From: Sergey Matveychuk User-Agent: Thunderbird 2.0.0.0 (X11/20070602) MIME-Version: 1.0 To: Andrew Thompson References: <4690A363.1050307@FreeBSD.org> <20070708102059.GA65610@heff.fud.org.nz> In-Reply-To: <20070708102059.GA65610@heff.fud.org.nz> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: iwi loses ssid X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jul 2007 12:28:01 -0000 Andrew Thompson wrote: > On Sun, Jul 08, 2007 at 12:42:11PM +0400, Sergey Matveychuk wrote: >> Hi. >> >> After I upgraded to Jul 1 CURRENT my notebook's iwi adapter started work >> unstable. It loses carrier. When I take a look at ifconfig output I >> see a strange ssid. After I make ifconfig iwi0 ssid myssid, everything >> is recovered. Time between ssid losses is accidental. Sometimes minutes, >> sometimes hours. > > Could you enable logging with 'wlandebug -i iwi0 +roam' and paste the > output when it switches access points. > >> PS. While I wrote this message it resets ssid again to >> ZXDSL531BII-1A0EE6. It looks like the ssid is always the same. > > Is this another AP somewhere? 'ifconfig iwi0 list scan' will show all > the access points available. > Yes, there is another AP somewhere in home: # ifconfig iwi0 list scan SSID BSSID CHAN RATE S:N INT CAPS ZXDSL531BII... 00:16:e3:f3:c6:32 11 54M 19:0 100 EP default 00:19:5b:54:26:39 6 54M 21:0 119 E sem-home 00:18:f8:a3:7a:58 11 54M 43:0 100 EPS sem-home is mine. -- Dixi. Sem. From owner-freebsd-current@FreeBSD.ORG Sun Jul 8 14:00:16 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1BC4D16A469 for ; Sun, 8 Jul 2007 14:00:16 +0000 (UTC) (envelope-from avatar@mmlab.cse.yzu.edu.tw) Received: from www.mmlab.cse.yzu.edu.tw (www.mmlab.cse.yzu.edu.tw [140.138.150.166]) by mx1.freebsd.org (Postfix) with ESMTP id DAC7A13C4C8 for ; Sun, 8 Jul 2007 14:00:15 +0000 (UTC) (envelope-from avatar@mmlab.cse.yzu.edu.tw) Received: by www.mmlab.cse.yzu.edu.tw (qmail, from userid 1000) id DC2658CA00D; Sun, 8 Jul 2007 22:00:14 +0800 (CST) Received: from localhost (localhost [127.0.0.1]) by www.mmlab.cse.yzu.edu.tw (qmail) with ESMTP id 9ECBB8C9D30; Sun, 8 Jul 2007 22:00:14 +0800 (CST) Date: Sun, 8 Jul 2007 22:00:14 +0800 (CST) From: Tai-hwa Liang To: Kostik Belousov In-Reply-To: <20070708024815.GK2200@deviant.kiev.zoral.com.ua> Message-ID: <0707082155317.77206@www.mmlab.cse.yzu.edu.tw> References: <20070703180141.GJ2200@deviant.kiev.zoral.com.ua> <20070705144443.GV2200@deviant.kiev.zoral.com.ua> <20070707160042.GJ2200@deviant.kiev.zoral.com.ua> <07070809441413.59322@www.mmlab.cse.yzu.edu.tw> <20070708024815.GK2200@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: current@freebsd.org Subject: Re: HEADS UP: destroy_dev_sched() KPI in the tree X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jul 2007 14:00:16 -0000 On Sun, 8 Jul 2007, Kostik Belousov wrote: > On Sun, Jul 08, 2007 at 09:47:41AM +0800, Tai-hwa Liang wrote: [...] >> Though it was reviewed before destroy_dev_sched() KPI enters to the tree, >> I'd be appreciate it if you can reviewed the attached patch again. > So, this is still the problem for scsi_targ ? > > It probably make sense to postpone free of softc until all threads > finished using it. You may use destroy_dev_sched_cb() to run the > function after the device is actually destroyed. It would just call > free(). Probably; however, I did not see any code inside scsi_target.c to detach or unregister the scsi_target device. Will this cause any cdev leakage? -- Thanks, Tai-hwa Liang From owner-freebsd-current@FreeBSD.ORG Sun Jul 8 07:21:04 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id ABF0416A479 for ; Sun, 8 Jul 2007 07:21:04 +0000 (UTC) (envelope-from xistence@0x58.com) Received: from mailexchange.osnn.net (1e.66.5646.static.theplanet.com [70.86.102.30]) by mx1.freebsd.org (Postfix) with SMTP id 3594913C48C for ; Sun, 8 Jul 2007 07:21:03 +0000 (UTC) (envelope-from xistence@0x58.com) Received: (qmail 67346 invoked by uid 0); 8 Jul 2007 07:17:18 -0000 Received: from unknown (HELO ?10.10.10.22?) (xistence@0x58.com@72.208.132.56) by mailexchange.osnn.net with SMTP; 8 Jul 2007 07:17:18 -0000 In-Reply-To: <20070707.221444.-1816826594.imp@bsdimp.com> References: <9496044C-3275-4D9C-8FFF-FD1FCE1F6728@0x58.com> <20070707.220203.776519881.imp@bsdimp.com> <20070707.221444.-1816826594.imp@bsdimp.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-5--586368409; protocol="application/pkcs7-signature" Message-Id: <89437BFD-62EF-49FB-9405-8364719F1CFE@0x58.com> From: Bert JW Regeer Date: Sun, 8 Jul 2007 00:21:01 -0700 To: M. Warner Losh X-Mailer: Apple Mail (2.752.3) X-Mailman-Approved-At: Sun, 08 Jul 2007 14:03:06 +0000 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: usb@freebsd.org, hackers@freebsd.org, current@freebsd.org Subject: Re: device rue causes kernel panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jul 2007 07:21:04 -0000 --Apple-Mail-5--586368409 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Jul 7, 2007, at 9:14 PM, M. Warner Losh wrote: > In message: <20070707.220203.776519881.imp@bsdimp.com> > "M. Warner Losh" writes: > : In message: <9496044C-3275-4D9C-8FFF-FD1FCE1F6728@0x58.com> > : Bert JW Regeer writes: > : : I have a USB 10/100 FastEthernet device, that is identified as a > : : RealTek device. On 6.2-RELEASE it works without any issues, and > some > : : older versions of CURRENT it worked perfectly as well. I > csup'ed to > : : CURRENT today (2007-07-07 at 16:30 MST), rebuild my kernel and it > : : failed: > : : panic (fmt=0xc0a94933 "Trying sleep, but thread marked as > sleeping prohibited") > : : _sleep (ident=0xc2322c00...) at /usr/src/sys/kern/kern_synch.c:201 > : : usbd_transfer (xfer=0xc2322c00) at /usr/src/sys/dev/usb/usbdi.c: > 333 > : : usbd_sync_transfer (xfer=0xc2322c00) at /usr/src/sys/dev/usb/ > usbdi.c:406 > : : usbd_do_request_flags_pipe ... at /usr/src/sys/dev/usb/usbdi.c: > 1098 > : : usbd_do_request_flags ...at /usr/src/sys/dev/usb/usbdi.c:1068 > : : usbd_do_request at /usr/src/sys/dev/usb/usbdi.c:1060 > : : rue_read_mem at /usr/src/sys/dev/usb/if_rue.c:227 > : : rue_csr_read_1 at /usr/src/sys/dev/usb/if_rue.c:276 > : : rue_miibus_readreg at /usr/src/sys/dev/usb/if_rue.c:376 > : ... > : : ruephy_service at miibus_if.h:26 /* Likely wrong */ > : : mii_tick at /usr/src/sys/dev/mii/mii.c:390 > : : rue_tick at /usr/src/sys/dev/usb/if_rue.c:935 > : : softclock at /usr/src/sys/kern/kern_timeout.c:281 > : ... > : > : This driver needs to be re-written ala aue, axe, kue and udav to > use a > : taskqueue for the mii ticking. It appears to be the only usb driver > : in the tree to still do stuff directly in a callout. This context > : can't sleep... > > You might try this patch. > > Warner > Index: if_rue.c > =================================================================== > RCS file: /cache/ncvs/src/sys/dev/usb/if_rue.c,v > retrieving revision 1.39 > diff -u -r1.39 if_rue.c > --- if_rue.c 20 Jun 2007 05:10:52 -0000 1.39 > +++ if_rue.c 8 Jul 2007 04:13:16 -0000 > @@ -142,6 +142,7 @@ > static void rue_rxeof(usbd_xfer_handle, usbd_private_handle, > usbd_status); > static void rue_txeof(usbd_xfer_handle, usbd_private_handle, > usbd_status); > static void rue_tick(void *); > +static void rue_tick_task(void *); > static void rue_rxstart(struct ifnet *); > static void rue_start(struct ifnet *); > static int rue_ioctl(struct ifnet *, u_long, caddr_t); > @@ -594,6 +595,8 @@ > goto error; > } > > + usb_init_task(&sc->rue_tick_task, rue_tick_task, sc); > + > err = usbd_device2interface_handle(uaa->device, RUE_IFACE_IDX, > &iface); > if (err) { > device_printf(sc->rue_dev, "getting interface handle failed\n"); > @@ -704,6 +707,7 @@ > > sc->rue_dying = 1; > untimeout(rue_tick, sc, sc->rue_stat_ch); > + usb_rem_task(sc->rue_udev, &sc->rue_tick_task); > ether_ifdetach(ifp); > if_free(ifp); > > @@ -916,6 +920,20 @@ > static void > rue_tick(void *xsc) > { > + struct rue_softc *sc = xsc; > + > + if (sc == NULL) > + return; > + if (sc->rue_dying) > + return; > + > + /* Perform periodic stuff in process context */ > + usb_add_task(sc->rue_udev, &sc->rue_tick_task, USB_TASKQ_DRIVER); > +} > + > +static void > +rue_tick_task(void *xsc) > +{ > struct rue_softc *sc = xsc; > struct ifnet *ifp; > struct mii_data *mii; > Index: if_ruereg.h > =================================================================== > RCS file: /cache/ncvs/src/sys/dev/usb/if_ruereg.h,v > retrieving revision 1.7 > diff -u -r1.7 if_ruereg.h > --- if_ruereg.h 12 May 2007 05:53:53 -0000 1.7 > +++ if_ruereg.h 8 Jul 2007 04:11:39 -0000 > @@ -204,6 +204,7 @@ > char rue_dying; > struct timeval rue_rx_notice; > struct usb_qdat rue_qdat; > + struct usb_task rue_tick_task; > }; > > #if defined(__FreeBSD__) > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers- > unsubscribe@freebsd.org" This patch works, in that no more Kernel panics are created, however the following did show up in dmesg//var/log/messages as I was using dhclient rue0: Jul 7 16:15:53 FreeBSD-VMWare root: Unknown USB device: vendor 0x0bda product 0x8150 bus uhub0 Jul 7 16:15:53 FreeBSD-VMWare kernel: rue0: on uhub0 Jul 7 16:15:53 FreeBSD-VMWare kernel: miibus0: on rue0 Jul 7 16:15:53 FreeBSD-VMWare kernel: ruephy0: PHY 0 on miibus0 Jul 7 16:15:53 FreeBSD-VMWare kernel: ruephy0: 10baseT, 10baseT- FDX, 100baseTX, 100baseTX-FDX, auto Jul 7 16:15:53 FreeBSD-VMWare kernel: rue0: using obsoleted if_watchdog interface Jul 7 16:15:53 FreeBSD-VMWare kernel: rue0: Ethernet address: 00:10:60:e0:ab:a8 Jul 7 16:15:53 FreeBSD-VMWare kernel: rue0: if_start running deferred for Giant Jul 7 16:15:53 FreeBSD-VMWare kernel: rue0: link state changed to DOWN Jul 7 16:15:54 FreeBSD-VMWare kernel: uhub2: on uhub0 Jul 7 16:15:54 FreeBSD-VMWare kernel: uhub2: 7 ports with 7 removable, self powered Jul 7 16:15:57 FreeBSD-VMWare kernel: rue0: link state changed to UP Jul 7 16:15:57 FreeBSD-VMWare kernel: rue0: link state changed to DOWN Jul 7 16:15:57 FreeBSD-VMWare kernel: rue0: link state changed to UP Jul 7 16:16:09 FreeBSD-VMWare kernel: Sleeping on "usbsyn" with the following non-sleepable locks held: Jul 7 16:16:09 FreeBSD-VMWare kernel: exclusive sleep mutex in_multi_mtx r = 0 (0xc0bf334c) locked @ /usr/src/sys/netinet/ in_mcast.c:317 Jul 7 16:16:09 FreeBSD-VMWare kernel: lock order reversal: (Giant after non-sleepable) Jul 7 16:16:09 FreeBSD-VMWare kernel: 1st 0xc0bf334c in_multi_mtx (in_multi_mtx) @ /usr/src/sys/netinet/in_mcast.c:317 Jul 7 16:16:09 FreeBSD-VMWare kernel: 2nd 0xc0ba47a8 Giant (Giant) @ /usr/src/sys/kern/kern_synch.c:235 Jul 7 16:16:09 FreeBSD-VMWare kernel: Sleeping on "usbsyn" with the following non-sleepable locks held: Jul 7 16:16:09 FreeBSD-VMWare kernel: exclusive sleep mutex in_multi_mtx r = 0 (0xc0bf334c) locked @ /usr/src/sys/netinet/ in_mcast.c:317 Jul 7 16:16:09 FreeBSD-VMWare kernel: Sleeping on "usbsyn" with the following non-sleepable locks held: Jul 7 16:16:09 FreeBSD-VMWare kernel: exclusive sleep mutex in_multi_mtx r = 0 (0xc0bf334c) locked @ /usr/src/sys/netinet/ in_mcast.c:317 Jul 7 16:16:09 FreeBSD-VMWare kernel: Sleeping on "usbsyn" with the following non-sleepable locks held: Jul 7 16:16:09 FreeBSD-VMWare kernel: exclusive sleep mutex in_multi_mtx r = 0 (0xc0bf334c) locked @ /usr/src/sys/netinet/ in_mcast.c:317 Jul 7 16:16:09 FreeBSD-VMWare kernel: Sleeping on "usbsyn" with the following non-sleepable locks held: Jul 7 16:16:09 FreeBSD-VMWare kernel: exclusive sleep mutex in_multi_mtx r = 0 (0xc0bf334c) locked @ /usr/src/sys/netinet/ in_mcast.c:317 Jul 7 16:16:09 FreeBSD-VMWare kernel: Sleeping on "usbsyn" with the following non-sleepable locks held: Jul 7 16:16:09 FreeBSD-VMWare kernel: exclusive sleep mutex in_multi_mtx r = 0 (0xc0bf334c) locked @ /usr/src/sys/netinet/ in_mcast.c:317 Jul 7 16:16:09 FreeBSD-VMWare kernel: Sleeping on "usbsyn" with the following non-sleepable locks held: Jul 7 16:16:09 FreeBSD-VMWare kernel: exclusive sleep mutex in_multi_mtx r = 0 (0xc0bf334c) locked @ /usr/src/sys/netinet/in.c:506 Jul 7 16:16:09 FreeBSD-VMWare kernel: Sleeping on "usbsyn" with the following non-sleepable locks held: Jul 7 16:16:09 FreeBSD-VMWare kernel: exclusive sleep mutex in_multi_mtx r = 0 (0xc0bf334c) locked @ /usr/src/sys/netinet/in.c:506 Jul 7 16:16:09 FreeBSD-VMWare kernel: Sleeping on "usbsyn" with the following non-sleepable locks held: Jul 7 16:16:09 FreeBSD-VMWare kernel: exclusive sleep mutex in_multi_mtx r = 0 (0xc0bf334c) locked @ /usr/src/sys/netinet/in.c:506 Jul 7 16:16:09 FreeBSD-VMWare kernel: Sleeping on "usbsyn" with the following non-sleepable locks held: Jul 7 16:16:09 FreeBSD-VMWare kernel: exclusive sleep mutex in_multi_mtx r = 0 (0xc0bf334c) locked @ /usr/src/sys/netinet/in.c:506 Jul 7 16:16:09 FreeBSD-VMWare kernel: Sleeping on "usbsyn" with the following non-sleepable locks held: Jul 7 16:16:09 FreeBSD-VMWare kernel: exclusive sleep mutex in_multi_mtx r = 0 (0xc0bf334c) locked @ /usr/src/sys/netinet/in.c:506 Jul 7 16:16:09 FreeBSD-VMWare kernel: Sleeping on "usbsyn" with the following non-sleepable locks held: Jul 7 16:16:09 FreeBSD-VMWare kernel: exclusive sleep mutex in_multi_mtx r = 0 (0xc0bf334c) locked @ /usr/src/sys/netinet/in.c:506 Jul 7 16:16:09 FreeBSD-VMWare kernel: Sleeping on "usbsyn" with the following non-sleepable locks held: Jul 7 16:16:09 FreeBSD-VMWare kernel: exclusive sleep mutex in_multi_mtx r = 0 (0xc0bf334c) locked @ /usr/src/sys/netinet/ in_mcast.c:317 Jul 7 16:16:09 FreeBSD-VMWare kernel: Sleeping on "usbsyn" with the following non-sleepable locks held: Jul 7 16:16:09 FreeBSD-VMWare kernel: exclusive sleep mutex in_multi_mtx r = 0 (0xc0bf334c) locked @ /usr/src/sys/netinet/ in_mcast.c:317 Jul 7 16:16:09 FreeBSD-VMWare kernel: Sleeping on "usbsyn" with the following non-sleepable locks held: Jul 7 16:16:09 FreeBSD-VMWare kernel: exclusive sleep mutex in_multi_mtx r = 0 (0xc0bf334c) locked @ /usr/src/sys/netinet/ in_mcast.c:317 Jul 7 16:16:09 FreeBSD-VMWare kernel: Sleeping on "usbsyn" with the following non-sleepable locks held: Jul 7 16:16:09 FreeBSD-VMWare kernel: exclusive sleep mutex in_multi_mtx r = 0 (0xc0bf334c) locked @ /usr/src/sys/netinet/ in_mcast.c:317 Jul 7 16:16:09 FreeBSD-VMWare kernel: Sleeping on "usbsyn" with the following non-sleepable locks held: Jul 7 16:16:09 FreeBSD-VMWare kernel: exclusive sleep mutex in_multi_mtx r = 0 (0xc0bf334c) locked @ /usr/src/sys/netinet/ in_mcast.c:317 Jul 7 16:16:09 FreeBSD-VMWare kernel: Sleeping on "usbsyn" with the following non-sleepable locks held: Jul 7 16:16:09 FreeBSD-VMWare kernel: exclusive sleep mutex in_multi_mtx r = 0 (0xc0bf334c) locked @ /usr/src/sys/netinet/ in_mcast.c:317 Jul 7 16:16:12 FreeBSD-VMWare kernel: Sleeping on "usbsyn" with the following non-sleepable locks held: Jul 7 16:16:12 FreeBSD-VMWare kernel: exclusive sleep mutex in_multi_mtx r = 0 (0xc0bf334c) locked @ /usr/src/sys/netinet/in.c:506 Jul 7 16:16:12 FreeBSD-VMWare kernel: Sleeping on "usbsyn" with the following non-sleepable locks held: Jul 7 16:16:12 FreeBSD-VMWare kernel: exclusive sleep mutex in_multi_mtx r = 0 (0xc0bf334c) locked @ /usr/src/sys/netinet/in.c:506 Jul 7 16:16:12 FreeBSD-VMWare kernel: Sleeping on "usbsyn" with the following non-sleepable locks held: Jul 7 16:16:12 FreeBSD-VMWare kernel: exclusive sleep mutex in_multi_mtx r = 0 (0xc0bf334c) locked @ /usr/src/sys/netinet/in.c:506 Jul 7 16:16:12 FreeBSD-VMWare kernel: Sleeping on "usbsyn" with the following non-sleepable locks held: Jul 7 16:16:12 FreeBSD-VMWare kernel: exclusive sleep mutex in_multi_mtx r = 0 (0xc0bf334c) locked @ /usr/src/sys/netinet/in.c:506 Jul 7 16:16:12 FreeBSD-VMWare kernel: Sleeping on "usbsyn" with the following non-sleepable locks held: Jul 7 16:16:12 FreeBSD-VMWare kernel: exclusive sleep mutex in_multi_mtx r = 0 (0xc0bf334c) locked @ /usr/src/sys/netinet/in.c:506 Jul 7 16:16:12 FreeBSD-VMWare kernel: Sleeping on "usbsyn" with the following non-sleepable locks held: Jul 7 16:16:12 FreeBSD-VMWare kernel: exclusive sleep mutex in_multi_mtx r = 0 (0xc0bf334c) locked @ /usr/src/sys/netinet/in.c:506 Jul 7 16:16:12 FreeBSD-VMWare kernel: Sleeping on "usbsyn" with the following non-sleepable locks held: Jul 7 16:16:12 FreeBSD-VMWare kernel: exclusive sleep mutex in_multi_mtx r = 0 (0xc0bf334c) locked @ /usr/src/sys/netinet/ in_mcast.c:317 Jul 7 16:16:12 FreeBSD-VMWare kernel: Sleeping on "usbsyn" with the following non-sleepable locks held: Jul 7 16:16:12 FreeBSD-VMWare kernel: exclusive sleep mutex in_multi_mtx r = 0 (0xc0bf334c) locked @ /usr/src/sys/netinet/ in_mcast.c:317 Jul 7 16:16:12 FreeBSD-VMWare kernel: Sleeping on "usbsyn" with the following non-sleepable locks held: Jul 7 16:16:12 FreeBSD-VMWare kernel: exclusive sleep mutex in_multi_mtx r = 0 (0xc0bf334c) locked @ /usr/src/sys/netinet/ in_mcast.c:317 Jul 7 16:16:12 FreeBSD-VMWare kernel: Sleeping on "usbsyn" with the following non-sleepable locks held: Jul 7 16:16:12 FreeBSD-VMWare kernel: exclusive sleep mutex in_multi_mtx r = 0 (0xc0bf334c) locked @ /usr/src/sys/netinet/ in_mcast.c:317 Jul 7 16:16:12 FreeBSD-VMWare kernel: Sleeping on "usbsyn" with the following non-sleepable locks held: Jul 7 16:16:12 FreeBSD-VMWare kernel: exclusive sleep mutex in_multi_mtx r = 0 (0xc0bf334c) locked @ /usr/src/sys/netinet/ in_mcast.c:317 Jul 7 16:16:12 FreeBSD-VMWare kernel: Sleeping on "usbsyn" with the following non-sleepable locks held: Jul 7 16:16:12 FreeBSD-VMWare kernel: exclusive sleep mutex in_multi_mtx r = 0 (0xc0bf334c) locked @ /usr/src/sys/netinet/ in_mcast.c:317 Jul 7 16:16:12 FreeBSD-VMWare dhclient: New IP Address (rue0): 10.10.10.228 Jul 7 16:16:12 FreeBSD-VMWare dhclient: New Subnet Mask (rue0): 255.255.255.0 Jul 7 16:16:12 FreeBSD-VMWare dhclient: New Broadcast Address (rue0): 10.10.10.255 Jul 7 16:16:12 FreeBSD-VMWare dhclient: New Routers (rue0): 10.10.10.11 Bert JW Regeer --Apple-Mail-5--586368409-- From owner-freebsd-current@FreeBSD.ORG Sun Jul 8 13:47:06 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5A1D516A41F for ; Sun, 8 Jul 2007 13:47:06 +0000 (UTC) (envelope-from bounces@nabble.com) Received: from kuber.nabble.com (kuber.nabble.com [216.139.236.158]) by mx1.freebsd.org (Postfix) with ESMTP id 31B7113C469 for ; Sun, 8 Jul 2007 13:47:06 +0000 (UTC) (envelope-from bounces@nabble.com) Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1I7Woh-0005EU-J5 for freebsd-current@freebsd.org; Sun, 08 Jul 2007 06:28:47 -0700 Message-ID: <11488718.post@talk.nabble.com> Date: Sun, 8 Jul 2007 06:28:47 -0700 (PDT) From: icaer To: freebsd-current@freebsd.org In-Reply-To: <20070704150312.GB31683@nagual.pp.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: jony1116@hotmail.com References: <1183557221.1799.16.camel@genius.i.cz> <20070704143642.GA31254@nagual.pp.ru> <20070704150312.GB31683@nagual.pp.ru> X-Mailman-Approved-At: Sun, 08 Jul 2007 14:03:06 +0000 Subject: Re: Environment handling broken in /bin/sh with changes to {get,set,put}env() X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jul 2007 13:47:06 -0000 Hi, How to apply this patch,if I want to correct it? rebuild the world?or other method. I try to get the new code by cvsup.But it compiled error( http://www.nabble.com/buildworld-error-tf4032292.html http://www.nabble.com/buildworld-error-tf4032292.html ).So I shouldn't correct this problem. it's bad news for me,I have focus on this problem for 3 days.... Andrey Chernov-2 wrote: > > On Wed, Jul 04, 2007 at 06:36:42PM +0400, Andrey Chernov wrote: >> 2) "s" may point to getenv()-provided value there. So just modifying it >> directly followed by setenv() call will make things inconsistent. >> >> 3) In my version of patch there was savestr() which copy arg to avoid >> this >> situation. >> >> Fix will be to restore var.c to mine variant 1.34 > > You may also try this patch against var.c 1.36: > > Index: var.c > =================================================================== > RCS file: /home/ncvs/src/bin/sh/var.c,v > retrieving revision 1.36 > diff -u -r1.36 var.c > --- var.c 4 Jul 2007 00:00:38 -0000 1.36 > +++ var.c 4 Jul 2007 14:59:19 -0000 > @@ -289,7 +289,7 @@ > setvareq(char *s, int flags) > { > struct var *vp, **vpp; > - char *p; > + char *p, *ss; > int len; > > if (aflag) > @@ -320,10 +320,11 @@ > if (vp == &vmpath || (vp == &vmail && ! mpathset())) > chkmail(1); > if ((vp->flags & VEXPORT) && localevar(s)) { > - p = strchr(s, '='); > + ss = savestr(s); > + p = strchr(ss, '='); > *p = '\0'; > - (void) setenv(s, p + 1, 1); > - *p = '='; > + (void) setenv(ss, p + 1, 1); > + ckfree(ss); > (void) setlocale(LC_ALL, ""); > } > INTON; > @@ -339,10 +340,11 @@ > INTOFF; > *vpp = vp; > if ((vp->flags & VEXPORT) && localevar(s)) { > - p = strchr(s, '='); > + ss = savestr(s); > + p = strchr(ss, '='); > *p = '\0'; > - (void) setenv(s, p + 1, 1); > - *p = '='; > + (void) setenv(ss, p + 1, 1); > + ckfree(ss); > (void) setlocale(LC_ALL, ""); > } > INTON; > @@ -567,7 +569,7 @@ > struct var **vpp; > struct var *vp; > char *name; > - char *p; > + char *p, *ss; > char *cmdname; > int ch, values; > int flag = argv[0][0] == 'r'? VREADONLY : VEXPORT; > @@ -603,10 +605,11 @@ > > vp->flags |= flag; > if ((vp->flags & VEXPORT) && localevar(vp->text)) { > - p = strchr(vp->text, '='); > + ss = savestr(vp->text); > + p = strchr(ss, '='); > *p = '\0'; > - (void) setenv(vp->text, p + 1, 1); > - *p = '='; > + (void) setenv(ss, p + 1, 1); > + ckfree(ss); > (void) setlocale(LC_ALL, ""); > } > goto found; > @@ -788,6 +791,7 @@ > { > struct var **vpp; > struct var *vp; > + char *ss, *eqp; > > vpp = hashvar(s); > for (vp = *vpp ; vp ; vpp = &vp->next, vp = *vpp) { > @@ -798,7 +802,11 @@ > if (*(strchr(vp->text, '=') + 1) != '\0') > setvar(s, nullstr, 0); > if ((vp->flags & VEXPORT) && localevar(vp->text)) { > - unsetenv(s); > + ss = savestr(s); > + if ((eqp = strchr(ss, '=')) != NULL) > + *eqp = '\0'; > + (void) unsetenv(ss); > + ckfree(ss); > setlocale(LC_ALL, ""); > } > vp->flags &= ~VEXPORT; > > -- > http://ache.pp.ru/ > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > -- View this message in context: http://www.nabble.com/Environment-handling-broken-in--bin-sh-with-changes-to-%7Bget%2Cset%2Cput%7Denv%28%29-tf4024589.html#a11488718 Sent from the freebsd-current mailing list archive at Nabble.com. From owner-freebsd-current@FreeBSD.ORG Sun Jul 8 14:16:15 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9F93D16A468; Sun, 8 Jul 2007 14:16:15 +0000 (UTC) (envelope-from avatar@mmlab.cse.yzu.edu.tw) Received: from www.mmlab.cse.yzu.edu.tw (www.mmlab.cse.yzu.edu.tw [140.138.150.166]) by mx1.freebsd.org (Postfix) with ESMTP id 6B96D13C447; Sun, 8 Jul 2007 14:16:15 +0000 (UTC) (envelope-from avatar@mmlab.cse.yzu.edu.tw) Received: by www.mmlab.cse.yzu.edu.tw (qmail, from userid 1000) id 5EBCD8C9F3B; Sun, 8 Jul 2007 21:43:59 +0800 (CST) Received: from localhost (localhost [127.0.0.1]) by www.mmlab.cse.yzu.edu.tw (qmail) with ESMTP id 541D78C9D30; Sun, 8 Jul 2007 21:43:59 +0800 (CST) Date: Sun, 8 Jul 2007 21:43:59 +0800 (CST) From: Tai-hwa Liang To: Sergey Matveychuk In-Reply-To: <4690D5D6.1020602@FreeBSD.org> Message-ID: <0707082143026.54158@www.mmlab.cse.yzu.edu.tw> References: <4690A363.1050307@FreeBSD.org> <20070708102059.GA65610@heff.fud.org.nz> <4690D5D6.1020602@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org, Andrew Thompson Subject: Re: iwi loses ssid X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jul 2007 14:16:15 -0000 On Sun, 8 Jul 2007, Sergey Matveychuk wrote: > Andrew Thompson wrote: >> On Sun, Jul 08, 2007 at 12:42:11PM +0400, Sergey Matveychuk wrote: >>> Hi. >>> >>> After I upgraded to Jul 1 CURRENT my notebook's iwi adapter started work >>> unstable. It loses carrier. When I take a look at ifconfig output I see a >>> strange ssid. After I make ifconfig iwi0 ssid myssid, everything is >>> recovered. Time between ssid losses is accidental. Sometimes minutes, >>> sometimes hours. >> Could you enable logging with 'wlandebug -i iwi0 +roam' and paste the >> output when it switches access points. > > Where can I get it? > % which wlandebug > wlandebug: Command not found. # cd /usr/src/tools/tools/net80211/wlandebug && make all install From owner-freebsd-current@FreeBSD.ORG Sun Jul 8 14:29:07 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1083216A421 for ; Sun, 8 Jul 2007 14:29:07 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from bunrab.catwhisker.org (adsl-63-193-123-122.dsl.snfc21.pacbell.net [63.193.123.122]) by mx1.freebsd.org (Postfix) with ESMTP id AEEBA13C480 for ; Sun, 8 Jul 2007 14:29:06 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from bunrab.catwhisker.org (localhost [127.0.0.1]) by bunrab.catwhisker.org (8.13.3/8.13.3) with ESMTP id l68ET543022561; Sun, 8 Jul 2007 07:29:05 -0700 (PDT) (envelope-from david@bunrab.catwhisker.org) Received: (from david@localhost) by bunrab.catwhisker.org (8.13.3/8.13.1/Submit) id l68ET5tH022560; Sun, 8 Jul 2007 07:29:05 -0700 (PDT) (envelope-from david) Date: Sun, 8 Jul 2007 07:29:05 -0700 From: David Wolfskill To: Marc UBM Bocklet Message-ID: <20070708142905.GB22374@bunrab.catwhisker.org> References: <8cdf6c720707070710k2b7e030v37683e460d983bf9@mail.gmail.com> <20070708111105.C9997@fledge.watson.org> <20070708132545.5604cbe9.ubm@u-boot-man.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+pHx0qQiF2pBVqBT" Content-Disposition: inline In-Reply-To: <20070708132545.5604cbe9.ubm@u-boot-man.de> User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@freebsd.org Subject: Re: status of 7.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jul 2007 14:29:07 -0000 --+pHx0qQiF2pBVqBT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jul 08, 2007 at 01:25:45PM +0200, Marc UBM Bocklet wrote: > ... > I'd like to do some testing, but I'm a little bit afraid of the upgrade > procedure 6.2-stable to -current. Is it possible to do a simple upgrade > if I follow the guidelines in UPGRADE or are there any hidden caveats? > (like "you've to recompile all installed ports", etc. :-)) It hasn't been a problem in my experience to date. Each of the 4 slices on my laptop is bootable, with its own / and /usr; the swap space and all other file systems are mounted in the same logical places in the tree (such as /var and /home --and in direct response to your query, /usr/local is a symlink to a place in one of these common file systems). I just finished building today's STABLE (RELENG_6) on slice 1, then updated all installed ports that warranted it; I'm now updating today's CURRENT (HEAD) on slice 4: g1-1(7.0-C)[1] uname -a FreeBSD g1-1.catwhisker.org. 7.0-CURRENT FreeBSD 7.0-CURRENT #476: Sat Jul = 7 10:00:45 PDT 2007 root@g1-1.catwhisker.org.:/common/S4/obj/usr/src/s= ys/CANARY i386 g1-1(7.0-C)[2]=20 Up until the recent 802.11 code overhaul, CURRENT had been working quite well for me, though I normally only run it while I'm building CURRENT, doing a reality check or two, or some testing for one of the developers. Since that point, my miniPCI wi0 NIC won't associate, so I've fallen back to a PCMCIA an0, which mostly works (but flakes out with a "kernel: an0: xmit failed" message every once in a while; I've found that forcing re-association appears to circumvent the connection-dropping that otherwise results, though that's a gross hack). And I think I goit through the recent sed(1) issues; there weren't many changes in CURRENT in the last 24 hrs. :-} Peace, david --=20 David H. Wolfskill david@catwhisker.org Anything and everything is a (potential) cat toy. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --+pHx0qQiF2pBVqBT Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iEYEARECAAYFAkaQ9K4ACgkQmprOCmdXAD3wPACfT4zUoU0ucgxpZ8KcaYlqEw5a Y7YAnRfWljW3AYxRVKfRC6x3RUgsQU28 =RHwo -----END PGP SIGNATURE----- --+pHx0qQiF2pBVqBT-- From owner-freebsd-current@FreeBSD.ORG Sun Jul 8 14:31:51 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0EEB116A46C for ; Sun, 8 Jul 2007 14:31:51 +0000 (UTC) (envelope-from yuri@darklight.org.ru) Received: from darklight.org.ru (darklight.org.ru [194.186.18.14]) by mx1.freebsd.org (Postfix) with ESMTP id B706613C45A for ; Sun, 8 Jul 2007 14:31:49 +0000 (UTC) (envelope-from yuri@darklight.org.ru) Received: from darklight.org.ru (yuri@darklight.org.ru [127.0.0.1]) by darklight.org.ru (8.14.1/8.14.1) with ESMTP id l68EVamd086424 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 8 Jul 2007 18:31:36 +0400 (MSD) (envelope-from yuri@darklight.org.ru) Received: (from yuri@localhost) by darklight.org.ru (8.14.1/8.14.1/Submit) id l68EVYFC085698; Sun, 8 Jul 2007 18:31:34 +0400 (MSD) (envelope-from yuri@darklight.org.ru) Date: Sun, 8 Jul 2007 18:31:34 +0400 From: Yuri Pankov To: icaer Message-ID: <20070708143134.GB1027@darklight.org.ru> References: <1183557221.1799.16.camel@genius.i.cz> <20070704143642.GA31254@nagual.pp.ru> <20070704150312.GB31683@nagual.pp.ru> <11488718.post@talk.nabble.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="24zk1gE8NUlDmwG9" Content-Disposition: inline In-Reply-To: <11488718.post@talk.nabble.com> User-Agent: Mutt/1.5.16 (2007-06-09) X-Greylist: Sender is SPF-compliant, not delayed by milter-greylist-3.0 (darklight.org.ru [127.0.0.1]); Sun, 08 Jul 2007 18:31:37 +0400 (MSD) Cc: freebsd-current@freebsd.org Subject: Re: Environment handling broken in /bin/sh with changes to {get,set,put}env() X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jul 2007 14:31:51 -0000 --24zk1gE8NUlDmwG9 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jul 08, 2007 at 06:28:47AM -0700, icaer wrote: >=20 > Hi, > How to apply this patch,if I want to correct it? > rebuild the world?or other method. > I try to get the new code by cvsup.But it compiled error( > http://www.nabble.com/buildworld-error-tf4032292.html > http://www.nabble.com/buildworld-error-tf4032292.html ).So I shouldn't > correct this problem. > it's bad news for me,I have focus on this problem for 3 days.... >=20 >=20 It's unrelated to sh brokenness. Check this link: http://lists.freebsd.org/pipermail/freebsd-current/2007-July/074620.html Yuri --24zk1gE8NUlDmwG9 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQBGkPVGeoAklVFrLdgRAo4iAKCHsqzNaxyyda5rQAACJnKGVGPusACeP/Yn 82WF98k+BHX7w70Aqo8sYNk= =6Hin -----END PGP SIGNATURE----- --24zk1gE8NUlDmwG9-- From owner-freebsd-current@FreeBSD.ORG Sun Jul 8 14:45:53 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2859216A46C for ; Sun, 8 Jul 2007 14:45:53 +0000 (UTC) (envelope-from dirk.meyer@dinoex.sub.org) Received: from uucp.dinoex.sub.de (uucp.dinoex.sub.de [194.45.71.2]) by mx1.freebsd.org (Postfix) with ESMTP id A682213C45E for ; Sun, 8 Jul 2007 14:45:52 +0000 (UTC) (envelope-from dirk.meyer@dinoex.sub.org) Received: from uucp.dinoex.sub.de (dinoex@uucp.dinoex.sub.de [194.45.71.2] (may be forged)) by uucp.dinoex.sub.de (8.14.0/8.14.0) with ESMTP id l68EF0Lr019612 for ; Sun, 8 Jul 2007 16:15:15 +0200 (CEST) (envelope-from dirk.meyer@dinoex.sub.org) X-MDaemon-Deliver-To: Received: from build.dinoex.sub.de (dinoex@localhost) by uucp.dinoex.sub.de (8.14.0/8.14.0/Submit) with BSMTP id l68EF0Qb019523 for ; Sun, 8 Jul 2007 16:15:00 +0200 (CEST) (envelope-from dirk.meyer@dinoex.sub.org) To: freebsd-current@freebsd.org Message-ID: From: dirk.meyer@dinoex.sub.org (Dirk Meyer) Organization: privat Date: Sun, 08 Jul 2007 16:13:49 +0200 X-Mailer: Dinoex 1.79 References: <20070703182400.Q1449@baba.farley.org> X-Gateway: ZCONNECT build.dinoex.sub.de [UNIX/Connect 0.94] X-PGP-Fingerprint: 44 16 EC 0A D3 3A 4F 28 8A 8A 47 93 F1 CF 2F 12 X-Copyright: (C) Copyright 2001 by Dirk Meyer -- All rights reserved. X-PGP-Key-Avail: mailto:pgp-public-keys@keys.de.pgp.net Subject:GET 0x331CDA5D X-ZC-VIA: 20070708000000S+2@dinoex.sub.org X-Milter: Spamilter (Reciever: uucp.dinoex.sub.de; Sender-ip: 194.45.71.2; Sender-helo: uucp.dinoex.sub.de; ) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (uucp.dinoex.sub.de [194.45.71.2]); Sun, 08 Jul 2007 16:15:16 +0200 (CEST) Subject: Re: HEADS UP: getenv() and family API change X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jul 2007 14:45:53 -0000 Hallo Sean C. Farley, > Changes in moving to POSIX from historic BSD API: > b. putenv takes a char * instead of const char *. > c. putenv no longer makes a copy of the input string. Can you give more details? An application will break in using this: putenv("PATH=/bin") now taking a char *, this will break with gcc42. kind regards Dirk - Dirk Meyer, Im Grund 4, 34317 Habichtswald, Germany - [dirk.meyer@dinoex.sub.org],[dirk.meyer@guug.de],[dinoex@FreeBSD.org] http://people.freebsd.org/~dinoex/errorlogs/ From owner-freebsd-current@FreeBSD.ORG Sun Jul 8 14:59:46 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E336016A46B for ; Sun, 8 Jul 2007 14:59:46 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (nagual.pp.ru [194.87.13.69]) by mx1.freebsd.org (Postfix) with ESMTP id 6411C13C457 for ; Sun, 8 Jul 2007 14:59:45 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.14.1/8.14.1) with ESMTP id l68ExG7J089033; Sun, 8 Jul 2007 18:59:16 +0400 (MSD) (envelope-from ache@nagual.pp.ru) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nagual.pp.ru; s=default; t=1183906757; bh=nq7z6bROJanaYhpI9bE2bq2JXhuX9+s8Wfa4zM3 QCl8=; l=772; h=Received:Date:From:To:Cc:Subject:Message-ID: Mail-Followup-To:References:MIME-Version:Content-Type: Content-Disposition:In-Reply-To:User-Agent; b=GEsGQVPC9MWTr4lEVi9t uxrSm6engFj+iyhQGp02XrfdmQGEtHkPpNSTrFk6C1ocVBMXcxr2lHfk+UTQi2Nwvt0 vZbOPYbSnNms0fnVPa9QjXBMnjixuleNN3tkD7EWh97WSA8l7GutVwQ7dP3VDvLVyRv ir+8gkFabimQGi9og= Received: (from ache@localhost) by nagual.pp.ru (8.14.1/8.14.1/Submit) id l68ExGgB089031; Sun, 8 Jul 2007 18:59:16 +0400 (MSD) (envelope-from ache) Date: Sun, 8 Jul 2007 18:59:16 +0400 From: Andrey Chernov To: Dirk Meyer Message-ID: <20070708145916.GA88793@nagual.pp.ru> Mail-Followup-To: Andrey Chernov , Dirk Meyer , freebsd-current@freebsd.org References: <20070703182400.Q1449@baba.farley.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.16 (2007-06-09) Cc: freebsd-current@freebsd.org Subject: Re: HEADS UP: getenv() and family API change X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jul 2007 14:59:47 -0000 On Sun, Jul 08, 2007 at 04:13:49PM +0200, Dirk Meyer wrote: > Hallo Sean C. Farley, > > > Changes in moving to POSIX from historic BSD API: > > b. putenv takes a char * instead of const char *. > > c. putenv no longer makes a copy of the input string. > > Can you give more details? > See POSIX description http://www.opengroup.org/onlinepubs/009695399/functions/putenv.html > An application will break in using this: > putenv("PATH=/bin") > > now taking a char *, this will break with gcc42. No break, this is illegal call (because this const _contents_ may be changed with the yet one putenv call). Why do you think gcc uses tlink.c: putenv (xstrdup ("COMPILER_PATH=")); in its own internal code? (like many others) -- http://ache.pp.ru/ From owner-freebsd-current@FreeBSD.ORG Sun Jul 8 15:18:16 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F290916A41F for ; Sun, 8 Jul 2007 15:18:16 +0000 (UTC) (envelope-from egypcio@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.182]) by mx1.freebsd.org (Postfix) with ESMTP id CC12613C457 for ; Sun, 8 Jul 2007 15:18:16 +0000 (UTC) (envelope-from egypcio@gmail.com) Received: by wa-out-1112.google.com with SMTP id j37so1016241waf for ; Sun, 08 Jul 2007 08:18:16 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=LVcz0zTxefjjFRIBhm1v6s3iHXoBGLlsVU6GpgUcWnmWutIDdaFmIhUEzgwbQ0WbaX2bQHz8eO+Mx5PR2q5bKnaN83F0Cgise0XgGTqUZlVxqS831m60nRGccKo7znRfs+H5m+sxNw2iHQ9J7ox/HTQUvlZxx3OLNFDgGJjJ5As= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ka12cU31qUwfCx+4d1Pxbes0qV51QoW6OjLTrXGFa+G8FLoE0dzecMwBC0k0osUlUvphPU2Q4+7Z6EBRRiB3v+GDHqgRWl8hYZQ1+bNHOoph0PIoB/cEDxgWw/AhayvrAZzAWQjRb+MaWdeqMw5UEnX7oGjfzrOdmtxGX8yfdGs= Received: by 10.114.209.1 with SMTP id h1mr2321987wag.1183906294981; Sun, 08 Jul 2007 07:51:34 -0700 (PDT) Received: by 10.115.15.16 with HTTP; Sun, 8 Jul 2007 07:51:34 -0700 (PDT) Message-ID: <8b5ad0e10707080751n7f8e19bdhb36012bd205a767f@mail.gmail.com> Date: Sun, 8 Jul 2007 10:51:34 -0400 From: "=?ISO-8859-1?Q?Zavam,_Vin=EDcius?=" To: MaXX In-Reply-To: <20070708122021.412747c4.maxx@mobistarmail.be> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <20070708093144.GA22598@ceid.upatras.gr> <20070708122021.412747c4.maxx@mobistarmail.be> Cc: freebsd-current@freebsd.org, benjamin.close@clearchain.com Subject: Re: IPW3945ABG -- Support in RELENG 7? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jul 2007 15:18:17 -0000 2007/7/8, MaXX : > On Sun, 8 Jul 2007 12:31:44 +0300 > Marinos Ilias wrote: > > > Hello list, > > Wondering what's the current state of Intel Pro Wireless Support = 3945 ABG support .Anyone knows if there will be support in RELENG_7 , so we= can use finally, our laptops' wifi? > > Hi, > I'm aware of http://www.clearchain.com/wiki/Wpi which seems to be active = and making great progress. But I think we have to be a little more patient = to allow the author to finish his work, or I you feel like you can, give hi= m some help. > > HTH, > -- > MaXX You are right. We need to be patients. I installed the module (20070131-wpi) here into my 62release-p5 box, but could not connect with my AP. ClearChain[1] now says that it can be possible. I'll try it later (-: Benjamin is doing a great job to grant support for 3945. A month ago I wrote an email with some debugs (I used a box with -current) and I sent they to Ben that friendly answered me with what's wrong. [1]; http://www.clearchain.com/wiki/Wpi --=20 Zavam, Vin=EDcius From owner-freebsd-current@FreeBSD.ORG Sun Jul 8 15:21:18 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8E98316A421 for ; Sun, 8 Jul 2007 15:21:18 +0000 (UTC) (envelope-from michiel@boland.org) Received: from neerbosch.nijmegen.internl.net (neerbosch.nijmegen.internl.net [217.149.193.38]) by mx1.freebsd.org (Postfix) with ESMTP id 171B013C45A for ; Sun, 8 Jul 2007 15:21:17 +0000 (UTC) (envelope-from michiel@boland.org) Received: from neerbosch.nijmegen.internl.net by neerbosch.nijmegen.internl.net via neerbosch.nijmegen.internl.net [217.149.193.38] with ESMTP for id l68FLGj1013578 (8.13.4/1.4); Sun, 8 Jul 2007 17:21:16 +0200 (MEST) Received: from localhost by neerbosch.nijmegen.internl.net via mboland@localhost with ESMTP for id l68FLGcM013574 (8.13.4/2.02); Sun, 8 Jul 2007 17:21:16 +0200 (MEST) X-Authentication-Warning: neerbosch.nijmegen.internl.net: mboland owned process doing -bs Date: Sun, 8 Jul 2007 17:21:16 +0200 (MEST) From: Michiel Boland To: freebsd-current@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: confusing kdump output X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jul 2007 15:21:18 -0000 Hi. If a program does something like setsockopt(sock, IPPROTO_TCP, TCP_NOPUSH, &onoff, sizeof onoff) this is reported by kdump as setsockopt(0x2a,0x6,SO_REUSEADDR,0x7fffffffe32c,0x4) Note that it reports SO_REUSEADDR rather than TCP_NOPUSH. This is confusing. It's probably a bit useless to compile all possible printable socket options into kdump, but at least it could be made to not print a symbolic name if the level is, say, not SOL_SOCKET. Cheers Michiel From owner-freebsd-current@FreeBSD.ORG Sun Jul 8 15:23:25 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9FEAC16A468 for ; Sun, 8 Jul 2007 15:23:25 +0000 (UTC) (envelope-from sfpoof@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.230]) by mx1.freebsd.org (Postfix) with ESMTP id 5C11F13C46C for ; Sun, 8 Jul 2007 15:23:25 +0000 (UTC) (envelope-from sfpoof@gmail.com) Received: by wx-out-0506.google.com with SMTP id i29so535312wxd for ; Sun, 08 Jul 2007 08:23:24 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=Oa/CNgMXcHmg4djUrxB3+a6/06H1v9z0FbRABBtTPKujZCjyCa4aM4yg/aMU9IHBeL8CQ16NN3vxLVIzNyxU4XHGf5gOF3wILMere0yFE2QdtprXAjF1+z9zASy7jDIK7mo69zh+2TgGkZH4hfbiTiqkwfNKAeYni9WxYb5VT/M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=A1gNH5NxwB1BwGRH+/HeuurdQh2s1ofoqRw0C40CxXzYe29++/47cEbo8TD0Gz5AAUB04+ctXWuS0gtVUQ+WgE3npv9FxN1XguRcq9CNxQG1zjLaKIE2ylqXSb0k4wcgPQfkz81dEUUoMQ+e7vFWwN8P+NGBHxp8648ApnZoiNk= Received: by 10.90.35.15 with SMTP id i15mr1267960agi.1183908204490; Sun, 08 Jul 2007 08:23:24 -0700 (PDT) Received: by 10.90.100.16 with HTTP; Sun, 8 Jul 2007 08:23:24 -0700 (PDT) Message-ID: Date: Sun, 8 Jul 2007 08:23:24 -0700 From: "Kevin Gerry" To: "Sergey Matveychuk" In-Reply-To: <4690D5D6.1020602@FreeBSD.org> MIME-Version: 1.0 References: <4690A363.1050307@FreeBSD.org> <20070708102059.GA65610@heff.fud.org.nz> <4690D5D6.1020602@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org, Andrew Thompson Subject: Re: iwi loses ssid X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jul 2007 15:23:25 -0000 For wlandebug: cd /usr/src/tools/tools/net80211/wlandebug ; make && make install On 7/8/07, Sergey Matveychuk wrote: > > Andrew Thompson wrote: > > On Sun, Jul 08, 2007 at 12:42:11PM +0400, Sergey Matveychuk wrote: > >> Hi. > >> > >> After I upgraded to Jul 1 CURRENT my notebook's iwi adapter started > work > >> unstable. It loses carrier. When I take a look at ifconfig output I > >> see a strange ssid. After I make ifconfig iwi0 ssid myssid, everything > >> is recovered. Time between ssid losses is accidental. Sometimes > minutes, > >> sometimes hours. > > > > Could you enable logging with 'wlandebug -i iwi0 +roam' and paste the > > output when it switches access points. > > Where can I get it? > % which wlandebug > wlandebug: Command not found. > > > > >> PS. While I wrote this message it resets ssid again to > >> ZXDSL531BII-1A0EE6. It looks like the ssid is always the same. > > > > Is this another AP somewhere? 'ifconfig iwi0 list scan' will show all > > the access points available. > > Even if there is another AP somewhere, should it reset ssid from the > interface? > > -- > Dixi. > Sem. > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Sun Jul 8 16:01:27 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8C13916A41F; Sun, 8 Jul 2007 16:01:27 +0000 (UTC) (envelope-from sem@FreeBSD.org) Received: from mail.ciam.ru (ns.ciam.ru [213.247.195.75]) by mx1.freebsd.org (Postfix) with ESMTP id 4A00813C484; Sun, 8 Jul 2007 16:01:25 +0000 (UTC) (envelope-from sem@FreeBSD.org) Received: from [87.240.16.199] (helo=solem.sem-home.ciam.ru) by mail.ciam.ru with esmtpa (Exim 4.x) id 1I7ZCN-000NDp-Qh; Sun, 08 Jul 2007 20:01:23 +0400 Message-ID: <469109EE.1030303@FreeBSD.org> Date: Sun, 08 Jul 2007 19:59:42 +0400 From: Sergey Matveychuk User-Agent: Thunderbird 2.0.0.0 (X11/20070602) MIME-Version: 1.0 To: Andrew Thompson References: <4690A363.1050307@FreeBSD.org> <20070708102059.GA65610@heff.fud.org.nz> In-Reply-To: <20070708102059.GA65610@heff.fud.org.nz> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: iwi loses ssid X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jul 2007 16:01:27 -0000 Andrew Thompson wrote: > On Sun, Jul 08, 2007 at 12:42:11PM +0400, Sergey Matveychuk wrote: >> Hi. >> >> After I upgraded to Jul 1 CURRENT my notebook's iwi adapter started work >> unstable. It loses carrier. When I take a look at ifconfig output I >> see a strange ssid. After I make ifconfig iwi0 ssid myssid, everything >> is recovered. Time between ssid losses is accidental. Sometimes minutes, >> sometimes hours. > > Could you enable logging with 'wlandebug -i iwi0 +roam' and paste the > output when it switches access points. When everything OK: ul 8 19:49:22 solem kernel: iwi0: sta_roam_check: currssi 80 currate 2 roamrssi 14 roamrate 10 Jul 8 19:49:22 solem kernel: iwi0: macaddr bssid chan rssi rate flag wep essid Jul 8 19:49:22 solem kernel: - 00:19:5b:54:26:39 00:19:5b:54:26:39 6 44 54M ess no! "default" Jul 8 19:49:22 solem kernel: + 00:16:e3:f3:c6:32 00:16:e3:f3:c6:32 11 39 54M ess wep "ZXDSL531BII-1A0EE6" Jul 8 19:49:22 solem kernel: + 00:18:f8:a3:7a:58 00:18:f8:a3:7a:58 11 80 54M ess wep "sem-home"* Jul 8 19:49:37 solem kernel: iwi0: sta_roam_check: currssi 80 currate 2 roamrssi 14 roamrate 10 SSID is reseted to ZXDSL531BII-1A0EE6: Jul 8 19:50:07 solem kernel: iwi0: macaddr bssid chan rssi rate flag wep essid Jul 8 19:50:07 solem kernel: - 00:19:5b:54:26:39 00:19:5b:54:26:39 6 43 54M ess no! "default" Jul 8 19:50:07 solem kernel: + 00:16:e3:f3:c6:32 00:16:e3:f3:c6:32 11 38 54M ess wep "ZXDSL531BII-1A0EE6" Jul 8 19:50:07 solem kernel: ^ 00:18:f8:a3:7a:58 00:18:f8:a3:7a:58 11 80 54M ess wep "sem-home"* Jul 8 19:50:07 solem kernel: iwi0: sta_roam_check: ROAM: curRate 2, roamRate 10, curRssi 80, roamRssi 14 Jul 8 19:50:07 solem kernel: iwi0: link state changed to DOWN How can I protect self from an alien AP? -- Dixi. Sem. From owner-freebsd-current@FreeBSD.ORG Sun Jul 8 16:03:22 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3722716A41F; Sun, 8 Jul 2007 16:03:22 +0000 (UTC) (envelope-from sem@FreeBSD.org) Received: from mail.ciam.ru (ns.ciam.ru [213.247.195.75]) by mx1.freebsd.org (Postfix) with ESMTP id E97C113C45E; Sun, 8 Jul 2007 16:03:21 +0000 (UTC) (envelope-from sem@FreeBSD.org) Received: from [87.240.16.199] (helo=solem.sem-home.ciam.ru) by mail.ciam.ru with esmtpa (Exim 4.x) id 1I7ZEH-000NF9-3G; Sun, 08 Jul 2007 20:03:21 +0400 Message-ID: <46910A66.1010806@FreeBSD.org> Date: Sun, 08 Jul 2007 20:01:42 +0400 From: Sergey Matveychuk User-Agent: Thunderbird 2.0.0.0 (X11/20070602) MIME-Version: 1.0 To: Andrew Thompson References: <4690A363.1050307@FreeBSD.org> <20070708102059.GA65610@heff.fud.org.nz> In-Reply-To: <20070708102059.GA65610@heff.fud.org.nz> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: iwi loses ssid X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jul 2007 16:03:22 -0000 I forgot to show my ifconfig output: iwi0: flags=8843 metric 0 mtu 1500 ether 00:12:f0:1e:1e:5a inet 192.168.0.4 netmask 0xffffffe0 broadcast 192.168.0.31 media: IEEE 802.11 Wireless Ethernet autoselect (OFDM/54Mbps) status: associated ssid sem-home channel 11 (2462 Mhz 11g) bssid 00:18:f8:a3:7a:58 authmode OPEN privacy ON deftxkey 1 wepkey 1:40-bit txpowmax 100 bmiss 10 scanvalid 60 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi11g 14 roam:rate11g 5 protmode CTS bintval 100 -- Dixi. Sem. From owner-freebsd-current@FreeBSD.ORG Sun Jul 8 16:26:02 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0C33B16A468; Sun, 8 Jul 2007 16:26:02 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id D829413C458; Sun, 8 Jul 2007 16:26:01 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.13.8/8.13.8) with ESMTP id l68GQ1FC041920; Sun, 8 Jul 2007 12:26:01 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.8/8.13.8) with ESMTP id l68GQ0B0042672; Sun, 8 Jul 2007 12:26:00 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 9E52673068; Sun, 8 Jul 2007 12:26:00 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070708162600.9E52673068@freebsd-current.sentex.ca> Date: Sun, 8 Jul 2007 12:26:00 -0400 (EDT) X-Virus-Scanned: ClamAV version devel-20070102, clamav-milter version devel-111206 on clamscanner4 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jul 2007 16:26:02 -0000 TB --- 2007-07-08 14:29:33 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-07-08 14:29:33 - starting HEAD tinderbox run for i386/pc98 TB --- 2007-07-08 14:29:33 - cleaning the object tree TB --- 2007-07-08 14:30:01 - checking out the source tree TB --- 2007-07-08 14:30:01 - cd /tinderbox/HEAD/i386/pc98 TB --- 2007-07-08 14:30:01 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-07-08 14:39:28 - building world (CFLAGS=-O2 -pipe) TB --- 2007-07-08 14:39:28 - cd /src TB --- 2007-07-08 14:39:28 - /usr/bin/make -B buildworld >>> World build started on Sun Jul 8 14:39:29 UTC 2007 >>> 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 Sun Jul 8 15:54:17 UTC 2007 TB --- 2007-07-08 15:54:17 - generating LINT kernel config TB --- 2007-07-08 15:54:17 - cd /src/sys/pc98/conf TB --- 2007-07-08 15:54:17 - /usr/bin/make -B LINT TB --- 2007-07-08 15:54:17 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-07-08 15:54:17 - cd /src TB --- 2007-07-08 15:54:17 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Jul 8 15:54:18 UTC 2007 >>> 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 >>> Kernel build for LINT completed on Sun Jul 8 16:18:49 UTC 2007 TB --- 2007-07-08 16:18:49 - building GENERIC kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-07-08 16:18:49 - cd /src TB --- 2007-07-08 16:18:49 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Sun Jul 8 16:18:49 UTC 2007 >>> 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 -x assembler-with-cpp -DLOCORE -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/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 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding /src/sys/i386/i386/support.s cc -c -x assembler-with-cpp -DLOCORE -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/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 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding /src/sys/i386/i386/swtch.s cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/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 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding /src/sys/i386/i386/sys_machdep.c /src/sys/i386/i386/sys_machdep.c: In function 'i386_ldt_grow': /src/sys/i386/i386/sys_machdep.c:697: error: 'NULL_LDT_BASE' undeclared (first use in this function) /src/sys/i386/i386/sys_machdep.c:697: error: (Each undeclared identifier is reported only once /src/sys/i386/i386/sys_machdep.c:697: error: for each function it appears in.) /src/sys/i386/i386/sys_machdep.c:751: warning: passing argument 1 of 'set_user_ldt' from incompatible pointer type *** Error code 1 Stop in /obj/pc98/src/sys/GENERIC. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-07-08 16:26:00 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-07-08 16:26:00 - ERROR: failed to build GENERIC kernel TB --- 2007-07-08 16:26:00 - tinderbox aborted TB --- 0.89 user 2.55 system 6987.27 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Sun Jul 8 16:52:11 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4725B16A400; Sun, 8 Jul 2007 16:52:11 +0000 (UTC) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id 06F5613C465; Sun, 8 Jul 2007 16:52:10 +0000 (UTC) (envelope-from sam@errno.com) Received: from sam-lefflers-powerbook-g4-15.local ([10.0.0.178]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id l68GqAJv097683 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 8 Jul 2007 09:52:10 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <46911636.3030604@errno.com> Date: Sun, 08 Jul 2007 09:52:06 -0700 From: Sam Leffler Organization: Errno Consulting User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) MIME-Version: 1.0 To: Sergey Matveychuk References: <4690A363.1050307@FreeBSD.org> <20070708102059.GA65610@heff.fud.org.nz> <469109EE.1030303@FreeBSD.org> In-Reply-To: <469109EE.1030303@FreeBSD.org> X-Enigmail-Version: 0.95.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Andrew Thompson Subject: Re: iwi loses ssid X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jul 2007 16:52:11 -0000 Sergey Matveychuk wrote: > Andrew Thompson wrote: >> On Sun, Jul 08, 2007 at 12:42:11PM +0400, Sergey Matveychuk wrote: >>> Hi. >>> >>> After I upgraded to Jul 1 CURRENT my notebook's iwi adapter started >>> work unstable. It loses carrier. When I take a look at ifconfig >>> output I see a strange ssid. After I make ifconfig iwi0 ssid myssid, >>> everything is recovered. Time between ssid losses is accidental. >>> Sometimes minutes, sometimes hours. >> >> Could you enable logging with 'wlandebug -i iwi0 +roam' and paste the >> output when it switches access points. > > When everything OK: > ul 8 19:49:22 solem kernel: iwi0: sta_roam_check: currssi 80 currate 2 > roamrssi 14 roamrate 10 > Jul 8 19:49:22 solem kernel: iwi0: macaddr bssid chan > rssi rate flag wep essid > Jul 8 19:49:22 solem kernel: - 00:19:5b:54:26:39 00:19:5b:54:26:39 6 > 44 54M ess no! "default" > Jul 8 19:49:22 solem kernel: + 00:16:e3:f3:c6:32 00:16:e3:f3:c6:32 11 > 39 54M ess wep "ZXDSL531BII-1A0EE6" > Jul 8 19:49:22 solem kernel: + 00:18:f8:a3:7a:58 00:18:f8:a3:7a:58 11 > 80 54M ess wep "sem-home"* > Jul 8 19:49:37 solem kernel: iwi0: sta_roam_check: currssi 80 currate 2 > roamrssi 14 roamrate 10 > > SSID is reseted to ZXDSL531BII-1A0EE6: > Jul 8 19:50:07 solem kernel: iwi0: macaddr bssid chan > rssi rate flag wep essid > Jul 8 19:50:07 solem kernel: - 00:19:5b:54:26:39 00:19:5b:54:26:39 6 > 43 54M ess no! "default" > Jul 8 19:50:07 solem kernel: + 00:16:e3:f3:c6:32 00:16:e3:f3:c6:32 11 > 38 54M ess wep "ZXDSL531BII-1A0EE6" > Jul 8 19:50:07 solem kernel: ^ 00:18:f8:a3:7a:58 00:18:f8:a3:7a:58 11 > 80 54M ess wep "sem-home"* > Jul 8 19:50:07 solem kernel: iwi0: sta_roam_check: ROAM: curRate 2, > roamRate 10, curRssi 80, roamRssi 14 > Jul 8 19:50:07 solem kernel: iwi0: link state changed to DOWN > > How can I protect self from an alien AP? > First thing to notice is that iwi is reporting rssi that is not calibrated to .5 dBm units. Initially this is unimportant since the threshold is 7 dBm (14) and hence it doesn't trigger roaming--but later on it does suppress roaming back to your desired ap. However the current tx rate in the first case is set to 1 Mb/s (currssi 2) and that is below the roaming threshold (5 Mb/s) so net80211 looks to roam to a better ap. You can avoid this several ways: ifconfig iwi -bgscan will disable bg scanning and implicitly roaming but then you'll potentially do a full scan when you need to roam or respond to your ap dropping you (e.g. due to inactivity). Otherwise I think you can do: ifconfig iwi roam:rate11g 1 to set the threshold on the tx rate to 1 Mb/s. But the better fix is to correct the driver so it reports calibrated rssi and figure out why the tx rate is dropping so low given the apparent strong signal. Another way to disable roaming is: ifconfig iwi roaming device though that won't work if you're using wpa_supplicant as it will set roaming mode to manual so it can control operation of the net80211 state machine. Sam From owner-freebsd-current@FreeBSD.ORG Sun Jul 8 16:10:10 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D6EDF16A46C; Sun, 8 Jul 2007 16:10:10 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (mail.soaustin.net [207.200.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id B259413C468; Sun, 8 Jul 2007 16:10:10 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: by mail.soaustin.net (Postfix, from userid 502) id 6CB38B3A; Sun, 8 Jul 2007 11:10:10 -0500 (CDT) Date: Sun, 8 Jul 2007 11:10:10 -0500 To: Robert Watson Message-ID: <20070708161010.GB23944@soaustin.net> References: <8cdf6c720707070710k2b7e030v37683e460d983bf9@mail.gmail.com> <20070708111105.C9997@fledge.watson.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070708111105.C9997@fledge.watson.org> User-Agent: Mutt/1.5.9i From: linimon@lonesome.com (Mark Linimon) X-Mailman-Approved-At: Sun, 08 Jul 2007 17:14:29 +0000 Cc: Paul Eskello , freebsd-current@freebsd.org Subject: Re: status of 7.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jul 2007 16:10:10 -0000 On Sun, Jul 08, 2007 at 11:15:49AM +0100, Robert Watson wrote: > At this point, the imperative for developers is to wrap up any remaining > outstanding features and work on testing and bug fixing. Don't forget that 6.3 will follow right on the heels of 7.0, so we need to be thinking about MFCs of bugfixes as well. mcl From owner-freebsd-current@FreeBSD.ORG Sun Jul 8 17:17:31 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 016BC16A476; Sun, 8 Jul 2007 17:17:31 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (nagual.pp.ru [194.87.13.69]) by mx1.freebsd.org (Postfix) with ESMTP id 6E08D13C4BB; Sun, 8 Jul 2007 17:17:30 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.14.1/8.14.1) with ESMTP id l68HHSxd090815; Sun, 8 Jul 2007 21:17:28 +0400 (MSD) (envelope-from ache@nagual.pp.ru) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nagual.pp.ru; s=default; t=1183915049; bh=mGizx7K62AUiaa+Lp2q2NfEQImRNHufvJRWumb5 dYkE=; l=986; h=Received:Date:From:To:Subject:Message-ID: Mail-Followup-To:References:MIME-Version:Content-Type: Content-Disposition:In-Reply-To:User-Agent; b=dCmCctxw9HSHS4Pqir38 oZMc2+UTV4AtCNaOzdJl4bUM0CGerMnrpBTpuQYQ+mxSWcROzl9ZbfHRA56v+Aa4TVw XCd1RclgLx/O/HW+3wOgbMAqroUKRUGwQVcCXVhGgNcjgsZZhpcQt3GaDhTvP0VTXdd wHqs0FWlyCp4dtcGY= Received: (from ache@localhost) by nagual.pp.ru (8.14.1/8.14.1/Submit) id l68HHSQp090814; Sun, 8 Jul 2007 21:17:28 +0400 (MSD) (envelope-from ache) Date: Sun, 8 Jul 2007 21:17:27 +0400 From: Andrey Chernov To: "Sean C. Farley" , Robert Watson , freebsd-current , Michal Mertl Message-ID: <20070708171727.GA90490@nagual.pp.ru> Mail-Followup-To: Andrey Chernov , "Sean C. Farley" , Robert Watson , freebsd-current , Michal Mertl References: <20070704235630.GA42227@nagual.pp.ru> <20070704215154.O77978@thor.farley.org> <20070705115816.GA50506@nagual.pp.ru> <20070705105922.F98700@thor.farley.org> <20070707130859.GA96605@nagual.pp.ru> <20070707131359.GB96605@nagual.pp.ru> <20070707133102.C14065@thor.farley.org> <20070707191835.GA4368@nagual.pp.ru> <20070707205410.B14065@thor.farley.org> <20070708020940.GA80166@nagual.pp.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070708020940.GA80166@nagual.pp.ru> User-Agent: Mutt/1.5.16 (2007-06-09) Cc: Subject: Re: Environment handling broken in /bin/sh with changes to {get,set,put}env() X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jul 2007 17:17:31 -0000 On Sun, Jul 08, 2007 at 06:09:40AM +0400, Andrey Chernov wrote: > On Sat, Jul 07, 2007 at 09:03:59PM -0500, Sean C. Farley wrote: > > > > Surprisingly, keeping the pointers saved time even if calling setenv(). > > Ok. It feels like time to commit comes :) Hmm. I just think a bit more and feel worry about that place in the merge code: *equals = '\0'; if (setenv(*env, equals + 1, 1) == -1) return (-1); *equals = '='; because it modifies memory which may be treated like const one. Consider following scenario: getenv() is not thread-safe, but may be called by thread-safe app if it is sure no other *env() calls in progress. In the same time another thread of this app use environ directly say for exec(), assuming it is const. In the middle of that getenv() modifies environ by *equals = '\0'; Could you please make setenv() wrapper like that to avoid modifying merged environ in the middle? __lsetenv(str, str_len, value) -- http://ache.pp.ru/ From owner-freebsd-current@FreeBSD.ORG Sun Jul 8 17:44:09 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.ORG Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 935AD16A46C for ; Sun, 8 Jul 2007 17:44:09 +0000 (UTC) (envelope-from hugo@barafranca.com) Received: from mail.barafranca.com (mail.barafranca.com [67.19.101.164]) by mx1.freebsd.org (Postfix) with ESMTP id 708D813C457 for ; Sun, 8 Jul 2007 17:44:09 +0000 (UTC) (envelope-from hugo@barafranca.com) Received: from localhost (localhost [127.0.0.1]) by mail.barafranca.com (Postfix) with ESMTP id 7ADAAC480C for ; Sun, 8 Jul 2007 18:21:06 +0000 (UTC) Received: from mail.barafranca.com ([67.19.101.164]) by localhost (mail.barafranca.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 64107-06 for ; Sun, 8 Jul 2007 18:20:29 +0000 (UTC) Received: from nexus.bsdlan.org (a213-22-26-49.cpe.netcabo.pt [213.22.26.49]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.barafranca.com (Postfix) with ESMTP id 23582C47EF for ; Sun, 8 Jul 2007 18:20:28 +0000 (UTC) Message-ID: <46912244.4060009@barafranca.com> Date: Sun, 08 Jul 2007 18:43:32 +0100 From: Hugo Silva User-Agent: Thunderbird 2.0.0.0 (X11/20070609) MIME-Version: 1.0 To: freebsd-current@FreeBSD.ORG References: <8cdf6c720707070710k2b7e030v37683e460d983bf9@mail.gmail.com> <20070708111105.C9997@fledge.watson.org> <20070708132545.5604cbe9.ubm@u-boot-man.de> In-Reply-To: <20070708132545.5604cbe9.ubm@u-boot-man.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at barafranca.com X-Spam-Status: No, score=0 tagged_above=-1 required=4 tests=[none] X-Spam-Score: 0 X-Spam-Level: Cc: Subject: Re: status of 7.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jul 2007 17:44:09 -0000 Marc UBM Bocklet wrote: > On Sun, 8 Jul 2007 11:15:49 +0100 (BST) > Robert Watson wrote: > > >> On Sat, 7 Jul 2007, Paul Eskello wrote: >> >> >>> I was wondering when to expect 7.0 release ? Did I miss the >>> schedule. Any showstoppers ? when to expect RC1 ? >>> >>> Just curious. >>> >>> Have a great weekend. >>> >> Ken may respond in a more detailed form, but the current stage is >> that we are waiting for the feature set to finally settle and some >> known outstanding issues to resolve themselves, at which point we'll >> cut a first beta in the next 2-4 weeks. As a precursor to that, >> monthly snapshots will likely get built and released in the next >> couple of days. Hopefully testing and feedback from that will allow >> us to nail down a more specific schedule for the release itself. >> >> At this point, the imperative for developers is to wrap up any >> remaining outstanding features and work on testing and bug fixing. >> Likewise users :-). We often find that even early adoption sites only >> really start testing during the RC cycle, and that's far too late to >> make larger changes that may be required to address some sorts of >> stability issues. Getting people doing testing the whole way through >> the cycle makes a big difference in the effectiveness of the test >> cycle. >> > > > I'd like to do some testing, but I'm a little bit afraid of the upgrade > procedure 6.2-stable to -current. Is it possible to do a simple upgrade > if I follow the guidelines in UPGRADE or are there any hidden caveats? > (like "you've to recompile all installed ports", etc. :-)) > > Bye > Marc > > I'm running -CURRENT now and will happily upgrade once there's a beta/rc out. Hugo From owner-freebsd-current@FreeBSD.ORG Sun Jul 8 18:14:49 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3F1D216A41F; Sun, 8 Jul 2007 18:14:49 +0000 (UTC) (envelope-from scf@FreeBSD.org) Received: from mail.farley.org (farley.org [67.64.95.201]) by mx1.freebsd.org (Postfix) with ESMTP id D557613C45A; Sun, 8 Jul 2007 18:14:48 +0000 (UTC) (envelope-from scf@FreeBSD.org) Received: from thor.farley.org (thor.farley.org [192.168.1.5]) by mail.farley.org (8.14.1/8.14.1) with ESMTP id l68IFw2I000729; Sun, 8 Jul 2007 13:15:58 -0500 (CDT) (envelope-from scf@FreeBSD.org) Date: Sun, 8 Jul 2007 13:14:31 -0500 (CDT) From: "Sean C. Farley" To: Andrey Chernov In-Reply-To: <20070708171727.GA90490@nagual.pp.ru> Message-ID: <20070708125905.F14065@thor.farley.org> References: <20070704235630.GA42227@nagual.pp.ru> <20070704215154.O77978@thor.farley.org> <20070705115816.GA50506@nagual.pp.ru> <20070705105922.F98700@thor.farley.org> <20070707130859.GA96605@nagual.pp.ru> <20070707131359.GB96605@nagual.pp.ru> <20070707133102.C14065@thor.farley.org> <20070707191835.GA4368@nagual.pp.ru> <20070707205410.B14065@thor.farley.org> <20070708020940.GA80166@nagual.pp.ru> <20070708171727.GA90490@nagual.pp.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.1 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on mail.farley.org Cc: freebsd-current , Robert Watson , Michal Mertl Subject: Re: Environment handling broken in /bin/sh with changes to {get,set,put}env() X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jul 2007 18:14:49 -0000 On Sun, 8 Jul 2007, Andrey Chernov wrote: > On Sun, Jul 08, 2007 at 06:09:40AM +0400, Andrey Chernov wrote: >> On Sat, Jul 07, 2007 at 09:03:59PM -0500, Sean C. Farley wrote: >>> >>> Surprisingly, keeping the pointers saved time even if calling >>> setenv(). >> >> Ok. It feels like time to commit comes :) > > Hmm. I just think a bit more and feel worry about that place in the > merge code: > > *equals = '\0'; > if (setenv(*env, equals + 1, 1) == -1) > return (-1); > *equals = '='; > because it modifies memory which may be treated like const one. > > Consider following scenario: getenv() is not thread-safe, but may be > called by thread-safe app if it is sure no other *env() calls in > progress. In the same time another thread of this app use environ > directly say for exec(), assuming it is const. In the middle of that > getenv() modifies environ by *equals = '\0'; SUSv3 states that that is not a safe assumption to make. Read the paragraph starting with "Conforming multi-threaded" from exec(3)[1]. It basically equates direct use of the environ variable as the same as any *env() call. > Could you please make setenv() wrapper like that to avoid modifying > merged environ in the middle? > __lsetenv(str, str_len, value) I could add this as a feature later. Unfortunately, unless I can lock the use of environ, an application could do this even with the 6-STABLE version of *env() functions. I have been pondering about thread-safety in a future release of these functions (8-CURRENT), but it may not be possible since environ is exposed. Sean 1. http://www.opengroup.org/onlinepubs/000095399/functions/exec.html -- scf@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Sun Jul 8 18:35:38 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1278216A468 for ; Sun, 8 Jul 2007 18:35:38 +0000 (UTC) (envelope-from ubm@u-boot-man.de) Received: from mail.upper.net (mail.upper.net [62.75.224.33]) by mx1.freebsd.org (Postfix) with ESMTP id A74C913C455 for ; Sun, 8 Jul 2007 18:35:37 +0000 (UTC) (envelope-from ubm@u-boot-man.de) Received: from ubm.mine.nu (p57AE1F07.dip0.t-ipconnect.de [87.174.31.7]) (authenticated bits=0) by mail.upper.net (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l68IZZAx011075 for ; Sun, 8 Jul 2007 20:35:35 +0200 Date: Sun, 8 Jul 2007 20:42:55 +0200 From: Marc "UBM" Bocklet To: freebsd-current@freebsd.org Message-Id: <20070708204255.01e19101.ubm@u-boot-man.de> In-Reply-To: <4690CFAA.30004@gmail.com> References: <8cdf6c720707070710k2b7e030v37683e460d983bf9@mail.gmail.com> <20070708111105.C9997@fledge.watson.org> <20070708132545.5604cbe9.ubm@u-boot-man.de> <4690CFAA.30004@gmail.com> X-Mailer: Sylpheed 2.4.0 (GTK+ 2.10.12; i386-portbld-freebsd6.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: status of 7.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jul 2007 18:35:38 -0000 On Sun, 08 Jul 2007 13:51:06 +0200 Rene Ladan wrote: > Marc UBM Bocklet schreef: > > > > > > I'd like to do some testing, but I'm a little bit afraid of the > > upgrade procedure 6.2-stable to -current. Is it possible to do a > > simple upgrade if I follow the guidelines in UPGRADE or are there > > any hidden caveats? (like "you've to recompile all installed > > ports", etc. :-)) > > > [...don't try this on a production box...] > > Just following the procedure and the changelog entries in > /usr/src/UPDATING should do the job. It's probably best to cvsup > into a new directory and clean /usr/obj before beginning the update. > That's how I updated from RELENG_6 to HEAD back in November 2006. > > Since we have a misc/compat6x port and a COMPAT_FREEBSD6 kernel > configuaration option, it shouldn't be necessary to rebuild all your > ports. Thanks a lot to you and David for the quick response, I'll try updating tomorrow :-) Bye Marc -- "And what rough beast, its hour come round at last, Slouches towards Bethlehem to be born?" W.B. Yeats, The Second Coming From owner-freebsd-current@FreeBSD.ORG Sun Jul 8 18:38:25 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EB24316A421; Sun, 8 Jul 2007 18:38:25 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (nagual.pp.ru [194.87.13.69]) by mx1.freebsd.org (Postfix) with ESMTP id 7D2FD13C4BD; Sun, 8 Jul 2007 18:38:25 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.14.1/8.14.1) with ESMTP id l68IcOpJ091549; Sun, 8 Jul 2007 22:38:24 +0400 (MSD) (envelope-from ache@nagual.pp.ru) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nagual.pp.ru; s=default; t=1183919904; bh=fhF5eg3+Rsx9i26lw0qzVu8jiMmcU9ygjV7fods lQmY=; l=2079; h=Received:Date:From:To:Cc:Subject:Message-ID: Mail-Followup-To:References:MIME-Version:Content-Type: Content-Disposition:In-Reply-To:User-Agent; b=nE/NjC0d4aub7O0N91Ma 9WjKBCq8oXD0r17qFk9jqUcgh5GEgRjxi/T4f6PpzPyOQg6QmTzy1mP9u+LY1zcS03Q ZEIGo1NxO2i0XN3H+vIYk6suTSp+6D62VFlfBPwFt1JBn0bW1BGtzYcK7H9tRZWsqW9 YnOXdIuWjou9NuNB8= Received: (from ache@localhost) by nagual.pp.ru (8.14.1/8.14.1/Submit) id l68IcNh2091548; Sun, 8 Jul 2007 22:38:24 +0400 (MSD) (envelope-from ache) Date: Sun, 8 Jul 2007 22:38:23 +0400 From: Andrey Chernov To: "Sean C. Farley" Message-ID: <20070708183823.GA91359@nagual.pp.ru> Mail-Followup-To: Andrey Chernov , "Sean C. Farley" , Robert Watson , freebsd-current , Michal Mertl References: <20070705115816.GA50506@nagual.pp.ru> <20070705105922.F98700@thor.farley.org> <20070707130859.GA96605@nagual.pp.ru> <20070707131359.GB96605@nagual.pp.ru> <20070707133102.C14065@thor.farley.org> <20070707191835.GA4368@nagual.pp.ru> <20070707205410.B14065@thor.farley.org> <20070708020940.GA80166@nagual.pp.ru> <20070708171727.GA90490@nagual.pp.ru> <20070708125905.F14065@thor.farley.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070708125905.F14065@thor.farley.org> User-Agent: Mutt/1.5.16 (2007-06-09) Cc: freebsd-current , Robert Watson , Michal Mertl Subject: Re: Environment handling broken in /bin/sh with changes to {get,set,put}env() X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jul 2007 18:38:26 -0000 On Sun, Jul 08, 2007 at 01:14:31PM -0500, Sean C. Farley wrote: > SUSv3 states that that is not a safe assumption to make. Read the > paragraph starting with "Conforming multi-threaded" from exec(3)[1]. It > basically equates direct use of the environ variable as the same as any > *env() call. >From my reading, not exactly so: "Conforming multi-threaded applications shall not use the environ variable to access or modify any environment variable while any other thread is concurrently modifying any environment variable. A call to any function dependent on any environment variable shall be considered a use of the environ variable to access that environment variable." They say "while any other thread is concurrently _modifying_ any environment variable" but getenv() is not supposed to modify environ in any way. They cleary separate "access" and "modify" terms in this paragraph. >From getenv(): "The getenv() function shall _search_ the environment of the calling process" I.e. no "modify" word found in getenv() description (and whole manpage). Meanwhile, they say in getenv(): "If the application modifies environ or the pointers to which it points, the behavior of getenv() is undefined." So we are free here to do the most reasonable strategy (as undefined). Modifying environ is "undefined" too, of course, but not looks so reasonable. >> Could you please make setenv() wrapper like that to avoid modifying >> merged environ in the middle? >> __lsetenv(str, str_len, value) > > I could add this as a feature later. Unfortunately, unless I can lock > the use of environ, an application could do this even with the 6-STABLE > version of *env() functions. I have been pondering about thread-safety > in a future release of these functions (8-CURRENT), but it may not be > possible since environ is exposed. Even in case it may happens with 6-STABLE, we better not repeat the way lead to mistakes again :) > Sean > 1. http://www.opengroup.org/onlinepubs/000095399/functions/exec.html -- http://ache.pp.ru/ From owner-freebsd-current@FreeBSD.ORG Sun Jul 8 18:42:42 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1BD0316A46D for ; Sun, 8 Jul 2007 18:42:42 +0000 (UTC) (envelope-from almarrie@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.241]) by mx1.freebsd.org (Postfix) with ESMTP id CCE3113C4CC for ; Sun, 8 Jul 2007 18:42:41 +0000 (UTC) (envelope-from almarrie@gmail.com) Received: by an-out-0708.google.com with SMTP id c14so155971anc for ; Sun, 08 Jul 2007 11:42:41 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=JZhmdj64Zqkoocm32pcR+dXCfuPfhOcaQjdlJ1kRDheMlUrBSEAVwJms1cRk0cggOkLORp7ctOux1snlE5oQ9V4Pc+PFaX6mULPQprY28jWcVv44Xu2ow0tepNaE8uQPoMrIMMNA6VgXycfzW2PRfmjAwA27wRZl7m3CNUmML/Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=YC8n7Ye83oSTktLo7E3S1wE2+ibmLZpa9IONDRktpTJThyOeu9HIeTDn7qsG/O9nUGg17G6IfN0ljGooLhixSLvJybdL6RuUeiUfYQBbThE398o8KAXa4xZIkRTdVW3J+dvud5VQ6oGmABk/Zj4E+q6v1fvM9K17TjzZG56ahjo= Received: by 10.100.38.16 with SMTP id l16mr1259437anl.1183920161168; Sun, 08 Jul 2007 11:42:41 -0700 (PDT) Received: by 10.100.9.14 with HTTP; Sun, 8 Jul 2007 11:42:41 -0700 (PDT) Message-ID: <499c70c0707081142x7a055787x67350667fb921cd2@mail.gmail.com> Date: Sun, 8 Jul 2007 21:42:41 +0300 From: "Abdullah Ibn Hamad Al-Marri" To: "Rene Ladan" In-Reply-To: <4690CFAA.30004@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <8cdf6c720707070710k2b7e030v37683e460d983bf9@mail.gmail.com> <20070708111105.C9997@fledge.watson.org> <20070708132545.5604cbe9.ubm@u-boot-man.de> <4690CFAA.30004@gmail.com> Cc: freebsd-current@freebsd.org, Marc UBM Bocklet Subject: Re: status of 7.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jul 2007 18:42:42 -0000 On 7/8/07, Rene Ladan wrote: > Marc UBM Bocklet schreef: > > > > > > I'd like to do some testing, but I'm a little bit afraid of the upgrade > > procedure 6.2-stable to -current. Is it possible to do a simple upgrade > > if I follow the guidelines in UPGRADE or are there any hidden caveats? > > (like "you've to recompile all installed ports", etc. :-)) > > > [...don't try this on a production box...] I run AMD64 arch in my server Intel Core 2 Duo E6600 with 2 GB of ram, with SCHED_SMP and I have no real problems. I did that to gain the SCHED peformance was done in 7.0 and MySQL 5.0.41 runs with no single issue or crash since 2 weeks with SCHED_SMP and since 2 months with SCHED_ULE in both i386 and AMD64. AMD64 runs MySQL faster, and Jeff removed more giant locked which made it performs better. So it's not a real problem trying it in heavy production server. > > HTH, > Rene -- Regards, -Abdullah Ibn Hamad Al-Marri Arab Portal http://www.WeArab.Net/ From owner-freebsd-current@FreeBSD.ORG Sun Jul 8 19:19:42 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0078316A400 for ; Sun, 8 Jul 2007 19:19:42 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from relay02.kiev.sovam.com (relay02.kiev.sovam.com [62.64.120.197]) by mx1.freebsd.org (Postfix) with ESMTP id 98B0D13C480 for ; Sun, 8 Jul 2007 19:19:41 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from [89.162.146.170] (helo=skuns.kiev.zoral.com.ua) by relay02.kiev.sovam.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1I7cIE-000Gjh-Tn for current@freebsd.org; Sun, 08 Jul 2007 22:19:40 +0300 Received: from deviant.kiev.zoral.com.ua (root@[10.1.1.148]) by skuns.kiev.zoral.com.ua (8.14.1/8.14.1) with ESMTP id l68JJULe059774 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 8 Jul 2007 22:19:30 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.1/8.14.1) with ESMTP id l68JJTOs020191; Sun, 8 Jul 2007 22:19:29 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.1/8.14.1/Submit) id l68JJTOt020190; Sun, 8 Jul 2007 22:19:29 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 8 Jul 2007 22:19:28 +0300 From: Kostik Belousov To: Tai-hwa Liang Message-ID: <20070708191928.GM2200@deviant.kiev.zoral.com.ua> References: <20070703180141.GJ2200@deviant.kiev.zoral.com.ua> <20070705144443.GV2200@deviant.kiev.zoral.com.ua> <20070707160042.GJ2200@deviant.kiev.zoral.com.ua> <07070809441413.59322@www.mmlab.cse.yzu.edu.tw> <20070708024815.GK2200@deviant.kiev.zoral.com.ua> <0707082155317.77206@www.mmlab.cse.yzu.edu.tw> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="XCKmtPOB2gS6QFgg" Content-Disposition: inline In-Reply-To: <0707082155317.77206@www.mmlab.cse.yzu.edu.tw> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.90.3, clamav-milter version 0.90.3 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.2.1 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on skuns.kiev.zoral.com.ua X-Scanner-Signature: f216f799903dddc2f9accd11d8a1fded X-DrWeb-checked: yes X-SpamTest-Envelope-From: kostikbel@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Header: Not Detected X-SpamTest-Info: Profiles 1190 [July 06 2007] X-SpamTest-Info: helo_type=3 X-SpamTest-Method: none X-SpamTest-Rate: 0 X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0255], KAS30/Release Cc: current@freebsd.org Subject: Re: HEADS UP: destroy_dev_sched() KPI in the tree X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jul 2007 19:19:42 -0000 --XCKmtPOB2gS6QFgg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jul 08, 2007 at 10:00:14PM +0800, Tai-hwa Liang wrote: > On Sun, 8 Jul 2007, Kostik Belousov wrote: > >On Sun, Jul 08, 2007 at 09:47:41AM +0800, Tai-hwa Liang wrote: > [...] > >> Though it was reviewed before destroy_dev_sched() KPI enters to the= =20 > >> tree, > >>I'd be appreciate it if you can reviewed the attached patch again. > >So, this is still the problem for scsi_targ ? > > > >It probably make sense to postpone free of softc until all threads > >finished using it. You may use destroy_dev_sched_cb() to run the > >function after the device is actually destroyed. It would just call > >free(). >=20 > Probably; however, I did not see any code inside scsi_target.c to > detach or unregister the scsi_target device. Will this cause any > cdev leakage? This is not about cdev linkage. Immediately after call to destriy_dev_sched(), driver code frees dev' softc. Thus, if any thread is still inside cdev method, it could access freed memory. Postponing the call to free until all threads leave the cdev methods would eliminate this bug. --XCKmtPOB2gS6QFgg Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGkTi/C3+MBN1Mb4gRAmtgAKCRxpL3BAXtEd8J3PVs/RnXzPfzbQCfUvTu LExgW/rSqyHjCynJeGlK3Ck= =pajg -----END PGP SIGNATURE----- --XCKmtPOB2gS6QFgg-- From owner-freebsd-current@FreeBSD.ORG Sun Jul 8 19:30:12 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id ED27116A46B for ; Sun, 8 Jul 2007 19:30:11 +0000 (UTC) (envelope-from sfpoof@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.232]) by mx1.freebsd.org (Postfix) with ESMTP id A9B2713C448 for ; Sun, 8 Jul 2007 19:30:11 +0000 (UTC) (envelope-from sfpoof@gmail.com) Received: by wx-out-0506.google.com with SMTP id i29so566780wxd for ; Sun, 08 Jul 2007 12:30:11 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=bl/8bBp1xutFoeijcnGtZQjlV7BUo5L7z2+ftV8TiEP2PfW7wDHvpbMzBNZoE+SObJVOfMgJlSX2TuvN1THadGbFEw5Qzbxb5Pkv5PK+8cSQ/YVw/i2Vrz8zECVB8WlC1xdY2+79ZYUHEKgaVkHUJ+ZeKOKz0TO1y0d46KmwO7w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=Xf7xCmGyku0Q3owSq2FiGqKA66ffibcN78JakREi2chnhUDV4XK+26kKJSm2jeAvrybUxOGTpUhygh4V7C3uevqaokt+P5Wa6Ne+M29+AyGAc/6wGR4r1wTeLuRTMtNFjecoUH+MI6qD/hW/g6UpiHxTLDLWViRBC9EgTde6QR4= Received: by 10.90.68.15 with SMTP id q15mr1308641aga.1183923011031; Sun, 08 Jul 2007 12:30:11 -0700 (PDT) Received: by 10.90.100.16 with HTTP; Sun, 8 Jul 2007 12:30:11 -0700 (PDT) Message-ID: Date: Sun, 8 Jul 2007 12:30:11 -0700 From: "Kevin Gerry" To: "Michael C Voorhis" In-Reply-To: <18049.19912.746062.704028@cs.wpi.edu> MIME-Version: 1.0 References: <20070626022444.GA6571@troutmask.apl.washington.edu> <18049.19912.746062.704028@cs.wpi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org, Steve Kargl Subject: Re: Issues with 'xl0' keeping link (bge0, em0 as well?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jul 2007 19:30:12 -0000 Did you ever have a result to this issue? What's interesting is my em0 NIC doesn't seem to have the up/down issue that the xl NICs have. On 6/26/07, Michael C Voorhis wrote: > > Steve Kargl writes: > > Good luck in getting any help. bge0 has been going DOWN/UP for > > about 2 months. > > I've been having issues with em0 going up/down as well. Have read > FreeBSD-Stable, FreeBSD-Current, FreeBSD-net. Having this problem > with separate NICs on both 6.2-STABLE and 7.0-CURRENT. On one SMP and > one Uniprocessor machine, with and without POLLING, on shared (the UP) > and unshared (on the SMP) interrupts. > > Since I found no recent complaints on the above mailing lists, I > concluded I was being stupid and doing some obvious thing wrong. I > had thought to solve the trouble on one machine (the other is a > notebook) by swapping in a Broadcom card, but reading your email here, > it appears that that may not be a solution, either. > > From owner-freebsd-current@FreeBSD.ORG Sun Jul 8 20:16:10 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 535F816A46C for ; Sun, 8 Jul 2007 20:16:10 +0000 (UTC) (envelope-from SRS0=f18ba5b167a2437a3c28d4fb6f81f6bd67e4cc18=390=es.net=oberman@es.net) Received: from postal1.es.net (postal1.es.net [198.128.3.205]) by mx1.freebsd.org (Postfix) with ESMTP id 1250F13C4B9 for ; Sun, 8 Jul 2007 20:16:10 +0000 (UTC) (envelope-from SRS0=f18ba5b167a2437a3c28d4fb6f81f6bd67e4cc18=390=es.net=oberman@es.net) Received: from ptavv.es.net (ptavv.es.net [198.128.4.29]) by postal1.es.net (Postal Node 1) with ESMTP (SSL) id NBI37459 for ; Sun, 08 Jul 2007 13:00:59 -0700 Received: from ptavv.es.net (ptavv.es.net [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id A107445042 for ; Sun, 8 Jul 2007 13:00:59 -0700 (PDT) X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: current@freebsd.org Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_1183924859_57196P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Sun, 08 Jul 2007 13:00:59 -0700 From: "Kevin Oberman" Message-Id: <20070708200059.A107445042@ptavv.es.net> Cc: Subject: Unable to build kernel after csup yesterday X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jul 2007 20:16:10 -0000 --==_Exmh_1183924859_57196P Content-Type: multipart/mixed ; boundary="==_Exmh_1183924848_571960" This is a multipart MIME message. --==_Exmh_1183924848_571960 Content-Type: text/plain; charset=us-ascii After updating sources yesterday and deleting everything in /usr/obj/usr/src, buildkernel no longer builds. Sources from Friday afternoon (US/Pacific) did build OK. I get: cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror /usr/src/sys/i386/i386/sys_machdep.c /usr/src/sys/i386/i386/sys_machdep.c: In function 'i386_ldt_grow': /usr/src/sys/i386/i386/sys_machdep.c:697: error: 'NULL_LDT_BASE' undeclared (first use in this function) /usr/src/sys/i386/i386/sys_machdep.c:697: error: (Each undeclared identifier is reported only once /usr/src/sys/i386/i386/sys_machdep.c:697: error: for each function it appears in.) cc1: warnings being treated as errors /usr/src/sys/i386/i386/sys_machdep.c:751: warning: passing argument 1 of 'set_user_ldt' from incompatible pointer type *** Error code 1 I don't see anything relevant in UPDATING. I am attaching my config and hopefully it will make it through the filters. Any idea what the problem might be? I did see a number of updates to this area recently. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 --==_Exmh_1183924848_571960 Content-Type: text/plain ; name="IBM-T43"; charset=us-ascii Content-Description: IBM-T43 Content-Disposition: attachment; filename="IBM-T43" # # IBM-T43 -- Kernel for IBM-T43 with debugging enabled # # For more information on this file, please read the handbook section on # Kernel Configuration Files: # # http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-config.html # # The handbook is also available locally in /usr/share/doc/handbook # if you've installed the doc distribution, otherwise always see the # FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the # latest information. # # An exhaustive list of options and more detailed explanations of the # device lines is also present in the ../../conf/NOTES and NOTES files. # If you are in doubt as to the purpose or necessity of a line, check first # in NOTES. # # $FreeBSD: src/sys/i386/conf/GENERIC,v 1.428 2005/03/31 20:21:42 scottl Exp $ machine i386 #cpu I486_CPU cpu I586_CPU cpu I686_CPU ident IBM-T43 maxusers 0 # To statically compile in device wiring instead of /boot/device.hints #hints "GENERIC.hints" # Default places to look for devices. makeoptions DEBUG=-g #Build kernel with gdb(1) debug symbols #options CPU_SUSP_HLT # Suspend on halt options SCHED_ULE # ULE scheduler #options SCHED_4BSD # 4BSD scheduler options PREEMPTION # Enable kernel thread preemption options INET # InterNETworking options INET6 # IPv6 communications protocols options SCTP # Stream Transmission Control Protocol options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists options UFS_DIRHASH # Improve performance on big directories options UFS_GJOURNAL # Enable gjournal-based UFS journaling #options NFSCLIENT # Network Filesystem Client #options NFSSERVER # Network Filesystem Server #options NFS_ROOT # NFS usable as root device, requires NFSCLIENT options MSDOSFS # MSDOS Filesystem options CD9660 # ISO 9660 Filesystem options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS # Pseudo-filesystem framework options GEOM_PART_GPT # GUID Partition Tables. options GEOM_LABEL # Provides labelization options COMPAT_43TTY # BSD 4.3 TTY compat [KEEP THIS!] options COMPAT_FREEBSD6 # Compatible with FreeBSD6 options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI options KTRACE # ktrace(1) support options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options IPFIREWALL # Start firewall at boot options IPFIREWALL_VERBOSE # Enable logging to syslogd(8) options IPFIREWALL_VERBOSE_LIMIT=100 # limit verbosity options IPFIREWALL_DEFAULT_TO_ACCEPT # allow everything by default options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options KBD_INSTALL_CDEV # install a CDEV entry in /dev options ADAPTIVE_GIANT # Giant mutex is adaptive. options STOP_NMI # Stop CPUS using NMI instead of IPI options AUDIT # Security event auditing #options IPSEC #options IPSEC_ESP # Debugging for use in -current options KDB # Enable kernel debugger support. options DDB # Support DDB. options GDB # Support remote GDB. #options INVARIANTS # Enable calls of extra sanity checking #options INVARIANT_SUPPORT # Extra sanity checks of internal structures, required by INVARIANTS #options WITNESS # Enable checks to detect deadlocks and cycles #options WITNESS_SKIPSPIN # Don't run witness on spinlocks for speeed # To make an SMP kernel, the next two are needed #options SMP # Symmetric MultiProcessor Kernel #device apic # I/O APIC # CPU frequency control device cpufreq # Bus support. Do not remove isa, even if you have no isa slots #device eisa device pci # Floppy drives device fdc # ATA and ATAPI devices device ata device atadisk # ATA disk drives #device ataraid # ATA RAID drives device atapicd # ATAPI CDROM drives #device atapifd # ATAPI floppy drives #device atapist # ATAPI tape drives device atapicam # Emulate ATAPI devices as SCSI ditto via CAM # needs CAM to be present (scbus & pass) options ATA_STATIC_ID #Static device numbering # SCSI peripherals device scbus # SCSI bus (required for SCSI) #device ch # SCSI media changers device da # Direct Access (disks) #device sa # Sequential Access (tape etc) device cd # CD device pass # Passthrough device (direct SCSI access) device ses # SCSI Environmental Services (and SAF-TE) # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc # AT keyboard controller device atkbd # AT keyboard device psm # PS/2 mouse device kbdmux # keyboard multiplexer options KBD_RESETDELAY=500 device vga # VGA video card driver device splash # Splash screen and screen saver support # syscons is the default console driver, resembling an SCO console device sc options SC_HISTORY_SIZE=2000 options SC_PIXEL_MODE #add support for the raster text mode device agp # support several AGP chipsets # Power management support (see NOTES for more options) #device apm # Add suspend/resume support for the i8254. device pmtimer # PCCARD (PCMCIA) support # PCMCIA and cardbus bridge support device cbb # cardbus (yenta) bridge device pccard # PC Card (16-bit) bus device cardbus # CardBus (32-bit) bus # Serial (COM) ports device sio # 8250, 16[45]50 based serial ports device uart # Generic UART driver # Parallel port #device ppc #device ppbus # Parallel port bus (required) #device lpt # Printer #device plip # TCP/IP over parallel #device ppi # Parallel port interface device #device vpo # Requires scbus and da # If you've got a "dumb" serial or parallel PCI card that is # supported by the puc(4) glue driver, uncomment the following # line to enable it (connects to the sio and/or ppc drivers): #device puc # PCI Ethernet NICs that use the common MII bus controller code. # NOTE: Be sure to keep the 'device miibus' line in order to use these NICs! device miibus # MII bus support device bge # Broadcom BCM570xx Gigabit Ethernet device dc # DEC/Intel 21143 and various workalikes # ISA Ethernet NICs. # Xircom Ethernet device xe # WaveLAN/IEEE 802.11 wireless NICs. Note: the WaveLAN/IEEE really # exists only as a PCMCIA device, so there is no ISA attachment needed # and resources will always be dynamically assigned by the pccard code. device wlan # Pseudo devices. device loop # Network loopback device random # Entropy device device ether # Ethernet support #device sl # Kernel SLIP #device ppp # Kernel PPP device tun # Packet tunnel. device pty # Pseudo-ttys (telnet etc) device md # Memory "disks" device gif # IPv6 and IPv4 tunneling device faith # IPv6-to-IPv4 relaying (translation) # The `bpf' device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! # Note that 'bpf' is required for DHCP. device bpf # Berkeley packet filter # USB support #device uhci # UHCI PCI->USB interface #device ohci # OHCI PCI->USB interface #device ehci # EHCI PCI->USB interface #device usb # USB Bus (required) #device udbp # USB Double Bulk Pipe devices #device ugen # Generic #device uhid # "Human Interface Devices" #device ukbd # Keyboard #device ulpt # Printer #device umass # Disks/Mass storage - Requires scbus and da #device ums # Mouse #device urio # Diamond Rio MP3 Player #device uscanner # Scanners # USB Ethernet, requires mii #device aue # ADMtek USB ethernet #device axe # ASIX Electronics USB Ethernet #device cdce # Generic USB over Ethernet #device cue # CATC USB ethernet #device kue # Kawasaki LSI USB ethernet #device rue # RealTek RTL8150 USB Ethernet # Sound support (Requires System Management Bus for ICH) device smbus device iicbus device iicbb device intpm device ichsmb device smb #device sound #device snd_ich --==_Exmh_1183924848_571960-- --==_Exmh_1183924859_57196P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) Comment: Exmh version 2.5 06/03/2002 iD8DBQFGkUJ7kn3rs5h7N1ERAlHQAJ9ya/sLdfR107IWnQdoEtaLRsxSEwCeLz6M /DhYUsxVmePiehRl2Xxyxeo= =FoTL -----END PGP SIGNATURE----- --==_Exmh_1183924859_57196P-- From owner-freebsd-current@FreeBSD.ORG Sun Jul 8 20:19:28 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E435916A468 for ; Sun, 8 Jul 2007 20:19:28 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from ik-out-1112.google.com (ik-out-1112.google.com [66.249.90.182]) by mx1.freebsd.org (Postfix) with ESMTP id 79D3413C4BE for ; Sun, 8 Jul 2007 20:19:28 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by ik-out-1112.google.com with SMTP id c21so433413ika for ; Sun, 08 Jul 2007 13:19:27 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:reply-to:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding:sender; b=q6uWdrOARjrIXFzQbjVXtIy7hjkI/WyZhtiDeZxgN4ChJI75uC7R2aN37u9OUzycCBVmrpid3fQvWuxewZ3rhdcGZTrFr2zkhDcGvI4hHaWXHy4yuW8VE+4bk7wd380Dh9hIcNn2Nijy81L1TW013rodIDEpIM2NSwJIdKrRcdI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:reply-to:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding:sender; b=SdiiQlyKUjqvtAKq0RfFN9SDbEXaP0e8kokVOGUEamDGCmoPpeK64DFuKOZBPLXFXocN6so27CbKsDbArUbpfzHfqiGZE+uS+GXsmc9qrii2lBi9+5/hKu266jrwH4WCKYPdGZ95dP9wJnTh/XMRAMZnIuEV0dzi0BGgCG+IaRk= Received: by 10.78.37.7 with SMTP id k7mr1225086huk.1183925966987; Sun, 08 Jul 2007 13:19:26 -0700 (PDT) Received: from ?151.75.234.50? ( [151.75.234.50]) by mx.google.com with ESMTP id h7sm5143308nfh.2007.07.08.13.19.26 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 08 Jul 2007 13:19:26 -0700 (PDT) Message-ID: <469146A8.9020004@FreeBSD.org> Date: Sun, 08 Jul 2007 22:18:48 +0200 From: Attilio Rao User-Agent: Thunderbird 1.5 (X11/20060526) MIME-Version: 1.0 To: Kevin Oberman References: <20070708200059.A107445042@ptavv.es.net> In-Reply-To: <20070708200059.A107445042@ptavv.es.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: Attilio Rao Cc: current@freebsd.org Subject: Re: Unable to build kernel after csup yesterday X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: attilio@FreeBSD.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jul 2007 20:19:29 -0000 Kevin Oberman wrote: > After updating sources yesterday and deleting everything in > /usr/obj/usr/src, buildkernel no longer builds. Sources from Friday > afternoon (US/Pacific) did build OK. > > I get: > cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs > -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual > -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/usr/src/sys > -I/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include > opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 > --param large-function-growth=1000 -mno-align-long-strings > -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 > -ffreestanding -Werror /usr/src/sys/i386/i386/sys_machdep.c > /usr/src/sys/i386/i386/sys_machdep.c: In function 'i386_ldt_grow': > /usr/src/sys/i386/i386/sys_machdep.c:697: error: 'NULL_LDT_BASE' undeclared > (first use in this function) > /usr/src/sys/i386/i386/sys_machdep.c:697: error: (Each undeclared identifier > is reported only once > /usr/src/sys/i386/i386/sys_machdep.c:697: error: for each function it appears > in.) > cc1: warnings being treated as errors > /usr/src/sys/i386/i386/sys_machdep.c:751: warning: passing argument 1 of > 'set_user_ldt' from incompatible pointer type > *** Error code 1 > > I don't see anything relevant in UPDATING. I am attaching my config and > hopefully it will make it through the filters. > > Any idea what the problem might be? I did see a number of updates to > this area recently. This has been fixed, please cvsup again. Attilio From owner-freebsd-current@FreeBSD.ORG Sun Jul 8 20:49:41 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5385016A469; Sun, 8 Jul 2007 20:49:41 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from mxout1.cac.washington.edu (mxout1.cac.washington.edu [140.142.32.134]) by mx1.freebsd.org (Postfix) with ESMTP id 31A9A13C45E; Sun, 8 Jul 2007 20:49:41 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.7] (may be forged)) by mxout1.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.06) with ESMTP id l68KneGV015534 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 8 Jul 2007 13:49:40 -0700 X-Auth-Received: from [192.168.10.45] (c-24-10-12-194.hsd1.ca.comcast.net [24.10.12.194]) (authenticated authid=youshi10) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l68KndlK005735 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 8 Jul 2007 13:49:40 -0700 Message-ID: <46914DE3.1070901@u.washington.edu> Date: Sun, 08 Jul 2007 13:49:39 -0700 From: Garrett Cooper User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: "Gelsema, P \(Patrick\)" References: <3921.10.202.77.103.1183926641.squirrel@webmail.superhero.nl> In-Reply-To: <3921.10.202.77.103.1183926641.squirrel@webmail.superhero.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 5.3.2.304607, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.7.8.133333 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' Cc: freebsd-questions@freebsd.org, current@freebsd.org Subject: Re: updating from I386 architecture to AMD64 on -Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jul 2007 20:49:41 -0000 Gelsema, P (Patrick) wrote: > Hi lists, > > I had tp reinstall my AMD box and the only version available was the > -Current snapshot of April architecture I386. Wouldnt be a problem I > thought, just install I386 and rebuild world/kernel for AMD64. > > So I did the following for crossbuilds. > > #chflags -R noschg /usr/obj > #rm -rf /usr/obj > #cd /usr/src > #make cleandir > #make cleandir > #make TARGET=amd64 TARGET_ARCH=amd64 -j8 buildworld > #make TARGET=amd64 TARGET_ARCH=amd64 -j8 buildkernel > > Until that moment everything is looking great. When I try to install the > world/kernel however the 'problem' starts. > > hulk# make TARGET=amd64 TARGET_ARCH=amd64 -j8 installkernel > ERROR: Please set DESTDIR! > *** Error code 1 > 1 error > *** Error code 2 > 1 error > > Can someone point the obvious out for me, cause it seems that I am missing > something really simple... > > Thanks > > Patrick > This has been brought up a few times. It's by far much more difficult to do an in-place upgrade from i386 -> amd64, than it is to just install amd64 from scratch. Scrounge around the questions@ archives (in particular over the last week or so) for more discussion/details. -Garrett From owner-freebsd-current@FreeBSD.ORG Sun Jul 8 20:57:19 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5E0DB16A421 for ; Sun, 8 Jul 2007 20:57:19 +0000 (UTC) (envelope-from gelsemap@superhero.nl) Received: from superman.superhero.nl (superhero.nl [82.95.198.17]) by mx1.freebsd.org (Postfix) with ESMTP id AC94A13C44B for ; Sun, 8 Jul 2007 20:57:18 +0000 (UTC) (envelope-from gelsemap@superhero.nl) Received: (qmail 3405 invoked by uid 80); 8 Jul 2007 20:30:41 -0000 Received: from robin.ad.superhero.nl ([10.202.77.103]) (SquirrelMail authenticated user gelsemap) by webmail.superhero.nl with HTTP; Sun, 8 Jul 2007 22:30:41 +0200 (CEST) Message-ID: <3921.10.202.77.103.1183926641.squirrel@webmail.superhero.nl> Date: Sun, 8 Jul 2007 22:30:41 +0200 (CEST) From: "Gelsema, P \(Patrick\)" To: freebsd-questions@freebsd.org User-Agent: SquirrelMail/1.4.8 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: current@freebsd.org Subject: updating from I386 architecture to AMD64 on -Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jul 2007 20:57:19 -0000 Hi lists, I had tp reinstall my AMD box and the only version available was the -Current snapshot of April architecture I386. Wouldnt be a problem I thought, just install I386 and rebuild world/kernel for AMD64. So I did the following for crossbuilds. #chflags -R noschg /usr/obj #rm -rf /usr/obj #cd /usr/src #make cleandir #make cleandir #make TARGET=amd64 TARGET_ARCH=amd64 -j8 buildworld #make TARGET=amd64 TARGET_ARCH=amd64 -j8 buildkernel Until that moment everything is looking great. When I try to install the world/kernel however the 'problem' starts. hulk# make TARGET=amd64 TARGET_ARCH=amd64 -j8 installkernel ERROR: Please set DESTDIR! *** Error code 1 1 error *** Error code 2 1 error Can someone point the obvious out for me, cause it seems that I am missing something really simple... Thanks Patrick From owner-freebsd-current@FreeBSD.ORG Sun Jul 8 22:28:50 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3E5CE16A46E for ; Sun, 8 Jul 2007 22:28:50 +0000 (UTC) (envelope-from dmw@unete.cl) Received: from mail04.ifxnetworks.com (mail04.ifxnetworks.com [190.61.128.14]) by mx1.freebsd.org (Postfix) with ESMTP id D3BEB13C458 for ; Sun, 8 Jul 2007 22:28:49 +0000 (UTC) (envelope-from dmw@unete.cl) Received: (qmail 13121 invoked from network); 8 Jul 2007 22:02:07 -0000 X-Spam-DCC: EATSERVER: mail04.ifxnetworks.com 1166; Body=1 Fuz1=1 Fuz2=1 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on mail04.ifxnetworks.com X-Spam-Level: X-Spam-Status: No, score=0.1 required=7.0 tests=RDNS_NONE autolearn=disabled version=3.2.1 Received: from unknown (HELO quake) (dmw@unete.cl@[200.73.82.175]) (envelope-sender ) by mail04.ifxnetworks.com (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 8 Jul 2007 22:02:06 -0000 From: Daniel Molina Wegener Organization: DMW To: "FreeBSD -CURRENT" Date: Sun, 8 Jul 2007 18:01:34 -0400 User-Agent: KMail/1.9.6 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200707081801.34424.dmw@unete.cl> Subject: source tree, problems updatng X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dmw@unete.cl List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jul 2007 22:28:50 -0000 Hello, I have some problems updating the -CURRENT source tree, I get these errors: ---8<--- Cannot access /home/ncvs/CVSROOT No such file or directory ---8<--- And also I want to know if there is a way to know when the -CURRENT source tree can be compiled without problems, both kernel and world. I know about the tinderbox anounces, but only on failures... Regards, -- .O. | Daniel Molina Wegener | C/C++ Developer ..O | dmw [at] unete [dot] cl | FOSS Coding Adict OOO | BSD & Linux User | Standards Rocks! From owner-freebsd-current@FreeBSD.ORG Sun Jul 8 23:10:13 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8893616A468 for ; Sun, 8 Jul 2007 23:10:13 +0000 (UTC) (envelope-from drosih@rpi.edu) Received: from smtp6.server.rpi.edu (smtp6.server.rpi.edu [128.113.2.226]) by mx1.freebsd.org (Postfix) with ESMTP id 379A213C455 for ; Sun, 8 Jul 2007 23:10:12 +0000 (UTC) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp6.server.rpi.edu (8.13.1/8.13.1) with ESMTP id l68M75k7020610; Sun, 8 Jul 2007 18:07:05 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <20070708132545.5604cbe9.ubm@u-boot-man.de> References: <8cdf6c720707070710k2b7e030v37683e460d983bf9@mail.gmail.com> <20070708111105.C9997@fledge.watson.org> <20070708132545.5604cbe9.ubm@u-boot-man.de> Date: Sun, 8 Jul 2007 18:07:05 -0400 To: Marc "UBM" Bocklet , freebsd-current@freebsd.org From: Garance A Drosihn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-RPI-SA-Score: undef - spam scanning disabled X-CanItPRO-Stream: default X-Canit-Stats-ID: Bayes signature not available X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.113.2.226 Cc: Subject: Re: status of 7.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jul 2007 23:10:13 -0000 At 1:25 PM +0200 7/8/07, Marc "UBM" Bocklet wrote: > >I'd like to do some testing, but I'm a little bit afraid of the upgrade >procedure 6.2-stable to -current. Is it possible to do a simple upgrade >if I follow the guidelines in UPGRADE or are there any hidden caveats? >(like "you've to recompile all installed ports", etc. :-)) For what it's worth, I just recently upgraded one of my i386 machines. I first upgraded to the latest snapshot of 6.2-stable, and then I went from there to 7.x-current. I just did that on Friday, so I can't say that I've tested everything yet. But so far I haven't had any problems. One note: when you build the new 7.x kernel on a 6.x system, you'll see a number of scary-looking warning messages about: "kldxref: file isn't dynamically-linked" but you can ignore those. If those are the only warnings that you see, then your kernel is probably fine. -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu From owner-freebsd-current@FreeBSD.ORG Sun Jul 8 23:38:51 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 704FF16A41F for ; Sun, 8 Jul 2007 23:38:51 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (c220-239-20-82.belrs4.nsw.optusnet.com.au [220.239.20.82]) by mx1.freebsd.org (Postfix) with ESMTP id F1FBB13C46E for ; Sun, 8 Jul 2007 23:38:50 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by turion.vk2pj.dyndns.org (8.14.1/8.14.1) with ESMTP id l68Ncm1I005952; Mon, 9 Jul 2007 09:38:48 +1000 (EST) (envelope-from peter@turion.vk2pj.dyndns.org) Received: (from peter@localhost) by turion.vk2pj.dyndns.org (8.14.1/8.14.1/Submit) id l68Ncmga005951; Mon, 9 Jul 2007 09:38:48 +1000 (EST) (envelope-from peter) Date: Mon, 9 Jul 2007 09:38:48 +1000 From: Peter Jeremy To: Daniel Molina Wegener Message-ID: <20070708233848.GG3434@turion.vk2pj.dyndns.org> References: <200707081801.34424.dmw@unete.cl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="azLHFNyN32YCQGCU" Content-Disposition: inline In-Reply-To: <200707081801.34424.dmw@unete.cl> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.16 (2007-06-09) Cc: FreeBSD -CURRENT Subject: Re: source tree, problems updatng X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jul 2007 23:38:51 -0000 --azLHFNyN32YCQGCU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2007-Jul-08 18:01:34 -0400, Daniel Molina Wegener wrote: > I have some problems updating the -CURRENT source tree, I >get these errors: > >---8<--- >Cannot access /home/ncvs/CVSROOT >No such file or directory >---8<--- How were you updating your source tree? Do you have a copy of the FreeBSD CVS repository at /home/ncvs? Is the CVSROOT directory present? Have you done this before? > And also I want to know if there is a way to know when the >-CURRENT source tree can be compiled without problems, The source trees should always be buildable. Sometimes, accidents happen and the tinderboxes are intended to catch those accidents. I build -stable and -current nightly and very rarely have problems. --=20 Peter Jeremy --azLHFNyN32YCQGCU Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGkXWI/opHv/APuIcRAobrAJ9Cq4M/p7kIs3/2giY5lHrArXW+8QCggi/K g09GyrVJD9huBrjuyKA/Rhk= =n5QI -----END PGP SIGNATURE----- --azLHFNyN32YCQGCU-- From owner-freebsd-current@FreeBSD.ORG Sun Jul 8 23:48:35 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1B3FC16A41F for ; Sun, 8 Jul 2007 23:48:35 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.freebsd.org (Postfix) with ESMTP id F2F3813C447 for ; Sun, 8 Jul 2007 23:48:34 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.1/8.13.8) with ESMTP id l68NlJOC073393; Sun, 8 Jul 2007 16:47:19 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.1/8.13.8/Submit) id l68NlIeE073392; Sun, 8 Jul 2007 16:47:18 -0700 (PDT) (envelope-from sgk) Date: Sun, 8 Jul 2007 16:47:18 -0700 From: Steve Kargl To: Peter Jeremy Message-ID: <20070708234718.GA73363@troutmask.apl.washington.edu> References: <200707081801.34424.dmw@unete.cl> <20070708233848.GG3434@turion.vk2pj.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070708233848.GG3434@turion.vk2pj.dyndns.org> User-Agent: Mutt/1.4.2.2i Cc: Daniel Molina Wegener , FreeBSD -CURRENT Subject: Re: source tree, problems updatng X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jul 2007 23:48:35 -0000 On Mon, Jul 09, 2007 at 09:38:48AM +1000, Peter Jeremy wrote: > On 2007-Jul-08 18:01:34 -0400, Daniel Molina Wegener wrote: > > I have some problems updating the -CURRENT source tree, I > >get these errors: > > > >---8<--- > >Cannot access /home/ncvs/CVSROOT > >No such file or directory > >---8<--- > > How were you updating your source tree? > Do you have a copy of the FreeBSD CVS repository at /home/ncvs? > Is the CVSROOT directory present? > Have you done this before? > freebsdanoncvs@anoncvs.FreeBSD.org:/home/ncvs went dead sometime last week. The above looks like the error I see when I try to update. -- Steve From owner-freebsd-current@FreeBSD.ORG Sun Jul 8 23:47:25 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A050A16A46B for ; Sun, 8 Jul 2007 23:47:25 +0000 (UTC) (envelope-from Benjamin.Close@clearchain.com) Received: from ipmail01.adl2.internode.on.net (ipmail01.adl2.internode.on.net [203.16.214.140]) by mx1.freebsd.org (Postfix) with ESMTP id 1801613C447 for ; Sun, 8 Jul 2007 23:47:24 +0000 (UTC) (envelope-from Benjamin.Close@clearchain.com) X-IronPort-AV: E=Sophos;i="4.16,514,1175437800"; d="scan'208";a="154311472" Received: from ppp121-45-153-254.lns10.adl6.internode.on.net (HELO mail.clearchain.com) ([121.45.153.254]) by ipmail01.adl2.internode.on.net with ESMTP; 09 Jul 2007 09:17:22 +0930 Received: from wolf.clearchain.com (wcl.ml.unisa.edu.au [130.220.166.5]) (authenticated bits=0) by mail.clearchain.com (8.13.8/8.13.8) with ESMTP id l68Nl9ko081929 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Jul 2007 09:17:16 +0930 (CST) (envelope-from Benjamin.Close@clearchain.com) Message-ID: <4691777D.3010801@clearchain.com> Date: Mon, 09 Jul 2007 09:17:09 +0930 From: Benjamin Close User-Agent: Thunderbird 2.0.0.0 (X11/20070615) MIME-Version: 1.0 To: =?ISO-8859-1?Q?=22Zavam=2C_Vin=EDcius=22?= References: <20070708093144.GA22598@ceid.upatras.gr> <20070708122021.412747c4.maxx@mobistarmail.be> <8b5ad0e10707080751n7f8e19bdhb36012bd205a767f@mail.gmail.com> In-Reply-To: <8b5ad0e10707080751n7f8e19bdhb36012bd205a767f@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV version 0.90.3, clamav-milter version 0.90.3 on pegasus.clearchain.com X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (mail.clearchain.com [192.168.154.1]); Mon, 09 Jul 2007 09:17:19 +0930 (CST) X-Mailman-Approved-At: Mon, 09 Jul 2007 00:12:25 +0000 Cc: MaXX , freebsd-current@freebsd.org Subject: Re: IPW3945ABG -- Support in RELENG 7? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jul 2007 23:47:25 -0000 Zavam, Vinícius wrote: > 2007/7/8, MaXX : >> On Sun, 8 Jul 2007 12:31:44 +0300 >> Marinos Ilias wrote: >> >> > Hello list, >> > Wondering what's the current state of Intel Pro Wireless >> Support 3945 ABG support .Anyone knows if there will be support in >> RELENG_7 , so we can use finally, our laptops' wifi? >> >> Hi, >> I'm aware of http://www.clearchain.com/wiki/Wpi which seems to be >> active and making great progress. But I think we have to be a little >> more patient to allow the author to finish his work, or I you feel >> like you can, give him some help. >> >> HTH, >> -- >> MaXX > > You are right. We need to be patients. > I installed the module (20070131-wpi) here into my 62release-p5 box, > but could not connect with my AP. > ClearChain[1] now says that it can be possible. I'll try it later (-: > > Benjamin is doing a great job to grant support for 3945. > A month ago I wrote an email with some debugs (I used a box with > -current) and I sent they to Ben that friendly answered me with what's > wrong. > > [1]; http://www.clearchain.com/wiki/Wpi > > Hi Folks, First off, thanks for the many votes of confidence. Whilst I'd like to see wpi support in 7.0, there's still a long way to go before it becomes stable. At present it can *almost* pass packets but there's still a few race conditions that exist and there is currently limited/untested support for ibss or hostap modes. Since 7.0-Current is already in a code freeze, I wouldn't get your hopes up... chances are slim at best. Cheers, Benjamin From owner-freebsd-current@FreeBSD.ORG Mon Jul 9 00:27:31 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1D3D116A41F for ; Mon, 9 Jul 2007 00:27:31 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.freebsd.org (Postfix) with ESMTP id 734A213C465 for ; Mon, 9 Jul 2007 00:27:30 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 6DAF645CD9; Mon, 9 Jul 2007 02:09:31 +0200 (CEST) Received: from localhost (154.81.datacomsa.pl [195.34.81.154]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id C802345696; Mon, 9 Jul 2007 02:09:26 +0200 (CEST) Date: Mon, 9 Jul 2007 02:09:18 +0200 From: Pawel Jakub Dawidek To: Doug Rabson Message-ID: <20070709000918.GD1208@garage.freebsd.pl> References: <200707071426.18202.dfr@rabson.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="F8dlzb82+Fcn6AgP" Content-Disposition: inline In-Reply-To: <200707071426.18202.dfr@rabson.org> X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 User-Agent: mutt-ng/devel-r804 (FreeBSD) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-2.6 required=3.0 tests=BAYES_00 autolearn=ham version=3.0.4 Cc: current@freebsd.org Subject: Re: ZFS leaking vnodes (sort of) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2007 00:27:31 -0000 --F8dlzb82+Fcn6AgP Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jul 07, 2007 at 02:26:17PM +0100, Doug Rabson wrote: > I've been testing ZFS recently and I noticed some performance issues=20 > while doing large-scale port builds on a ZFS mounted /usr/ports tree.=20 > Eventually I realised that virtually nothing ever ended up on the vnode= =20 > free list. This meant that when the system reached its maximum vnode=20 > limit, it had to resort to reclaiming vnodes from the various=20 > filesystem's active vnode lists (via vlrureclaim). Since those lists=20 > are not sorted in LRU order, this led to pessimal cache performance=20 > after the system got into that state. >=20 > I looked a bit closer at the ZFS code and poked around with DDB and I=20 > think the problem was caused by a couple of extraneous calls to vhold=20 > when creating a new ZFS vnode. On FreeBSD, getnewvnode returns a vnode=20 > which is already held (not on the free list) so there is no need to=20 > call vhold again. Whoa! Nice catch... The patch works here - I did some pretty heavy tests, so please commit it ASAP. I also wonder if this can help with some of those 'kmem_map too small' panics. I was observing that ARC cannot reclaim memory and this may be because all vnodes and thus associated data are beeing held. To ZFS users having problems with performance and/or stability of ZFS: Can you test the patch and see if it helps? > This patch appears to fix the problem (only very lightly tested): >=20 > Index: zfs_vnops.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > RCS=20 > file: /home/ncvs/src/sys/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.= c,v > retrieving revision 1.22 > diff -u -r1.22 zfs_vnops.c > --- zfs_vnops.c 28 May 2007 02:37:43 -0000 1.22 > +++ zfs_vnops.c 7 Jul 2007 13:01:41 -0000 > @@ -3493,7 +3493,7 @@ > rele =3D 0; > vp->v_data =3D NULL; > ASSERT(vp->v_holdcnt > 1); > - vdropl(vp); > + VI_UNLOCK(vp); > if (!zp->z_unlinked && rele) > VFS_RELE(zfsvfs->z_vfs); > return (0); > Index: zfs_znode.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > RCS=20 > file: /home/ncvs/src/sys/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.= c,v > retrieving revision 1.8 > diff -u -r1.8 zfs_znode.c > --- zfs_znode.c 6 May 2007 19:05:37 -0000 1.8 > +++ zfs_znode.c 7 Jul 2007 13:17:32 -0000 > @@ -115,7 +115,6 @@ > ASSERT(error =3D=3D 0); > zp->z_vnode =3D vp; > vp->v_data =3D (caddr_t)zp; > - vhold(vp); > vp->v_vnlock->lk_flags |=3D LK_CANRECURSE; > vp->v_vnlock->lk_flags &=3D ~LK_NOSHARE; > } else { > @@ -601,7 +600,6 @@ > ASSERT(err =3D=3D 0); > vp =3D ZTOV(zp); > vp->v_data =3D (caddr_t)zp; > - vhold(vp); > vp->v_vnlock->lk_flags |=3D LK_CANRECURSE; > vp->v_vnlock->lk_flags &=3D ~LK_NOSHARE; > vp->v_type =3D IFTOVT((mode_t)zp->z_phys->zp_mode); --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --F8dlzb82+Fcn6AgP Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFGkXyuForvXbEpPzQRAkHvAKDFBCHWRhxQk0P10U/0mOC3WnuGSQCg3ZfS 3EHjm23mHkelZtf8/EeSm7U= =Jx74 -----END PGP SIGNATURE----- --F8dlzb82+Fcn6AgP-- From owner-freebsd-current@FreeBSD.ORG Mon Jul 9 01:13:27 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A595816A421 for ; Mon, 9 Jul 2007 01:13:27 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.179]) by mx1.freebsd.org (Postfix) with ESMTP id 7A8F713C448 for ; Mon, 9 Jul 2007 01:13:27 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by wa-out-1112.google.com with SMTP id j37so1159631waf for ; Sun, 08 Jul 2007 18:13:27 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:received:received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=IMMUB9bglkijrW4m1RMgl2tfoYJlaKCTeyTYBHzG86UFp7VUhy9iDwknIcW/5iHHIjJLSftWGVGwWdXBNSRzff7cOtLg31tKMsD9qmjrwVqOZJoz+cQMGtaR33RMkt4YaiepppD/yN/jqMqjmABFseNWKXPqK4NdhNvxKTv7eF4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=iuimiiDrhGJ+U5XxLnxqgW3NLLdVr4EQvdDtjdIO81MXWU3Mglz1UPHOSUfpfrAc8/fKOERBjPQ4R5j9Fr/6/X/GdFcgGCNnB8JkaE5xQMnAfe8K/ntxrfIsmjQjkfLnNBLQPpwKl1g1xAkWeu6EwdnoNMw1p0pvIDkrlJvIkPY= Received: by 10.114.12.9 with SMTP id 9mr2637519wal.1183943606826; Sun, 08 Jul 2007 18:13:26 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTP id m24sm28464814waf.2007.07.08.18.13.24 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 08 Jul 2007 18:13:25 -0700 (PDT) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id l691DMwP001563 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Jul 2007 10:13:22 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id l691DL4c001562; Mon, 9 Jul 2007 10:13:21 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Mon, 9 Jul 2007 10:13:21 +0900 From: Pyun YongHyeon To: Danny Braniss Message-ID: <20070709011321.GC1062@cdnetworks.co.kr> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: current@freebsd.org Subject: Re: src/UPDATE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2007 01:13:27 -0000 On Sun, Jul 08, 2007 at 02:20:21PM +0300, Danny Braniss wrote: > the latest src/UPDATE has bad date: > ... > 20060612: > The i386/amd64 GENERIC kernel now defaults to the nfe(4) driver > instead of the nve(4) driver. Please update your configuration > accordingly. > ... > > danny > Fixed, thank you! -- Regards, Pyun YongHyeon From owner-freebsd-current@FreeBSD.ORG Mon Jul 9 01:40:33 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3B33716A469; Mon, 9 Jul 2007 01:40:33 +0000 (UTC) (envelope-from scf@FreeBSD.org) Received: from mail.farley.org (farley.org [67.64.95.201]) by mx1.freebsd.org (Postfix) with ESMTP id E916413C46C; Mon, 9 Jul 2007 01:40:32 +0000 (UTC) (envelope-from scf@FreeBSD.org) Received: from thor.farley.org (thor.farley.org [192.168.1.5]) by mail.farley.org (8.14.1/8.14.1) with ESMTP id l691fc6u006363; Sun, 8 Jul 2007 20:41:38 -0500 (CDT) (envelope-from scf@FreeBSD.org) Date: Sun, 8 Jul 2007 20:40:11 -0500 (CDT) From: "Sean C. Farley" To: Andrey Chernov In-Reply-To: <20070708183823.GA91359@nagual.pp.ru> Message-ID: <20070708203635.A14065@thor.farley.org> References: <20070705115816.GA50506@nagual.pp.ru> <20070705105922.F98700@thor.farley.org> <20070707130859.GA96605@nagual.pp.ru> <20070707131359.GB96605@nagual.pp.ru> <20070707133102.C14065@thor.farley.org> <20070707191835.GA4368@nagual.pp.ru> <20070707205410.B14065@thor.farley.org> <20070708020940.GA80166@nagual.pp.ru> <20070708171727.GA90490@nagual.pp.ru> <20070708125905.F14065@thor.farley.org> <20070708183823.GA91359@nagual.pp.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.1 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on mail.farley.org Cc: freebsd-current , Robert Watson , Michal Mertl Subject: Re: Environment handling broken in /bin/sh with changes to {get,set,put}env() X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2007 01:40:33 -0000 On Sun, 8 Jul 2007, Andrey Chernov wrote: > On Sun, Jul 08, 2007 at 01:14:31PM -0500, Sean C. Farley wrote: *snip* >>> Could you please make setenv() wrapper like that to avoid modifying >>> merged environ in the middle? >>> __lsetenv(str, str_len, value) >> >> I could add this as a feature later. Unfortunately, unless I can >> lock the use of environ, an application could do this even with the >> 6-STABLE version of *env() functions. I have been pondering about >> thread-safety in a future release of these functions (8-CURRENT), but >> it may not be possible since environ is exposed. > > Even in case it may happens with 6-STABLE, we better not repeat the > way lead to mistakes again :) Your interpretation of the specification is correct. My latest patch should apply. I changed getenv() to never change environ. If it detects that environ was replaced, it falls back to returning the value from there. Only setenv(), unsetenv() and putenv() will alter environ. How does it look to you? Sean -- scf@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Mon Jul 9 02:51:15 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A3FB016A421 for ; Mon, 9 Jul 2007 02:51:15 +0000 (UTC) (envelope-from drosih@rpi.edu) Received: from smtp6.server.rpi.edu (smtp6.server.rpi.edu [128.113.2.226]) by mx1.freebsd.org (Postfix) with ESMTP id 69D0913C457 for ; Mon, 9 Jul 2007 02:51:15 +0000 (UTC) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp6.server.rpi.edu (8.13.1/8.13.1) with ESMTP id l692pD6Y030182; Sun, 8 Jul 2007 22:51:14 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <8cdf6c720707070710k2b7e030v37683e460d983bf9@mail.gmail.com> <20070708111105.C9997@fledge.watson.org> <20070708132545.5604cbe9.ubm@u-boot-man.de> Date: Sun, 8 Jul 2007 22:51:12 -0400 To: Marc "UBM" Bocklet , freebsd-current@freebsd.org From: Garance A Drosihn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-RPI-SA-Score: undef - spam scanning disabled X-CanItPRO-Stream: default X-Canit-Stats-ID: Bayes signature not available X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.113.2.226 Cc: Subject: Re: status of 7.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2007 02:51:15 -0000 At 6:07 PM -0400 7/8/07, Garance A Drosihn wrote: >At 1:25 PM +0200 7/8/07, Marc "UBM" Bocklet wrote: >> >>I'd like to do some testing, but I'm a little bit afraid of the upgrade >>procedure 6.2-stable to -current. Is it possible to do a simple upgrade >>if I follow the guidelines in UPGRADE or are there any hidden caveats? >>(like "you've to recompile all installed ports", etc. :-)) > >For what it's worth, I just recently upgraded one of my i386 machines. >I first upgraded to the latest snapshot of 6.2-stable, and then I went >from there to 7.x-current. I just did that on Friday, so I can't say >that I've tested everything yet. But so far I haven't had any problems. Okay, I just hit one non-obvious problem. On the system I had upgraded, 'portupgrade' was out-of-date, but 'ruby' had already been updated before the switch to 7.x-current. Portupgrade *was* working, but then I tried to upgrade it and it stopped working. Lots of errors, and then a program-interrupt while trying to do 'pkgdb -fu'. On a hunch, I did: cd /usr/ports/lang/ruby18 make deinstall make make install && make clean and then portupgrade went back to working fine. So, there might be some cases where you'll have to build a few ports even though they are already up-to-date. -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu From owner-freebsd-current@FreeBSD.ORG Mon Jul 9 03:14:13 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2F83316A46D for ; Mon, 9 Jul 2007 03:14:13 +0000 (UTC) (envelope-from zhouzhouyi@FreeBSD.org) Received: from ercist.iscas.ac.cn (ercist.iscas.ac.cn [124.16.138.3]) by mx1.freebsd.org (Postfix) with SMTP id CA04813C46A for ; Mon, 9 Jul 2007 03:14:11 +0000 (UTC) (envelope-from zhouzhouyi@FreeBSD.org) Received: (qmail 57435 invoked by uid 98); 9 Jul 2007 03:05:00 -0000 Received: from 222.191.237.170 by ercist.iscas.ac.cn (envelope-from , uid 89) with qmail-scanner-1.25 (spamassassin: 3.1.0. Clear:RC:1(222.191.237.170):SA:0(0.0/10.0):. Processed in 12.211863 secs); 09 Jul 2007 03:05:00 -0000 X-Spam-Status: No, hits=0.0 required=10.0 X-Qmail-Scanner-Mail-From: zhouzhouyi@FreeBSD.org via ercist.iscas.ac.cn X-Qmail-Scanner: 1.25 (Clear:RC:1(222.191.237.170):SA:0(0.0/10.0):. Processed in 12.211863 secs) Received: from unknown (HELO zzy.H.qngy.gscas) (zhouzhouyi@ercist.iscas.ac.cn@222.191.237.170) by 0 with SMTP; 9 Jul 2007 03:04:48 -0000 Date: Mon, 9 Jul 2007 11:02:16 +0800 From: zhouyi zhou To: zhouyi zhou Message-Id: <20070709110216.459ca250.zhouzhouyi@FreeBSD.org> In-Reply-To: <20070709105547.71827eb8.zhouzhouyi@FreeBSD.org> References: <20070709105547.71827eb8.zhouzhouyi@FreeBSD.org> Organization: Institute of Software X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; i386-portbld-freebsd5.4) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: rewrite src/sys/i386/i386/in_cksum.c X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2007 03:14:13 -0000 Sorry, previously send the preprocessed version of in_cksum.c: What really needs to be replaced is for example: 408 if (mlen >= 16) { 409 ADD(0); 410 ADDC(4); 411 ADDC(8); 412 ADDC(12); 413 MOP; 414 w += 8; 415 mlen -= 16; 416 } On Mon, 9 Jul 2007 10:55:47 +0800 zhouyi zhou wrote: > Hey, > Since FreeBSD update gcc from 3.4.x to 4.2.0, the FreeBSD gdb remote debugger in i386 platform > will find the TCP/UPD checksum will not be computed right, when calling macro in_cksum > which calls in_cksum_skip in src/sys/i386/i386/in_cksum.c in case of getting rid of -O flag > supplied to gcc when compiling(The optimize will interfere with comfortable gdb debugging). > > The reason is for example in src/sys/i386/i386/in_cksum.c: > 126 if (mlen >= 16) { > 127 __asm volatile ("addl %1, %0" : "+r" (sum) : "g" (((const unsigned int *)w)[0 / 4])); > 128 __asm volatile ("adcl %1, %0" : "+r" (sum) : "g" (((const unsigned int *)w)[4 / 4])); > 129 __asm volatile ("adcl %1, %0" : "+r" (sum) : "g" (((const unsigned int *)w)[8 / 4])); > 130 __asm volatile ("adcl %1, %0" : "+r" (sum) : "g" (((const unsigned int *)w)[12 / 4])); > 131 __asm volatile ("adcl $0, %0" : "+r" (sum)); > 132 w += 8; > 133 mlen -= 16; > 134 } > From owner-freebsd-current@FreeBSD.ORG Mon Jul 9 03:27:32 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 36AA016A46B for ; Mon, 9 Jul 2007 03:27:32 +0000 (UTC) (envelope-from zhouzhouyi@FreeBSD.org) Received: from ercist.iscas.ac.cn (ercist.iscas.ac.cn [124.16.138.3]) by mx1.freebsd.org (Postfix) with SMTP id BA14C13C4B9 for ; Mon, 9 Jul 2007 03:27:29 +0000 (UTC) (envelope-from zhouzhouyi@FreeBSD.org) Received: (qmail 55506 invoked by uid 98); 9 Jul 2007 02:58:19 -0000 Received: from 222.191.237.170 by ercist.iscas.ac.cn (envelope-from , uid 89) with qmail-scanner-1.25 (spamassassin: 3.1.0. Clear:RC:1(222.191.237.170):SA:0(0.0/10.0):. Processed in 1.014499 secs); 09 Jul 2007 02:58:19 -0000 X-Spam-Status: No, hits=0.0 required=10.0 X-Qmail-Scanner-Mail-From: zhouzhouyi@FreeBSD.org via ercist.iscas.ac.cn X-Qmail-Scanner: 1.25 (Clear:RC:1(222.191.237.170):SA:0(0.0/10.0):. Processed in 1.014499 secs) Received: from unknown (HELO zzy.H.qngy.gscas) (zhouzhouyi@ercist.iscas.ac.cn@222.191.237.170) by 0 with SMTP; 9 Jul 2007 02:58:17 -0000 Date: Mon, 9 Jul 2007 10:55:47 +0800 From: zhouyi zhou To: freebsd-hackers@FreeBSD.org Message-Id: <20070709105547.71827eb8.zhouzhouyi@FreeBSD.org> Organization: Institute of Software X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; i386-portbld-freebsd5.4) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: rewrite src/sys/i386/i386/in_cksum.c X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2007 03:27:32 -0000 Hey, Since FreeBSD update gcc from 3.4.x to 4.2.0, the FreeBSD gdb remote debugger in i386 platform will find the TCP/UPD checksum will not be computed right, when calling macro in_cksum which calls in_cksum_skip in src/sys/i386/i386/in_cksum.c in case of getting rid of -O flag supplied to gcc when compiling(The optimize will interfere with comfortable gdb debugging). The reason is for example in src/sys/i386/i386/in_cksum.c: 126 if (mlen >= 16) { 127 __asm volatile ("addl %1, %0" : "+r" (sum) : "g" (((const unsigned int *)w)[0 / 4])); 128 __asm volatile ("adcl %1, %0" : "+r" (sum) : "g" (((const unsigned int *)w)[4 / 4])); 129 __asm volatile ("adcl %1, %0" : "+r" (sum) : "g" (((const unsigned int *)w)[8 / 4])); 130 __asm volatile ("adcl %1, %0" : "+r" (sum) : "g" (((const unsigned int *)w)[12 / 4])); 131 __asm volatile ("adcl $0, %0" : "+r" (sum)); 132 w += 8; 133 mlen -= 16; 134 } This is OK with gcc-3.4.x, because the compiler will not insert add instructions between the _asm expressions, but in gcc-4.x.x case, the compiler will insert add instruction between the _asm expressions which will let carrage bit in eflags cleared. 0x0804877c : cmpl $0xf,0xffffffec(%ebp) 0x08048780 : jle 0x80487d0 0x08048782 : mov 0xffffffe4(%ebp),%eax 0x08048785 : mov (%eax),%eax 0x08048787 : mov 0xffffffe8(%ebp),%edx 0x0804878a : add %eax,%edx 0x0804878c : mov %edx,0xffffffe8(%ebp) 0x0804878f : mov 0xffffffe4(%ebp),%eax ---Type to continue, or q to quit--- 0x08048792 : add $0x4,%eax 0x08048795 : mov (%eax),%eax 0x08048797 : mov 0xffffffe8(%ebp),%edx 0x0804879a : adc %eax,%edx 0x0804879c : mov %edx,0xffffffe8(%ebp) 0x0804879f : mov 0xffffffe4(%ebp),%eax 0x080487a2 : add $0x8,%eax 0x080487a5 : mov (%eax),%eax 0x080487a7 : mov 0xffffffe8(%ebp),%edx 0x080487aa : adc %eax,%edx 0x080487ac : mov %edx,0xffffffe8(%ebp) 0x080487af : mov 0xffffffe4(%ebp),%eax 0x080487b2 : add $0xc,%eax 0x080487b5 : mov (%eax),%eax 0x080487b7 : mov 0xffffffe8(%ebp),%edx 0x080487ba : adc %eax,%edx 0x080487bc : mov %edx,0xffffffe8(%ebp) So, I suggest rewrite src/sys/i386/i386/in_cksum.c in following style, for example: --- in_cksum.c 2007-07-06 22:45:52.000000000 +0000 +++ in_cksum1.c 2007-07-07 00:18:25.000000000 +0000 @@ -124,11 +124,14 @@ mlen -= 32; } if (mlen >= 16) { - __asm volatile ("addl %1, %0" : "+r" (sum) : "g" (((const unsigned int *)w)[0 / 4])); - __asm volatile ("adcl %1, %0" : "+r" (sum) : "g" (((const unsigned int *)w)[4 / 4])); - __asm volatile ("adcl %1, %0" : "+r" (sum) : "g" (((const unsigned int *)w)[8 / 4])); - __asm volatile ("adcl %1, %0" : "+r" (sum) : "g" (((const unsigned int *)w)[12 / 4])); - __asm volatile ("adcl $0, %0" : "+r" (sum)); + __asm volatile ("addl %1, %0 \n" + "adcl %2, %0 \n" + "adcl %3, %0 \n" + "adcl %4, %0 \n" + "adcl $0, %0": "+r"(sum): "g" (((const unsigned int *)w)[0 / 4]), + "g" (((const unsigned int *)w)[4 / 4]), + "g" (((const unsigned int *)w)[8 / 4]), + "g" (((const unsigned int *)w)[12 / 4])); w += 8; mlen -= 16; } If someone is interested in it, he can lend me a hand to rewrite all of the similiar cases. Sincerely yours Zhouyi Zhou From owner-freebsd-current@FreeBSD.ORG Mon Jul 9 03:54:14 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 16B6616A468 for ; Mon, 9 Jul 2007 03:54:14 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.177]) by mx1.freebsd.org (Postfix) with ESMTP id DD01413C489 for ; Mon, 9 Jul 2007 03:54:13 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by wa-out-1112.google.com with SMTP id j37so1200451waf for ; Sun, 08 Jul 2007 20:54:13 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:received:received:date:from:to:subject:message-id:reply-to:mime-version:content-type:content-disposition:user-agent; b=X8sdDG0YIT+p8hT3c29AceJQvyJtS3ODjH++72xysBT0KnwpIuufHEQL/AD6k2z5M1p3eNh79RuFKwxD4qyfKuuSgjLwCp+89O3V9I5ViW7dWVEIARePrf7dWY4oa4D48xJHeea5H/v5dfQuw6g9/dH+NtBovMhFT6YxnTJp2kE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:date:from:to:subject:message-id:reply-to:mime-version:content-type:content-disposition:user-agent; b=nn4XTdVVrxDwhOHw6SOQlymp6lF9rJ/6x6Mj4Z/9QKoOwEV0J0YH5A3S6yUJalo9QBn0uzE5h4O7tGQYsjnvnWoEkWs2Uc3SzjaT8cFWr5zUxVmLM9vJTKVGTfrU3jDHpYXp7z5Vy0n8eZPOAMwR2NzMkUf2vcp6WvCY70Ra8pg= Received: by 10.115.32.1 with SMTP id k1mr2730607waj.1183953253278; Sun, 08 Jul 2007 20:54:13 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTP id j29sm24007916waf.2007.07.08.20.54.10 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 08 Jul 2007 20:54:11 -0700 (PDT) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id l693s5P2002138 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 9 Jul 2007 12:54:05 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id l693s4B4002137 for freebsd-current@FreeBSD.org; Mon, 9 Jul 2007 12:54:04 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Mon, 9 Jul 2007 12:54:04 +0900 From: Pyun YongHyeon To: freebsd-current@FreeBSD.org Message-ID: <20070709035404.GF1062@cdnetworks.co.kr> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="ALfTUftag+2gvp1h" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Cc: Subject: CFT: re(4) MSI support X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2007 03:54:14 -0000 --ALfTUftag+2gvp1h Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, I've added MSI capability to re(4) and it would fix occasional watchdog timeout erros seen on re(4) when its interrupt is shared with other devices. The fix only affects PCIe based hardwares. In these days, more and more hardwares use PCIe based hardwares and these hardwares surly share interrupts with other devices. If you ever encountered watchdog timeouts on re(4) with PCIe hardwares please try attached patch and report back the result. Thanks. -- Regards, Pyun YongHyeon --ALfTUftag+2gvp1h Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="re.msi.patch" Index: if_re.c =================================================================== RCS file: /home/ncvs/src/sys/dev/re/if_re.c,v retrieving revision 1.91 diff -u -r1.91 if_re.c --- if_re.c 6 Jul 2007 00:05:11 -0000 1.91 +++ if_re.c 9 Jul 2007 01:52:23 -0000 @@ -160,6 +160,10 @@ #include +/* Tunables. */ +static int msi_disable = 0; +TUNABLE_INT("hw.re.msi_disable", &msi_disable); + #define RE_CSUM_FEATURES (CSUM_IP | CSUM_TCP | CSUM_UDP) /* @@ -1159,6 +1163,7 @@ int hwrev; u_int16_t re_did = 0; int error = 0, rid, i; + int msic, reg; sc = device_get_softc(dev); sc->rl_dev = dev; @@ -1185,15 +1190,45 @@ sc->rl_btag = rman_get_bustag(sc->rl_res); sc->rl_bhandle = rman_get_bushandle(sc->rl_res); - /* Allocate interrupt */ - rid = 0; - sc->rl_irq = bus_alloc_resource_any(dev, SYS_RES_IRQ, &rid, - RF_SHAREABLE | RF_ACTIVE); + msic = 0; + if (pci_find_extcap(dev, PCIY_EXPRESS, ®) == 0) { + msic = pci_msi_count(dev); + if (bootverbose) + device_printf(dev, "MSI count : %d\n", msic); + } + if (msic == RL_MSI_MESSAGES && msi_disable == 0) { + if (pci_alloc_msi(dev, &msic) == 0) { + if (msic == RL_MSI_MESSAGES) { + device_printf(dev, "Using %d MSI messages\n", + msic); + sc->rl_msi = 1; + } else + pci_release_msi(dev); + } + } - if (sc->rl_irq == NULL) { - device_printf(dev, "couldn't map interrupt\n"); - error = ENXIO; - goto fail; + /* Allocate interrupt */ + if (sc->rl_msi == 0) { + rid = 0; + sc->rl_irq[0] = bus_alloc_resource_any(dev, SYS_RES_IRQ, &rid, + RF_SHAREABLE | RF_ACTIVE); + if (sc->rl_irq[0] == NULL) { + device_printf(dev, "couldn't allocate IRQ resources\n"); + error = ENXIO; + goto fail; + } + } else { + for (i = 0, rid = 1; i < RL_MSI_MESSAGES; i++, rid++) { + sc->rl_irq[i] = bus_alloc_resource_any(dev, + SYS_RES_IRQ, &rid, RF_ACTIVE); + if (sc->rl_irq[i] == NULL) { + device_printf(dev, + "couldn't llocate IRQ resources for " + "message %d\n", rid); + error = ENXIO; + goto fail; + } + } } /* Reset the adapter. */ @@ -1320,8 +1355,19 @@ #endif /* Hook interrupt last to avoid having to lock softc */ - error = bus_setup_intr(dev, sc->rl_irq, INTR_TYPE_NET | INTR_MPSAFE, - re_intr, NULL, sc, &sc->rl_intrhand); + if (sc->rl_msi == 0) + error = bus_setup_intr(dev, sc->rl_irq[0], + INTR_TYPE_NET | INTR_MPSAFE, re_intr, NULL, sc, + &sc->rl_intrhand[0]); + else { + for (i = 0; i < RL_MSI_MESSAGES; i++) { + error = bus_setup_intr(dev, sc->rl_irq[i], + INTR_TYPE_NET | INTR_MPSAFE, re_intr, NULL, sc, + &sc->rl_intrhand[i]); + if (error != 0) + break; + } + } if (error) { device_printf(dev, "couldn't set up irq\n"); ether_ifdetach(ifp); @@ -1348,7 +1394,7 @@ { struct rl_softc *sc; struct ifnet *ifp; - int i; + int i, rid; sc = device_get_softc(dev); ifp = sc->rl_ifp; @@ -1393,12 +1439,31 @@ * stopped here. */ - if (sc->rl_intrhand) - bus_teardown_intr(dev, sc->rl_irq, sc->rl_intrhand); + for (i = 0; i < RL_MSI_MESSAGES; i++) { + if (sc->rl_intrhand[i] != NULL) { + bus_teardown_intr(dev, sc->rl_irq[i], + sc->rl_intrhand[i]); + sc->rl_intrhand[i] = NULL; + } + } if (ifp != NULL) if_free(ifp); - if (sc->rl_irq) - bus_release_resource(dev, SYS_RES_IRQ, 0, sc->rl_irq); + if (sc->rl_msi == 0) { + if (sc->rl_irq[0] != NULL) { + bus_release_resource(dev, SYS_RES_IRQ, 0, + sc->rl_irq[0]); + sc->rl_irq[0] = NULL; + } + } else { + for (i = 0, rid = 1; i < RL_MSI_MESSAGES; i++, rid++) { + if (sc->rl_irq[i] != NULL) { + bus_release_resource(dev, SYS_RES_IRQ, rid, + sc->rl_irq[i]); + sc->rl_irq[i] = NULL; + } + } + pci_release_msi(dev); + } if (sc->rl_res) bus_release_resource(dev, RL_RES, RL_RID, sc->rl_res); Index: ../../pci/if_rl.c =================================================================== RCS file: /home/ncvs/src/sys/pci/if_rl.c,v retrieving revision 1.169 diff -u -r1.169 if_rl.c --- ../../pci/if_rl.c 23 Feb 2007 12:19:03 -0000 1.169 +++ ../../pci/if_rl.c 9 Jul 2007 01:52:24 -0000 @@ -828,10 +828,10 @@ /* Allocate interrupt */ rid = 0; - sc->rl_irq = bus_alloc_resource_any(dev, SYS_RES_IRQ, &rid, + sc->rl_irq[0] = bus_alloc_resource_any(dev, SYS_RES_IRQ, &rid, RF_SHAREABLE | RF_ACTIVE); - if (sc->rl_irq == NULL) { + if (sc->rl_irq[0] == NULL) { device_printf(dev, "couldn't map interrupt\n"); error = ENXIO; goto fail; @@ -971,8 +971,8 @@ ether_ifattach(ifp, eaddr); /* Hook interrupt last to avoid having to lock softc */ - error = bus_setup_intr(dev, sc->rl_irq, INTR_TYPE_NET | INTR_MPSAFE, - NULL, rl_intr, sc, &sc->rl_intrhand); + error = bus_setup_intr(dev, sc->rl_irq[0], INTR_TYPE_NET | INTR_MPSAFE, + NULL, rl_intr, sc, &sc->rl_intrhand[0]); if (error) { device_printf(sc->rl_dev, "couldn't set up irq\n"); ether_ifdetach(ifp); @@ -1022,10 +1022,10 @@ device_delete_child(dev, sc->rl_miibus); bus_generic_detach(dev); - if (sc->rl_intrhand) - bus_teardown_intr(dev, sc->rl_irq, sc->rl_intrhand); - if (sc->rl_irq) - bus_release_resource(dev, SYS_RES_IRQ, 0, sc->rl_irq); + if (sc->rl_intrhand[0]) + bus_teardown_intr(dev, sc->rl_irq[0], sc->rl_intrhand[0]); + if (sc->rl_irq[0]) + bus_release_resource(dev, SYS_RES_IRQ, 0, sc->rl_irq[0]); if (sc->rl_res) bus_release_resource(dev, RL_RES, RL_RID, sc->rl_res); Index: ../../pci/if_rlreg.h =================================================================== RCS file: /home/ncvs/src/sys/pci/if_rlreg.h,v retrieving revision 1.66 diff -u -r1.66 if_rlreg.h --- ../../pci/if_rlreg.h 6 Jul 2007 00:05:12 -0000 1.66 +++ ../../pci/if_rlreg.h 9 Jul 2007 01:52:24 -0000 @@ -664,6 +664,8 @@ #define RE_RX_DESC_BUFLEN MCLBYTES #endif +#define RL_MSI_MESSAGES 2 + #define RL_ADDR_LO(y) ((uint64_t) (y) & 0xFFFFFFFF) #define RL_ADDR_HI(y) ((uint64_t) (y) >> 32) @@ -710,8 +712,8 @@ bus_space_tag_t rl_btag; /* bus space tag */ device_t rl_dev; struct resource *rl_res; - struct resource *rl_irq; - void *rl_intrhand; + struct resource *rl_irq[RL_MSI_MESSAGES]; + void *rl_intrhand[RL_MSI_MESSAGES]; device_t rl_miibus; bus_dma_tag_t rl_parent_tag; bus_dma_tag_t rl_tag; @@ -742,6 +744,7 @@ struct mtx rl_intlock; int rl_txstart; int rl_link; + int rl_msi; }; #define RL_LOCK(_sc) mtx_lock(&(_sc)->rl_mtx) --ALfTUftag+2gvp1h-- From owner-freebsd-current@FreeBSD.ORG Mon Jul 9 04:13:40 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D9AAD16A400; Mon, 9 Jul 2007 04:13:40 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (nagual.pp.ru [194.87.13.69]) by mx1.freebsd.org (Postfix) with ESMTP id 4D14A13C468; Mon, 9 Jul 2007 04:13:39 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.14.1/8.14.1) with ESMTP id l694Dca4097527; Mon, 9 Jul 2007 08:13:38 +0400 (MSD) (envelope-from ache@nagual.pp.ru) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nagual.pp.ru; s=default; t=1183954418; bh=DailEOU/EkCDg2HhRLlRvnJh1HmEsB+JCjaiyR3 dHLM=; l=442; h=Received:Date:From:To:Cc:Subject:Message-ID: Mail-Followup-To:References:MIME-Version:Content-Type: Content-Disposition:In-Reply-To:User-Agent; b=ZAD0/UC1VRV2p+3VDgNs kgIJJaDOndWUulvG9VGIP52m45dOblNtBUJXgLkauepsh3HaqCOlF+zSQtOVSEVlFzO 4JuiOlejOEZ4/UT5rSXsloVdKw/Ws4ORIO+ffLH/JF8g5cYIvm755b5spuFzQQQOweY TT7pgcoT7BMXmxqvA= Received: (from ache@localhost) by nagual.pp.ru (8.14.1/8.14.1/Submit) id l694Dc41097526; Mon, 9 Jul 2007 08:13:38 +0400 (MSD) (envelope-from ache) Date: Mon, 9 Jul 2007 08:13:37 +0400 From: Andrey Chernov To: "Sean C. Farley" Message-ID: <20070709041337.GA97347@nagual.pp.ru> Mail-Followup-To: Andrey Chernov , "Sean C. Farley" , Robert Watson , freebsd-current , Michal Mertl References: <20070707130859.GA96605@nagual.pp.ru> <20070707131359.GB96605@nagual.pp.ru> <20070707133102.C14065@thor.farley.org> <20070707191835.GA4368@nagual.pp.ru> <20070707205410.B14065@thor.farley.org> <20070708020940.GA80166@nagual.pp.ru> <20070708171727.GA90490@nagual.pp.ru> <20070708125905.F14065@thor.farley.org> <20070708183823.GA91359@nagual.pp.ru> <20070708203635.A14065@thor.farley.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070708203635.A14065@thor.farley.org> User-Agent: Mutt/1.5.16 (2007-06-09) Cc: freebsd-current , Robert Watson , Michal Mertl Subject: Re: Environment handling broken in /bin/sh with changes to {get,set,put}env() X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2007 04:13:40 -0000 On Sun, Jul 08, 2007 at 08:40:11PM -0500, Sean C. Farley wrote: > > Your interpretation of the specification is correct. My latest patch > should apply. I changed getenv() to never change environ. If it > detects that environ was replaced, it falls back to returning the value > from there. Only setenv(), unsetenv() and putenv() will alter environ. > How does it look to you? Ok now. No suggestions left. -- http://ache.pp.ru/ From owner-freebsd-current@FreeBSD.ORG Mon Jul 9 04:18:39 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3D7B716A400 for ; Mon, 9 Jul 2007 04:18:39 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id CC20E13C45D for ; Mon, 9 Jul 2007 04:18:38 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from [192.168.254.15] (ydesk.samsco.home [192.168.254.15]) (authenticated bits=0) by pooker.samsco.org (8.13.8/8.13.8) with ESMTP id l694IVrf079578; Sun, 8 Jul 2007 22:18:31 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <4691B717.502@samsco.org> Date: Sun, 08 Jul 2007 22:18:31 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.7) Gecko/20050416 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kostik Belousov References: <20070703180141.GJ2200@deviant.kiev.zoral.com.ua> <20070705144443.GV2200@deviant.kiev.zoral.com.ua> <20070707160042.GJ2200@deviant.kiev.zoral.com.ua> <07070809441413.59322@www.mmlab.cse.yzu.edu.tw> <20070708024815.GK2200@deviant.kiev.zoral.com.ua> <0707082155317.77206@www.mmlab.cse.yzu.edu.tw> <20070708191928.GM2200@deviant.kiev.zoral.com.ua> In-Reply-To: <20070708191928.GM2200@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (pooker.samsco.org [192.168.254.1]); Sun, 08 Jul 2007 22:18:32 -0600 (MDT) X-Spam-Status: No, score=-1.4 required=5.5 tests=ALL_TRUSTED autolearn=failed version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: Tai-hwa Liang , current@freebsd.org Subject: Re: HEADS UP: destroy_dev_sched() KPI in the tree X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2007 04:18:39 -0000 Kostik Belousov wrote: > On Sun, Jul 08, 2007 at 10:00:14PM +0800, Tai-hwa Liang wrote: > >>On Sun, 8 Jul 2007, Kostik Belousov wrote: >> >>>On Sun, Jul 08, 2007 at 09:47:41AM +0800, Tai-hwa Liang wrote: >> >>[...] >> >>>> Though it was reviewed before destroy_dev_sched() KPI enters to the >>>> tree, >>>>I'd be appreciate it if you can reviewed the attached patch again. >>> >>>So, this is still the problem for scsi_targ ? >>> >>>It probably make sense to postpone free of softc until all threads >>>finished using it. You may use destroy_dev_sched_cb() to run the >>>function after the device is actually destroyed. It would just call >>>free(). >> >> Probably; however, I did not see any code inside scsi_target.c to >>detach or unregister the scsi_target device. Will this cause any >>cdev leakage? > > This is not about cdev linkage. Immediately after call to > destriy_dev_sched(), driver code frees dev' softc. Thus, if any thread > is still inside cdev method, it could access freed memory. Postponing > the call to free until all threads leave the cdev methods would eliminate > this bug. > Nate and I and the other SCSI guys can take a whack at scsi_targ, so don't worry too much about slaying the dragons in it. Scott From owner-freebsd-current@FreeBSD.ORG Mon Jul 9 07:48:52 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AA84B16A468; Mon, 9 Jul 2007 07:48:52 +0000 (UTC) (envelope-from dfr@rabson.org) Received: from itchy.rabson.org (mailgate.nlsystems.com [80.177.232.242]) by mx1.freebsd.org (Postfix) with ESMTP id 61C0A13C448; Mon, 9 Jul 2007 07:48:52 +0000 (UTC) (envelope-from dfr@rabson.org) Received: from herring.rabson.org (herring.rabson.org [80.177.232.250]) by itchy.rabson.org (8.13.3/8.13.3) with ESMTP id l697moH7058085; Mon, 9 Jul 2007 08:48:50 +0100 (BST) (envelope-from dfr@rabson.org) From: Doug Rabson To: Pawel Jakub Dawidek Date: Mon, 9 Jul 2007 08:48:49 +0100 User-Agent: KMail/1.9.6 References: <200707071426.18202.dfr@rabson.org> <20070709000918.GD1208@garage.freebsd.pl> (sfid-20070709_01093_48523222) In-Reply-To: <20070709000918.GD1208@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200707090848.50190.dfr@rabson.org> X-Virus-Scanned: ClamAV 0.87.1/3613/Mon Jul 9 02:16:11 2007 on itchy.rabson.org X-Virus-Status: Clean Cc: current@freebsd.org Subject: Re: Re: ZFS leaking vnodes (sort of) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2007 07:48:52 -0000 On Monday 09 July 2007, Pawel Jakub Dawidek wrote: > On Sat, Jul 07, 2007 at 02:26:17PM +0100, Doug Rabson wrote: > > I've been testing ZFS recently and I noticed some performance > > issues while doing large-scale port builds on a ZFS mounted > > /usr/ports tree. Eventually I realised that virtually nothing ever > > ended up on the vnode free list. This meant that when the system > > reached its maximum vnode limit, it had to resort to reclaiming > > vnodes from the various filesystem's active vnode lists (via > > vlrureclaim). Since those lists are not sorted in LRU order, this > > led to pessimal cache performance after the system got into that > > state. > > > > I looked a bit closer at the ZFS code and poked around with DDB and > > I think the problem was caused by a couple of extraneous calls to > > vhold when creating a new ZFS vnode. On FreeBSD, getnewvnode > > returns a vnode which is already held (not on the free list) so > > there is no need to call vhold again. > > Whoa! Nice catch... The patch works here - I did some pretty heavy > tests, so please commit it ASAP. > > I also wonder if this can help with some of those 'kmem_map too > small' panics. I was observing that ARC cannot reclaim memory and > this may be because all vnodes and thus associated data are beeing > held. > > To ZFS users having problems with performance and/or stability of > ZFS: Can you test the patch and see if it helps? I think it should help the memory usage problems - for one thing since the vnodes were never hitting the free list, VOP_INACTIVE wasn't being properly called on then after last-close which (I think) is supposed to flush out various things. Not quite sure about that bit. Certainly it reduces the number of active vnodes in the system back down to the wantfreevnodes value. From owner-freebsd-current@FreeBSD.ORG Mon Jul 9 07:52:11 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D9C4516A400 for ; Mon, 9 Jul 2007 07:52:11 +0000 (UTC) (envelope-from ganbold@micom.mng.net) Received: from publicd.ub.mng.net (publicd.ub.mng.net [202.179.0.88]) by mx1.freebsd.org (Postfix) with ESMTP id 7596313C45E for ; Mon, 9 Jul 2007 07:52:11 +0000 (UTC) (envelope-from ganbold@micom.mng.net) Received: from [202.179.0.164] (helo=daemon.micom.mng.net) by publicd.ub.mng.net with esmtpa (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I7o1X-000E5f-B7 for freebsd-current@freebsd.org; Mon, 09 Jul 2007 15:52:08 +0800 Message-ID: <4691E8F0.8080005@micom.mng.net> Date: Mon, 09 Jul 2007 15:51:12 +0800 From: Ganbold User-Agent: Thunderbird 2.0.0.0 (X11/20070425) MIME-Version: 1.0 To: "freebsd-current@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: today's buildworld breaks X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2007 07:52:11 -0000 Hi, I'm trying to update my machine, however buildworld fails with following error: ... ln -fs /usr/obj/usr/src/tmp/lib/libkvm.so.4 /usr/obj/usr/src/tmp/usr/lib/libkvm.so sh /usr/src/tools/install.sh -C -o root -g wheel -m 444 /usr/src/lib/libkvm/kvm.h /usr/obj/usr/src/tmp/usr/include ===> lib/libmd (obj,depend,all,install) (echo '#define LENGTH 16'; sed -e 's/mdX/md2/g' -e 's/MDX/MD2/g' /usr/src/lib/libmd/mdXhl.c) > md2hl.c (echo '#define LENGTH 16'; sed -e 's/mdX/md4/g' -e 's/MDX/MD4/g' /usr/src/lib/libmd/mdXhl.c) > md4hl.c (echo '#define LENGTH 16'; sed -e 's/mdX/md5/g' -e 's/MDX/MD5/g' /usr/src/lib/libmd/mdXhl.c) > md5hl.c (echo '#define LENGTH 20'; sed -e 's/mdX/ripemd/g' -e 's/MDX/RIPEMD160_/g' -e 's/RIPEMD160__/RIPEMD160_/g' /usr/src/lib/libmd/mdXhl.c) > rmd160hl.c (echo '#define LENGTH 20'; sed -e 's/mdX/sha/g' -e 's/MDX/SHA_/g' -e 's/SHA__/SHA_/g' /usr/src/lib/libmd/mdXhl.c) > sha0hl.c (echo '#define LENGTH 20'; sed -e 's/mdX/sha/g' -e 's/MDX/SHA1_/g' -e 's/SHA1__/SHA1_/g' /usr/src/lib/libmd/mdXhl.c) > sha1hl.c (echo '#define LENGTH 32'; sed -e 's/mdX/sha256/g' -e 's/MDX/SHA256_/g' -e 's/SHA256__/SHA256_/g' /usr/src/lib/libmd/mdXhl.c) > sha256hl.c rm -f .depend mkdep -f .depend -a -I/usr/src/lib/libmd -DSHA1_ASM -DELF -DRMD160_ASM -DELF /usr/src/lib/libmd/md2c.c /usr/src/lib/libmd/md4c.c /usr/src/lib/libmd/md5c.c md2hl.c md4hl.c md5hl.c /usr/src/lib/libmd/rmd160c.c rmd160hl.c /usr/src/lib/libmd/sha0c.c sha0hl.c /usr/src/lib/libmd/sha1c.c sha1hl.c /usr/src/lib/libmd/sha256c.c sha256hl.c /usr/src/lib/libmd/i386/sha.S /usr/src/lib/libmd/i386/rmd160.S cc -O1 -pipe -I/usr/src/lib/libmd -DSHA1_ASM -DELF -DRMD160_ASM -DELF -c /usr/src/lib/libmd/md2c.c cc -O1 -pipe -I/usr/src/lib/libmd -DSHA1_ASM -DELF -DRMD160_ASM -DELF -c /usr/src/lib/libmd/md4c.c cc -O1 -pipe -I/usr/src/lib/libmd -DSHA1_ASM -DELF -DRMD160_ASM -DELF -c /usr/src/lib/libmd/md5c.c cc -O1 -pipe -I/usr/src/lib/libmd -DSHA1_ASM -DELF -DRMD160_ASM -DELF -c md2hl.c md2hl.c:25: error: expected ')' before '*' token md2hl.c: In function 'md2File': md2hl.c:47: warning: return makes pointer from integer without a cast md2hl.c: At top level: md2hl.c:52: error: conflicting types for 'md2FileChunk' md2hl.c:47: error: previous implicit declaration of 'md2FileChunk' was here md2hl.c: In function 'md2FileChunk': md2hl.c:54: error: 'md2_CTX' undeclared (first use in this function) md2hl.c:54: error: (Each undeclared identifier is reported only once md2hl.c:54: error: for each function it appears in.) md2hl.c:54: error: expected ';' before 'ctx' md2hl.c:59: error: 'ctx' undeclared (first use in this function) md2hl.c:88: warning: return makes pointer from integer without a cast md2hl.c: In function 'md2Data': md2hl.c:94: error: 'md2_CTX' undeclared (first use in this function) md2hl.c:94: error: expected ';' before 'ctx' md2hl.c:96: error: 'ctx' undeclared (first use in this function) md2hl.c:98: warning: return makes pointer from integer without a cast *** Error code 1 Stop in /usr/src/lib/libmd. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. devil# How to fix this problem? thanks, Ganbold -- Delusions are often functional. A mother's opinions about her children's beauty, intelligence, goodness, et cetera ad nauseam, keep her from drowning them at birth. From owner-freebsd-current@FreeBSD.ORG Mon Jul 9 08:08:22 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B341516A41F for ; Mon, 9 Jul 2007 08:08:12 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [210.51.165.229]) by mx1.freebsd.org (Postfix) with ESMTP id 690C713C447 for ; Mon, 9 Jul 2007 08:08:12 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from localhost (tarsier.geekcn.org [210.51.165.229]) by tarsier.geekcn.org (Postfix) with ESMTP id 90CA1EB55C7; Mon, 9 Jul 2007 16:08:11 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([210.51.165.229]) by localhost (mail.geekcn.org [210.51.165.229]) (amavisd-new, port 10024) with ESMTP id oLUS8IgTzcq5; Mon, 9 Jul 2007 16:08:05 +0800 (CST) Received: from LI-Xins-MacBook.local (sina152-194.staff.sina.com.cn [61.135.152.194]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTP id 81008EB0D9F; Mon, 9 Jul 2007 16:08:05 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:cc:subject:references:in-reply-to: x-enigmail-version:openpgp:content-type; b=gPO91kBDJbXqiCEhM9+dEp0/XNn1JUwQSOKEXrVMjxNIX0fAsChl+D0/QE8hpG7Wp TpS0eUIFqlRY+W+IsOZqA== Message-ID: <4691ECDC.8070500@delphij.net> Date: Mon, 09 Jul 2007 16:07:56 +0800 From: LI Xin Organization: The FreeBSD Project User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) MIME-Version: 1.0 To: Ganbold References: <4691E8F0.8080005@micom.mng.net> In-Reply-To: <4691E8F0.8080005@micom.mng.net> X-Enigmail-Version: 0.95.2 OpenPGP: url=http://www.delphij.net/delphij.asc Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enigA571B761D6F26BE64120F73D" Cc: "freebsd-current@freebsd.org" Subject: Re: today's buildworld breaks X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2007 08:08:22 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA571B761D6F26BE64120F73D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Ganbold wrote: > Hi, >=20 > I'm trying to update my machine, however buildworld fails with followin= g > error: re-sync your code and make sure that you have src/usr.bin/sed/compile.c,v 1.30, then: cd /usr/src/usr.bin/sed make cleandir make cleandir make obj make depend make make install Then do 'make buildworld' would work out ok. See my previous mail to -current@. Cheers, --=20 Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! --------------enigA571B761D6F26BE64120F73D 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.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGkezdOfuToMruuMARCscFAJ4k+QcxwY/Xm7prntWK3SOtre2/LQCdGUpI DaYTh1SRyAjSFxfBfRP3e5Q= =KCF+ -----END PGP SIGNATURE----- --------------enigA571B761D6F26BE64120F73D-- From owner-freebsd-current@FreeBSD.ORG Mon Jul 9 08:15:15 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BB79016A421; Mon, 9 Jul 2007 08:15:15 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 92EC613C44B; Mon, 9 Jul 2007 08:15:15 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.13.8/8.13.8) with ESMTP id l698FFYW082452; Mon, 9 Jul 2007 04:15:15 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.8/8.13.8) with ESMTP id l698FElB043807; Mon, 9 Jul 2007 04:15:14 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id A0FBA73068; Mon, 9 Jul 2007 04:15:14 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070709081514.A0FBA73068@freebsd-current.sentex.ca> Date: Mon, 9 Jul 2007 04:15:14 -0400 (EDT) X-Virus-Scanned: ClamAV version devel-20070102, clamav-milter version devel-111206 on clamscanner3 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2007 08:15:15 -0000 TB --- 2007-07-09 06:34:19 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-07-09 06:34:19 - starting HEAD tinderbox run for i386/i386 TB --- 2007-07-09 06:34:19 - cleaning the object tree TB --- 2007-07-09 06:34:54 - checking out the source tree TB --- 2007-07-09 06:34:54 - cd /tinderbox/HEAD/i386/i386 TB --- 2007-07-09 06:34:54 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-07-09 06:43:48 - building world (CFLAGS=-O2 -pipe) TB --- 2007-07-09 06:43:48 - cd /src TB --- 2007-07-09 06:43:48 - /usr/bin/make -B buildworld >>> World build started on Mon Jul 9 06:43:49 UTC 2007 >>> 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 Mon Jul 9 08:03:52 UTC 2007 TB --- 2007-07-09 08:03:52 - generating LINT kernel config TB --- 2007-07-09 08:03:52 - cd /src/sys/i386/conf TB --- 2007-07-09 08:03:52 - /usr/bin/make -B LINT TB --- 2007-07-09 08:03:52 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-07-09 08:03:52 - cd /src TB --- 2007-07-09 08:03:52 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Jul 9 08:03:53 UTC 2007 >>> 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 -Werror -pg -mprofiler-epilogue /src/sys/dev/usb/ehci_pci.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 -Werror -pg -mprofiler-epilogue /src/sys/dev/usb/hid.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 -Werror -pg -mprofiler-epilogue /src/sys/dev/usb/if_aue.c In file included from /src/sys/dev/usb/if_aue.c:100: ./usbdevs.h:586:1: error: "USB_VENDOR_NOVATEL" redefined ./usbdevs.h:469:1: error: this is the location of the previous definition ./usbdevs.h:642:1: error: "USB_VENDOR_PROLIFIC2" redefined ./usbdevs.h:566:1: error: this is the location of the previous definition *** Error code 1 Stop in /obj/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-07-09 08:15:14 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-07-09 08:15:14 - ERROR: failed to build lint kernel TB --- 2007-07-09 08:15:14 - tinderbox aborted TB --- 0.85 user 3.04 system 6054.95 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Mon Jul 9 08:18:18 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8586C16A400 for ; Mon, 9 Jul 2007 08:18:18 +0000 (UTC) (envelope-from ganbold@micom.mng.net) Received: from publicd.ub.mng.net (publicd.ub.mng.net [202.179.0.88]) by mx1.freebsd.org (Postfix) with ESMTP id D41B513C45D for ; Mon, 9 Jul 2007 08:18:17 +0000 (UTC) (envelope-from ganbold@micom.mng.net) Received: from [202.179.0.164] (helo=daemon.micom.mng.net) by publicd.ub.mng.net with esmtpa (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I7oRg-000ELh-VE; Mon, 09 Jul 2007 16:18:13 +0800 Message-ID: <4691EF44.50408@micom.mng.net> Date: Mon, 09 Jul 2007 16:18:12 +0800 From: Ganbold User-Agent: Thunderbird 2.0.0.0 (X11/20070425) MIME-Version: 1.0 To: d@delphij.net References: <4691E8F0.8080005@micom.mng.net> <4691ECDC.8070500@delphij.net> In-Reply-To: <4691ECDC.8070500@delphij.net> 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-current@freebsd.org" Subject: Re: today's buildworld breaks X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2007 08:18:18 -0000 LI Xin wrote: > Ganbold wrote: > >> Hi, >> >> I'm trying to update my machine, however buildworld fails with following >> error: >> > > re-sync your code and make sure that you have > src/usr.bin/sed/compile.c,v 1.30, then: > > cd /usr/src/usr.bin/sed > make cleandir > make cleandir > make obj > make depend > make > make install > > Then do 'make buildworld' would work out ok. See my previous mail to > -current@. > > Cheers, > Thanks a lot, I just started buildworld again. Should it be noted somewhere, maybe in /usr/src/UPDATING? Maybe I'm wrong here. thanks, Ganbold -- Experience is that marvelous thing that enables you recognize a mistake when you make it again. -- Franklin Jones From owner-freebsd-current@FreeBSD.ORG Mon Jul 9 08:44:09 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 34F7C16A421 for ; Mon, 9 Jul 2007 08:44:09 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from redbull.bpaserver.net (redbullneu.bpaserver.net [213.198.78.217]) by mx1.freebsd.org (Postfix) with ESMTP id E76CD13C487 for ; Mon, 9 Jul 2007 08:44:08 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from outgoing.leidinger.net (p54A579F8.dip.t-dialin.net [84.165.121.248]) by redbull.bpaserver.net (Postfix) with ESMTP id E65A42E1DD; Mon, 9 Jul 2007 10:44:03 +0200 (CEST) Received: from webmail.leidinger.net (webmail.Leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id BECA05B5A49; Mon, 9 Jul 2007 10:41:52 +0200 (CEST) Received: (from www@localhost) by webmail.leidinger.net (8.13.8/8.13.8/Submit) id l698fqxc057080; Mon, 9 Jul 2007 10:41:52 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from pslux.cec.eu.int (pslux.cec.eu.int [158.169.9.14]) by webmail.leidinger.net (Horde MIME library) with HTTP; Mon, 09 Jul 2007 10:41:52 +0200 Message-ID: <20070709104152.rsg4v3hjww8woksk@webmail.leidinger.net> X-Priority: 3 (Normal) Date: Mon, 09 Jul 2007 10:41:52 +0200 From: Alexander Leidinger To: bushman@rsu.ru MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.1.4) / FreeBSD-7.0 X-BPAnet-MailScanner-Information: Please contact the ISP for more information X-BPAnet-MailScanner: Found to be clean X-BPAnet-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-14.9, required 8, BAYES_00 -15.00, DKIM_POLICY_SIGNSOME 0.00, RDNS_DYNAMIC 0.10) X-BPAnet-MailScanner-From: alexander@leidinger.net X-Spam-Status: No Cc: current@freebsd.org Subject: cached update flaws... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2007 08:44:09 -0000 Hi, somehow cached doesn't work as I think it should work. I have a jail in which I use cached. There I wanted to install doxygen. As part of this cups (dependency from qt) is build. The cups port adds a cups user and group. After adding the group/user the configure script checks for the user. This fails as cached doesn't know about the added user. I have to restart cached to see the user/group (tested with "pw groupshow cups"). Are my expectations about cached wrong, or is it misbehaving? And while we are at it, is there really a need to print the cached version number and the fact that it was developed during GSoC 2005 at each start? It clutters the visual appearance at boot time. Bye, Alexander. -- Lord, defend me from my friends; I can account for my enemies. -- Charles D'Hericault http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-current@FreeBSD.ORG Mon Jul 9 08:50:47 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6D95616A41F for ; Mon, 9 Jul 2007 08:50:47 +0000 (UTC) (envelope-from grafan@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.179]) by mx1.freebsd.org (Postfix) with ESMTP id 2DD4D13C447 for ; Mon, 9 Jul 2007 08:50:46 +0000 (UTC) (envelope-from grafan@gmail.com) Received: by py-out-1112.google.com with SMTP id a73so1684255pye for ; Mon, 09 Jul 2007 01:50:46 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=rNO2FosZVu1lnrDnEgONqNK+kg3pP9QOGpCIvag/qEYR/jvcG0h51myQU4QH4dpbSrQm+6RAlO1kmlLxA8X0UX+fTMEmt9FmWmEEGSspNtkzT26Ar2RbrGWEG7/7OcwyO3u4EuZ6R588cdsyycmloVpAYKFZ2nlRs14OOW1TNyk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=VBaD++hnQrCM1Lozw+DQZp2lk+e47iV3egLxjTfQ5m6HeWfisPJZthiDlwODWw83Ff3Jojigl0q2BzkCuvVh6oXWd5z70n0KBZvtbMAXgrhAVCq4SmaHtQWWOZksWzKfADwMJKNovFD111cdGdcO+Jqge+1lgcwMI+s+CcCvBFU= Received: by 10.64.10.2 with SMTP id 2mr4360799qbj.1183971046262; Mon, 09 Jul 2007 01:50:46 -0700 (PDT) Received: by 10.64.185.10 with HTTP; Mon, 9 Jul 2007 01:50:46 -0700 (PDT) Message-ID: <6eb82e0707090150t2977c32ex42abf09c21eb6a5b@mail.gmail.com> Date: Mon, 9 Jul 2007 16:50:46 +0800 From: "Rong-en Fan" To: "Alexander Leidinger" In-Reply-To: <20070709104152.rsg4v3hjww8woksk@webmail.leidinger.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070709104152.rsg4v3hjww8woksk@webmail.leidinger.net> Cc: current@freebsd.org, bushman@rsu.ru Subject: Re: cached update flaws... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2007 08:50:47 -0000 On 7/9/07, Alexander Leidinger wrote: > Hi, > > somehow cached doesn't work as I think it should work. I have a jail > in which I use cached. There I wanted to install doxygen. As part of > this cups (dependency from qt) is build. The cups port adds a cups > user and group. After adding the group/user the configure script > checks for the user. This fails as cached doesn't know about the added > user. I have to restart cached to see the user/group (tested with "pw > groupshow cups"). > > Are my expectations about cached wrong, or is it misbehaving? I encountered the same problem few days ago. But I forget which port I was installing. > And while we are at it, is there really a need to print the cached > version number and the fact that it was developed during GSoC 2005 at > each start? It clutters the visual appearance at boot time. I feel the same. BTW, is there any plan to enable cached by default in 7.0? Regards, Rong-En Fan > > Bye, > Alexander. > > -- > Lord, defend me from my friends; I can account for my enemies. > -- Charles D'Hericault > > http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 > http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Mon Jul 9 09:18:09 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5A2F016A468 for ; Mon, 9 Jul 2007 09:18:09 +0000 (UTC) (envelope-from ianf@clue.co.za) Received: from munchkin.clue.co.za (munchkin.clue.co.za [66.219.59.160]) by mx1.freebsd.org (Postfix) with ESMTP id 2B4BE13C46C for ; Mon, 9 Jul 2007 09:18:09 +0000 (UTC) (envelope-from ianf@clue.co.za) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=20070313; d=clue.co.za; h=Received:Received:Received:To:cc:Subject:From:X-Attribution:Date:Message-Id; b=BGrp6q6vyVlEcWnU+64mtmFhUfYLmd4K1mbI+dPRK20+ioCYOW2AvLgY2qRV7VnKGYr6z/ry6XmTu8rQdDkIKbobayAAp1IcPqe7qDU+ph+5zvju0YqwLhzk25uc/LVu3UJrAtXw7cPq09juyJimKdW7LJ9qjFWahbXpT4arS4bd4tD9FfSAVFVFQa6Z7hTv+3Zjy5fkxlFdLKO9UkmdCZ+LxKimXqliRETbIt4KVF+M1l362FoYMZcWy+fx322M; Received: from uucp by munchkin.clue.co.za with local (Exim 4.66) (envelope-from ) id 1I7pNg-0006sq-KZ; Mon, 09 Jul 2007 09:18:08 +0000 Received: from ianf.clue.co.za ([10.0.0.6] helo=clue.co.za) by urchin.clue.co.za with esmtpa (Exim 4.66) (envelope-from ) id 1I7pMk-0006ix-5r; Mon, 09 Jul 2007 09:17:10 +0000 Received: from localhost ([127.0.0.1] helo=clue.co.za) by clue.co.za with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I7pMi-0000jV-Uy; Mon, 09 Jul 2007 11:17:08 +0200 To: imp@freebsd.org From: Ian FREISLICH X-Attribution: BOFH Date: Mon, 09 Jul 2007 11:17:08 +0200 Message-Id: Cc: current@freebsd.org Subject: Duplicate vendor names in usbdevs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2007 09:18:09 -0000 Hi These duplicate vendor names were introduced in rev 1.320: vendor NOVATEL 0x09d7 Novatel Wireless vendor NOVATEL 0x1410 Novatel Wireless and vendor PROLIFIC2 0x11f6 Prolific vendor PROLIFIC2 0x5372 Prolific Technology Ian -- Ian Freislich From owner-freebsd-current@FreeBSD.ORG Mon Jul 9 09:47:12 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 73BAE16A46B for ; Mon, 9 Jul 2007 09:47:12 +0000 (UTC) (envelope-from lulf@stud.ntnu.no) Received: from merke.itea.ntnu.no (merke.itea.ntnu.no [129.241.7.61]) by mx1.freebsd.org (Postfix) with ESMTP id 3587013C46A for ; Mon, 9 Jul 2007 09:47:12 +0000 (UTC) (envelope-from lulf@stud.ntnu.no) Received: from localhost (localhost [127.0.0.1]) by merke.itea.ntnu.no (Postfix) with ESMTP id CD24313D659; Mon, 9 Jul 2007 11:23:15 +0200 (CEST) Received: from gaupe.stud.ntnu.no (gaupe.stud.ntnu.no [129.241.56.184]) by merke.itea.ntnu.no (Postfix) with ESMTP; Mon, 9 Jul 2007 11:22:46 +0200 (CEST) Received: by gaupe.stud.ntnu.no (Postfix, from userid 2312) id 5C933D0034; Mon, 9 Jul 2007 11:22:52 +0200 (CEST) Date: Mon, 9 Jul 2007 11:22:52 +0200 From: Ulf Lilleengen To: freebsd-geom@freebsd.org Message-ID: <20070709092252.GA7809@stud.ntnu.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i X-Content-Scanned: with sophos and spamassassin at mailgw.ntnu.no. Cc: freebsd-current@freebsd.org Subject: Patches for updated gvinum X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2007 09:47:12 -0000 Hi, Gvinum just got better. At least, that's what I hope. Lukas rewrote gvinum to use a simpler and easier to handle single-thread event system, and I have been adapting existing code to this. The result can be found in the patches here: http://folk.ntnu.no/lulf/patches/freebsd/gvinum One is for current, and the other is for RELENG_6. The code is not tested on RELENG_6 yet, but I expect I'll do that soon. This patch includes some missed gvinum features, as well as improvements on old ones. It is completely compatible with old vinum/gvinum configurations, so there should not be any problems with upgrading. However, even though it might seem to work for us, that might not be the case for others! Therefore, I hope many will test this patch and help discovering bugs that otherwise would just stay there. I'm also working on a test-suite, so one easily can identify the correctness of gvinum, but there will probably be cases where my tests are not sufficient. -- Ulf Lilleengen From owner-freebsd-current@FreeBSD.ORG Mon Jul 9 09:58:54 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EA8C216A469; Mon, 9 Jul 2007 09:58:54 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from redbull.bpaserver.net (redbullneu.bpaserver.net [213.198.78.217]) by mx1.freebsd.org (Postfix) with ESMTP id 95F6513C45B; Mon, 9 Jul 2007 09:58:54 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from outgoing.leidinger.net (p54A579F8.dip.t-dialin.net [84.165.121.248]) by redbull.bpaserver.net (Postfix) with ESMTP id DD1C62E25F; Mon, 9 Jul 2007 11:58:48 +0200 (CEST) Received: from webmail.leidinger.net (webmail.Leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id 8FE6F5B5A49; Mon, 9 Jul 2007 11:56:37 +0200 (CEST) Received: (from www@localhost) by webmail.leidinger.net (8.13.8/8.13.8/Submit) id l699ubWK069540; Mon, 9 Jul 2007 11:56:37 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from pslux.cec.eu.int (pslux.cec.eu.int [158.169.9.14]) by webmail.leidinger.net (Horde MIME library) with HTTP; Mon, 09 Jul 2007 11:56:37 +0200 Message-ID: <20070709115637.sapzl5uq3osw4gc4@webmail.leidinger.net> X-Priority: 3 (Normal) Date: Mon, 09 Jul 2007 11:56:37 +0200 From: Alexander Leidinger To: zhouyi zhou References: <20070709105547.71827eb8.zhouzhouyi@FreeBSD.org> In-Reply-To: <20070709105547.71827eb8.zhouzhouyi@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1.4) / FreeBSD-7.0 X-BPAnet-MailScanner-Information: Please contact the ISP for more information X-BPAnet-MailScanner: Found to be clean X-BPAnet-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-14.3, required 8, BAYES_00 -15.00, DKIM_POLICY_SIGNSOME 0.00, J_CHICKENPOX_93 0.60, RDNS_DYNAMIC 0.10) X-BPAnet-MailScanner-From: alexander@leidinger.net X-Spam-Status: No Cc: freebsd-hackers@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: rewrite src/sys/i386/i386/in_cksum.c X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2007 09:58:55 -0000 Quoting zhouyi zhou (from Mon, 9 Jul 2007 =20 10:55:47 +0800): > Hey, > Since FreeBSD update gcc from 3.4.x to 4.2.0, the FreeBSD gdb =20 > remote debugger in i386 platform > will find the TCP/UPD checksum will not be computed right, when =20 > calling macro in_cksum > which calls in_cksum_skip in src/sys/i386/i386/in_cksum.c in case of =20 > getting rid of -O flag > supplied to gcc when compiling(The optimize will interfere with =20 > comfortable gdb debugging). > If someone is interested in it, he can lend me a hand to rewrite =20 > all of the similiar cases. A rewrite (port from DFly) of the IP checksum code exists since a long =20 time. ATM I don't remember who ported it (sorry!). I know that Andre =20 wanted to review the code as part of his network-fundraising work, but =20 I don't remember the outcome (or if there's an outcome at all). Search the archives of net/current/arch, maybe you can find it there =20 and test if it solves your problem. Bye, Alexander. --=20 Ignorance should be painful. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID =3D B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID =3D 72077137 From owner-freebsd-current@FreeBSD.ORG Mon Jul 9 10:31:58 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0BAFD16A46B for ; Mon, 9 Jul 2007 10:31:58 +0000 (UTC) (envelope-from gavin.atkinson@ury.york.ac.uk) Received: from mail-gw2.york.ac.uk (mail-gw2.york.ac.uk [144.32.128.247]) by mx1.freebsd.org (Postfix) with ESMTP id 93A1E13C45B for ; Mon, 9 Jul 2007 10:31:57 +0000 (UTC) (envelope-from gavin.atkinson@ury.york.ac.uk) Received: from mail-gw7.york.ac.uk (mail-gw7.york.ac.uk [144.32.129.30]) by mail-gw2.york.ac.uk (8.13.6/8.13.6) with ESMTP id l69A02U1023206; Mon, 9 Jul 2007 11:00:02 +0100 (BST) Received: from buffy-128.york.ac.uk ([144.32.128.160] helo=buffy.york.ac.uk) by mail-gw7.york.ac.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1I7q2E-0007cL-MY; Mon, 09 Jul 2007 11:00:02 +0100 Received: from buffy.york.ac.uk (localhost [127.0.0.1]) by buffy.york.ac.uk (8.14.1/8.14.1) with ESMTP id l69A01bQ031660; Mon, 9 Jul 2007 11:00:02 +0100 (BST) (envelope-from gavin.atkinson@ury.york.ac.uk) Received: (from ga9@localhost) by buffy.york.ac.uk (8.14.1/8.14.1/Submit) id l699xt8H031640; Mon, 9 Jul 2007 10:59:55 +0100 (BST) (envelope-from gavin.atkinson@ury.york.ac.uk) X-Authentication-Warning: buffy.york.ac.uk: ga9 set sender to gavin.atkinson@ury.york.ac.uk using -f From: Gavin Atkinson To: Rong-en Fan In-Reply-To: <6eb82e0707090150t2977c32ex42abf09c21eb6a5b@mail.gmail.com> References: <20070709104152.rsg4v3hjww8woksk@webmail.leidinger.net> <6eb82e0707090150t2977c32ex42abf09c21eb6a5b@mail.gmail.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Mon, 09 Jul 2007 10:59:54 +0100 Message-Id: <1183975194.31312.6.camel@buffy.york.ac.uk> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 FreeBSD GNOME Team Port X-York-MailScanner: Found to be clean X-York-MailScanner-From: gavin.atkinson@ury.york.ac.uk Cc: Alexander Leidinger , current@freebsd.org, bushman@rsu.ru Subject: Re: cached update flaws... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2007 10:31:58 -0000 On Mon, 2007-07-09 at 16:50 +0800, Rong-en Fan wrote: > On 7/9/07, Alexander Leidinger wrote: > > And while we are at it, is there really a need to print the cached > > version number and the fact that it was developed during GSoC 2005 at > > each start? It clutters the visual appearance at boot time. > > I feel the same. > > BTW, is there any plan to enable cached by default in 7.0? There have also been several discussions about renaming it to "nscd" to match other operating systems, and to indicate that it does now do more than just caching. Realistically, this has to happen before 7.0 or not at all. Gavin From owner-freebsd-current@FreeBSD.ORG Mon Jul 9 10:45:26 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BCC4316A475; Mon, 9 Jul 2007 10:45:26 +0000 (UTC) (envelope-from lulf@stud.ntnu.no) Received: from fri.itea.ntnu.no (fri.itea.ntnu.no [129.241.7.60]) by mx1.freebsd.org (Postfix) with ESMTP id 4EAC413C44B; Mon, 9 Jul 2007 10:45:26 +0000 (UTC) (envelope-from lulf@stud.ntnu.no) Received: from localhost (localhost [127.0.0.1]) by fri.itea.ntnu.no (Postfix) with ESMTP id 5699D93D7; Mon, 9 Jul 2007 12:45:25 +0200 (CEST) Received: from gaupe.stud.ntnu.no (gaupe.stud.ntnu.no [129.241.56.184]) by fri.itea.ntnu.no (Postfix) with ESMTP; Mon, 9 Jul 2007 12:45:25 +0200 (CEST) Received: by gaupe.stud.ntnu.no (Postfix, from userid 2312) id 5D74CD0034; Mon, 9 Jul 2007 12:45:31 +0200 (CEST) Date: Mon, 9 Jul 2007 12:45:31 +0200 From: Ulf Lilleengen To: Fluffles Message-ID: <20070709104531.GA18511@stud.ntnu.no> References: <20070709092252.GA7809@stud.ntnu.no> <46920754.6080901@fluffles.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46920754.6080901@fluffles.net> User-Agent: Mutt/1.5.9i X-Content-Scanned: with sophos and spamassassin at mailgw.ntnu.no. Cc: freebsd-current@freebsd.org, freebsd-geom@freebsd.org Subject: Re: Patches for updated gvinum X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2007 10:45:26 -0000 On man, jul 09, 2007 at 12:00:52 +0200, Fluffles wrote: > Ulf Lilleengen wrote: > >Hi, > > > >Gvinum just got better. At least, that's what I hope. Lukas rewrote gvinum > >to > >use a simpler and easier to handle single-thread event system, and I have > >been > >adapting existing code to this. The result can be found in the patches > >here: > > > > Nice to see gvinum get's the facelift it so desperately needed. It's > unfortunate gvinum was never able to recover from the GEOM-age, until > now maybe. :-) > > However, do you think that it's performance is affected too? Last time i > tested, i was not impressed with gvinum's RAID5 performance, write > speeds were very low. RAID0 and RAID1 appeared to be on par with gstripe > and gmirror though. I guess gvinum is primary for people who feel > comfortable with its configuration and user-interface. > It might, since it won't have pass BIOs through the consumer/provider system. I did benchmark it a bit with gmirror with rawio, and gvinum was a bit faster. I did a test on another system that showed gmirror a bit faster, so I guess they're still the same. I'll try make a comparison with old gvinum as well. I heard about the RAID-5 problems, but I do not think that will be any better, as the problem was related to the request ordering or at least the way RAID-5 is done(I can't remember exactly, since it's in an old mailbox). However, this seems to be a good tip on what I can look into next after my stability testing. As you say, gvinum is primary for the people who like the complete "volume-manager" it offers. Also, what is important, is that people can upgrade old boxes running vinum. > >Therefore, I hope many will > >test this patch and help discovering bugs that otherwise would just stay > >there. > > > > I will be able to test this on my new test system, coming Wedsnesday. > This consists of a modern dualcore AMD 3GHz processor with 4GB RAM and 8 > SATA disks. If you like, i can report my findings to the list when i'm done. > Yes, that would be nice. Thank you very much, I appreciate your help! Currently, I only have 6 "old" SCSI disks to run my real-world tests on. -- Ulf Lilleengen From owner-freebsd-current@FreeBSD.ORG Mon Jul 9 10:41:20 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 68CAB16A46B for ; Mon, 9 Jul 2007 10:41:20 +0000 (UTC) (envelope-from etc@fluffles.net) Received: from auriate.fluffles.net (cust.95.160.adsl.cistron.nl [195.64.95.160]) by mx1.freebsd.org (Postfix) with ESMTP id 2169013C45B for ; Mon, 9 Jul 2007 10:41:19 +0000 (UTC) (envelope-from etc@fluffles.net) Received: from 195-241-125-45.dsl.ip.tiscali.nl ([195.241.125.45] helo=[10.0.0.18]) by auriate.fluffles.net with esmtpa (Exim 4.66 (FreeBSD)) (envelope-from ) id 1I7q2v-000O6B-MW; Mon, 09 Jul 2007 12:00:45 +0200 Message-ID: <46920754.6080901@fluffles.net> Date: Mon, 09 Jul 2007 12:00:52 +0200 From: Fluffles User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Ulf Lilleengen References: <20070709092252.GA7809@stud.ntnu.no> In-Reply-To: <20070709092252.GA7809@stud.ntnu.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 09 Jul 2007 11:21:36 +0000 Cc: freebsd-current@freebsd.org, freebsd-geom@freebsd.org Subject: Re: Patches for updated gvinum X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2007 10:41:20 -0000 Ulf Lilleengen wrote: > Hi, > > Gvinum just got better. At least, that's what I hope. Lukas rewrote gvinum to > use a simpler and easier to handle single-thread event system, and I have been > adapting existing code to this. The result can be found in the patches here: > Nice to see gvinum get's the facelift it so desperately needed. It's unfortunate gvinum was never able to recover from the GEOM-age, until now maybe. :-) However, do you think that it's performance is affected too? Last time i tested, i was not impressed with gvinum's RAID5 performance, write speeds were very low. RAID0 and RAID1 appeared to be on par with gstripe and gmirror though. I guess gvinum is primary for people who feel comfortable with its configuration and user-interface. > Therefore, I hope many will > test this patch and help discovering bugs that otherwise would just stay there. > I will be able to test this on my new test system, coming Wedsnesday. This consists of a modern dualcore AMD 3GHz processor with 4GB RAM and 8 SATA disks. If you like, i can report my findings to the list when i'm done. Regards, Veronica From owner-freebsd-current@FreeBSD.ORG Mon Jul 9 12:15:02 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7EDB716A468 for ; Mon, 9 Jul 2007 12:15:02 +0000 (UTC) (envelope-from zhouzhouyi@FreeBSD.org) Received: from ercist.iscas.ac.cn (ercist.iscas.ac.cn [124.16.138.3]) by mx1.freebsd.org (Postfix) with SMTP id 914C713C4BA for ; Mon, 9 Jul 2007 12:15:01 +0000 (UTC) (envelope-from zhouzhouyi@FreeBSD.org) Received: (qmail 78319 invoked by uid 98); 9 Jul 2007 12:12:31 -0000 Received: from 222.191.237.170 by ercist.iscas.ac.cn (envelope-from , uid 89) with qmail-scanner-1.25 (spamassassin: 3.1.0. Clear:RC:1(222.191.237.170):SA:0(0.0/10.0):. Processed in 3.962652 secs); 09 Jul 2007 12:12:31 -0000 X-Spam-Status: No, hits=0.0 required=10.0 X-Qmail-Scanner-Mail-From: zhouzhouyi@FreeBSD.org via ercist.iscas.ac.cn X-Qmail-Scanner: 1.25 (Clear:RC:1(222.191.237.170):SA:0(0.0/10.0):. Processed in 3.962652 secs) Received: from unknown (HELO iosdf17a8152bc) (zhouzhouyi@ercist.iscas.ac.cn@222.191.237.170) by 0 with SMTP; 9 Jul 2007 12:12:27 -0000 Message-ID: <00d901c7c222$109cb310$f100a8c0@iosdf17a8152bc> From: "Zhouyi Zhou" To: "Alexander Leidinger" References: <20070709105547.71827eb8.zhouzhouyi@FreeBSD.org> <20070709115637.sapzl5uq3osw4gc4@webmail.leidinger.net> Date: Mon, 9 Jul 2007 20:09:54 +0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-RFC2646: Format=Flowed; Response Cc: freebsd-hackers@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: rewrite src/sys/i386/i386/in_cksum.c X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Zhouyi Zhou List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2007 12:15:02 -0000 The patch supplied by Gordon http://generic.0xfce3.net/20060524-ipchecksum.patch no longer exists, but I take a look at DragonFlyBSD, I feel that modification follows my idea is modestly to FreeBSD implementation. Zhouyi ----- Original Message ----- From: "Alexander Leidinger" To: "zhouyi zhou" Cc: ; Sent: Monday, July 09, 2007 5:56 PM Subject: Re: rewrite src/sys/i386/i386/in_cksum.c Quoting zhouyi zhou (from Mon, 9 Jul 2007 10:55:47 +0800): > Hey, > Since FreeBSD update gcc from 3.4.x to 4.2.0, the FreeBSD gdb remote > debugger in i386 platform > will find the TCP/UPD checksum will not be computed right, when calling > macro in_cksum > which calls in_cksum_skip in src/sys/i386/i386/in_cksum.c in case of > getting rid of -O flag > supplied to gcc when compiling(The optimize will interfere with > comfortable gdb debugging). > If someone is interested in it, he can lend me a hand to rewrite all > of the similiar cases. A rewrite (port from DFly) of the IP checksum code exists since a long time. ATM I don't remember who ported it (sorry!). I know that Andre wanted to review the code as part of his network-fundraising work, but I don't remember the outcome (or if there's an outcome at all). Search the archives of net/current/arch, maybe you can find it there and test if it solves your problem. Bye, Alexander. -- Ignorance should be painful. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-current@FreeBSD.ORG Mon Jul 9 12:31:35 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DE34A16A46C; Mon, 9 Jul 2007 12:31:35 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id B45B013C459; Mon, 9 Jul 2007 12:31:35 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.13.8/8.13.8) with ESMTP id l69CVZTv097826; Mon, 9 Jul 2007 08:31:35 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.8/8.13.8) with ESMTP id l69CVYA9065011; Mon, 9 Jul 2007 08:31:35 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id C09F873068; Mon, 9 Jul 2007 08:31:34 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070709123134.C09F873068@freebsd-current.sentex.ca> Date: Mon, 9 Jul 2007 08:31:34 -0400 (EDT) X-Virus-Scanned: ClamAV version devel-20070108, clamav-milter version devel-111206 on clamscanner2 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2007 12:31:36 -0000 TB --- 2007-07-09 11:01:56 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-07-09 11:01:56 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2007-07-09 11:01:56 - cleaning the object tree TB --- 2007-07-09 11:02:17 - checking out the source tree TB --- 2007-07-09 11:02:17 - cd /tinderbox/HEAD/sparc64/sparc64 TB --- 2007-07-09 11:02:17 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-07-09 11:10:52 - building world (CFLAGS=-O2 -pipe) TB --- 2007-07-09 11:10:52 - cd /src TB --- 2007-07-09 11:10:52 - /usr/bin/make -B buildworld >>> World build started on Mon Jul 9 11:10:53 UTC 2007 >>> 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 Mon Jul 9 12:24:14 UTC 2007 TB --- 2007-07-09 12:24:14 - generating LINT kernel config TB --- 2007-07-09 12:24:14 - cd /src/sys/sparc64/conf TB --- 2007-07-09 12:24:14 - /usr/bin/make -B LINT TB --- 2007-07-09 12:24:14 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-07-09 12:24:14 - cd /src TB --- 2007-07-09 12:24:14 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Jul 9 12:24:15 UTC 2007 >>> 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=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/dev/usb/ehci_pci.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=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/dev/usb/hid.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=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/dev/usb/if_aue.c In file included from /src/sys/dev/usb/if_aue.c:100: ./usbdevs.h:587:1: error: "USB_VENDOR_NOVATEL" redefined ./usbdevs.h:469:1: error: this is the location of the previous definition ./usbdevs.h:643:1: error: "USB_VENDOR_PROLIFIC2" redefined ./usbdevs.h:566:1: error: this is the location of the previous definition *** Error code 1 Stop in /obj/sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-07-09 12:31:34 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-07-09 12:31:34 - ERROR: failed to build lint kernel TB --- 2007-07-09 12:31:34 - tinderbox aborted TB --- 0.74 user 2.48 system 5378.11 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Mon Jul 9 12:33:20 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 54F7A16A400 for ; Mon, 9 Jul 2007 12:33:20 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 0DF3113C45D for ; Mon, 9 Jul 2007 12:33:19 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1I7sQY-0001wg-0h for freebsd-current@freebsd.org; Mon, 09 Jul 2007 14:33:18 +0200 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 09 Jul 2007 14:33:18 +0200 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 09 Jul 2007 14:33:18 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Ivan Voras Date: Mon, 09 Jul 2007 14:33:02 +0200 Lines: 39 Message-ID: References: <468FD2FA.1040102@lissyara.su> <20070707225802.GF38748@turion.vk2pj.dyndns.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig5CD57BCE6F8CBD4080364841" X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 1.5.0.12 (X11/20060911) In-Reply-To: <20070707225802.GF38748@turion.vk2pj.dyndns.org> X-Enigmail-Version: 0.94.2.0 Sender: news Subject: Re: What is reason for fixed system data format? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2007 12:33:20 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig5CD57BCE6F8CBD4080364841 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Peter Jeremy wrote: > On 2007-Jul-07 21:52:58 +0400, Alex Keda wrote: >> I looks means for global change system date format (example -> 2007-07= -07=20 >> 21:48:58). But - it not exist. >> In code some applications I see fixed string for length date string (e= xample=20 >> - ./usr.sbin/syslogd/syslogd.c). >> =3D=3D=3D=3D=3D=3D=3D=3D=3D >> What reason for use fixed format, and is exists plans for change this?= >=20 > I presume you are referring to the time format returned by ctime(3). > This format is specified by POSIX and thre are no plans to change it. I think he means: why hasn't ctime() been replaced with strftime("%c"),=20 since then the format could be varied by setting LC_* variables. --------------enig5CD57BCE6F8CBD4080364841 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.5 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFGkisFldnAQVacBcgRAvMlAKDH5B7zeHDW1MswCe3WWScEr7uAGgCgtsaG PunyaS9EsYqwJuaJdxfzedA= =Xnlf -----END PGP SIGNATURE----- --------------enig5CD57BCE6F8CBD4080364841-- From owner-freebsd-current@FreeBSD.ORG Mon Jul 9 13:28:40 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 795E816A468; Mon, 9 Jul 2007 13:28:40 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 512B613C43E; Mon, 9 Jul 2007 13:28:40 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.13.8/8.13.8) with ESMTP id l69DSd4K006018; Mon, 9 Jul 2007 09:28:39 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.8/8.13.8) with ESMTP id l69DSdbb066760; Mon, 9 Jul 2007 09:28:39 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 3B73673068; Mon, 9 Jul 2007 09:28:39 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070709132839.3B73673068@freebsd-current.sentex.ca> Date: Mon, 9 Jul 2007 09:28:39 -0400 (EDT) X-Virus-Scanned: ClamAV version devel-20070102, clamav-milter version devel-111206 on clamscanner5 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on sparc64/sun4v X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2007 13:28:40 -0000 TB --- 2007-07-09 12:06:00 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-07-09 12:06:00 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2007-07-09 12:06:00 - cleaning the object tree TB --- 2007-07-09 12:06:19 - checking out the source tree TB --- 2007-07-09 12:06:19 - cd /tinderbox/HEAD/sparc64/sun4v TB --- 2007-07-09 12:06:19 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-07-09 12:15:34 - building world (CFLAGS=-O2 -pipe) TB --- 2007-07-09 12:15:34 - cd /src TB --- 2007-07-09 12:15:34 - /usr/bin/make -B buildworld >>> World build started on Mon Jul 9 12:15:35 UTC 2007 >>> 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 Mon Jul 9 13:22:13 UTC 2007 TB --- 2007-07-09 13:22:13 - generating LINT kernel config TB --- 2007-07-09 13:22:13 - cd /src/sys/sun4v/conf TB --- 2007-07-09 13:22:13 - /usr/bin/make -B LINT TB --- 2007-07-09 13:22:13 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-07-09 13:22:13 - cd /src TB --- 2007-07-09 13:22:13 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Jul 9 13:22:13 UTC 2007 >>> 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=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/dev/usb/ehci_pci.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=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/dev/usb/hid.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=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/dev/usb/if_aue.c In file included from /src/sys/dev/usb/if_aue.c:100: ./usbdevs.h:587:1: error: "USB_VENDOR_NOVATEL" redefined ./usbdevs.h:469:1: error: this is the location of the previous definition ./usbdevs.h:643:1: error: "USB_VENDOR_PROLIFIC2" redefined ./usbdevs.h:566:1: error: this is the location of the previous definition *** Error code 1 Stop in /obj/sun4v/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-07-09 13:28:38 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-07-09 13:28:38 - ERROR: failed to build lint kernel TB --- 2007-07-09 13:28:38 - tinderbox aborted TB --- 0.66 user 2.15 system 4958.09 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From owner-freebsd-current@FreeBSD.ORG Mon Jul 9 15:37:38 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D4C3216A400; Mon, 9 Jul 2007 15:37:38 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 9372613C455; Mon, 9 Jul 2007 15:37:38 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.13.8/8.13.8) with ESMTP id l69FbcfI029981; Mon, 9 Jul 2007 11:37:38 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.8/8.13.8) with ESMTP id l69FbbwN087974; Mon, 9 Jul 2007 11:37:37 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 8A7C973068; Mon, 9 Jul 2007 11:37:37 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070709153737.8A7C973068@freebsd-current.sentex.ca> Date: Mon, 9 Jul 2007 11:37:37 -0400 (EDT) X-Virus-Scanned: ClamAV version devel-20070102, clamav-milter version devel-111206 on clamscanner1 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2007 15:37:39 -0000 TB --- 2007-07-09 13:30:00 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-07-09 13:30:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2007-07-09 13:30:00 - cleaning the object tree TB --- 2007-07-09 13:30:38 - checking out the source tree TB --- 2007-07-09 13:30:38 - cd /tinderbox/HEAD/amd64/amd64 TB --- 2007-07-09 13:30:38 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-07-09 13:41:54 - building world (CFLAGS=-O2 -pipe) TB --- 2007-07-09 13:41:54 - cd /src TB --- 2007-07-09 13:41:54 - /usr/bin/make -B buildworld >>> World build started on Mon Jul 9 13:41:55 UTC 2007 >>> 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 Mon Jul 9 15:28:28 UTC 2007 TB --- 2007-07-09 15:28:28 - generating LINT kernel config TB --- 2007-07-09 15:28:28 - cd /src/sys/amd64/conf TB --- 2007-07-09 15:28:28 - /usr/bin/make -B LINT TB --- 2007-07-09 15:28:29 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-07-09 15:28:29 - cd /src TB --- 2007-07-09 15:28:29 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Jul 9 15:28:29 UTC 2007 >>> 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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/dev/usb/ehci_pci.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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/dev/usb/hid.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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/dev/usb/if_aue.c In file included from /src/sys/dev/usb/if_aue.c:100: ./usbdevs.h:587:1: error: "USB_VENDOR_NOVATEL" redefined ./usbdevs.h:469:1: error: this is the location of the previous definition ./usbdevs.h:643:1: error: "USB_VENDOR_PROLIFIC2" redefined ./usbdevs.h:566:1: error: this is the location of the previous definition *** Error code 1 Stop in /obj/amd64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-07-09 15:37:37 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-07-09 15:37:37 - ERROR: failed to build lint kernel TB --- 2007-07-09 15:37:37 - tinderbox aborted TB --- 0.99 user 3.68 system 7656.55 real http://tinderbox.des.no/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Mon Jul 9 17:15:10 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5A75316A41F for ; Mon, 9 Jul 2007 17:15:10 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe10.swip.net [212.247.155.33]) by mx1.freebsd.org (Postfix) with ESMTP id EF88F13C459 for ; Mon, 9 Jul 2007 17:15:09 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] Received: from [212.17.141.53] (account mc467741@c2i.net HELO [10.150.99.181]) by mailfe10.swip.net (CommuniGate Pro SMTP 5.1.10) with ESMTPA id 372025372; Mon, 09 Jul 2007 18:15:07 +0200 From: Hans Petter Selasky To: "Kevin Oberman" Date: Mon, 9 Jul 2007 18:15:07 +0200 User-Agent: KMail/1.9.5 References: <20070708053128.4EB0245042@ptavv.es.net> In-Reply-To: <20070708053128.4EB0245042@ptavv.es.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200707091815.07326.hselasky@c2i.net> Cc: current@freebsd.org Subject: Re: HPS USB stack on current will not build any longer X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2007 17:15:10 -0000 On Sunday 08 July 2007 07:31, Kevin Oberman wrote: > Hans, > > It seems that, with a recent change to the 802.11 code, your USB code no > longer compiles. It dies building if_rum because an additional argument > is needed by ieee80211_input. > > Do you have any patch for this? Not yet, except that you zero out the files that do not compile. --HPS From owner-freebsd-current@FreeBSD.ORG Mon Jul 9 17:45:19 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3235316A46C for ; Mon, 9 Jul 2007 17:45:18 +0000 (UTC) (envelope-from SRS0=933710200a974c989e663264386c3293d315fc4f=391=es.net=oberman@es.net) Received: from postal1.es.net (postal1.es.net [198.128.3.205]) by mx1.freebsd.org (Postfix) with ESMTP id 0F06E13C45E for ; Mon, 9 Jul 2007 17:45:17 +0000 (UTC) (envelope-from SRS0=933710200a974c989e663264386c3293d315fc4f=391=es.net=oberman@es.net) Received: from ptavv.es.net (ptavv.es.net [198.128.4.29]) by postal1.es.net (Postal Node 1) with ESMTP (SSL) id OYN51412; Mon, 09 Jul 2007 10:30:12 -0700 Received: from ptavv.es.net (ptavv.es.net [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 5CBAF45042; Mon, 9 Jul 2007 10:30:12 -0700 (PDT) To: Hans Petter Selasky In-Reply-To: Your message of "Mon, 09 Jul 2007 18:15:07 +0200." <200707091815.07326.hselasky@c2i.net> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_1184002212_90633P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Mon, 09 Jul 2007 10:30:12 -0700 From: "Kevin Oberman" Message-Id: <20070709173012.5CBAF45042@ptavv.es.net> Cc: current@freebsd.org Subject: Re: HPS USB stack on current will not build any longer X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2007 17:45:19 -0000 --==_Exmh_1184002212_90633P Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > From: Hans Petter Selasky > Date: Mon, 9 Jul 2007 18:15:07 +0200 > > On Sunday 08 July 2007 07:31, Kevin Oberman wrote: > > Hans, > > > > It seems that, with a recent change to the 802.11 code, your USB code no > > longer compiles. It dies building if_rum because an additional argument > > is needed by ieee80211_input. > > > > Do you have any patch for this? > > Not yet, except that you zero out the files that do not compile. Thanks! Fortunately, I don't need rum. I mostly need umass and, now and then, one of the serial controllers. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 --==_Exmh_1184002212_90633P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) Comment: Exmh version 2.5 06/03/2002 iD8DBQFGknCkkn3rs5h7N1ERAlztAKCpceO0wZmKqNb1apGpmGhgPxIsWwCfScZc 8BvSQVqsAJIWrlPJOsBmlPQ= =kznI -----END PGP SIGNATURE----- --==_Exmh_1184002212_90633P-- From owner-freebsd-current@FreeBSD.ORG Mon Jul 9 17:58:28 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B733C16A421 for ; Mon, 9 Jul 2007 17:58:28 +0000 (UTC) (envelope-from thierry@herbelot.com) Received: from smtp4-g19.free.fr (smtp4-g19.free.fr [212.27.42.30]) by mx1.freebsd.org (Postfix) with ESMTP id 7B17E13C447 for ; Mon, 9 Jul 2007 17:58:28 +0000 (UTC) (envelope-from thierry@herbelot.com) Received: from herbelot.dyndns.org (bne75-4-82-227-159-103.fbx.proxad.net [82.227.159.103]) by smtp4-g19.free.fr (Postfix) with ESMTP id ACD496F449; Mon, 9 Jul 2007 19:58:27 +0200 (CEST) Received: from diversion.herbelot.nom (diversion.herbelot.nom [192.168.2.6]) by herbelot.dyndns.org (8.14.0/8.14.0) with ESMTP id l69HwGsn003765; Mon, 9 Jul 2007 19:58:17 +0200 (CEST) From: Thierry Herbelot To: freebsd-current@freebsd.org Date: Mon, 9 Jul 2007 19:58:07 +0200 User-Agent: KMail/1.9.7 References: <200707071426.18202.dfr@rabson.org> <20070709000918.GD1208@garage.freebsd.pl> <200707090848.50190.dfr@rabson.org> In-Reply-To: <200707090848.50190.dfr@rabson.org> X-Warning: Windows can lose your files X-Op-Sys: Le FriBi de la mort qui tue X-Org: TfH&Co X-MailScanner: Found to be clean MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 8bit Content-Disposition: inline Message-Id: <200707091958.10023.thierry@herbelot.com> Cc: Pawel Jakub Dawidek Subject: Re: ZFS leaking vnodes (sort of) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: thierry@herbelot.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2007 17:58:28 -0000 Le Monday 09 July 2007, Doug Rabson a écrit : > I think it should help the memory usage problems - for one thing since > the vnodes were never hitting the free list, VOP_INACTIVE wasn't being > properly called on then after last-close which (I think) is supposed to > flush out various things. Not quite sure about that bit. Certainly it > reduces the number of active vnodes in the system back down to the > wantfreevnodes value. At least, here, on a very old and very small machine, with a pair of obsolete IDE disks, the three changes you suggested improve buildworld by around 30% (18hrs -> 14hrs) Thanks TfH From owner-freebsd-current@FreeBSD.ORG Mon Jul 9 18:08:38 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 67BE316A41F for ; Mon, 9 Jul 2007 18:08:38 +0000 (UTC) (envelope-from bdonnell@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.226]) by mx1.freebsd.org (Postfix) with ESMTP id 8B76A13C448 for ; Mon, 9 Jul 2007 18:08:37 +0000 (UTC) (envelope-from bdonnell@gmail.com) Received: by wr-out-0506.google.com with SMTP id i23so476228wra for ; Mon, 09 Jul 2007 11:08:36 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=D9cAan2SakxKYFByIlQWmqMDSKTCW6jo2/+HC4x+cE/xAjMPipWrNa34saIyHm3BOJGABFSQfxz1PVt3oKmbWtqRcW8DfDJ9RQjGXdccg9CLB3bcQt7/fuJ260J+T22o4EB88oeSCdk6KOvAwP9E4pITIpByLrqXw7iZN/OOw8Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=LfEecL/s5po/Im4EwuUUmXDhcDcUU6tMeHwju62ji4VnFhYmzCmmzuenRxiZztBjeQQ8ka7VmMMBfFanVCCHuYlWpPAj16xk6YNp4oxa1LzYZDBHRtLJqLdR1XVrH95nErFjJjEDRW7mzsjvBaIldaGuGIGUuLYlfbZliWN+pmw= Received: by 10.142.82.17 with SMTP id f17mr249087wfb.1184004516147; Mon, 09 Jul 2007 11:08:36 -0700 (PDT) Received: by 10.142.77.9 with HTTP; Mon, 9 Jul 2007 11:08:36 -0700 (PDT) Message-ID: <1c5c32890707091108m726d27a7ue9f44b99590e1934@mail.gmail.com> Date: Mon, 9 Jul 2007 14:08:36 -0400 From: "Brian Donnell" To: "Pawel Jakub Dawidek" In-Reply-To: <20070709000918.GD1208@garage.freebsd.pl> MIME-Version: 1.0 References: <200707071426.18202.dfr@rabson.org> <20070709000918.GD1208@garage.freebsd.pl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: current@freebsd.org Subject: Re: ZFS leaking vnodes (sort of) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2007 18:08:38 -0000 I put these patches in on my i386, took out the i386 recommended tunings and increased the max vnodes as recommended for amd64. Last time I did this I was able to cause kmem_map errors very quickly. With these changes, however, I'm not seeing any problems yet. I'm running through as many tests as I can think of for file accesses and transfers between and out of zfs pools. So far so good. Other than the memory usage I haven't really noticed a change in performance. Note this is a pretty high spec'd machine I'm testing on, though. -- Brian On 7/8/07, Pawel Jakub Dawidek wrote: > > Whoa! Nice catch... The patch works here - I did some pretty heavy > tests, so please commit it ASAP. > > I also wonder if this can help with some of those 'kmem_map too small' > panics. I was observing that ARC cannot reclaim memory and this may be > because all vnodes and thus associated data are beeing held. > > To ZFS users having problems with performance and/or stability of ZFS: > Can you test the patch and see if it helps? > > From owner-freebsd-current@FreeBSD.ORG Mon Jul 9 19:16:42 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A42FC16A468; Mon, 9 Jul 2007 19:16:42 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 6333C13C4C4; Mon, 9 Jul 2007 19:16:42 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.13.8/8.13.8) with ESMTP id l69JGfwD062717; Mon, 9 Jul 2007 15:16:41 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.8/8.13.8) with ESMTP id l69JGf73091920; Mon, 9 Jul 2007 15:16:41 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 1093D73068; Mon, 9 Jul 2007 15:16:40 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070709191641.1093D73068@freebsd-current.sentex.ca> Date: Mon, 9 Jul 2007 15:16:40 -0400 (EDT) X-Virus-Scanned: ClamAV version devel-20070102, clamav-milter version devel-111206 on clamscanner3 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2007 19:16:42 -0000 TB --- 2007-07-09 17:46:08 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-07-09 17:46:08 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2007-07-09 17:46:08 - cleaning the object tree TB --- 2007-07-09 17:46:34 - checking out the source tree TB --- 2007-07-09 17:46:34 - cd /tinderbox/HEAD/powerpc/powerpc TB --- 2007-07-09 17:46:34 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-07-09 17:54:11 - building world (CFLAGS=-O2 -pipe) TB --- 2007-07-09 17:54:11 - cd /src TB --- 2007-07-09 17:54:11 - /usr/bin/make -B buildworld >>> World build started on Mon Jul 9 17:54:12 UTC 2007 >>> 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 Mon Jul 9 19:09:58 UTC 2007 TB --- 2007-07-09 19:09:58 - generating LINT kernel config TB --- 2007-07-09 19:09:58 - cd /src/sys/powerpc/conf TB --- 2007-07-09 19:09:58 - /usr/bin/make -B LINT TB --- 2007-07-09 19:09:58 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-07-09 19:09:58 - cd /src TB --- 2007-07-09 19:09:58 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Jul 9 19:09:58 UTC 2007 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] /src/sys/dev/usb/if_rue.c:598: error: 'struct rue_softc' has no member named 'rue_tick_task' /src/sys/dev/usb/if_rue.c:598: warning: left-hand operand of comma expression has no effect /src/sys/dev/usb/if_rue.c:598: error: 'struct rue_softc' has no member named 'rue_tick_task' /src/sys/dev/usb/if_rue.c:598: warning: left-hand operand of comma expression has no effect /src/sys/dev/usb/if_rue.c: In function 'rue_detach': /src/sys/dev/usb/if_rue.c:710: error: 'struct rue_softc' has no member named 'rue_tick_task' /src/sys/dev/usb/if_rue.c: In function 'rue_tick': /src/sys/dev/usb/if_rue.c:931: error: 'struct rue_softc' has no member named 'rue_tick_task' *** Error code 1 Stop in /obj/powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-07-09 19:16:40 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-07-09 19:16:40 - ERROR: failed to build lint kernel TB --- 2007-07-09 19:16:40 - tinderbox aborted TB --- 0.77 user 2.56 system 5431.88 real http://tinderbox.des.no/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Mon Jul 9 19:18:04 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CD1F716A41F; Mon, 9 Jul 2007 19:18:04 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 8C02A13C4C2; Mon, 9 Jul 2007 19:18:04 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.13.8/8.13.8) with ESMTP id l69JI4Hb062891; Mon, 9 Jul 2007 15:18:04 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.8/8.13.8) with ESMTP id l69JI38U052043; Mon, 9 Jul 2007 15:18:03 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id BCA3D73068; Mon, 9 Jul 2007 15:18:03 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070709191803.BCA3D73068@freebsd-current.sentex.ca> Date: Mon, 9 Jul 2007 15:18:03 -0400 (EDT) X-Virus-Scanned: ClamAV version devel-20070108, clamav-milter version devel-111206 on clamscanner2 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2007 19:18:04 -0000 TB --- 2007-07-09 17:18:17 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-07-09 17:18:17 - starting HEAD tinderbox run for ia64/ia64 TB --- 2007-07-09 17:18:17 - cleaning the object tree TB --- 2007-07-09 17:18:50 - checking out the source tree TB --- 2007-07-09 17:18:50 - cd /tinderbox/HEAD/ia64/ia64 TB --- 2007-07-09 17:18:50 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-07-09 17:27:12 - building world (CFLAGS=-O2 -pipe) TB --- 2007-07-09 17:27:12 - cd /src TB --- 2007-07-09 17:27:12 - /usr/bin/make -B buildworld >>> World build started on Mon Jul 9 17:27:14 UTC 2007 >>> 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 Mon Jul 9 19:07:46 UTC 2007 TB --- 2007-07-09 19:07:46 - generating LINT kernel config TB --- 2007-07-09 19:07:46 - cd /src/sys/ia64/conf TB --- 2007-07-09 19:07:46 - /usr/bin/make -B LINT TB --- 2007-07-09 19:07:46 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-07-09 19:07:46 - cd /src TB --- 2007-07-09 19:07:46 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Jul 9 19:07:47 UTC 2007 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] /src/sys/dev/usb/if_rue.c:598: error: 'struct rue_softc' has no member named 'rue_tick_task' /src/sys/dev/usb/if_rue.c:598: warning: left-hand operand of comma expression has no effect /src/sys/dev/usb/if_rue.c:598: error: 'struct rue_softc' has no member named 'rue_tick_task' /src/sys/dev/usb/if_rue.c:598: warning: left-hand operand of comma expression has no effect /src/sys/dev/usb/if_rue.c: In function 'rue_detach': /src/sys/dev/usb/if_rue.c:710: error: 'struct rue_softc' has no member named 'rue_tick_task' /src/sys/dev/usb/if_rue.c: In function 'rue_tick': /src/sys/dev/usb/if_rue.c:931: error: 'struct rue_softc' has no member named 'rue_tick_task' *** Error code 1 Stop in /obj/ia64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-07-09 19:18:03 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-07-09 19:18:03 - ERROR: failed to build lint kernel TB --- 2007-07-09 19:18:03 - tinderbox aborted TB --- 0.71 user 2.77 system 7186.29 real http://tinderbox.des.no/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Mon Jul 9 19:25:21 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D299416A400 for ; Mon, 9 Jul 2007 19:25:21 +0000 (UTC) (envelope-from r.c.ladan@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.172]) by mx1.freebsd.org (Postfix) with ESMTP id 6523913C48C for ; Mon, 9 Jul 2007 19:25:21 +0000 (UTC) (envelope-from r.c.ladan@gmail.com) Received: by ug-out-1314.google.com with SMTP id o4so1447677uge for ; Mon, 09 Jul 2007 12:25:20 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; b=q+f7G3kMUFY4nR17pTz8HZQPtx3Dx+cV1MR5a4FxKtgL6eULUL72jzw7+52JxGqJ6lV9URmeoS0WAJRmc7vZKeg7IvJxmozMj/hTgcmllbB3JYxOXHVOodlVpIgkNZ5BGfnoZpMXTap5YacpBYbwlDV5sVOqg0e82y8ppkhSTec= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; b=IqmHFnMl/c9r9hNQW9bJR3pKr8sGsPFLQYO27wxR7r94ooKmWyofeI3AelU6QuRA5ER8NHA9t+UZW4kPePju3Jk0yLfEQd9L/A4SVss7pit5blz6pFHsqPt3RTqPkAvfyU2rs9lPHnNUSLcgmjjWSyMklPSb9CmnnQXHEsszq5I= Received: by 10.67.29.7 with SMTP id g7mr5307138ugj.1184009120387; Mon, 09 Jul 2007 12:25:20 -0700 (PDT) Received: from 195-241-221-201.dsl.ip.tiscali.nl ( [195.241.221.201]) by mx.google.com with ESMTPS id k28sm3042549ugd.2007.07.09.12.25.18 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 09 Jul 2007 12:25:18 -0700 (PDT) Message-ID: <46928B9D.8070403@gmail.com> Date: Mon, 09 Jul 2007 21:25:17 +0200 From: Rene Ladan User-Agent: Thunderbird 2.0.0.4 (X11/20070616) MIME-Version: 1.0 To: Benjamin Close References: <20070708093144.GA22598@ceid.upatras.gr> <20070708122021.412747c4.maxx@mobistarmail.be> <8b5ad0e10707080751n7f8e19bdhb36012bd205a767f@mail.gmail.com> <4691777D.3010801@clearchain.com> In-Reply-To: <4691777D.3010801@clearchain.com> X-Enigmail-Version: 0.95.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: IPW3945ABG -- Support in RELENG 7? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2007 19:25:21 -0000 Benjamin Close schreef: >> >> > Hi Folks, > First off, thanks for the many votes of confidence. Whilst I'd like > to see wpi support in 7.0, there's still a long way to go before it > becomes stable. At present it can *almost* pass packets but there's > still a few race conditions that exist and there is currently > limited/untested support for ibss or hostap modes. Since 7.0-Current is > already in a code freeze, I wouldn't get your hopes up... chances are > slim at best. > On my i386 CURRENT from 2007-07-08 00:10 UTC using p4 revision 123160 I can compile and install if_wpi but I cannot kldload it: # kldload if_wpi (no such file/dir) # dmesg link_elf: symbol ieee80211_amrr_node_init undefined but this symbol is defined in wlan_amrr.ko which I kldload'ed before wpifw.ko, firmware.ko, wlan_wep.ko, wlan.ko, and wlan_scan_sta.ko are also kldload'ed. Any ideas? Regards, Rene -- GPG fingerprint = E738 5471 D185 7013 0EE0 4FC8 3C1D 6F83 12E1 84F6 (subkeys.pgp.net) "It won't fit on the line." -- me, 2001 From owner-freebsd-current@FreeBSD.ORG Mon Jul 9 19:49:10 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 652C116A400 for ; Mon, 9 Jul 2007 19:49:10 +0000 (UTC) (envelope-from ubm@u-boot-man.de) Received: from mail.upper.net (mail.upper.net [62.75.224.33]) by mx1.freebsd.org (Postfix) with ESMTP id 04B9913C45A for ; Mon, 9 Jul 2007 19:49:09 +0000 (UTC) (envelope-from ubm@u-boot-man.de) Received: from ubm.mine.nu (p57AE0EF1.dip0.t-ipconnect.de [87.174.14.241]) (authenticated bits=0) by mail.upper.net (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l69Jn7Yo009323 for ; Mon, 9 Jul 2007 21:49:07 +0200 Date: Mon, 9 Jul 2007 21:55:00 +0200 From: Marc "UBM" Bocklet To: freebsd-current@freebsd.org Message-Id: <20070709215500.e13cf5b1.ubm@u-boot-man.de> In-Reply-To: <20070708204255.01e19101.ubm@u-boot-man.de> References: <8cdf6c720707070710k2b7e030v37683e460d983bf9@mail.gmail.com> <20070708111105.C9997@fledge.watson.org> <20070708132545.5604cbe9.ubm@u-boot-man.de> <4690CFAA.30004@gmail.com> <20070708204255.01e19101.ubm@u-boot-man.de> X-Mailer: Sylpheed 2.4.0 (GTK+ 2.10.12; i386-portbld-freebsd6.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: status of 7.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2007 19:49:10 -0000 On Sun, 8 Jul 2007 20:42:55 +0200 Marc "UBM" Bocklet wrote: > > Since we have a misc/compat6x port and a COMPAT_FREEBSD6 kernel > > configuaration option, it shouldn't be necessary to rebuild all your > > ports. > > Thanks a lot to you and David for the quick response, I'll try > updating tomorrow :-) FreeBSD blah.blah 7.0-CURRENT FreeBSD 7.0-CURRENT #0: Mon Jul 9 17:06:47 CEST 2007 Update went smooth, everything is up and running again :-) Now lets see if it crashes *g* Thanks again, guys! Bye Marc -- "Come away, O human child! To the waters and the wild With a faery, hand in hand, For the world's more full of weeping than you can understand." W.B. Yeats, The Stolen Child From owner-freebsd-current@FreeBSD.ORG Mon Jul 9 20:08:38 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8E96D16A469 for ; Mon, 9 Jul 2007 20:08:38 +0000 (UTC) (envelope-from scf@FreeBSD.org) Received: from mail.farley.org (farley.org [67.64.95.201]) by mx1.freebsd.org (Postfix) with ESMTP id 55DF513C4C1 for ; Mon, 9 Jul 2007 20:08:38 +0000 (UTC) (envelope-from scf@FreeBSD.org) Received: from thor.farley.org (thor.farley.org [192.168.1.5]) by mail.farley.org (8.14.1/8.14.1) with ESMTP id l69K99gN023711; Mon, 9 Jul 2007 15:09:09 -0500 (CDT) (envelope-from scf@FreeBSD.org) Date: Mon, 9 Jul 2007 15:07:42 -0500 (CDT) From: "Sean C. Farley" To: Dirk Meyer In-Reply-To: Message-ID: <20070709145418.T52164@thor.farley.org> References: <20070703182400.Q1449@baba.farley.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.1 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on mail.farley.org Cc: freebsd-current@FreeBSD.org Subject: Re: HEADS UP: getenv() and family API change X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2007 20:08:38 -0000 On Sun, 8 Jul 2007, Dirk Meyer wrote: > Hallo Sean C. Farley, > >> Changes in moving to POSIX from historic BSD API: >> b. putenv takes a char * instead of const char *. >> c. putenv no longer makes a copy of the input string. > > Can you give more details? > > An application will break in using this: > putenv("PATH=/bin") > > now taking a char *, this will break with gcc42. True. As Andrey said, you should pass a copy of a const string into putenv(). putenv() is designed to allow changing a value at any time by manipulating the string. This is why I really wish the Open Group would just remove this function. While they are at it, they should remove direct access to environ. Some helper functions would be best. I rant every time I think about putenv() and an exposed environ variable. :) The best is to replace putenv() with setenv() in any applications with issues as it is less error-prone. Sean -- scf@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Mon Jul 9 20:51:18 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DD07A16A400; Mon, 9 Jul 2007 20:51:18 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 8CE4213C46C; Mon, 9 Jul 2007 20:51:18 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.13.8/8.13.8) with ESMTP id l69KpHUw071185; Mon, 9 Jul 2007 16:51:17 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.8/8.13.8) with ESMTP id l69KpHVK054863; Mon, 9 Jul 2007 16:51:17 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 8C6E873068; Mon, 9 Jul 2007 16:51:17 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070709205117.8C6E873068@freebsd-current.sentex.ca> Date: Mon, 9 Jul 2007 16:51:17 -0400 (EDT) X-Virus-Scanned: ClamAV version devel-20070108, clamav-milter version devel-111206 on news X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on sparc64/sun4v X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2007 20:51:19 -0000 TB --- 2007-07-09 19:18:03 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-07-09 19:18:03 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2007-07-09 19:18:03 - cleaning the object tree TB --- 2007-07-09 19:18:37 - checking out the source tree TB --- 2007-07-09 19:18:37 - cd /tinderbox/HEAD/sparc64/sun4v TB --- 2007-07-09 19:18:37 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-07-09 19:28:15 - building world (CFLAGS=-O2 -pipe) TB --- 2007-07-09 19:28:15 - cd /src TB --- 2007-07-09 19:28:15 - /usr/bin/make -B buildworld >>> World build started on Mon Jul 9 19:28:16 UTC 2007 >>> 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 Mon Jul 9 20:43:45 UTC 2007 TB --- 2007-07-09 20:43:45 - generating LINT kernel config TB --- 2007-07-09 20:43:45 - cd /src/sys/sun4v/conf TB --- 2007-07-09 20:43:45 - /usr/bin/make -B LINT TB --- 2007-07-09 20:43:45 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-07-09 20:43:45 - cd /src TB --- 2007-07-09 20:43:45 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Jul 9 20:43:45 UTC 2007 >>> 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 [...] cc1: warnings being treated as errors /src/sys/dev/usb/if_rue.c:598: warning: left-hand operand of comma expression has no effect /src/sys/dev/usb/if_rue.c:598: error: 'struct rue_softc' has no member named 'rue_tick_task' /src/sys/dev/usb/if_rue.c:598: warning: left-hand operand of comma expression has no effect /src/sys/dev/usb/if_rue.c: In function 'rue_detach': /src/sys/dev/usb/if_rue.c:710: error: 'struct rue_softc' has no member named 'rue_tick_task' /src/sys/dev/usb/if_rue.c: In function 'rue_tick': /src/sys/dev/usb/if_rue.c:931: error: 'struct rue_softc' has no member named 'rue_tick_task' *** Error code 1 Stop in /obj/sun4v/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-07-09 20:51:17 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-07-09 20:51:17 - ERROR: failed to build lint kernel TB --- 2007-07-09 20:51:17 - tinderbox aborted TB --- 0.62 user 1.75 system 5593.47 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From owner-freebsd-current@FreeBSD.ORG Mon Jul 9 20:51:36 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0E75316A400; Mon, 9 Jul 2007 20:51:36 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id B17FE13C4AD; Mon, 9 Jul 2007 20:51:35 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.13.8/8.13.8) with ESMTP id l69KpZV5071200; Mon, 9 Jul 2007 16:51:35 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.8/8.13.8) with ESMTP id l69KpZj5055100; Mon, 9 Jul 2007 16:51:35 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 0BCCF7306B; Mon, 9 Jul 2007 16:51:35 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070709205135.0BCCF7306B@freebsd-current.sentex.ca> Date: Mon, 9 Jul 2007 16:51:35 -0400 (EDT) X-Virus-Scanned: ClamAV version devel-20070108, clamav-milter version devel-111206 on clamscanner1 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2007 20:51:36 -0000 TB --- 2007-07-09 19:16:40 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-07-09 19:16:40 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2007-07-09 19:16:40 - cleaning the object tree TB --- 2007-07-09 19:16:57 - checking out the source tree TB --- 2007-07-09 19:16:57 - cd /tinderbox/HEAD/sparc64/sparc64 TB --- 2007-07-09 19:16:57 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-07-09 19:28:15 - building world (CFLAGS=-O2 -pipe) TB --- 2007-07-09 19:28:15 - cd /src TB --- 2007-07-09 19:28:15 - /usr/bin/make -B buildworld >>> World build started on Mon Jul 9 19:28:16 UTC 2007 >>> 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 Mon Jul 9 20:43:43 UTC 2007 TB --- 2007-07-09 20:43:43 - generating LINT kernel config TB --- 2007-07-09 20:43:43 - cd /src/sys/sparc64/conf TB --- 2007-07-09 20:43:43 - /usr/bin/make -B LINT TB --- 2007-07-09 20:43:44 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-07-09 20:43:44 - cd /src TB --- 2007-07-09 20:43:44 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Jul 9 20:43:44 UTC 2007 >>> 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 [...] cc1: warnings being treated as errors /src/sys/dev/usb/if_rue.c:598: warning: left-hand operand of comma expression has no effect /src/sys/dev/usb/if_rue.c:598: error: 'struct rue_softc' has no member named 'rue_tick_task' /src/sys/dev/usb/if_rue.c:598: warning: left-hand operand of comma expression has no effect /src/sys/dev/usb/if_rue.c: In function 'rue_detach': /src/sys/dev/usb/if_rue.c:710: error: 'struct rue_softc' has no member named 'rue_tick_task' /src/sys/dev/usb/if_rue.c: In function 'rue_tick': /src/sys/dev/usb/if_rue.c:931: error: 'struct rue_softc' has no member named 'rue_tick_task' *** Error code 1 Stop in /obj/sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-07-09 20:51:35 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-07-09 20:51:35 - ERROR: failed to build lint kernel TB --- 2007-07-09 20:51:35 - tinderbox aborted TB --- 0.52 user 1.98 system 5694.23 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Mon Jul 9 21:26:05 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 929DA16A468 for ; Mon, 9 Jul 2007 21:26:05 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 5119713C480 for ; Mon, 9 Jul 2007 21:26:04 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1I80jz-0005qe-Ky for freebsd-current@freebsd.org; Mon, 09 Jul 2007 23:25:55 +0200 Received: from 89-172-53-69.adsl.net.t-com.hr ([89.172.53.69]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 09 Jul 2007 23:25:55 +0200 Received: from ivoras by 89-172-53-69.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 09 Jul 2007 23:25:55 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Ivan Voras Date: Mon, 09 Jul 2007 23:25:46 +0200 Lines: 20 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 89-172-53-69.adsl.net.t-com.hr User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) Sender: news Cc: freebsd-hackers@freebsd.org Subject: Debugging time X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2007 21:26:05 -0000 Hi After much frustration I found out what was wrong with my LiveCD (thread "LiveCD trouble"): it was all in the environment. I'm developing and testing everything under VMWare, and for some reason, when booted from the CD, FreeBSD thinks the "current date" is in 1937, which causes all sorts of trouble (among other things, it's not a valid date for time_t). The "BIOS" in the VM is set up correctly and it always shows the current date. The date is set wrong either on boot or very early after the kernel has booted (I've verified it's wrong before hostid rc.d script, which is one of the first to be executed). How can debug this? Can I show the "current date" from the loader prompt, before the kernel has booted? The same kernel and loader (except the early cdboot part) work fine when booted from a hard drive. Has anyone seen this behaviour, with or without VMWare? From owner-freebsd-current@FreeBSD.ORG Mon Jul 9 21:42:19 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 274F516A468 for ; Mon, 9 Jul 2007 21:42:19 +0000 (UTC) (envelope-from dwmalone@maths.tcd.ie) Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by mx1.freebsd.org (Postfix) with SMTP id 5655513C489 for ; Mon, 9 Jul 2007 21:42:18 +0000 (UTC) (envelope-from dwmalone@maths.tcd.ie) Received: from walton.maths.tcd.ie ([134.226.81.10] helo=walton.maths.tcd.ie) by salmon.maths.tcd.ie with SMTP id ; 9 Jul 2007 22:42:17 +0100 (BST) Date: Mon, 9 Jul 2007 22:42:16 +0100 From: David Malone To: Ivan Voras Message-ID: <20070709214216.GA72912@walton.maths.tcd.ie> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i Sender: dwmalone@maths.tcd.ie Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: Debugging times X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2007 21:42:19 -0000 On Mon, Jul 09, 2007 at 11:25:46PM +0200, Ivan Voras wrote: > The date is set wrong either on boot or very early after the kernel has > booted (I've verified it's wrong before hostid rc.d script, which is one > of the first to be executed). I have some patches to make the code that reads the date from the bios print errors if there is a problem parsing the date. I was going to commit them to -current, but it might be useful for you to test them? David. From owner-freebsd-current@FreeBSD.ORG Mon Jul 9 22:01:24 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B106E16A468 for ; Mon, 9 Jul 2007 22:01:24 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 44A3E13C458 for ; Mon, 9 Jul 2007 22:01:24 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 6ADA446EFA; Mon, 9 Jul 2007 18:01:22 -0400 (EDT) Date: Mon, 9 Jul 2007 23:01:22 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Maksim Yevmenkin In-Reply-To: Message-ID: <20070709230022.D9997@fledge.watson.org> References: <20070613150534.D83504@fledge.watson.org> <20070613.212825.-957834923.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: current@freebsd.org, "M. Warner Losh" Subject: Re: HEADS UP: IPX over IP support removed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2007 22:01:24 -0000 On Thu, 14 Jun 2007, Maksim Yevmenkin wrote: > On 6/13/07, M. Warner Losh wrote: >> In message: <20070613150534.D83504@fledge.watson.org> >> Robert Watson writes: >> : ng_h4 - Bluetooth serial drivers -- I know of no on-going work here >> >> Isn't emax working on this? I didn't notice it before now... > > ok, i have the code, but i can not test it. my old xircom cbt pccard no > longer gets recognized :( i asked Warner for assistance. > > in the mean time, if anyone has working serial bluetooth device please let > me know. > > if i cant get this code tested in time, what should i do? commit untested > code or just retire ng_h4(4) for now? Max, Just realized you had a question in here, which I must have missed in the previous pass. What we're doing for i4b and netatm is leaving the code in the tree, but disconnecting it from the build for 7.0. So if things don't come together in time, we can just do that. I'm currently preparing a netatm patch, and Bjoern now has the i4b patch in the tree, so the ng_h4 bits are the only ones left after that. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Mon Jul 9 22:26:38 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0282816A421 for ; Mon, 9 Jul 2007 22:26:38 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.245]) by mx1.freebsd.org (Postfix) with ESMTP id 6A20213C4BC for ; Mon, 9 Jul 2007 22:26:37 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by an-out-0708.google.com with SMTP id c14so245150anc for ; Mon, 09 Jul 2007 15:26:36 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=q/7P7BB0Y7lpnZYvhfm2Or02FTaqslXBAVRnXwMImvKmachEwSYYFvIBtAsVklBvbLRcf5atc6mZoKF5No16tUwAeHHefFqNltMIKg2SIJkXLTvtnM5eu5Nb0O4Fs2nGl+QuwRENnyi8C21ZAL/Vzt/xXd8+3GGKEedWzic1vB4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=LzSQt7jjCT/4ukHWYhhmnVMcMyl7UN9p6XSdydY1S+if9D4VoEZKR3hfjlez+KMQz24mq6BE5/kxEO4r832nnBAJcFcxtHgVdYtePRKoWNGj8ioH0TnJqvxO5Z+tchXDMyI5Kj1aUwsL+RtFLISynX0hplYxJ9bp6l/RWIF3pZ4= Received: by 10.100.190.8 with SMTP id n8mr1855197anf.1184019996104; Mon, 09 Jul 2007 15:26:36 -0700 (PDT) Received: by 10.100.154.8 with HTTP; Mon, 9 Jul 2007 15:26:35 -0700 (PDT) Message-ID: Date: Mon, 9 Jul 2007 15:26:35 -0700 From: "Maksim Yevmenkin" To: "Robert Watson" In-Reply-To: <20070709230022.D9997@fledge.watson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070613150534.D83504@fledge.watson.org> <20070613.212825.-957834923.imp@bsdimp.com> <20070709230022.D9997@fledge.watson.org> Cc: current@freebsd.org, "M. Warner Losh" Subject: Re: HEADS UP: IPX over IP support removed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2007 22:26:38 -0000 On 7/9/07, Robert Watson wrote: > > On Thu, 14 Jun 2007, Maksim Yevmenkin wrote: > > > On 6/13/07, M. Warner Losh wrote: > >> In message: <20070613150534.D83504@fledge.watson.org> > >> Robert Watson writes: > >> : ng_h4 - Bluetooth serial drivers -- I know of no on-going work here > >> > >> Isn't emax working on this? I didn't notice it before now... > > > > ok, i have the code, but i can not test it. my old xircom cbt pccard no > > longer gets recognized :( i asked Warner for assistance. > > > > in the mean time, if anyone has working serial bluetooth device please let > > me know. > > > > if i cant get this code tested in time, what should i do? commit untested > > code or just retire ng_h4(4) for now? > > Max, > > Just realized you had a question in here, which I must have missed in the > previous pass. What we're doing for i4b and netatm is leaving the code in the > tree, but disconnecting it from the build for 7.0. So if things don't come > together in time, we can just do that. I'm currently preparing a netatm > patch, and Bjoern now has the i4b patch in the tree, so the ng_h4 bits are the > only ones left after that. i could not make my xircom cbt pccard work under -current :( and could not test my changes. also no one stepped forward and said that ng_h4(4) is being used. so, i vote in favor of disconnecting ng_h4(4) from the build right now. should i disconnect ng_h4(4) only or make a bigger change and retire all support for serial bluetooth devices? thanks, max From owner-freebsd-current@FreeBSD.ORG Mon Jul 9 22:29:41 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 173A516A477 for ; Mon, 9 Jul 2007 22:29:41 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id C6F6713C483 for ; Mon, 9 Jul 2007 22:29:40 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1I81jZ-0003L1-FM for freebsd-current@freebsd.org; Tue, 10 Jul 2007 00:29:33 +0200 Received: from 89-172-53-69.adsl.net.t-com.hr ([89.172.53.69]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 10 Jul 2007 00:29:33 +0200 Received: from ivoras by 89-172-53-69.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 10 Jul 2007 00:29:33 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Ivan Voras Date: Tue, 10 Jul 2007 00:29:26 +0200 Lines: 17 Message-ID: References: <20070709214216.GA72912@walton.maths.tcd.ie> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 89-172-53-69.adsl.net.t-com.hr User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) In-Reply-To: <20070709214216.GA72912@walton.maths.tcd.ie> Sender: news Cc: freebsd-hackers@freebsd.org Subject: Re: Debugging times X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2007 22:29:41 -0000 David Malone wrote: > On Mon, Jul 09, 2007 at 11:25:46PM +0200, Ivan Voras wrote: >> The date is set wrong either on boot or very early after the kernel has >> booted (I've verified it's wrong before hostid rc.d script, which is one >> of the first to be executed). > > I have some patches to make the code that reads the date from the > bios print errors if there is a problem parsing the date. I was > going to commit them to -current, but it might be useful for you > to test them? Yes, I'll test them. The problem is - the same kernel works when booted off a hard drive, so unless the VMWare BIOS is very messed up (it's the first time I see such problems) it may not help. Please, scatter debug printf's around so I can see what's going on :) From owner-freebsd-current@FreeBSD.ORG Mon Jul 9 22:40:24 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BFC9A16A41F for ; Mon, 9 Jul 2007 22:40:24 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 9652413C44C for ; Mon, 9 Jul 2007 22:40:24 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 3C04E46EFA; Mon, 9 Jul 2007 18:40:24 -0400 (EDT) Date: Mon, 9 Jul 2007 23:40:24 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Maksim Yevmenkin In-Reply-To: Message-ID: <20070709233036.V9997@fledge.watson.org> References: <20070613150534.D83504@fledge.watson.org> <20070613.212825.-957834923.imp@bsdimp.com> <20070709230022.D9997@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: current@freebsd.org, "M. Warner Losh" Subject: Re: HEADS UP: IPX over IP support removed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2007 22:40:24 -0000 On Mon, 9 Jul 2007, Maksim Yevmenkin wrote: >> Just realized you had a question in here, which I must have missed in the >> previous pass. What we're doing for i4b and netatm is leaving the code in >> the tree, but disconnecting it from the build for 7.0. So if things don't >> come together in time, we can just do that. I'm currently preparing a >> netatm patch, and Bjoern now has the i4b patch in the tree, so the ng_h4 >> bits are the only ones left after that. > > i could not make my xircom cbt pccard work under -current :( and could not > test my changes. also no one stepped forward and said that ng_h4(4) is being > used. so, i vote in favor of disconnecting ng_h4(4) from the build right > now. > > should i disconnect ng_h4(4) only or make a bigger change and retire all > support for serial bluetooth devices? Well, my interest here is only in eliminating NET_NEEDS_GIANT -- I don't mean to pass judgement on the more general class of devices, and as I know relatively little about them, couldn't do so in an informed way. My advice would be to leave everything that works, even if the devices are less common, as long as there's not a maintenance issue. And nothing says that ng_h4 can't come back in the future if people do turn up to do the testing. You might want to consider polling stable@ if you haven't already -- there's a much larger user community there. So I guess my advice is not to retire the rest if it's believed to work and isn't causing problems. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Mon Jul 9 23:01:51 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5E1EE16A46C; Mon, 9 Jul 2007 23:01:51 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 1DD7413C45B; Mon, 9 Jul 2007 23:01:50 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.13.8/8.13.8) with ESMTP id l69N1oUL078017; Mon, 9 Jul 2007 19:01:50 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.8/8.13.8) with ESMTP id l69N1ocQ024810; Mon, 9 Jul 2007 19:01:50 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id E02C773068; Mon, 9 Jul 2007 19:01:49 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070709230149.E02C773068@freebsd-current.sentex.ca> Date: Mon, 9 Jul 2007 19:01:49 -0400 (EDT) X-Virus-Scanned: ClamAV version devel-20070108, clamav-milter version devel-111206 on clamscanner4 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2007 23:01:51 -0000 TB --- 2007-07-09 20:55:00 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-07-09 20:55:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2007-07-09 20:55:01 - cleaning the object tree TB --- 2007-07-09 20:55:36 - checking out the source tree TB --- 2007-07-09 20:55:36 - cd /tinderbox/HEAD/amd64/amd64 TB --- 2007-07-09 20:55:36 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-07-09 21:06:39 - building world (CFLAGS=-O2 -pipe) TB --- 2007-07-09 21:06:39 - cd /src TB --- 2007-07-09 21:06:39 - /usr/bin/make -B buildworld >>> World build started on Mon Jul 9 21:06:41 UTC 2007 >>> 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 Mon Jul 9 22:52:38 UTC 2007 TB --- 2007-07-09 22:52:38 - generating LINT kernel config TB --- 2007-07-09 22:52:38 - cd /src/sys/amd64/conf TB --- 2007-07-09 22:52:38 - /usr/bin/make -B LINT TB --- 2007-07-09 22:52:39 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-07-09 22:52:39 - cd /src TB --- 2007-07-09 22:52:39 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Jul 9 22:52:39 UTC 2007 >>> 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 [...] cc1: warnings being treated as errors /src/sys/dev/usb/if_rue.c:598: warning: left-hand operand of comma expression has no effect /src/sys/dev/usb/if_rue.c:598: error: 'struct rue_softc' has no member named 'rue_tick_task' /src/sys/dev/usb/if_rue.c:598: warning: left-hand operand of comma expression has no effect /src/sys/dev/usb/if_rue.c: In function 'rue_detach': /src/sys/dev/usb/if_rue.c:710: error: 'struct rue_softc' has no member named 'rue_tick_task' /src/sys/dev/usb/if_rue.c: In function 'rue_tick': /src/sys/dev/usb/if_rue.c:931: error: 'struct rue_softc' has no member named 'rue_tick_task' *** Error code 1 Stop in /obj/amd64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-07-09 23:01:49 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-07-09 23:01:49 - ERROR: failed to build lint kernel TB --- 2007-07-09 23:01:49 - tinderbox aborted TB --- 0.89 user 2.89 system 7608.46 real http://tinderbox.des.no/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Mon Jul 9 23:14:17 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6E99516A41F; Mon, 9 Jul 2007 23:14:17 +0000 (UTC) (envelope-from huang@gddsn.org.cn) Received: from gddsn.org.cn (gddsn.org.cn [218.19.164.145]) by mx1.freebsd.org (Postfix) with ESMTP id B515713C46E; Mon, 9 Jul 2007 23:13:56 +0000 (UTC) (envelope-from huang@gddsn.org.cn) Received: from tp.gddsn.org.cn (unknown [121.28.82.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gddsn.org.cn (Postfix) with ESMTP id 989EA38CB4F; Mon, 9 Jul 2007 20:43:44 +0800 (CST) Message-ID: <46922D75.4010006@gddsn.org.cn> Date: Mon, 09 Jul 2007 20:43:33 +0800 From: Huang wen hui User-Agent: Thunderbird 2.0.0.0 (X11/20070528) MIME-Version: 1.0 To: Pawel Jakub Dawidek References: <200707071426.18202.dfr@rabson.org> <20070709000918.GD1208@garage.freebsd.pl> In-Reply-To: <20070709000918.GD1208@garage.freebsd.pl> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit Cc: current@freebsd.org Subject: Re: ZFS leaking vnodes (sort of) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2007 23:14:17 -0000 Pawel Jakub Dawidek дµÀ: > On Sat, Jul 07, 2007 at 02:26:17PM +0100, Doug Rabson wrote: > >> I've been testing ZFS recently and I noticed some performance issues >> while doing large-scale port builds on a ZFS mounted /usr/ports tree. >> Eventually I realised that virtually nothing ever ended up on the vnode >> free list. This meant that when the system reached its maximum vnode >> limit, it had to resort to reclaiming vnodes from the various >> filesystem's active vnode lists (via vlrureclaim). Since those lists >> are not sorted in LRU order, this led to pessimal cache performance >> after the system got into that state. >> >> I looked a bit closer at the ZFS code and poked around with DDB and I >> think the problem was caused by a couple of extraneous calls to vhold >> when creating a new ZFS vnode. On FreeBSD, getnewvnode returns a vnode >> which is already held (not on the free list) so there is no need to >> call vhold again. >> > > Whoa! Nice catch... The patch works here - I did some pretty heavy > tests, so please commit it ASAP. > > I also wonder if this can help with some of those 'kmem_map too small' > panics. I was observing that ARC cannot reclaim memory and this may be > because all vnodes and thus associated data are beeing held. > > To ZFS users having problems with performance and/or stability of ZFS: > Can you test the patch and see if it helps? > my T60p notebook, -CURRENT amd64: buildworld time before patch: 58xx second. buildworld time after path: 28xx second. Thanks! From owner-freebsd-current@FreeBSD.ORG Mon Jul 9 23:19:45 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3360216A41F for ; Mon, 9 Jul 2007 23:19:45 +0000 (UTC) (envelope-from henrik@brixandersen.dk) Received: from solow.pil.dk (relay.pil.dk [195.41.47.164]) by mx1.freebsd.org (Postfix) with ESMTP id EA70613C455 for ; Mon, 9 Jul 2007 23:19:44 +0000 (UTC) (envelope-from henrik@brixandersen.dk) Received: from tirith.brixandersen.dk (osgiliath.brixandersen.dk [87.53.223.189]) by solow.pil.dk (Postfix) with ESMTP id 4F1D51CC0B8; Tue, 10 Jul 2007 01:19:44 +0200 (CEST) Received: by tirith.brixandersen.dk (Postfix, from userid 1001) id BE875B834; Tue, 10 Jul 2007 01:19:43 +0200 (CEST) Date: Tue, 10 Jul 2007 01:19:43 +0200 From: Henrik Brix Andersen To: Doug Barton , freebsd-current@freebsd.org Message-ID: <20070709231943.GD58369@tirith.brixandersen.dk> Mail-Followup-To: Doug Barton , freebsd-current@freebsd.org References: <20070419133550.GA65054@tirith.brixandersen.dk> <4627C342.2010103@FreeBSD.org> <20070419200929.GA70735@tirith.brixandersen.dk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Rgf3q3z9SdmXC6oT" Content-Disposition: inline In-Reply-To: <20070419200929.GA70735@tirith.brixandersen.dk> X-PGP-Key: http://www.brixandersen.dk/files/HenrikBrixAndersen.asc User-Agent: Mutt/1.5.16 (2007-06-09) Cc: Subject: Re: RFT: bin/106642: [patch] Allow excluding certain files from mergemaster(8) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2007 23:19:45 -0000 --Rgf3q3z9SdmXC6oT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Doug, On Thu, Apr 19, 2007 at 10:09:29PM +0200, Henrik Brix Andersen wrote: > Hi Doug, >=20 > On Thu, Apr 19, 2007 at 12:30:10PM -0700, Doug Barton wrote: > > This is a slightly easier way of doing something that can already be > > done easily in other ways, so I have given it a very low priority. >=20 > That's perfectly ok with me - I just wondered when I didn't hear from > you for 4 months :) >=20 > While it is true that there are other ways of doing this, it would be > nice to have generic support for this in the official mergemaster(8) - > especially given the limited complexity of the patch, imho. >=20 > > My goal is to review the various suggestions for accomplishing what > > you're suggesting, and then to incorporate the best one(s). While I > > appreciate your enthusiasm, this isn't something that is any way shape > > or form "urgent." >=20 > Thanks. I appreciate you taking the time to get this done right, and I > look forward to seeing this - or a similar - feature being added to > mergemaster(8). Any chance of seeing this or a similar feature in mergemaster(8) in the upcoming 7.0 release? Regards, Brix --=20 Henrik Brix Andersen --Rgf3q3z9SdmXC6oT Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) Comment: GnuPG signed iD8DBQFGksKPv+Q4flTiePgRAh8JAJ4w7lrBwezODUsv8JTUbaVt2vmY+gCfbVHN tyZtzjf0pC6ex0N3HBFq3Y0= =gYcA -----END PGP SIGNATURE----- --Rgf3q3z9SdmXC6oT-- From owner-freebsd-current@FreeBSD.ORG Tue Jul 10 02:03:10 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C2D9F16A400 for ; Tue, 10 Jul 2007 02:03:10 +0000 (UTC) (envelope-from sfpoof@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.231]) by mx1.freebsd.org (Postfix) with ESMTP id 7E8F113C44B for ; Tue, 10 Jul 2007 02:03:10 +0000 (UTC) (envelope-from sfpoof@gmail.com) Received: by wr-out-0506.google.com with SMTP id i23so571151wra for ; Mon, 09 Jul 2007 19:03:09 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=ld5BgXq5LxBmS71rKR1Uwoh06MkqbsbBvirpew4wnwrH72eSz59htQqx16dLe4Gqw9XalKtiO++m6mJ7AFZVBpyw9FPu3xT6x0S83lHImxxkh31AvPg7ubrzwzmDrAdjGEqi3CfxX76thdCFbetnappEO0RkOT+WDtDIv+FSrMc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=upNsNGmZFbZ2mk/RGObOW80u4hQVJvtd5y7EWLw3P3nSMujJwHLD2eGiH5sSNGRhDjXGIAwlmohTRhtwPwpIPQQSTfjvDqCvOBN0ZrgCpQ7WpeNdoeRjz3oP+Eh37vb4Y5hWqpbPdYziOqZ5dHpwXw2oL1TFV5zYI4G2+FxbzLM= Received: by 10.90.97.11 with SMTP id u11mr2533772agb.1184032989757; Mon, 09 Jul 2007 19:03:09 -0700 (PDT) Received: by 10.90.100.16 with HTTP; Mon, 9 Jul 2007 19:03:09 -0700 (PDT) Message-ID: Date: Mon, 9 Jul 2007 19:03:09 -0700 From: "Kevin Gerry" To: "Sepherosa Ziehau" In-Reply-To: MIME-Version: 1.0 References: <468488B3.7010607@errno.com> <46848C1E.2080404@errno.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org Subject: Re: Wireless NICs not obeying 'SSID' setting. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2007 02:03:10 -0000 Well, this is all it gave when it switched: -- messages.0:Jul 9 17:18:07 storage kernel: ral0: sta_roam_check: currssi 21 currate 108 roamrssi 14 roamrate 10 messages.0:Jul 9 17:18:22 storage kernel: ral0: sta_roam_check: currssi 21 currate 108 roamrssi 14 roamrate 10 messages.0:Jul 9 17:18:37 storage kernel: ral0: sta_roam_check: currssi 21 currate 108 roamrssi 14 roamrate 10 messages.0:Jul 9 17:18:52 storage kernel: ral0: sta_roam_check: currssi 21 currate 108 roamrssi 14 roamrate 10 messages.0:Jul 9 17:19:07 storage kernel: ral0: sta_roam_check: currssi 19 currate 72 roamrssi 14 roamrate 10 messages.0:Jul 9 17:19:22 storage kernel: ral0: sta_roam_check: currssi 21 currate 108 roamrssi 14 roamrate 10 messages.0:Jul 9 17:19:37 storage kernel: ral0: sta_roam_check: currssi 21 currate 108 roamrssi 14 roamrate 10 messages.0:Jul 9 17:19:52 storage kernel: ral0: sta_roam_check: currssi 21 currate 108 roamrssi 14 roamrate 10 messages.0:Jul 9 17:20:07 storage kernel: ral0: sta_roam_check: currssi 23 currate 108 roamrssi 14 roamrate 10 messages.0:Jul 9 17:20:22 storage kernel: ral0: sta_roam_check: currssi 21 currate 108 roamrssi 14 roamrate 10 messages.0:Jul 9 17:20:37 storage kernel: ral0: sta_roam_check: currssi 21 currate 108 roamrssi 14 roamrate 10 messages.0:Jul 9 17:20:52 storage kernel: ral0: sta_roam_check: currssi 21 currate 108 roamrssi 14 roamrate 10 messages.0:Jul 9 17:21:07 storage kernel: ral0: sta_roam_check: currssi 21 currate 108 roamrssi 14 roamrate 10 messages.0:Jul 9 17:21:22 storage kernel: ral0: sta_roam_check: currssi 23 currate 108 roamrssi 14 roamrate 10 messages.0:Jul 9 17:21:37 storage kernel: ral0: link state changed to DOWN messages.0:Jul 9 17:21:39 storage kernel: ral0: link state changed to UP messages.0:Jul 9 17:21:54 storage kernel: ral0: sta_roam_check: currssi 45 currate 108 roamrssi 14 roamrate 10 messages.0:Jul 9 17:22:09 storage kernel: ral0: sta_roam_check: currssi 45 currate 108 roamrssi 14 roamrate 10 messages.0:Jul 9 17:22:24 storage kernel: ral0: sta_roam_check: currssi 45 currate 108 roamrssi 14 roamrate 10 messages.0:Jul 9 17:22:40 storage kernel: ral0: sta_roam_check: currssi 45 currate 108 roamrssi 14 roamrate 10 messages.0:Jul 9 17:22:55 storage kernel: ral0: sta_roam_check: currssi 45 currate 108 roamrssi 14 roamrate 10 messages.0:Jul 9 17:23:10 storage kernel: ral0: sta_roam_check: currssi 45 currate 108 roamrssi 14 roamrate 10 messages.0:Jul 9 17:23:25 storage kernel: ral0: sta_roam_check: currssi 43 currate 108 roamrssi 14 roamrate 10 messages.0:Jul 9 17:23:39 storage kernel: ral0: sta_roam_check: currssi 45 currate 108 roamrssi 14 roamrate 10 -- Any ideas? Or, any other commands you'd like me to try to give any more verbose logging? On 7/7/07, Sepherosa Ziehau wrote: > > On 7/5/07, Kevin Gerry wrote: > > Weird, one of the issues it appears I'm having is that when it's set to > > -bgscan and roaming device, the device will just get stuck on "no > carrier" > > Please leave bgscan and roaming on and run following command: > wlandebug -i ral0 +roam > wlandebug -i ath0 +roam > > Post the log, when the AP switching happened. > > Best Regards, > sephe > > -- > Live Free or Die > From owner-freebsd-current@FreeBSD.ORG Tue Jul 10 02:21:34 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 534AF16A400 for ; Tue, 10 Jul 2007 02:21:34 +0000 (UTC) (envelope-from lists@jnielsen.net) Received: from ns1.jnielsen.net (ns1.jnielsen.net [69.55.238.237]) by mx1.freebsd.org (Postfix) with ESMTP id 3743C13C459 for ; Tue, 10 Jul 2007 02:21:34 +0000 (UTC) (envelope-from lists@jnielsen.net) Received: from localhost (jn@ns1 [69.55.238.237]) (authenticated bits=0) by ns1.jnielsen.net (8.12.9p2/8.12.9) with ESMTP id l6A22DpT061564 for ; Mon, 9 Jul 2007 22:02:14 -0400 (EDT) (envelope-from lists@jnielsen.net) From: John Nielsen To: current@freebsd.org Date: Mon, 9 Jul 2007 22:01:29 -0400 User-Agent: KMail/1.9.7 X-Face: #X5#Y*q>F:]zT!DegL3z5Xo'^MN[$8k\[4^3rN~wm=s=Uw(sW}R?3b^*f1Wu*. X-Virus-Scanned: ClamAV version 0.88.4, clamav-milter version 0.88.4 on ns1.jnielsen.net X-Virus-Status: Clean Cc: Subject: geom_fox vs gmultipath X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2007 02:21:34 -0000 I was just reading the (pre-) release notes for 7.0 at http://people.freebsd.org/~bmah/relnotes/CURRENT/relnotes.html and learned about mjacob's gmultipath(8) implementation, which seems very similar to phk's older geom_fox(4) but perhaps a bit more polished. First off, is that a correct assessment? I haven't used either, but externally gmultipath is distinguished by having its own control utility (rather than relying on geom(8)), a manpage (and perhaps other features) more consistent with other geom utilities, and support for predictable volume names under /dev/multipath/. Assuming I'm basically on target so far, does geom_fox have any features that are not in gmultipath? If not, should it be considered deprecated? (or should gmultipath be considered experimental since it's newer?) I'm just curious, esp. since I may have a need for one of the two in the near future. Thanks, JN From owner-freebsd-current@FreeBSD.ORG Tue Jul 10 04:46:06 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5966D16A41F for ; Tue, 10 Jul 2007 04:46:06 +0000 (UTC) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id 0634C13C43E for ; Tue, 10 Jul 2007 04:46:05 +0000 (UTC) (envelope-from sam@errno.com) Received: from trouble.errno.com (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id l6A4k32T008549 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Jul 2007 21:46:04 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <46930F7A.6020007@errno.com> Date: Mon, 09 Jul 2007 21:47:54 -0700 From: Sam Leffler User-Agent: Thunderbird 2.0.0.0 (X11/20070530) MIME-Version: 1.0 To: Kevin Gerry References: <468488B3.7010607@errno.com> <46848C1E.2080404@errno.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Sepherosa Ziehau , freebsd-current@freebsd.org Subject: Re: Wireless NICs not obeying 'SSID' setting. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2007 04:46:06 -0000 Kevin Gerry wrote: > Well, this is all it gave when it switched: > > -- > messages.0:Jul 9 17:18:07 storage kernel: ral0: sta_roam_check: currssi > 21 currate 108 roamrssi 14 roamrate 10 > messages.0:Jul 9 17:18:22 storage kernel: ral0: sta_roam_check: currssi > 21 currate 108 roamrssi 14 roamrate 10 > messages.0:Jul 9 17:18:37 storage kernel: ral0: sta_roam_check: currssi > 21 currate 108 roamrssi 14 roamrate 10 > messages.0:Jul 9 17:18:52 storage kernel: ral0: sta_roam_check: currssi > 21 currate 108 roamrssi 14 roamrate 10 > messages.0:Jul 9 17:19:07 storage kernel: ral0: sta_roam_check: currssi > 19 currate 72 roamrssi 14 roamrate 10 > messages.0:Jul 9 17:19:22 storage kernel: ral0: sta_roam_check: currssi > 21 currate 108 roamrssi 14 roamrate 10 > messages.0:Jul 9 17:19:37 storage kernel: ral0: sta_roam_check: currssi > 21 currate 108 roamrssi 14 roamrate 10 > messages.0:Jul 9 17:19:52 storage kernel: ral0: sta_roam_check: currssi > 21 currate 108 roamrssi 14 roamrate 10 > messages.0:Jul 9 17:20:07 storage kernel: ral0: sta_roam_check: currssi > 23 currate 108 roamrssi 14 roamrate 10 > messages.0:Jul 9 17:20:22 storage kernel: ral0: sta_roam_check: currssi > 21 currate 108 roamrssi 14 roamrate 10 > messages.0:Jul 9 17:20:37 storage kernel: ral0: sta_roam_check: currssi > 21 currate 108 roamrssi 14 roamrate 10 > messages.0:Jul 9 17:20:52 storage kernel: ral0: sta_roam_check: currssi > 21 currate 108 roamrssi 14 roamrate 10 > messages.0:Jul 9 17:21:07 storage kernel: ral0: sta_roam_check: currssi > 21 currate 108 roamrssi 14 roamrate 10 > messages.0:Jul 9 17:21:22 storage kernel: ral0: sta_roam_check: currssi > 23 currate 108 roamrssi 14 roamrate 10 > messages.0:Jul 9 17:21:37 storage kernel: ral0: link state changed to DOWN > messages.0:Jul 9 17:21:39 storage kernel: ral0: link state changed to UP > messages.0:Jul 9 17:21:54 storage kernel: ral0: sta_roam_check: currssi > 45 currate 108 roamrssi 14 roamrate 10 > messages.0:Jul 9 17:22:09 storage kernel: ral0: sta_roam_check: currssi > 45 currate 108 roamrssi 14 roamrate 10 > messages.0:Jul 9 17:22:24 storage kernel: ral0: sta_roam_check: currssi > 45 currate 108 roamrssi 14 roamrate 10 > messages.0:Jul 9 17:22:40 storage kernel: ral0: sta_roam_check: currssi > 45 currate 108 roamrssi 14 roamrate 10 > messages.0:Jul 9 17:22:55 storage kernel: ral0: sta_roam_check: currssi > 45 currate 108 roamrssi 14 roamrate 10 > messages.0:Jul 9 17:23:10 storage kernel: ral0: sta_roam_check: currssi > 45 currate 108 roamrssi 14 roamrate 10 > messages.0:Jul 9 17:23:25 storage kernel: ral0: sta_roam_check: currssi > 43 currate 108 roamrssi 14 roamrate 10 > messages.0:Jul 9 17:23:39 storage kernel: ral0: sta_roam_check: currssi > 45 currate 108 roamrssi 14 roamrate 10 > -- > > Any ideas? Or, any other commands you'd like me to try to give any more > verbose logging? Looks like you moved to another ap not because of roaming but because you were dropped from your original ap. This can happen for various reasons but the fact that you did not go back to it means the station could not communicate w/ the ap so it chose another one. There are other wlandebug knobs you can turn on to see exactly what happened (e.g. state+scan). You can also look at wlanstats output and identify what happened (probably). I changed the behaviour of setting the ssid from being mandatory to "desired" for various reasons but it's likely I'll have to add back a way to make it mandatory. But then you'll likely find yourself taking a long time to re-connect to your ap if the ral card isn't being reset properly or otherwise getting into a bad state (ral has known issues). A well-behaved card+driver should locate the ap you want during the re-scan and/or it should roam quickly if it misses the ap but then picks it up on a bg scan. Sam > > On 7/7/07, *Sepherosa Ziehau* > wrote: > > On 7/5/07, Kevin Gerry > > wrote: > > Weird, one of the issues it appears I'm having is that when it's > set to > > -bgscan and roaming device, the device will just get stuck on "no > carrier" > > Please leave bgscan and roaming on and run following command: > wlandebug -i ral0 +roam > wlandebug -i ath0 +roam > > Post the log, when the AP switching happened. > > Best Regards, > sephe > > -- > Live Free or Die > > From owner-freebsd-current@FreeBSD.ORG Tue Jul 10 04:50:34 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 87D9A16A41F for ; Tue, 10 Jul 2007 04:50:34 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.freebsd.org (Postfix) with ESMTP id 5546413C458 for ; Tue, 10 Jul 2007 04:50:34 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.1/8.13.8) with ESMTP id l6A4n6mU062301 for ; Mon, 9 Jul 2007 21:49:06 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.1/8.13.8/Submit) id l6A4n2Th062300 for freebsd-current@freebsd.org; Mon, 9 Jul 2007 21:49:02 -0700 (PDT) (envelope-from sgk) Date: Mon, 9 Jul 2007 21:49:02 -0700 From: Steve Kargl To: freebsd-current@freebsd.org Message-ID: <20070710044902.GA62286@troutmask.apl.washington.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.2i Subject: Closing some old bug reports. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2007 04:50:34 -0000 Can someone please close 2006/02/02 kern/92742 2002/05/27 gnu/38594 2005/06/25 standards/82654 2006/01/20 bin/92074 2006/10/26 standards/104841 2007/05/04 bin/112408 2007/05/25 ports/112999 2007/05/30 standards/113147 These have out lived their shelf life. Thanks. -- Steve From owner-freebsd-current@FreeBSD.ORG Tue Jul 10 05:04:55 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2969B16A421 for ; Tue, 10 Jul 2007 05:04:55 +0000 (UTC) (envelope-from nslay@comcast.net) Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.200.82]) by mx1.freebsd.org (Postfix) with ESMTP id F18A413C448 for ; Tue, 10 Jul 2007 05:04:54 +0000 (UTC) (envelope-from nslay@comcast.net) Received: from lightbulb.local (c-68-35-224-189.hsd1.fl.comcast.net[68.35.224.189]) by comcast.net (sccrmhc12) with ESMTP id <20070710050453012003l0f3e>; Tue, 10 Jul 2007 05:04:54 +0000 Message-ID: <4693131B.8090306@comcast.net> Date: Tue, 10 Jul 2007 01:03:23 -0400 From: Nathan Lay User-Agent: Thunderbird 2.0.0.4 (X11/20070620) MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: ums, Microsoft Wireless Presenter mouse X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2007 05:04:55 -0000 Hi list, I was pleased that my Microsoft Wireless Presenter mouse successfully attaches with CURRENT ums without fiddling with the source. I had to write a patch to use it with 6.2 (I submitted it to the drivers list...probably the wrong place to submit it). However, button bit positions and x,y,z,t positions do not register properly (This mouse reports mostly lies). I see a newly added quirks section for the Microsoft wireless optical mouse, though, is there a way I can gracefully add the quirks for this particular mouse too? Additionally, this mouse has 5 extra buttons on the bottom that serve for presentation purposes, though the mouse doesn't actually report them. The mouse has some sort of mode or status byte that can indicate whether the bottom 5 presentation buttons are in use or if the normal buttons are in use. I don't think this support would be too difficult to add, I'm just not sure how useful it is or how to add the support such that it isn't disruptive to other mice. http://www.microsoft.com/hardware/mouseandkeyboard/ProductDetails.aspx?pid=085 Best Regards, Nathan Lay From owner-freebsd-current@FreeBSD.ORG Tue Jul 10 05:47:42 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 851B216A46C for ; Tue, 10 Jul 2007 05:47:42 +0000 (UTC) (envelope-from silby@silby.com) Received: from relay03.pair.com (relay03.pair.com [209.68.5.17]) by mx1.freebsd.org (Postfix) with SMTP id 4D3B613C487 for ; Tue, 10 Jul 2007 05:47:42 +0000 (UTC) (envelope-from silby@silby.com) Received: (qmail 26673 invoked from network); 10 Jul 2007 05:20:59 -0000 Received: from 209.68.2.70 (HELO localhost) (209.68.2.70) by relay03.pair.com with SMTP; 10 Jul 2007 05:20:59 -0000 X-pair-Authenticated: 209.68.2.70 Date: Tue, 10 Jul 2007 00:20:49 -0500 (CDT) From: Mike Silbersack To: current@freebsd.org, net@freebsd.org Message-ID: <20070709234401.S29353@odysseus.silby.com> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1185318269-1184043945=:29353" Content-ID: <20070710000720.E29353@odysseus.silby.com> Cc: Robert Watson , Andre Oppermann Subject: FreeBSD 7 TCP syncache fix: request for testers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2007 05:47:42 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1185318269-1184043945=:29353 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; FORMAT=flowed Content-ID: <20070710000720.U29353@odysseus.silby.com> I've found one of the causes of the network instability of FreeBSD 7; the tcp syncache fails to retransmit SYN-ACK packets. This causes interesting problems when packet loss is experienced during connection setup. The symptoms that I have witnessed are twofold: 1. If the third part of the 3WHS is lost, the client will believe that the connection is in the ESTABLISHED state, while the server will still have the connection in the syncache. 2. Subsequently, the above syncache entry will stay stuck in the syncache forever. If you attempt to re-use that same 4-tuple, the syncache will ack the new SYN with the old sequence number. Anyway, the attached patch simplifies the syncache structure a bit and makes it retransmit properly. I'd appreciate testing from anyone who has experienced TCP problems with FreeBSD 7, as well as anyone who is pushing significant traffic through FreeBSD 7. I'm not interested in FreeBSD 6 testers, since the FreeBSD 6 syncache has a different structure and is not affected by this bug. FWIW, here's how to prove the existence of the bug. Install nemesis from ports, then use it to send SYN packets at your FreeBSD 7 machine. As of now, you should see only one SYN-ACK reply, and you should also notice that the sysctl net.inet.tcp.syncache.count goes up, but does not come back down. Once you have applied the patch, you should see the behavior demonstrated below: >From your client machine: (nemesis will pick an IP to spoof, change that if you wish.) nemesis tcp -y 80 -D 10.1.1.6 TCP Packet Injected On your FreeBSD 7 machine: patrocles# tcpdump -n port 80 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on nve0, link-type EN10MB (Ethernet), capture size 96 bytes 23:49:02.075118 IP 133.120.85.92.48922 > 10.1.1.6.80: S 1519649939:1519649939(0) win 4096 23:49:02.075165 IP 10.1.1.6.80 > 133.120.85.92.48922: S 269601671:269601671(0) ack 1519649940 win 65535 23:49:05.164195 IP 10.1.1.6.80 > 133.120.85.92.48922: S 269601671:269601671(0) ack 1519649940 win 65535 23:49:11.264245 IP 10.1.1.6.80 > 133.120.85.92.48922: S 269601671:269601671(0) ack 1519649940 win 65535 23:49:23.364342 IP 10.1.1.6.80 > 133.120.85.92.48922: S 269601671:269601671(0) ack 1519649940 win 65535 Thanks, Mike "Silby" Silbersack --0-1185318269-1184043945=:29353 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME=tcp_syncache.c-timerfix.patch Content-Transfer-Encoding: BASE64 Content-ID: <20070710000545.B29353@odysseus.silby.com> Content-Description: Content-Disposition: ATTACHMENT; FILENAME=tcp_syncache.c-timerfix.patch LS0tIC91c3Ivc3JjL3N5cy5vbGQvbmV0aW5ldC90Y3Bfc3luY2FjaGUuYwky MDA3LTA2LTI0IDIwOjE3OjMxLjAwMDAwMDAwMCAtMDUwMA0KKysrIC91c3Iv c3JjL3N5cy9uZXRpbmV0L3RjcF9zeW5jYWNoZS5jCTIwMDctMDctMDkgMDA6 NDY6MTguMDAwMDAwMDAwIC0wNTAwDQpAQCAtMTQ5LDcgKzE1MCw2IEBADQog CXN0cnVjdCBtdHgJc2NoX210eDsNCiAJVEFJTFFfSEVBRChzY2hfaGVhZCwg c3luY2FjaGUpCXNjaF9idWNrZXQ7DQogCXN0cnVjdCBjYWxsb3V0CXNjaF90 aW1lcjsNCi0JaW50CQlzY2hfbmV4dGM7DQogCXVfaW50CQlzY2hfbGVuZ3Ro Ow0KIAl1X2ludAkJc2NoX29kZGV2ZW47DQogCXVfaW50MzJfdAlzY2hfc2Vj Yml0c19vZGRbU1lOQ09PS0lFX1NFQ1JFVF9TSVpFXTsNCkBAIC0yNDAsMTYg KzI0MCwxMCBAQA0KIA0KICNkZWZpbmUgRU5EUFRTNl9FUShhLCBiKSAobWVt Y21wKGEsIGIsIHNpemVvZigqYSkpID09IDApDQogDQotI2RlZmluZSBTWU5D QUNIRV9USU1FT1VUKHNjLCBzY2gsIGNvKSBkbyB7CQkJCVwNCisjZGVmaW5l IFNZTkNBQ0hFX1RJTUVPVVQoc2MpIGRvIHsJCQkJCVwNCiAJKHNjKS0+c2Nf cnhtaXRzKys7CQkJCQkJXA0KIAkoc2MpLT5zY19yeHR0aW1lID0gdGlja3Mg KwkJCQkJXA0KIAkJVENQVFZfUlRPQkFTRSAqIHRjcF9iYWNrb2ZmWyhzYykt PnNjX3J4bWl0cyAtIDFdOwlcDQotCWlmICgoc2NoKS0+c2NoX25leHRjID4g KHNjKS0+c2Nfcnh0dGltZSkJCQlcDQotCQkoc2NoKS0+c2NoX25leHRjID0g KHNjKS0+c2Nfcnh0dGltZTsJCQlcDQotCWlmICghVEFJTFFfRU1QVFkoJihz Y2gpLT5zY2hfYnVja2V0KSAmJiAhKGNvKSkJCQlcDQotCQljYWxsb3V0X3Jl c2V0KCYoc2NoKS0+c2NoX3RpbWVyLAkJCVwNCi0JCQkoc2NoKS0+c2NoX25l eHRjIC0gdGlja3MsCQkJXA0KLQkJCXN5bmNhY2hlX3RpbWVyLCAodm9pZCAq KShzY2gpKTsJCQlcDQogfSB3aGlsZSAoMCkNCiANCiAjZGVmaW5lCVNDSF9M T0NLKHNjaCkJCW10eF9sb2NrKCYoc2NoKS0+c2NoX210eCkNCkBAIC0yNzUs NiArMjY5LDcgQEANCiBzeW5jYWNoZV9pbml0KHZvaWQpDQogew0KIAlpbnQg aTsNCisJc3RydWN0IHN5bmNhY2hlX2hlYWQgKnNjaDsNCiANCiAJdGNwX3N5 bmNhY2hlLmNhY2hlX2NvdW50ID0gMDsNCiAJdGNwX3N5bmNhY2hlLmhhc2hz aXplID0gVENQX1NZTkNBQ0hFX0hBU0hTSVpFOw0KQEAgLTMxNyw2ICszMTIs MTcgQEANCiAJdGNwX3N5bmNhY2hlLnpvbmUgPSB1bWFfemNyZWF0ZSgic3lu Y2FjaGUiLCBzaXplb2Yoc3RydWN0IHN5bmNhY2hlKSwNCiAJICAgIE5VTEws IE5VTEwsIE5VTEwsIE5VTEwsIFVNQV9BTElHTl9QVFIsIDApOw0KIAl1bWFf em9uZV9zZXRfbWF4KHRjcF9zeW5jYWNoZS56b25lLCB0Y3Bfc3luY2FjaGUu Y2FjaGVfbGltaXQpOw0KKw0KKwkvKg0KKwkgKiBTdGFydCB0aGUgc3luY2Fj aGUgaGVhZCB0aW1lcnMgcnVubmluZy4gIFRoZXkgZWFjaCBydW4gdGVuIHRp bWVzDQorCSAqIGEgc2Vjb25kLCBhbmQgYXJlIHNwcmVhZCBvdXQgc28gdGhh dCB0aGV5IGFyZSBub3QgYWxsIHJ1bm5pbmcgb24NCisJICogdGhlIHNhbWUg Y2xvY2sgdGljay4NCisJICovDQorCWZvciAoaSA9IDA7IGkgPCB0Y3Bfc3lu Y2FjaGUuaGFzaHNpemU7IGkrKykgew0KKwkJc2NoID0gJnRjcF9zeW5jYWNo ZS5oYXNoYmFzZVtpXTsNCisJCWNhbGxvdXRfcmVzZXQoJihzY2gpLT5zY2hf dGltZXIsIGkgKiAoaHogLyAxMCksICAgIA0KKyAgICAgICAgICAgICAgICBz eW5jYWNoZV90aW1lciwgKHZvaWQgKikoc2NoKSk7DQorCX0NCiB9DQogDQog LyoNCkBAIC0zNDYsOCArMzUyLDggQEANCiAJVEFJTFFfSU5TRVJUX0hFQUQo JnNjaC0+c2NoX2J1Y2tldCwgc2MsIHNjX2hhc2gpOw0KIAlzY2gtPnNjaF9s ZW5ndGgrKzsNCiANCi0JLyogUmVpbml0aWFsaXplIHRoZSBidWNrZXQgcm93 J3MgdGltZXIuICovDQotCVNZTkNBQ0hFX1RJTUVPVVQoc2MsIHNjaCwgMSk7 DQorCS8qIFNldCB0aGUgcmV0cmFuc21pdCB0aW1lciBmb3IgdGhpcyBzb2Nr ZXQuICovDQorCVNZTkNBQ0hFX1RJTUVPVVQoc2MpOw0KIA0KIAlTQ0hfVU5M T0NLKHNjaCk7DQogDQpAQCAtMzk4LDggKzQwNCw2IEBADQogCQkgKiBob3N0 IGRvZXMgdGhlIFNZTi9BQ0stPkFDSy4NCiAJCSAqLw0KIAkJaWYgKHNjLT5z Y19yeHR0aW1lID49IHRpY2spIHsNCi0JCQlpZiAoc2MtPnNjX3J4dHRpbWUg PCBzY2gtPnNjaF9uZXh0YykNCi0JCQkJc2NoLT5zY2hfbmV4dGMgPSBzYy0+ c2Nfcnh0dGltZTsNCiAJCQljb250aW51ZTsNCiAJCX0NCiANCkBAIC00MTYs MTEgKzQyMCwxMCBAQA0KIA0KIAkJKHZvaWQpIHN5bmNhY2hlX3Jlc3BvbmQo c2MpOw0KIAkJdGNwc3RhdC50Y3BzX3NjX3JldHJhbnNtaXR0ZWQrKzsNCi0J CVNZTkNBQ0hFX1RJTUVPVVQoc2MsIHNjaCwgMCk7DQorCQlTWU5DQUNIRV9U SU1FT1VUKHNjKTsNCiAJfQ0KLQlpZiAoIVRBSUxRX0VNUFRZKCYoc2NoKS0+ c2NoX2J1Y2tldCkpDQotCQljYWxsb3V0X3Jlc2V0KCYoc2NoKS0+c2NoX3Rp bWVyLCAoc2NoKS0+c2NoX25leHRjIC0gdGljaywNCi0JCQlzeW5jYWNoZV90 aW1lciwgKHZvaWQgKikoc2NoKSk7DQorCWNhbGxvdXRfcmVzZXQoJihzY2gp LT5zY2hfdGltZXIsIGh6IC8gMTAsDQorCQlzeW5jYWNoZV90aW1lciwgKHZv aWQgKikoc2NoKSk7DQogfQ0KIA0KIC8qDQpAQCAtMTAwNyw3ICsxMDEwLDcg QEANCiAJCSAgICAoIiVzOiBsYWJlbCBub3QgaW5pdGlhbGl6ZWQiLCBfX2Z1 bmNfXykpOw0KICNlbmRpZg0KIAkJaWYgKHN5bmNhY2hlX3Jlc3BvbmQoc2Mp ID09IDApIHsNCi0JCQlTWU5DQUNIRV9USU1FT1VUKHNjLCBzY2gsIDEpOw0K KwkJCVNZTkNBQ0hFX1RJTUVPVVQoc2MpOw0KIAkJCXRjcHN0YXQudGNwc19z bmRhY2tzKys7DQogCQkJdGNwc3RhdC50Y3BzX3NuZHRvdGFsKys7DQogCQl9 DQo= --0-1185318269-1184043945=:29353-- From owner-freebsd-current@FreeBSD.ORG Tue Jul 10 06:26:04 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0F4BB16A400; Tue, 10 Jul 2007 06:26:04 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.freebsd.org (Postfix) with ESMTP id E642613C44B; Tue, 10 Jul 2007 06:26:03 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.1/8.13.8) with ESMTP id l6A6OZ4N062970; Mon, 9 Jul 2007 23:24:36 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.1/8.13.8/Submit) id l6A6OZav062969; Mon, 9 Jul 2007 23:24:35 -0700 (PDT) (envelope-from sgk) Date: Mon, 9 Jul 2007 23:24:35 -0700 From: Steve Kargl To: Mike Silbersack Message-ID: <20070710062435.GA62925@troutmask.apl.washington.edu> References: <20070709234401.S29353@odysseus.silby.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070709234401.S29353@odysseus.silby.com> User-Agent: Mutt/1.4.2.2i Cc: Andre Oppermann , Robert Watson , current@freebsd.org, net@freebsd.org Subject: Re: FreeBSD 7 TCP syncache fix: request for testers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2007 06:26:04 -0000 On Tue, Jul 10, 2007 at 12:20:49AM -0500, Mike Silbersack wrote: > > I've found one of the causes of the network instability of FreeBSD 7; the > tcp syncache fails to retransmit SYN-ACK packets. This causes interesting > problems when packet loss is experienced during connection setup. The > symptoms that I have witnessed are twofold: > > 1. If the third part of the 3WHS is lost, the client will believe that > the connection is in the ESTABLISHED state, while the server will still > have the connection in the syncache. > 2. Subsequently, the above syncache entry will stay stuck in the syncache > forever. If you attempt to re-use that same 4-tuple, the syncache will > ack the new SYN with the old sequence number. > > Anyway, the attached patch simplifies the syncache structure a bit and > makes it retransmit properly. I'd appreciate testing from anyone who has > experienced TCP problems with FreeBSD 7, as well as anyone who is pushing > significant traffic through FreeBSD 7. Mike, Thanks for tracking this problem down. I can't test this patch for a few weeks due to deadlines. I'll run some tests when I can. From owner-freebsd-current@FreeBSD.ORG Tue Jul 10 07:29:25 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0647E16A469 for ; Tue, 10 Jul 2007 07:29:25 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id B6F9413C448 for ; Tue, 10 Jul 2007 07:29:24 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.13.8/8.13.4) with ESMTP id l6A7Sjt4006801; Tue, 10 Jul 2007 01:28:46 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Tue, 10 Jul 2007 01:29:27 -0600 (MDT) Message-Id: <20070710.012927.-300782446.imp@bsdimp.com> To: nslay@comcast.net From: "M. Warner Losh" In-Reply-To: <4693131B.8090306@comcast.net> References: <4693131B.8090306@comcast.net> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Tue, 10 Jul 2007 01:28:46 -0600 (MDT) Cc: freebsd-current@freebsd.org Subject: Re: ums, Microsoft Wireless Presenter mouse X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2007 07:29:25 -0000 In message: <4693131B.8090306@comcast.net> Nathan Lay writes: : Hi list, : I was pleased that my Microsoft Wireless Presenter mouse successfully : attaches with CURRENT ums without fiddling with the source. I had to : write a patch to use it with 6.2 (I submitted it to the drivers : list...probably the wrong place to submit it). However, button bit : positions and x,y,z,t positions do not register properly (This mouse : reports mostly lies). I see a newly added quirks section for the : Microsoft wireless optical mouse, though, is there a way I can : gracefully add the quirks for this particular mouse too? : Additionally, this mouse has 5 extra buttons on the bottom that serve : for presentation purposes, though the mouse doesn't actually report : them. The mouse has some sort of mode or status byte that can indicate : whether the bottom 5 presentation buttons are in use or if the normal : buttons are in use. I don't think this support would be too difficult : to add, I'm just not sure how useful it is or how to add the support : such that it isn't disruptive to other mice. : : http://www.microsoft.com/hardware/mouseandkeyboard/ProductDetails.aspx?pid=085 : Please send me a usbdevs -v output and I'll get you started. Warner From owner-freebsd-current@FreeBSD.ORG Tue Jul 10 08:15:00 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0625A16A46B for ; Tue, 10 Jul 2007 08:15:00 +0000 (UTC) (envelope-from bushman@freebsd.org) Received: from mail.r61.net (mail.r61.net [195.208.245.249]) by mx1.freebsd.org (Postfix) with ESMTP id 73F6313C455 for ; Tue, 10 Jul 2007 08:14:58 +0000 (UTC) (envelope-from bushman@freebsd.org) Received: from [127.0.0.1] (shogun.cc.rsu.ru [195.208.252.84]) (authenticated bits=0) by mail.r61.net (8.14.1/8.14.1) with ESMTP id l6A7kxF7098924; Tue, 10 Jul 2007 11:47:01 +0400 (MSD) (envelope-from bushman@freebsd.org) Message-ID: <46933969.7050602@freebsd.org> Date: Tue, 10 Jul 2007 11:46:49 +0400 From: Michael Bushkov User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Alexander Leidinger References: <20070709104152.rsg4v3hjww8woksk@webmail.leidinger.net> In-Reply-To: <20070709104152.rsg4v3hjww8woksk@webmail.leidinger.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: cached update flaws... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2007 08:15:00 -0000 Alexander Leidinger wrote: > Hi, > Hi Alexander, > somehow cached doesn't work as I think it should work. I have a jail in > which I use cached. There I wanted to install doxygen. As part of this > cups (dependency from qt) is build. The cups port adds a cups user and > group. After adding the group/user the configure script checks for the > user. This fails as cached doesn't know about the added user. I have to > restart cached to see the user/group (tested with "pw groupshow cups"). > > Are my expectations about cached wrong, or is it misbehaving? Your expectations are not wrong. There is a cached version in my perforce branch that has all the necessary functionality (it watches local files and flushes the cache when needed). It's in the process of commitment. I'm sorry that it takes so much time to get it committed. > > And while we are at it, is there really a need to print the cached > version number and the fact that it was developed during GSoC 2005 at > each start? It clutters the visual appearance at boot time. While I was developing cached (during GSoC 2005, as you can guess) I was extremely inspired by the GSoC program and about the people that I had a chance to meet because of this program. That's why I put that message. Actually, I'm still as inspired :) . I can delete the message, however. > > Bye, > Alexander. > -- With best regards, Michael Bushkov Southern Federal University From owner-freebsd-current@FreeBSD.ORG Tue Jul 10 08:15:01 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 803CF16A400 for ; Tue, 10 Jul 2007 08:15:01 +0000 (UTC) (envelope-from bushman@freebsd.org) Received: from mail.r61.net (mail.r61.net [195.208.245.249]) by mx1.freebsd.org (Postfix) with ESMTP id B572313C458 for ; Tue, 10 Jul 2007 08:15:00 +0000 (UTC) (envelope-from bushman@freebsd.org) Received: from [127.0.0.1] (shogun.cc.rsu.ru [195.208.252.84]) (authenticated bits=0) by mail.r61.net (8.14.1/8.14.1) with ESMTP id l6A7c6DB097984; Tue, 10 Jul 2007 11:38:10 +0400 (MSD) (envelope-from bushman@freebsd.org) Message-ID: <46933754.6090402@freebsd.org> Date: Tue, 10 Jul 2007 11:37:56 +0400 From: Michael Bushkov User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Gavin Atkinson References: <20070709104152.rsg4v3hjww8woksk@webmail.leidinger.net> <6eb82e0707090150t2977c32ex42abf09c21eb6a5b@mail.gmail.com> <1183975194.31312.6.camel@buffy.york.ac.uk> In-Reply-To: <1183975194.31312.6.camel@buffy.york.ac.uk> Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 7bit Cc: Alexander Leidinger , Rong-en Fan , current@freebsd.org Subject: Re: cached update flaws... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2007 08:15:01 -0000 Hi Gavin, I fully agree. The patch, that renames cached to nscd was sent to re@ - I just didn't receive approval yet. Gavin Atkinson wrote: > On Mon, 2007-07-09 at 16:50 +0800, Rong-en Fan wrote: >> On 7/9/07, Alexander Leidinger wrote: >>> And while we are at it, is there really a need to print the cached >>> version number and the fact that it was developed during GSoC 2005 at >>> each start? It clutters the visual appearance at boot time. >> I feel the same. >> >> BTW, is there any plan to enable cached by default in 7.0? > > There have also been several discussions about renaming it to "nscd" to > match other operating systems, and to indicate that it does now do more > than just caching. Realistically, this has to happen before 7.0 or not > at all. > > Gavin -- With best regards, Michael Bushkov Southern Federal University From owner-freebsd-current@FreeBSD.ORG Tue Jul 10 08:19:18 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E344716A421; Tue, 10 Jul 2007 08:19:18 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from redbull.bpaserver.net (redbullneu.bpaserver.net [213.198.78.217]) by mx1.freebsd.org (Postfix) with ESMTP id 3CD2213C457; Tue, 10 Jul 2007 08:19:18 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from outgoing.leidinger.net (p54A571E0.dip.t-dialin.net [84.165.113.224]) by redbull.bpaserver.net (Postfix) with ESMTP id 403332E178; Tue, 10 Jul 2007 10:19:09 +0200 (CEST) Received: from webmail.leidinger.net (webmail.Leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id 07C145B4AB1; Tue, 10 Jul 2007 10:16:58 +0200 (CEST) Received: (from www@localhost) by webmail.leidinger.net (8.13.8/8.13.8/Submit) id l6A8GvbG098584; Tue, 10 Jul 2007 10:16:57 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from pslux.cec.eu.int (pslux.cec.eu.int [158.169.9.14]) by webmail.leidinger.net (Horde MIME library) with HTTP; Tue, 10 Jul 2007 10:16:57 +0200 Message-ID: <20070710101657.jam16yes54wg8g88@webmail.leidinger.net> X-Priority: 3 (Normal) Date: Tue, 10 Jul 2007 10:16:57 +0200 From: Alexander Leidinger To: Michael Bushkov References: <20070709104152.rsg4v3hjww8woksk@webmail.leidinger.net> <46933969.7050602@freebsd.org> In-Reply-To: <46933969.7050602@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1.4) / FreeBSD-7.0 X-BPAnet-MailScanner-Information: Please contact the ISP for more information X-BPAnet-MailScanner: Found to be clean X-BPAnet-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-15.4, required 8, autolearn=not spam, BAYES_00 -15.00, DKIM_POLICY_SIGNSOME 0.00, RDNS_DYNAMIC 0.10, SMILEY -0.50) X-BPAnet-MailScanner-From: alexander@leidinger.net X-Spam-Status: No Cc: current@freebsd.org Subject: Re: cached update flaws... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2007 08:19:19 -0000 Quoting Michael Bushkov (from Tue, 10 Jul 2007 =20 11:46:49 +0400): > Alexander Leidinger wrote: >> Are my expectations about cached wrong, or is it misbehaving? > > Your expectations are not wrong. There is a cached version in my > perforce branch that has all the necessary functionality (it watches > local files and flushes the cache when needed). It's in the process of > commitment. I'm sorry that it takes so much time to get it committed. Thanks for the status update. >> And while we are at it, is there really a need to print the cached =20 >> version number and the fact that it was developed during GSoC 2005 =20 >> at each start? It clutters the visual appearance at boot time. > > While I was developing cached (during GSoC 2005, as you can guess) I > was extremely inspired by the GSoC program and about the people that I > had a chance to meet because of this program. That's why I put that > message. Actually, I'm still as inspired :) . I can delete the message, > however. No program/daemon in the base system which is started at boot time =20 prints such a message (at least I don't remember one in my typical =20 configurations), so I would say we have a lot of precedence which =20 suggests at least to suppress this message at boot time... Bye, Alexander. --=20 There are three kinds of lies: lies, damned lies and statistics. =09=09-- Benjamin Disraeli http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID =3D B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID =3D 72077137 From owner-freebsd-current@FreeBSD.ORG Tue Jul 10 08:26:24 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E686A16A400 for ; Tue, 10 Jul 2007 08:26:24 +0000 (UTC) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (gate.funkthat.com [69.17.45.168]) by mx1.freebsd.org (Postfix) with ESMTP id BED7D13C4B8 for ; Tue, 10 Jul 2007 08:26:24 +0000 (UTC) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (w56zmleccq02sbbx@localhost.funkthat.com [127.0.0.1]) by hydrogen.funkthat.com (8.13.6/8.13.3) with ESMTP id l6A8QNtV021360; Tue, 10 Jul 2007 01:26:23 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.13.6/8.13.3/Submit) id l6A8QMWr021359; Tue, 10 Jul 2007 01:26:22 -0700 (PDT) (envelope-from jmg) Date: Tue, 10 Jul 2007 01:26:22 -0700 From: John-Mark Gurney To: Michael Bushkov Message-ID: <20070710082622.GC1221@funkthat.com> Mail-Followup-To: Michael Bushkov , Alexander Leidinger , current@freebsd.org References: <20070709104152.rsg4v3hjww8woksk@webmail.leidinger.net> <46933969.7050602@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46933969.7050602@freebsd.org> User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD 5.4-RELEASE-p6 i386 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html Cc: Alexander Leidinger , current@freebsd.org Subject: Re: cached update flaws... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: John-Mark Gurney List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2007 08:26:25 -0000 Michael Bushkov wrote this message on Tue, Jul 10, 2007 at 11:46 +0400: > >And while we are at it, is there really a need to print the cached > >version number and the fact that it was developed during GSoC 2005 at > >each start? It clutters the visual appearance at boot time. > > While I was developing cached (during GSoC 2005, as you can guess) I was > extremely inspired by the GSoC program and about the people that I had > a chance to meet because of this program. That's why I put that message. > Actually, I'm still as inspired :) . I can delete the message, however. If you feel that inspired, include it in the man page, but at startup is not the place for it. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-current@FreeBSD.ORG Tue Jul 10 08:27:57 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DCF1F16A468 for ; Tue, 10 Jul 2007 08:27:57 +0000 (UTC) (envelope-from ivoras@fer.hr) Received: from pinus.cc.fer.hr (pinus.cc.fer.hr [161.53.73.18]) by mx1.freebsd.org (Postfix) with ESMTP id 6280413C45D for ; Tue, 10 Jul 2007 08:27:57 +0000 (UTC) (envelope-from ivoras@fer.hr) Received: from [161.53.72.113] (lara.cc.fer.hr [161.53.72.113]) by pinus.cc.fer.hr (8.12.2/8.12.2) with ESMTP id l6A8dr3f018321; Tue, 10 Jul 2007 10:39:55 +0200 (MEST) Message-ID: <46934301.5080302@fer.hr> Date: Tue, 10 Jul 2007 10:27:45 +0200 From: Ivan Voras User-Agent: Thunderbird 1.5.0.12 (X11/20060911) MIME-Version: 1.0 To: Victor Snezhko References: In-Reply-To: X-Enigmail-Version: 0.94.2.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig3DF98B718EE8063EEEC21C16" Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: Debugging time X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2007 08:27:58 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig3DF98B718EE8063EEEC21C16 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Victor Snezhko wrote: > Hi, Ivan, David, Hi, > For about half a year I have another weirdness with time on my > -current box without vmware, maybe it's somehow has common origins > with your behaviour. When I boot FreeBSD, ntpdate (which is set up to > run via rc.conf) often reports huge time offsets: > 10 Jul 12:04:34 ntpdate[51761]: step time server ntp.server.name offs= et 234456.074166 sec >=20 > I have so far only noticed that the value of the the offset is roughly > equal to the amount of time when FreeBSD isn't running (this is a > dual-boot box with windows). The box is pretty old, 600-MHz Celeron=20 Is the above number correct (i.e. ~~ 65 hours)? I noticed there can be a = consistent "shift" of duration equal to your timezone when VMWare sets=20 the RTC to the host's local time and FreeBSD thinks it's UTC. But if the = difference is not constant, it's not it. --------------enig3DF98B718EE8063EEEC21C16 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.5 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFGk0MIldnAQVacBcgRAhjgAJ9mNV0Nyjy/iyD+88Y0W5gKUMMC3wCfeWkU 2xWQ2TGgr2TiELuHHg2158s= =81ct -----END PGP SIGNATURE----- --------------enig3DF98B718EE8063EEEC21C16-- From owner-freebsd-current@FreeBSD.ORG Tue Jul 10 08:30:06 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 86E4D16A46D for ; Tue, 10 Jul 2007 08:30:06 +0000 (UTC) (envelope-from bushman@freebsd.org) Received: from mail.r61.net (mail.r61.net [195.208.245.249]) by mx1.freebsd.org (Postfix) with ESMTP id DD2D813C46E for ; Tue, 10 Jul 2007 08:30:05 +0000 (UTC) (envelope-from bushman@freebsd.org) Received: from [127.0.0.1] (shogun.cc.rsu.ru [195.208.252.84]) (authenticated bits=0) by mail.r61.net (8.14.1/8.14.1) with ESMTP id l6A8TriU004255; Tue, 10 Jul 2007 12:30:04 +0400 (MSD) (envelope-from bushman@freebsd.org) Message-ID: <46934377.3080709@freebsd.org> Date: Tue, 10 Jul 2007 12:29:43 +0400 From: Michael Bushkov User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Alexander Leidinger References: <20070709104152.rsg4v3hjww8woksk@webmail.leidinger.net> <46933969.7050602@freebsd.org> <20070710101657.jam16yes54wg8g88@webmail.leidinger.net> In-Reply-To: <20070710101657.jam16yes54wg8g88@webmail.leidinger.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: cached update flaws... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2007 08:30:06 -0000 Alexander Leidinger wrote: > > No program/daemon in the base system which is started at boot time > prints such a message (at least I don't remember one in my typical > configurations), so I would say we have a lot of precedence which > suggests at least to suppress this message at boot time... Agreed. This message is not an issue for me at all. > > Bye, > Alexander. > -- With best regards, Michael Bushkov Southern Federal University From owner-freebsd-current@FreeBSD.ORG Tue Jul 10 08:40:48 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 77CA816A468; Tue, 10 Jul 2007 08:40:48 +0000 (UTC) (envelope-from snezhko@indorsoft.ru) Received: from indorsoft.ru (indor.net.tomline.ru [213.183.100.90]) by mx1.freebsd.org (Postfix) with ESMTP id 9612B13C45B; Tue, 10 Jul 2007 08:40:46 +0000 (UTC) (envelope-from snezhko@indorsoft.ru) Received: from SNEZHKO by indorsoft.ru (MDaemon.PRO.v7.2.2.R) with ESMTP id md50000218776.msg; Tue, 10 Jul 2007 15:40:38 +0700 From: Victor Snezhko To: Ivan Voras References: <46934301.5080302@fer.hr> Date: Tue, 10 Jul 2007 15:40:31 +0700 In-Reply-To: <46934301.5080302@fer.hr> (Ivan Voras's message of "Tue, 10 Jul 2007 10:27:45 +0200") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.3 (windows-nt) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Processed: indor.net.tomline.ru, Tue, 10 Jul 2007 15:40:38 +0700 (not processed: spam filter disabled) X-Return-Path: snezhko@indorsoft.ru Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: Debugging time X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2007 08:40:48 -0000 Ivan Voras writes: >> For about half a year I have another weirdness with time on my >> -current box without vmware, maybe it's somehow has common origins >> with your behaviour. When I boot FreeBSD, ntpdate (which is set up to >> run via rc.conf) often reports huge time offsets: >> 10 Jul 12:04:34 ntpdate[51761]: step time server ntp.server.name offset 234456.074166 sec >> >> I have so far only noticed that the value of the the offset is roughly >> equal to the amount of time when FreeBSD isn't running (this is a >> dual-boot box with windows). The box is pretty old, 600-MHz Celeron > > Is the above number correct (i.e. ~~ 65 hours)? Yes, sometimes my FreeBSD is not running for several days - in this case ntpdate prints such numbers. It looks like kernel stores date and time values somewhere and then re-reads them. I still don't rule out some stupidity on my part - the behaviour I'm observing is very illogic. Maybe I should try installing current from a fresh snapshot when it's released. > I noticed there can be a consistent "shift" of duration equal to > your timezone when VMWare sets the RTC to the host's local time and > FreeBSD thinks it's UTC. But if the difference is not constant, it's > not it. When I just reboot FreeBSD, offset doesn't exceed one or two seconds (notably, bios takes longer to boot, about 5-10 seconds). When BSD is inactive for several hours, number is much bigger. I neglected to debug this deeply before - I assumed I have overlooked something simple, but now that you have reported another issue in the similar area, I'll try to collect full information. -- WBR, Victor V. Snezhko E-mail: snezhko@indorsoft.ru From owner-freebsd-current@FreeBSD.ORG Tue Jul 10 08:51:51 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D7D1E16A469 for ; Tue, 10 Jul 2007 08:51:51 +0000 (UTC) (envelope-from ubm@u-boot-man.de) Received: from mail.upper.net (mail.upper.net [62.75.224.33]) by mx1.freebsd.org (Postfix) with ESMTP id 76E2D13C455 for ; Tue, 10 Jul 2007 08:51:51 +0000 (UTC) (envelope-from ubm@u-boot-man.de) Received: from ubm.mine.nu (p57AE3FD7.dip0.t-ipconnect.de [87.174.63.215]) (authenticated bits=0) by mail.upper.net (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l6A8poLw010749 for ; Tue, 10 Jul 2007 10:51:50 +0200 Date: Tue, 10 Jul 2007 10:57:48 +0200 From: Marc "UBM" Bocklet To: freebsd-current@freebsd.org Message-Id: <20070710105748.e8b697fa.ubm@u-boot-man.de> In-Reply-To: <200707050405.l6545vrO086595@repoman.freebsd.org> References: <200707050405.l6545vrO086595@repoman.freebsd.org> X-Mailer: Sylpheed 2.4.0 (GTK+ 2.10.12; i386-portbld-freebsd6.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: cvs commit: src/sys/dev/usb umass.c usbdevs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2007 08:51:51 -0000 On Thu, 5 Jul 2007 04:05:52 +0000 (UTC) Warner Losh wrote: > imp 2007-07-05 04:05:52 UTC > > FreeBSD src repository > > Modified files: > sys/dev/usb umass.c usbdevs > Log: > Add support for Western Digital MyBook external enclosures. They > need this quirk to work. > > Submitted by: Dierk Sacher > PR: usb/99419 > Approved by: re (blanket) > > Revision Changes Path > 1.159 +4 -0 src/sys/dev/usb/umass.c > 1.317 +6 -0 src/sys/dev/usb/usbdevs > _______________________________________________ > cvs-src@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/cvs-src > To unsubscribe, send any mail to "cvs-src-unsubscribe@freebsd.org" Thanks a lot! :-) For the record, this fixes the long wait (approx. 20min) before the drive inside the enclosure is detected by the scsi layer. Bye Marc From owner-freebsd-current@FreeBSD.ORG Tue Jul 10 09:20:49 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6815E16A421 for ; Tue, 10 Jul 2007 09:20:49 +0000 (UTC) (envelope-from shigeru@iij.ad.jp) Received: from otm-mgo00.iij.ad.jp (otm-mgo00.iij.ad.jp [210.138.20.174]) by mx1.freebsd.org (Postfix) with ESMTP id 1A5BC13C44C for ; Tue, 10 Jul 2007 09:20:48 +0000 (UTC) (envelope-from shigeru@iij.ad.jp) Received: OTM-MO(otm-mgo00) id l6A9Khqn000216; Tue, 10 Jul 2007 18:20:43 +0900 (JST) DKIM-Signature: v=0.5; a=rsa-sha1; c=relaxed/simple; d=iij.ad.jp; s=omgo0; t=1184059243; bh=aQb8HJkOwA/3h4mDdKTAMF4q0Qc=; h=Received:Received: Date:Message-Id:To:Cc:Subject:From:In-Reply-To:References:X-Mailer: Mime-Version:Content-Type:Content-Transfer-Encoding; b=h09T6FxI1om JXKnjQ7W+i19wHPTBXPhC698ZHAh930fMfVAB0x/M8yAyD9dwZ0Rwb+LX4lWCiOU39T bm02THDZDdnycvhYkTKxV99KV74NSFMWgP5vJY7kbvuZG0nFOaXKMR/ZzZQ4DHYPQv4 /z6XzBDUwEyrKr6AIvSkql7nrg= Received: OTM-MIX(otm-mix00) id l6A9KhVE036202; Tue, 10 Jul 2007 18:20:43 +0900 (JST) Received: from localhost (mercury.iij.ad.jp [192.168.184.90]) by rsmtp.iij.ad.jp (OTM-MR/rsmtp00) id l6A9KemF046884 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 10 Jul 2007 18:20:42 +0900 (JST) Date: Tue, 10 Jul 2007 18:20:40 +0900 (JST) Message-Id: <20070710.182040.184709560.shigeru@iij.ad.jp> To: d@delphij.net, delphij@delphij.net From: YAMAMOTO Shigeru In-Reply-To: <4691ECDC.8070500@delphij.net> References: <4691E8F0.8080005@micom.mng.net> <4691ECDC.8070500@delphij.net> X-Mailer: Mew version 5.2 on Emacs 22.0.99 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Tue_Jul_10_18_20_40_2007_382)--" Content-Transfer-Encoding: 7bit Cc: ganbold@micom.mng.net, freebsd-current@freebsd.org Subject: Re: today's buildworld breaks X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2007 09:20:49 -0000 ----Next_Part(Tue_Jul_10_18_20_40_2007_382)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, all. I think, it is better to add 'sed' to cross-tools. #because, 'sed' is required to 'make buildworld'. Thanks, ------- YAMAMOTO Shigeru ----Next_Part(Tue_Jul_10_18_20_40_2007_382)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Makefile.inc1.diff" Index: Makefile.inc1 =================================================================== RCS file: /share/cvsup/FreeBSD/current/usr/src/Makefile.inc1,v retrieving revision 1.582 diff -u -r1.582 Makefile.inc1 --- Makefile.inc1 26 May 2007 20:17:19 -0000 1.582 +++ Makefile.inc1 10 Jul 2007 07:54:18 -0000 @@ -967,6 +967,7 @@ .for _tool in \ gnu/usr.bin/binutils \ gnu/usr.bin/cc \ + usr.bin/sed \ usr.bin/xlint/lint1 usr.bin/xlint/lint2 usr.bin/xlint/xlint \ ${_btxld} \ ${_crunchide} \ ----Next_Part(Tue_Jul_10_18_20_40_2007_382)---- From owner-freebsd-current@FreeBSD.ORG Tue Jul 10 09:26:04 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 16FF516A41F for ; Tue, 10 Jul 2007 09:26:04 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [210.51.165.229]) by mx1.freebsd.org (Postfix) with ESMTP id BE04E13C45D for ; Tue, 10 Jul 2007 09:26:03 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from localhost (tarsier.geekcn.org [210.51.165.229]) by tarsier.geekcn.org (Postfix) with ESMTP id 04F05EB5923; Tue, 10 Jul 2007 17:26:03 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([210.51.165.229]) by localhost (mail.geekcn.org [210.51.165.229]) (amavisd-new, port 10024) with ESMTP id Dtzm3sjAhrnT; Tue, 10 Jul 2007 17:25:58 +0800 (CST) Received: from LI-Xins-MacBook.local (sina152-194.staff.sina.com.cn [61.135.152.194]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTP id 19B3EEB4630; Tue, 10 Jul 2007 17:25:58 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:cc:subject:references:in-reply-to: x-enigmail-version:openpgp:content-type; b=BW6eXOjJsLM+f/7zkV9sTge3YPDykzYNsC0OcoPfvY8mMIzOVhslOeAY06R6acjsa p01jlbeLnaNpckzq83xiw== Message-ID: <4693509B.3080107@delphij.net> Date: Tue, 10 Jul 2007 17:25:47 +0800 From: LI Xin Organization: The FreeBSD Project User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) MIME-Version: 1.0 To: YAMAMOTO Shigeru References: <4691E8F0.8080005@micom.mng.net> <4691ECDC.8070500@delphij.net> <20070710.182040.184709560.shigeru@iij.ad.jp> In-Reply-To: <20070710.182040.184709560.shigeru@iij.ad.jp> X-Enigmail-Version: 0.95.2 OpenPGP: url=http://www.delphij.net/delphij.asc Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enigFDF36C1C37CF54DE765C9DAC" Cc: ganbold@micom.mng.net, freebsd-current@freebsd.org, d@delphij.net Subject: Re: today's buildworld breaks X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2007 09:26:04 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigFDF36C1C37CF54DE765C9DAC Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable YAMAMOTO Shigeru wrote: > Hi, all. >=20 > I think, it is better to add 'sed' to cross-tools. > #because, 'sed' is required to 'make buildworld'. Sounds reasonable. I will discuss this with re@ and commit the patch if I got approval. Cheers, --=20 Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! --------------enigFDF36C1C37CF54DE765C9DAC 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.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGk1CbOfuToMruuMARCsxgAKCCW3UtEmlM0StOIiw6yYes+ZXJ8QCePrDi n/EKLGpNwyPUIU8uunjJtHc= =5jKJ -----END PGP SIGNATURE----- --------------enigFDF36C1C37CF54DE765C9DAC-- From owner-freebsd-current@FreeBSD.ORG Tue Jul 10 10:14:08 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B6D9D16A421; Tue, 10 Jul 2007 10:14:08 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by mx1.freebsd.org (Postfix) with ESMTP id 94B2613C468; Tue, 10 Jul 2007 10:14:07 +0000 (UTC) (envelope-from max@love2party.net) Received: from [88.66.11.242] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu8) with ESMTP (Nemesis), id 0ML31I-1I8CjN0wMX-0004BO; Tue, 10 Jul 2007 12:14:06 +0200 From: Max Laier Organization: FreeBSD To: freebsd-hackers@freebsd.org Date: Tue, 10 Jul 2007 12:16:26 +0200 User-Agent: KMail/1.9.7 X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGdu+2]; R]*pL,U>^H?)gW@49@wdJ`H<%}*_BD U_or=\mOZf764&nYj=JYbR1PW0ud>|!~, , CPC.1-D$FG@0h3#'5"k{V]a~. X-Provags-ID: V01U2FsdGVkX1+Qvb5GxdVV4c9EbPD/glyC5WGa/wvoEE+72xx qfmrwPpgS9nHoWuvWIyMRB81sBdini6aYZeujsZTN64C9yHIBu RM2cK7fd0e1l98wuYMLCAAV58Wc9LCe1vcZPNj2oo8= Cc: freebsd-current@freebsd.org Subject: FreeBSD Status Reports Q2/2007 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2007 10:14:08 -0000 --Boundary-00=_8x1kGLTmGz2Z4zJ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline --Boundary-00=_8x1kGLTmGz2Z4zJ Content-Type: text/plain; charset="us-ascii"; name="report-2007-04-2007-06.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline; filename="report-2007-04-2007-06.txt" =46reeBSD Quarterly Status Report Introduction This report covers FreeBSD related projects between April and June 2007. Again an exciting quarter for FreeBSD. In May we saw one of the biggest developers summits to date at BSDCan , our 25 Google Summer of Code students started working on their projects - progress reports are available below, and finally the 7.0 release cycle was started three weeks ago. If your are curious about what's new in FreeBSD 7.0 we suggest reading Ivan Voras' excellent summary at: http://ivoras.sharanet.org/freebsd/freebsd7.html and of course these reports. The next gathering of the BSD community will be at EuroBSDCon in Copenhagen , September 14-15. More details about the conference and the developer summit are available in the respective reports below. Thanks to all the reporters for the excellent work! We hope you enjoy reading. __________________________________________________________________ Google summer of code * A GUI audit analyzer for FreeBSD * Apple's MacBook on FreeBSD * BSD Bintools project * Distributed Logging Daemon * finstall * FreeBSD-update front end * Gvinum improvements * http support for PXE * Linuxulator update * lockmgr rewriting * mtund - Magic Tunnel Daemon * Multicast DNS and Service Discovery * Porting Linux KVM to FreeBSD * Porting OpenBSD's sysctl Hardware Sensors Framework to FreeBSD * Ports Collection infrastructure improvements * Security Regression Test * tarfs: A tar File System Projects * FreeBSD/xen * HDTV Drivers (ATSC) * Kernel contention reduction using mysql * Stack trace capture in PMCTools * TrustedBSD Audit * TrustedBSD MAC Framework * USB * USB update =46reeBSD Team Reports * Ports Collection * Problem Report Database * Release Engineering * Security Officer and Security Team * The FreeBSD Foundation Kernel * Fine grain thread locking * gvirstor * SCHED_SMP and SCHED_ULE * TrustedBSD priv(9) Network Infrastructure * 10Gigabit Network Support * FAST_IPSEC Upgrade * FreeBSD and Wake On Lan * Multi-link PPP daemon (MPD) * Multiprocessor Network Stack * Network Stack Virtualization * Wireless Networking Vendor / 3rd Party Software * FreeBSD and Coverity Prevent * FreeSBIE * OpenBSD packet filter - pf * PC-BSD Miscellaneous * EuroBSDcon 2007 * EuroBSDCon 2007 Developer Summit * libarchive/bsdtar * The Hungarian Documentation Project __________________________________________________________________ 10Gigabit Network Support Contact: Kip Macy Contact: Andrew Gallatin Contact: Jack Vogel Contact: Robert Watson Support was added for two more 10gigabit network drivers and there were major advances on improving system performance over 10g media. Kip Macy committed a new driver for the Chelsio adapters. The cxgb driver supports all current 10g adapters, as well as the new four-port gigabit model. The cxgb driver work was supported by Chelsio. Drew Gallatin made significant improvements to the Myricom 10g driver mxge. With these updates the driver does line rate transfers with less system overhead. Neterion contributed the nxge driver to support all their Xframe 10Gbe Server/Storage adapters. The initial driver import was done by Sam Leffler; a switch over to vendor support will happen soon. Jack Vogel is preparing a driver to support the latest Intel 10g hardware devices. The new driver - ixgbe - will complement the existing ixgb driver that supports older Intel 10g cards. Kip and Drew worked with other folks on performance analysis and tuning. This work improved cpu affinity and reduced overhead for managing network resources. Work is also underway to define a common Large Receive Offlaod (LRO) infrastructure. LRO is analogous to TSO on the receive side enabling drivers to receive at near line rate with normal sized frames. This common code base will help replace driver-specific code. __________________________________________________________________ A GUI audit analyzer for FreeBSD URL: Contact: Dongmei Liu This project is due to provide a GUI audit log analysis tool for FreeBSD. Refer to ethereal/wireshark packet parsing engine and its framework to view and parse audit logs. Open tasks: 1. Get a GUI framework using GTK2.0 include menu bar, toolbar, list view and tree view. 2. Parse and display audit log in the trailer file in the list view and tree view. 3. Online capture audit log and parse and display them in the list view and tree view 4. Add the filter mechanism 5. Add the statistic mechanism 6. Remote audit log analysis mechanism __________________________________________________________________ Apple's MacBook on FreeBSD URL: http://repoman.freebsd.org/depotTreeBrowser.cgi?FSPC=3D//depot/projects/s oc2007/rpaulo%2dmacbook/ URL: http://wiki.freebsd.org/AppleMacbook Contact: Rui Paulo Apple's MacBook computers are nicely designed and have neat features that other laptops don't. While Mac OS X is a nice operating system, UNIX folks (like me) would prefer to run other operating systems like FreeBSD. This project aims to bring bug fixes and new drivers to FreeBSD that would help running this OS on this platform. Open tasks: 1. Write drivers or fix issues for/with the touchpad, keyboard, remote control IR reciever, Bluetooth. 2. Fix reboot, halt, suspend/resume issues. __________________________________________________________________ BSD Bintools project URL: http://wiki.freebsd.org/BSDBintools Contact: Kai Wang A basic implementation of ar(1) (include ranlib) was finished and available in the perforce repository. Currently it provides all the main functions an ar(1) should have and it is based on the libarchive and libelf library thus is expected to have a better and simpler structure than the GPL'ed version. The work left in this part of the project is to perform a elaborate test and add additional functions. __________________________________________________________________ Distributed Logging Daemon URL: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=3D232192+0+/usr/local/www/db /text/2007/freebsd-hackers/20070527.freebsd-hackers URL: http://perforce.freebsd.org/depotTreeBrowser.cgi?FSPC=3D//depot/projects/ soc2007/karma%5faudit/dlog&HIDEDEL=3DNO Contact: Alexey Mikhailov Contact: Bjoern Zeeb The basic idea behind this project is to implement secure and reliable log file shipping to remote hosts. While the implementation focuses on audit logs, the goal is to build tools that will make it possible to perform distributed logging for any application by using a simple API and linking with a shared library. Open tasks: 1. Network protocol implementation 2. Spooling 3. SSL support __________________________________________________________________ EuroBSDcon 2007 URL: http://2007.EuroBSDCon.org/ Contact: EuroBSDCon 2007 Organizing Committee The sixth EuroBSDCon will take place at Symbion in Copenhagen, Denmark on Friday the 14th and Saturday 15th of September 2007. The programme is ready and online at the webpage. Registration is open. Details about tutorials and Legoland trip are ready too. The keynote will be John Hartman: Real men's pipes If you share a room with friends at the hostel, then lodging is really inexpensive, and the lounge has high speed Internet access. Staying at the hostel is of course optional, and the area has several hotels. KD85.com and O'Reilly will each have a booth at the conference. We are still looking for more sponsors. A public IRC channel #eurobsdcon on EFnet has been created for discussion and questions about the conference. __________________________________________________________________ EuroBSDCon 2007 Developer Summit URL: http://wiki.freebsd.org/200709DevSummit Contact: Poul-Henning Kamp The next developer summit will be different from the previous ones. Very different. Gone are the auditorium style seating, beamers, endless presentations and soggy sandwiches. Instead we head out to a an old village school in the beautiful Danish countryside, we hang around all over the place, sleep in the old science room, cook our own food and hack the living daylights out of anything we care for. September 17th and 18th, right after EuroBSDcon2007 in Copenhagen. (Well, right after the optional trip to legoland...) Be there! PS: Yes, it's not uncivilized, there is a full speed ADSL and WLAN. __________________________________________________________________ =46AST_IPSEC Upgrade Contact: George Neville-Neil Contact: Bjoern Zeeb FAST_IPSEC has now replaced Kame IPsec as the IPsec stack in HEAD. This will be part of the 7.0 release. The merge happened in early July with George handling the kernel bits and Bjoern handling user space. The kernel option IPSEC is now the ONLY option for IPsec support in the FreeBSD kernel. Open tasks: 1. Test test test!!!! __________________________________________________________________ =46ine grain thread locking Contact: Jeff Roberson Contact: Attilio Rao Contact: Kris Kennaway Over the past 6 months several developers undertook an effort to replace the global scheduler lock with a finer-grain interface modeled on the Solaris container lock approach. This significantly reduces contention on higher-end multiprocessor machines. This patch went into 7.0-CURRENT and has proven to be very stable. The last remaining bugs are in rusage and effect only process time accounting statistics. __________________________________________________________________ finstall URL: http://wiki.freebsd.org/finstall Contact: Ivan Voras Project "finstall" aims to create a next-generation FreeBSD installer that will make use of the newest features present in the system. The project should yield something usable for 7.0-RELEASE, but the intention is to keep it as a "second" installer system during 7.x, alongside sysinstall. In any case, sysinstall will be kept for architectures not supported by finstall (e.g. all except i386 and amd64). Open tasks: 1. The work is progressing well and on plan. There's a small setback currently with X11 applications executing of a read-only file system (at least that's the currently recognizable symptom). 2. Any interested testers are very much welcome! __________________________________________________________________ =46reeBSD and Coverity Prevent Contact: Pawel Jakub Dawidek Contact: David Maxwell FreeBSD's static analysis scans have been updated with a recent version of Coverity Prevent. Coverity is providing additional advice on configuration of the analysis to maximize the benefit from the tools. At BSDCan2007, Coverity provided FreeBSD with a license for an additional analysis tool called Extend, which allows writing custom FreeBSD specific code checkers. David Maxwell presented training material for interested FreeBSD developers. Some applications of custom checkers have been considered, and more results will be forthcoming as they are implemented and tested. __________________________________________________________________ =46reeBSD and Wake On Lan URL: http://stsp.name/wol/ URL: http://stsp.name/wol/README.txt URL: http://www.freebsd.org/cgi/query-pr.cgi?pr=3D83807&cat=3Dkern Contact: Stefan Sperling I have been working on making wake on lan (WOL) work with FreeBSD. Contrary to popular believe OS support is required for WOL to work properly. In particular network card drivers need to configure network cards for WOL during system shutdown, else the cards won't wake up. WOL is _not_ just a BIOS issue. This is work in progress. Currently the following cards/chipsets are supported: * NatSemi DP83815 (if_sis) * Via Rhine (if_vr, only VT6102 and up chips support WOL) * Nvidia nForce (if_nve, needs testing ) * 3Com Etherlink XL and Fast Etherlink XL (if_xl, needs testing , only 3c905B type adapters support WOL) I would be glad to get more feedback on my patch. I can add support for more chipsets but I need testers for hardware I don't have. I would appreciate access to data sheets for any NIC chipsets that are supported by FreeBSD and have WOL support. I would especially appreciate technical feedback on the patch, preferably by a committer who is willing to nitpick the patch to make it ready for inclusion in -CURRENT. I currently maintain the patch against RELENG_6_2 for my own use but I would port it to -CURRENT for inclusion. __________________________________________________________________ =46reeBSD-update front end URL: http://wiki.freebsd.org/FreeBSDUpdateFrontend Contact: Andrew Turner The project is split up with a front end to interact with the user and a back end to interact with freebsd-update. The back and front ends are able to communicate with each other using an XML protocol. The GUI is almost at the point it can take a command from the user and send it to the back end. The back end is able to detect when updates are ready. __________________________________________________________________ =46reeBSD/xen Contact: Rink Springer Work is well under way to finish Kip Macy's FreeBSD/xen port, and get it into a shape which is suitable for inclusion in 7.0. Generally, the port is stable and performs quite well. The major bottleneck is the inability to work with GCC 4.2, this is the last major TODO before the work can be committed. Open tasks: 1. Fix the port to correctly work with GCC 4.2. 2. Port the Xen drivers to newbus. 3. Test/fix PAE support. 4. Start on amd64 support. __________________________________________________________________ =46reeSBIE URL: http://www.freesbie.org URL: http://liste.gufi.org/mailman/listinfo/freesbie Contact: Matteo Riondato Contact: FreeSBIE Staff Contact: FreeSBIE ML After the success of FreeSBIE-2.0.1-RELEASE, development slew down a bit, but we have a big task for the summer: enable unionfs again and trying the new efficient memory filesystem, tmpfs. For all new ISO images we will be following RELENG_7, with the hope to release a stable image once 7.0-RELEASE have been released. Open tasks: 1. Build and test an ISO image with FreeSBIE+unionfs+tmpfs. __________________________________________________________________ Gvinum improvements URL: http://folk.ntnu.no/lulf/patches/freebsd/gvinum/soc2007 URL: http://blogs.freebsdish.org/lulf/ URL: http://wiki.freebsd.org/UlfLilleengen/SOC Contact: Ulf Lilleengen My previous status reports contained a lot of code that updated gvinum with the old vinum features. This year gvinum has been significantly rewritten. Lukas Ertl began rewriting the way gvinum is organized from using a multi consumer/provider model, to use a single consumer and provider, and having an event-system that first handles user-requests, and then runs normal I/O operations (Much like other GEOM classes). This makes the code easier to read, and perhaps there will be less bugs :) 1. setstate on plexes and volumes. 2. attach/detach command now works. 3. concat/stripe/mirror commands. The previous code conflicted more than I expected with the new gvinum system, but it should work now. 4. (Mounted) rebuilds possible. 5. (Mounted) sync possible. 6. Some refactoring of old code (Basically updating old code to use the new event system, and add some abstractions where possible) And of course, some time has gone to work out how things should be done, and to fix other bugs. I hope some of you are interested in trying this out (all the work has been in perforce so far), a patch can be found in the URL section. . This is a bit experimental, and although I've done much testing to hunt down bugs, there are most probably bugs left. I have other goals this summer as well. However, since some parts of gvinum was rewritten, I might not be able to do all of these, but growing is already working for the concatenated volumes (and also mirrored). I'd also like to implement growing for Raid5 arrays as well. Logging plexes would also be cool to have, but this is not really needed, since we have g_journal. Both these features will be addressed after I've made sure gvinum does all old vinum does, and also perhaps better. As I might have some extra time on my hands this summer, so I gladly accept suggestions on what else I might fix or implement "while I'm at it". Open tasks: 1. Stability, stability, stability. I want gvinum to work really well. To accomplish that I have several test-machines I'm going to do different tests on. I sort of have a little test-plan in the working that I'll be using. 2. A gvinumadmin tool that would make gvinum easier to use for unexperienced users. Perhaps integrate this into the installer. This is now probably something I'll do at the end, when hopefully everything works :) I might poke Ivan Voras a bit on this. 3. Documenting gvinum and it's differences to vinum better. I take notes on where I need to document, so this is in progress. 4. Implementing growing and shrinking of volumes. 5. Implement logging plexes. Log all parity data being written. __________________________________________________________________ gvirstor URL: http://wiki.freebsd.org/gvirstor Contact: Ivan Voras Gvirstor is a GEOM class which provides virtual storage capacity (something like virtual memory for storage devices). It's ready to be committed to HEAD (the plan is for it to get into 7.0-RELEASE). Open tasks: 1. Any interested testers are welcome! __________________________________________________________________ HDTV Drivers (ATSC) URL: http://perforce.freebsd.org/fileSearch.cgi?FSPC=3D%2F%2Fdepot%2Fuser%2Fjm g%2Fbktrau%2F...&ignore=3DGO%21 URL: http://perforce.freebsd.org/fileSearch.cgi?FSPC=3D%2F%2Fdepot%2Fuser%2Fjm g%2Fcxd%2F...&ignore=3DGO%21 Contact: John-Mark Gurney This entry was previously the Bt878 Audio Driver (aka FusionHDTV 5 Lite driver) announcement, but as work expanded slightly, it's a bit more generic now. A few bugs in bktrau has been fixed since January. If you have been running an earlier version, it is recommended to upgrade as the driver could panic. The driver works with multiple cards in the same machine (tested with two). FusionHDTV 5 Lite -- Due to lack of documentation from DViCO and LG, I have copied magic values from the Linux driver to get ATSC capturing working. ATI HDTV Wonder -- After years of trying to get into the ATI developer program, they have finally suspended it, so no support from ATI. I have started work on a driver, cxd, for the Conexant CX2388x based cards. The ATI HDTV Wonder uses ATI's own demodulator, and I was able to get it to tune, after cribbing from the Linux driver. When capturning, I get some valid data, but not all the data. Due to lack of support from ATI and linux-dvb the project has been put on indefinate hold. If someone has another CX2388x based card, it shouldn't be too hard to take the driver and get it working with a different tuner. A Python module is available for both drivers/cards, along w/ a sample capture application using it. The module is now known to work well with threads so that tuning (expensive due to i2c ioctl's) can happen in another thread without causing program slow down. The module is working well with a custom PVR backend. Open tasks: 1. Provide support for NTSC and FM tuning. 2. Add support for other cards and tuners that use the Bt878 chip. 3. Add support for other cards and tuners that use the CX2388x chip. __________________________________________________________________ http support for PXE URL: http://perforce.freebsd.org/depotTreeBrowser.cgi?FSPC=3D//depot/projects/ soc2007/taleks-pxe_http URL: http://wiki.freebsd.org/http_support_for_PXE Contact: Alexey Tarasov Main goal of project is to introduce code working in PXE preboot environment, able to download from web server via direct connection or http proxy and prepare booting of FreeBSD kernel. Already implemented, but haven't thoroughly tested: PXE wrappers core code, ARP, ICMP echo request/reply, sockets code similar to common sockets (UDP and TCP modules). On base of sockets: simple DHCP client, DNS client. Currently working on http client, TCP testing, kernel booting and documenting main concepts of project modules. Open tasks: 1. Testing PXE API related code in different PXE implementations. 2. Testing of implemented protocols. __________________________________________________________________ Kernel contention reduction using mysql URL: http://jeffr-tech.livejournal.com/ Contact: Jeff Roberson FreeBSD developers have been using mysql as a testbed to find kernel contention hotspots in the kernel. As a result of this we have seen a 5x performance improvement over 6.0 on 8way machines. Recent changes include finer locking in fcntl(), removing Giant from flock and fcntl F_SETLK. These changes will be available in 7.0 and primarily improve write performance. Experimental changes to select() have also been discussed on arch@ that solve contention issues there however these will not be ready in the 7.0 timeframe. __________________________________________________________________ libarchive/bsdtar URL: http://people.freebsd.org/~kientzle/libarchive/ Contact: Tim Kientzle Contact: Colin Percival Both libarchive 2 and bsdtar 2 are now in -CURRENT and will be in 7.0. Libarchive 1.9 and bsdtar 1.9 should be in 6-STABLE in time for 6.3. libarchive 2 is much faster writing to disk than libarchive 1. It also supports new formats, has several minor API/ABI corrections, is more portable, and has many fewer bugs. Of special note is "libarchive_test", a new program that exercises much of the libarchive functionality; anyone interested in working on libarchive should become familiar with this test suite. bsdtar 2 is less ambitious, but does have a number of bug fixes and takes advantage of several new features in libarchive 2. libarchive 1.9 is identical to libarchive 2 except it maintains the old API/ABI. Similarly, bsdtar 1.9 is nearly identical to bsdtar 2, lacking only a few features that would prevent it from being used with existing libarchive 1 libraries. Open tasks: 1. Tim Kientzle has started work on a libarchive-based cpio implementation that should be ready for inclusion with FreeBSD 8. 2. Volunteer needed: We want a libarchive-based pax to replace our out-of-date pax implementation. 3. Volunteer needed: pkg_add should use libarchive instead of forking an external tar; this could eventually make it much faster. 4. Volunteer(s) needed: libarchive should write more cpio variants (easy); libarchive should read and write mtree format (not difficult); libarchive should write GNUtar 1.0 format sparse tar entries (tricky); bsdtar should support --metadata=3D to read names and properties from one archive, with data from disk, to create a new archive (mtree support in libarchive would make this very useful); bsdtar should preserve sparseness when creating archives. __________________________________________________________________ Linuxulator update URL: http://wiki.freebsd.org/linux-soc2007 Contact: Roman Divacky Contact: Konstantin Belousov Just like last year I got the opportunity to work on updating the Linuxulator to Linux version 2.6. This year I work on finishing futexes, *at syscalls and epoll/inotify. I, cooperating with Konstantin Belousov, have managed to fix futexes to the state of passing the official futex testing program. The fix was committed and 7.0R will ship with correct futex implementation. Work is planned on removing Giant locking from futexes. This only needs some carefull review and testing. These days I mostly focus on *at syscalls, the patch is almost finished for commiting and I hope that it will make it into 7.0R. As a part of this work I implemented native FreeBSD syscalls as well. Watch arch mailing list as I post the patch there. I also finished writing my master thesis describing how the Linuxulator works and Gabor Kovesdan is working on integrating it into official FreeBSD articles. No work has happened in the epoll/inotify area but I hope to work on it right after I finish the *at syscalls.h Open tasks: 1. Finishing *at syscalls. 2. Start the epoll/inotify work. 3. Finish removal of Giant from futexes. __________________________________________________________________ lockmgr rewriting URL: http://wiki.freebsd.org/AttilioRao Contact: Attilio Rao Contact: Jeff Roberson The project consists in a rewriting of the lockmgr(9) interface on a lighter basis, using atomic instructions and direct usage of the sleepqueue interface. This should lead to a faster primitive, a saner interface and an higher maintainability of the code. So far, 3 newly files called kern/kern_lockng.c, sys/_lockmgrng.h and sys/lockmgrng.h have been created for the new primitive and an initial implementation has been committed into the perforce branch: //depot/user/attilio/attilio_lockmgr/... The implementation contains a good set of code intended to replace old lockmgr. Actually it only misses the support for lock draining that will be committed after an initial phase of testing and the inclusion of a better wake-up algorithm (which will simplify draining a lot and will improve performance on wakeup). Open tasks: 1. Need some testing __________________________________________________________________ mtund - Magic Tunnel Daemon URL: http://wiki.freebsd.org/SuperTunnelDaemon Contact: Matus Harvan IP can easily be tunneled over a plethora of network protocols at various layers, such as IP, ICMP, UDP, TCP, DNS, HTTP, SSH. While a direct connection may not always be possible due to a firewall, the IP packets could be encapsulated as payload in other protocols, which would get through. However, each such encapsulation requires the setup of a different program and the user has to manually probe different encapsulations to find out which of them works in a given environment. mtund is a tunneling daemon using run-time loadable plugins for the different encapsulations. It automagically selects the best encapsulation in each environment and fails over to another encapsulation in case the environment changes. There already is running code available, capable of tunneling via TCP and UDP with a working failover mechanism. As this is a Summer of Code project, rapid changes and addition of new features can be expected during the summer. Please see the wiki page for more details and up-to-date information. Note that the project originally started under the name of Super Tunnel Daemon, but was later renamed to mtund for Magic Tunnel Daemon. Open tasks: 1. I am always happy to hear from others trying out the code and providing feedback, both positive and negative. __________________________________________________________________ Multi-link PPP daemon (MPD) URL: http://sourceforge.net/projects/mpd/ URL: http://mpd.sourceforge.net/doc/mpd5.html Contact: Alexander Motin Mpd-4.2 has been released. It includes many new features, performance improvements and fixes. The most significant and unique new feature is a link repeater functionality. It allows mpd to accept incoming connection of any supported type and forward it out as same or different type outgoing connection. As example, this functionality allows mpd to implement real LAC with accepting incoming PPPoE connection from client and forwarding it using L2TP tunnel to LNS. All other software L2TP implementations I know is only a LAC emulators without real incoming calls forwarding abilities. Also mpd-4.2 presents: * PPTP listening on multiple different IPs, * L2TP tunnel authentication with shared secret, * fast traffic filtering, shaping and rate-limiting using ng_bpf and ng_car, * new 'ext-auth' auth backend as full-featured local alternative to 'radius-auth', * NetFlow generation for both incoming and outgoing packets same time. Replacing external ifconfig and route calls with their internal implementations and other optimizations in 4.2 gave significant performance boost in session management. Newly implemented overload protection mechanism partially drops incoming connection requests for periods of critical load by monitoring daemon's internal message queue. As result, simple 2GHz P4 system is now able to accept, authenticate and completely process spike of 1000 concurrent PPPoE connections in just a 30 seconds. Open tasks: 1. Implement dynamic link/bundle creation. 2. Auth proxying support in repeater mode. It is required for some LAC/PAC and Tunnel Switching Aggregator (TSA) setups. 3. Remove static phys - link - bundle and phys - repeater relations. Implement ability to differentiate incoming connections processing depending on user login, domain and/or other parameters. __________________________________________________________________ Multicast DNS and Service Discovery URL: http://wiki.freebsd.org/MulticastDNS Contact: Fredrik Lindberg This project aims to create a multicast DNS daemon and service discovery utilities suitable for the base system. Multicast DNS is a part of Zero Configuration Networking (Zeroconf) and provides the ability to address hosts using DNS-like names without the need of an existing (unicast), managed DNS server. Work on the responder daemon is well underway and the only large missing piece of the puzzle is a way for local clients to do queries. The code can be found in the p4 branch projects/soc2007/fli-mdns_sd if anyone would like to give it a spin, even though it's incomplete. The project plan can be found on the wiki. __________________________________________________________________ Multiprocessor Network Stack URL: http://www.FreeBSD.org/projects/netperf/ Contact: Robert Watson Contact: The custom file descriptor array lock has been replaced with an optimized sx lock, resulting in 2x-4x improvement in MySQL transaction rates on 8-core MySQL benchmarks. This improvement is due to moving to shared locking for frequent fd lookup operations, as well as significant optimization of the case where the filedesc lock is highly contended (as occurs in the threaded MySQL server performing constant socket I/O). The custom socket buffer I/O serialization lock (sblock), previously created by interlocking SB_WANT and SB_LOCK flags with the socket buffer mutex, has been replaced with an optimized sx lock, leading to a 10% performance improvement in MySQL and PostgreSQL benchmarks on 8-core systems. As part of this change, sx locks now have interruptible sleep primitives to allow the SB_NOINTR flag to work properly. These changes also correct a long-standing bug in socket buffer lock contention and SB_NOWAIT reported by Isilon; a simpler patch has been merged to 6.x to fix this bug without merging loocking changes. TCP debugging is now properly synchronized using a new tcp_debug_mtx. UMA allocation counters are now used for pipes rather than custom atomic counters, resulting in lowered overhead for pipe allocation and free. Significant code cleanup, commenting, and in some cases MFC'ing, has taken place with respect to the network stack and synchronization. Additional DDB debugging commands for sockets of various sorts have been added, allowing listing of socket state from DDB without the use of GDB. Certain non-MPSAFE subsystems have been removed or will be removed from FreeBSD 7.0, including IPX over IP tunneling (not general IPX/SPX support, just the tunneling over IP), KAME IPSEC (FAST_IPSEC is MPSAFE and now now supports IPv6), i4b, netatm (two other ATM stacks are still present), and ng_h4. Some of these features will be reintroduced in FreeBSD 7.1, but by removing them now, we are able to remove the NET_NEEDS_GIANT compatibility infrastructure that significant complicates and obfuscates the socket and network stack code. Other measurement and optimization projects continue; however, the 7.0 locking/synchronization work for the network stack is essentially complete. Open tasks: 1. New work to parallelize the netisr thread (netisr2) as well as distribute UDP and TCP processing over multiple CPUs by connection, rather than just by input source as in 7.0, was presented at BSDCan. This work will be targeted at the 8-CURRENT branch. 2. Complete netatm and NET_NEEDS_GIANT removal for 7.0. 3. Complete MPSAFE locking of mld6 and nd6 IPv6 subsystems, which currently run under a global lock. __________________________________________________________________ Network Stack Virtualization URL: http://imunes.tel.fer.hr/virtnet/ Contact: Marko Zec The network stack virtualization project aims at extending the FreeBSD kernel to maintain multiple independent instances of networking state. This will allow for complete networking independence between jails on a system, including giving each jail its own firewall, virtual network interfaces, rate limiting, routing tables, and IPSEC configuration. I believe that the prototype, which is kept in sync with FreeBSD -CURRENT, is now sufficiently stable for testing. It virtualizes the basic INET and INET6 kernel structures and subsystems, including IPFW and PF firewalls, and more. In the next month I plan to have the IPSEC code fully virtualized, and refine and document the management APIs. The short-term goal is to deliver production-grade kernel support for virtualized networking for FreeBSD 7.0-RELEASE (as a snap-in kernel replacement), while continuing to keep the code in sync with -CURRENT for possible merging at a later date. __________________________________________________________________ OpenBSD packet filter - pf Contact: Max Laier pf in HEAD (soon to be FreeBSD 7.0) has been updated to OpenBSD 4.1 bringing in a couple of new features: * ftp-proxy has been rewritten, and a tftp version, tftp-proxy, has been added * pf(4) now supports Unicast Reverse Path Forwarding (uRPF) checks for simplified ingress filtering * The pflog(4) interface is now clonable. pf(4) can log to multiple pflog interfaces now, each rule can specify which pflog interface to log to * pflogd(8) can now be told which pflog interface to work with * pfctl(8) can now expire table entries * keep state is now the default for pf.conf(5) rules, as is the flags S/SA option on TCP connections. no state and flags any can be used to disable stateful filtering or TCP flags checking * The pfctl(8) ruleset optimiser can be enabled in pf.conf(5) * pf(4) anchors can now be loaded inline in the main pf.conf(5) and can be printed recursively * Allow pf(4) rules inside anchors to have their counters reset, and make counter read & reset an atomic operation Some patches that went into OpenBSD after 4.1 and improve performance significantly will be merged later. Work to support pf and netgraph interaction is underway and will be imported after 7.0. As all required ABI changes have been made during the update, we will be able to MFC this work for 7.1 later on. __________________________________________________________________ PC-BSD URL: http://www.pcbsd.org/ Contact: Kris Moore The last major updates are currently being made to PC-BSD 1.4, which will include KDE 3.5.7, Beryl, Flash, Intel Wireless, Nvidia Drivers and more! This release will also include new utilities to make running PC-BSD on the desktop easier than ever, including: * Network Manager with WIFI Support * Add / Remove Components * Firewall Manager for PF * Xorg Display setup wizard Once any final major issues are resolved, we will be issuing a public beta of PC-BSD 1.4 to ensure compatibility across a variety of platforms. __________________________________________________________________ Porting Linux KVM to FreeBSD URL: http://wiki.freebsd.org/FabioChecconi/PortingLinuxKVMToFreeBSD Contact: Fabio Checconi Contact: Luigi Rizzo The Linux kernel-based Virtual Machine (KVM) is a mechanism to exploit the virtualization extensions present in some modern CPUs (e.g., Intel VT and AMD-V). Virtualization extensions let ordinary processes execute a subset of privileged instructions in a controlled way at near-native speed. This in turn may improve the performance of system emulators such as qemu, xen, vmware, vkernel, User Mode Linux (UML), etc. This project consists in porting to FreeBSD the Linux KVM, implemented as a loadable module, lkvm.ko. We use the approach in ports/devel/linux-kmod-compat to reuse the original Linux source code almost unmodified. We will also port a modified version of qemu which exploits the facilities made available by the Linux KVM to speed up emulation. The URL above links to progress report detailing the exact project goals, milestones reached, and commit log details. As of end of June 2007, we have mainly extended linux-kmod-compat to support the kernel API used by the Linux KVM code. The required functions have been implemented at various degrees, from simple stubs to fully functional ones. We have also imported the modified qemu and the libraries that are used to build the Linux KVM userspace client. In the second half of the SoC work we plan to complete the implementation of the kernel API and have a fully functional Linux KVM module, together with its client (qemu). __________________________________________________________________ Porting OpenBSD's sysctl Hardware Sensors Framework to FreeBSD URL: http://mojo.ru/us/GSoC2007.FreeBSD.cnst-sensors.proposal.html URL: http://cnst.livejournal.com/tag/GSoC2007 URL: http://cnst.livejournal.com/data/atom?tag=3DGSoC2007 URL: http://perforce.freebsd.org/depotTreeBrowser.cgi?FSPC=3D//depot/projects/ soc2007/cnst-sensors/ Contact: Constantine A. Murenin Contact: Shteryana Shopova OpenBSD includes sysctl hw.sensors framework since 2003; since 2005 the frameworks supports raid drives and most known i2c sensors; since 2006 the framework is redesigned with a sensor device concept in mind to accommodate continued growth. Consists of kernel api, sysctl(3)/sysctl(8), sensorsd(8), ntpd(8), systat(1), ports/sysutils/symon and 51 drivers as of 2007-07-07. This GSoC2007 project is to port the underpinnings of this unified hardware monitoring interface to FreeBSD. Whilst it won't be possible to port all of the drivers due to architecture differences, we aim at porting all other parts of the framework and accompanying userland utilities. At this time, lm(4) at isa and some kernel api have already been ported. The next big step is to complete sysctl(3) glue code so that further work on porting userland utilities could be accomplished. Details about sysctl are being discussed on arch@. Open tasks: 1. sysctl(3) glue code __________________________________________________________________ Ports Collection URL: http://www.freebsd.org/ports/ URL: http://www.freebsd.org/doc/en_US.ISO8859-1/articles/contributing-ports/ URL: http://people.freebsd.org/~fenner/portsurvey/ URL: http://portsmon.FreeBSD.org/index.html URL: http://www.freebsd.org/portmgr/index.html URL: http://tinderbox.marcuscom.com Contact: Mark Linimon The ports count is over 17,300. The PR count has been stable at around 800; we have not quite cleared up the backlog that showed up during the freeze to import xorg7.2. There have been 4 experimental runs on the build cluster, most notably resulting in some speedups for package registration. A further experimental run to genericize autotools handling is in progress. One of the most sweeping ports commits to happen in years was the upgrade of xorg from 6.9 to 7.2. This involved a complete rework of the internals of the port, as X.org itself has effectively pushed the responsibility for packaging to the OSes that incorporate it. The idea was to be able for them to update individual code (such as video drivers) without having to reroll the entire distribution. This commit caused us to have the longest period of preparation work, and actual tree lockdown, that I am aware of. The commit continues to be controversial, partly due to the fact that none of our port upgrade tools was up to the task of doing the upgrade without manual intervention. At the same time that xorg was upgraded, we moved the installation directory from the obsolete /usr/X11R6 to our default /usr/local. This further complicated the upgrade. There have been new releases of the ports tinderbox code, the portmaster update utility, and portupgrade. GNOME was updated to 2.18.2. We have added 7 new committers since the last report. We appreciate all the new help. However, a few committers have turned in their commit bits for safekeeping, due to lack of time. Unfortunately, Clement Laforet has also had to step down from portmgr due to lack of time. We thank him for his help so far. Erwin, Kris and Mark met up at BSDCan and reviewed all the portmgr-owned PRs. A large number were closed, or suspended pending more work from the submitter. After closing the PRs that were committed after the -exp builds, the number of portmgr owned PRs came down to an all time low of 48 from around 70. We hope to make further progress during the rest of the year. Open tasks: 1. gcc4.2 has been imported to the base for 7.0. Unfortunately, this breaks a large number of ports. We need committer and maintainer help to get these in good shape for the release. 2. Most of the remaining ports PRs are "existing port/PR assigned to committer". Although the maintainer-timeout policy is helping to keep the backlog down, we are going to need to do more to get the ports in the shape they really need to be in. 3. Although we have added many maintainers, we still have many unmaintained ports. The packages on amd64 are lagging behind a bit; those on sparc64 require even more work. __________________________________________________________________ Ports Collection infrastructure improvements URL: http://wiki.freebsd.org/G%C3%A1borSoC2007 Contact: G=E1bor K=F6vesd=E1n Contact: Andrew Pantyukhin G=E1bor K=F6vesd=E1n is working on some improvements for the Ports Colle= ction infrastructure. This year, he aimed to work on long-standing issues, which are tracked in GNATS, but we have not had a volunteer for recently. With the mentorship of Andrew Pantyukhin, he is also reimplementing the DESTDIR support for Ports Collection in a more practical way. The complete description and status of this project is available on G=E1bor's SoC 2007 Wiki page. Open tasks: 1. Please see the Wiki page for the current status. __________________________________________________________________ Problem Report Database URL: http://www.freebsd.org/support.html#gnats URL: http://people.freebsd.org/~bsd/prstats/ Contact: Mark Linimon Gavin Atkinson has joined the bugbuster team via getting a GNATS account on the FreeBSD cluster. He is following in the footsteps of Matteo Riondato, who later graduated to a full src commit bit. So far, he has helped close nearly 150 PRs, including many that had become stale. Welcome! Our short-term goal is to try to identify bugs that we might be easily able to fix before the 6.3/7.0 simultaneous release. So far, great progress has been made on ata- and usb-related PRs. The goal for the rest of this year is to generate more developer interest in fixing bugs. To do this, we are, first, trying to do more work on triaging PRs as they come in, to help flag ones that seem to be valid problems (especially if they include patches.) Secondly, we have started a new weekly periodic posting to the freebsd-bugbusters@FreeBSD.org mailing list, which is a short list of PRs that we feel are ready for committer action. This posting is automatically generated from a text-file list that we maintain. We are continuing to try to manage our community's expectations of what we can do with the incoming PRs. In particular, we are trying to discourage submissions of the form "I cannot get the XYZ function to work". In practice, these PRs are not worked on. Instead, we are now encouraging these postings to go to one of the mailing lists such as freebsd-questions@, freebsd-x11@, and so forth. The idea is to emphasize GNATS as a "Problem Report" method, rather than a "general FreeBSD support" method. I feel that, otherwise, we were creating a false expectation. The overall PR count has dropped to below 5000, despite the extra PRs still not cleared up from the ports freeze for the xorg7.2 import. Significant progress has been made on the i386, kern, and bin PRs, as well as PRs in the 'feedback' state. In addition, Warner Losh has made progress on closing many of the usb PRs. Open tasks: 1. Please join us on the freebsd-bugbusters@ mailing list, or on #freebsd-bugbusters on EFNet, to help us triage PRs as they come in and also help us to work through the backlog, and help us to try to create a bugbusting "community". __________________________________________________________________ Release Engineering URL: http://www.FreeBSD.org/releng/ URL: http://www.FreeBSD.org/snapshots/ Contact: Release Engineering Team Code freeze in preparation for FreeBSD 7.0 began on June 18th. There are several large projects still being finished up as well as some issues that resulted as "fallout" from the work done just before the code freeze started (e.g. things resulting from the GCC 4.2 import). A schedule for the 7.0 release has not been set yet but the hope is that the first BETA build will be done near the end of July with a "fairly normal" release cycle (a few BETA builds followed by two or three RCs, each separated by around two weeks). We are planning to release FreeBSD 6.3 around the same time as FreeBSD 7.0 is released so the release schedule for that will be set at the same point we set the release cycle for 7.0, hopefully late in July. __________________________________________________________________ SCHED_SMP and SCHED_ULE URL: http://jeffr-tech.livejournal.com/ Contact: Jeff Roberson SCHED_SMP is a fork of the ULE scheduler which makes use of the new fine grain scheduler locking in 7.0-CURRENT to significantly improve SMP performance on some workloads. It has improved and stronger affinity, smarter CPU load balancing, structural improvements and many sysctl tunables. This can be considered ULE 3.0. Discussions are ongoing as to whether this will go into 7.0 as SCHED_SMP or as SCHED_ULE in 7.0 or 7.1. SCHED_ULE has had many bugfixes and performance improvements over the 7.0 development cycle and should no longer be considered unstable or experimental. On most workloads it significantly outperforms SCHED_4BSD on SMP and even slightly outperforms it on UP. There are some pathlogical workloads which exhibit as much as a 5% performance penalty. Many thanks to Kris Kennaway and current users for bug reports and performance testing. __________________________________________________________________ Security Officer and Security Team URL: http://www.freebsd.org/security/ URL: http://www.freebsd.org/doc/en_US.ISO8859-1/articles/contributors/staff- listing.html#STAFF-SECTEAM URL: http://vuxml.freebsd.org/ Contact: Security Officer Contact: Security Team In the time since the last status report, two security advisories have been issued concerning problems in the base system of FreeBSD; both of these problems were in "contributed" code maintained outside of FreeBSD. The FreeBSD Vulnerabilities and Exposures Markup Language (VuXML) document has continued to be updated; since the last status report, 35 new entries have been added, bringing the total up to 925. In order to improve handling of security issues in the FreeBSD Ports Collection a new "ports-security" team has been created to include ports committers who periodically help with fixing ports security issues and documenting them in the FreeBSD VuXML document. Committers who wish to help with this effort can contact simon@ for details. The following FreeBSD releases are supported by the FreeBSD Security Team: FreeBSD 5.5, FreeBSD 6.1, and FreeBSD 6.2. The respective End of Life dates of supported releases are listed on the web site; it is expected that of the upcoming releases, FreeBSD 6.3 will be supported for two years after release, while FreeBSD 7.0 will be supported for one year after release. __________________________________________________________________ Security Regression Test URL: http://perforce.freebsd.org/depotTreeBrowser.cgi?FSPC=3D//depot/projects/ soc2007/zhouzhouyi%5fmactest%5fsoc Contact: Zhouyi Zhou Contact: Robert Watson Security Regression Test is supported by the project of Google summer code 2007. The main objective of this stage is to test the correctness of FreeBSD Mandatory Access Control Framework including correctly passing the security label from userland to kernel and non-bypassibility of Mandatory Access Control Hooks. Work performed in the last month: 1. Constructed a pair of pseudo ethernet drivers used for testing network related hooks. To avoid the packet go through the lo interface, the IP address in the packet is twisted in the driver. 2. Constructed a framework for logging Mandatory Access Control hooks which is got called during a period of time. + In kernel, every non-null label is got externalized into human readable string and recorded in a tail queue together with the name of hook that got called and possible flags or modes (etc. VREAD/VWRITE for mac_check_vnode_open hook). There is a thread much like audit subsystem's audit_worker logging the queue into a userspace file. The userland program use open, ioctl and close the /dev/mactest node to trigger and stop the logging. The logging file is truncated to zero every time the logging mechanism is triggered. + In userland, a bison based parsing tool is used to parse the logged file and reconstruct the record chain which will be compared with testsuite supplied configuration file to examine if expected hooks is got called and the label/flags/modes are correct. c) The testsuite mainly follows src/tools/regression/fstest, modified to adapt to test Mandatory Access Control Framework and include tests for signals Open tasks: 1. The code is quick and dirty. For example, a call to vn_open without checking its return value which is not fault tolerance. The coding style also needs modifications. 2. Although a test framework is completely constructed, the detailed test cases still need to be written, the test cases beside fstest and signal need to be add. 3. Testing of audit subsystem has not begin. 4. Other parts of Security Subsystem in FreeBSD also need concern. __________________________________________________________________ Stack trace capture in PMCTools URL: http://wiki.freebsd.org/PmcTools Contact: Joseph Koshy The kernel/hwpmc(4) bits of stack trace capture have been implemented and are available in Perforce under path '//depot/user/jkoshy/projects/pmc/...'. I'm currently enhancing pmcstat(8) to extract and summarize this information. Support by Google Inc. for this project is thankfully acknowledged. __________________________________________________________________ tarfs: A tar File System URL: http://www.googlebit.com/doku.php?id=3Dtarfs Contact: Eric Anderson Tarfs is a simple tar file system implementation for FreeBSD. The current goals are: * Support all standard read-only operations * Support large tar files (several gb's) * Use minimal memory * Allow using tar file as a root file system * Fast enough to actually use Here's the current state of things: * Can mount most tar files * Can do most operations (open,lookup,stat,readdir,etc) * Supports large tar files (tested up to 2GB) * Uses a relatively small amount of memory - proportional to number of files/dirs Open tasks: 1. No `..' directory in root of mounted tar file system 2. Locking issues regarding `..' in subdirs off root of fs 3. No block/char special device support. Needed? 4. Needs a directory hashing method 5. More testing needed. __________________________________________________________________ The FreeBSD Foundation URL: http://www.freebsdfoundation.org Contact: Deb Goodkin The FreeBSD Foundation ended Q2 raising over $116,000. We're almost half way to our goal of raising $250,000 this year! We continued our mission of supporting developer communication by helping FreeBSD developers attend BSDCan. We were also a sponsor of BSDCan and the developer summit. We are a sponsor of EuroBSDCon 2007 and are now accepting travel grant applications for this conference. Foundation board members met with representatives of companies that use or are thinking of using FreeBSD both in the bay area and Ottawa. The Foundation has negotiated a joint development agreement with Google, Inc. to sponsor FreeBSD developer Joseph Koshy to improve FreeBSD's HWPMC implementation, including adding stacktrace support, and a donation of SMP hardware for future SMP scalability work. We greatly appreciate Google's support for this project, which will facilitate performance measurement and optimization of both the FreeBSD operating system and applications running on it. To learn more about what we're doing, go to our website at http://www.FreeBSDFoundation.org/ . Our July newsletter will be published soon to update you on how we've been supporting the project and community worldwide. __________________________________________________________________ The Hungarian Documentation Project URL: http://www.freebsd.org/hu/docproj/hungarian.html URL: http://www.freebsd.org/hu/ URL: http://www.freebsd.org/doc/hu_HU.ISO8859-2/articles/linux-comparison/ Contact: G=E1bor K=F6vesd=E1n We have added one translated article since the last status report about this project. The infrastructure is ready to support localized articles and books as well, we just lack of human resource. New volunteers are highly welcome! Please see the link below and contact G=E1bor if you are interested. Open tasks: 1. Translate more articles and books. __________________________________________________________________ TrustedBSD Audit URL: http://www.TrustedBSD.org/audit.html Contact: Robert Watson Contact: Christian Peron Contact: General cleanups in preparation for 7.0. Process audit state moved to the credential to allow it to be accessed lock-free in most cases, as well as allowing it to be used in asynchronous contexts. OpenBSM 1.0a14 has been imported, which: fixes IPv6 endian issues, makes OpenBSM gcc41 warnings clean, teaches audit_submit(3) about getaudit_addr(), adds zonename tokens; other changes since the existing CVS 1.0a12 release previously imported include man page improvements, XML printing support, better audit.log.5 documentation, additional 64-bit token types, and new audit event identifiers. MAC checks have been added so that MAC policies can control use of audit system calls. Additional system call arguments are now audited. Audit now provides a security.audit sysctl node in order to determine if audit support is compiled in; boot-time console printfs have been removed. "options AUDIT" is now in the 7-CURRENT GENERIC kernel, so AUDIT support will be available out of the box in 7.0 without a kernel recompile. Manually enabling audit support in rc.conf will still be required. With FreeBSD 7.0, AUDIT will be a fully supported, rather than experimental, feature. __________________________________________________________________ TrustedBSD MAC Framework URL: http://www.TrustedBSD.org/mac.html Contact: Robert Watson Contact: Cleanup of MAC Framework API/KPI layers: mac.h is now just the user and user<->kernel API; mac_framework.h is the kernel<->MAC Framework KPI, and mac_policy.h is the MAC Framework<->MAC policy module KPI. Along similar lines, mac_label_get() and mac_label_set() accessor functions now allow policies to access label data without encoding struct label binary layout into policy modules, opening the door to more efficient layouts. struct label is now in mac_internal.h and used only inside the MAC Framework. General MAC policy cleanup, including removing no-op entry points and sysctls for some sample policies. mac_test(4) has been cleaned up significantly, and counters for all entry points added. A MAC check for UNIX domain socket connect has been added. MAC checks have been added so that MAC policies can control use of audit system calls. MAC checks that duplicate existing privileges but add no additional context have been removed (such as sysarch_ioperm, kld_unload, settime, and system_nfsd) -- checks aligned with privileges but that do provide additional context, such as additional arguments, have been kept. The Biba and LOMAC policies now implement priv(9) checks, differentiating between privileges that may compromise system integrity models, and those that don't. The essentially unused mnt_fslabel / mnt_label distinction has been eliminated by moving to a single mnt_label. No functional change to any policy. Several MAC-related interfaces have been modified to synchronize with the naming conventions present in the version of the MAC Framework adopted in Mac OS X Leopard; significant further changes are in the pipeline to complete this synchronization. While it will not be possible to reuse a policy between the two platforms without careful thinking and modification, this makes porting much easier. __________________________________________________________________ TrustedBSD priv(9) URL: http://www.TrustedBSD.org/ Contact: Robert Watson Contact: Further reduction of suser(9) consumers in order to attempt to remove the suser(9) KPI for 7.0. This includes resource limits, System V IPC, PPP, netinet port reuse, the NFS server, and netatalk. Remove unnecessary or redundant privilege checks were possible. UFS-privileges that apply to other file systems have been renamed to VFS privileges. All suser_cred() flags and priv_check_cred() flags are no longer required, as SUSER_ALLOWJAIL and SUSER_RUID use are determined entirely inside kern_jail.c and kern_priv.c and selected based on the privilege number, not a calling context flag. All privileges are now consistently allowed or not allowed in jail, and consistently use the ruid or euid. We will leave the flags field there as it will likely be used for other things in the future. Documentation in suser(9) and priv(9) has been updated. __________________________________________________________________ USB URL: http://perforce.freebsd.org/depotTreeBrowser.cgi?FSPC=3D//depot/projects/ usb/src/sys/dev/usb&HIDEDEL=3DNO URL: http://www.turbocat.net/~hselasky/usb4bsd URL: http://www.turbocat.net/~hselasky/usb4bsd/dev_new_usb.pdf Contact: Hans Petter Sirevaag Selasky During the last three months there has been several changes to the USB stack. Here is a quick list of the most important changes: 1. FULL speed isochronous devices over HIGH speed USB Hubs are now fully supported. Due to various reasons the maximum isochronous bandwidth has been limited to 6MBit/s. This limit is tunable. 2. There is now full support for Linux USB device drivers through a Linux USB API emulation layer. 3. Various cleanups and fixes. Markus Brueffer is still working on the USB HID parser and support. Nothing has been committed yet. If you want to test the new USB stack, checkout the USB perforce tree or download the SVN version of the USB driver from my USB homepage. At the moment the tarballs are a little out of date. Ideas and comments with regard to the new USB API are welcome at freebsd-usb@FreeBSD.org . __________________________________________________________________ USB update Contact: Warner Losh About 18 months ago, I started to remove the compatibility macros that we had in the USB stack. These macros made it very hard to read the code and to diagnose problems. They represented a barrier to entry for people reading and understanding the stack. In addition, many of them effectively hid bugs from all but the most intensive investigations of the code. I've removed almost all of the macros in the client drivers, and all instances of the macros in the core FreeBSD USB stack. This makes the drivers more readable, and a little more robust. During this process, I fixed a lot of little bugs that people had been tripping over, and some that people hadn't reported. I've added a boatload of new vendor and product ids to the drivers from user PRs as well as from OpenBSD/NetBSD drivers. I finished up this work so that the FreeBSD USB stack would be more maintainable during the RELENG_7 period of time. I plan on MFCing most of the changes I've made into RELENG_6 after they have been shaken out in current. There was only one API changes in this work, so this is doable, and makes sharing drivers between 6.x and 7.x much easier. At this stage, it is unclear how long RELENG_6 will be around, so I'm hoping this will make USB much better in 6.3 if that's the release people choose to run. I've shied away from many of the more complicated changes to the stack. There's work being done outside of the tree by Hans Petter Selasky (hps) to make these sorts of changes. There is much in his stack that's ready to be merged, and I hope to integrate from that work useful bits that can be merged without disruption to improve the FreeBSD USB stack. I'm also looking for other FreeBSD developers that can jump in and help. Nearly all of the improvements I've done by spending a few hours a week sorting through the PRs for extremely low hanging fruit. There's plenty of room for others to be involved as well in improving FreeBSD's USB stack, as well as chances for us to import the now-useful bits from the evolving hps USB stack, hopefully reducing the diffs between it and the present FreeBSD USB stack. In addition, I'm looking for someone to do similar device ID merges from DragonFlyBSD. Finally, I've embarked on a mission to try to merge all the BSD's usbdevs files. There's no reason to have separate ones. I've started to modify usbdevs(1) to read the src/sys/dev/usb/usbdevs file and report more verbose information that way. A merged usbdevs would be larger, and take up more memory in a USBVERBOSE kernel, so to mitigate that effect, I'm making changes to usbdevs(1). Open tasks: 1. The biggest area of concern before the 7.0 release is to get the updated device lists into the manual pages. This task is too big for me to take on in addition to the work I'm doing in cleaning up. 2. We need more people that are willing to help out on the 'trivial' PRs that add IDs to the driver. In addition, we need people to periodically sync our driver lists with DragonFlyBSD, NetBSD, and OpenBSD drivers. 3. Merging the other BSD's usbdevs tables would be very helpful. 4. Writing a usbdevs parser for usbdevs(1) to use. __________________________________________________________________ Wireless Networking Contact: Sam Leffler Contact: Andrew Thompson A major update of the 802.11 wireless support was committed. Changes include advanced station mode facilities such as background scanning and roaming, and support for 802.11n devices. In addition parts of the Atheros' SuperG protocol extensions were added so that wireless clients that communicate with Atheros-based access points can operate more effectively. The changes to the infrastructure are also important because they simplify future distribution of Virtual AP (VAP) support. This work represents the effort of many people including Kip Macy, Andrew Thompson, Sepherosa Ziehau, Max Laier, and Kevin Lo. Getting these changes into the tree now ensures they will be present for the lifetime of the 7.x branch. The scanning and SuperG work were supported by Atheros. The 802.11n-related work was supported by Marvell. Open tasks: 1. Please test your wireless networking, especially during the 7.0 BETA and RC period. __________________________________________________________________ =A9 1995-2007 The FreeBSD Project. All rights reserved. --Boundary-00=_8x1kGLTmGz2Z4zJ-- From owner-freebsd-current@FreeBSD.ORG Tue Jul 10 10:15:08 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 55DB416A400 for ; Tue, 10 Jul 2007 10:15:08 +0000 (UTC) (envelope-from vova@sw.ru) Received: from vbook.fbsd.ru (swsoft-mipt-nat.sw.ru [195.214.233.10]) by mx1.freebsd.org (Postfix) with ESMTP id 0887313C44C for ; Tue, 10 Jul 2007 10:15:07 +0000 (UTC) (envelope-from vova@sw.ru) Received: from vova by vbook.fbsd.ru with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I8CkJ-0000pN-AF for current@freebsd.org; Tue, 10 Jul 2007 14:15:03 +0400 From: Vladimir Grebenschikov To: current Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: SWsoft Date: Tue, 10 Jul 2007 14:15:02 +0400 Message-Id: <1184062502.1478.14.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.10.2 FreeBSD GNOME Team Port Sender: Vladimir Grebenschikov Cc: Subject: Hard fsck failure on UFS2 after successefull background fsck X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2007 10:15:08 -0000 Hi Following scenario give me re-predicable hard fsck failure (requires manual intervention). Filesystem: /dev/ad0s2d on /usr (ufs, local, soft-updates) 1. System crash (nothing serious in disc write caches), idle or almost idle before. 2. Boot, background fsck started and succeeded Shutdown system gracefully. 3. Boot system, auto fsck failed: Jul 10 00:43:51 vbook fsck: /dev/ad0s2d: INCORRECT BLOCK COUNT I=4103188 (4 should be 0) (CORRECTED) Jul 10 00:43:51 vbook fsck: /dev/ad0s2d: INCORRECT BLOCK COUNT I=4103200 (4 should be 0) (CORRECTED) Jul 10 00:43:51 vbook fsck: /dev/ad0s2d: INCORRECT BLOCK COUNT I=4145417 (4 should be 0) (CORRECTED) Jul 10 00:43:51 vbook fsck: /dev/ad0s2d: INCORRECT BLOCK COUNT I=8902657 (24 should be 20) (CORRECTED) Jul 10 00:43:51 vbook fsck: /dev/ad0s2d: INCORRECT BLOCK COUNT I=8903709 (12 should be 4) (CORRECTED) Jul 10 00:43:51 vbook fsck: /dev/ad0s2d: INCORRECT BLOCK COUNT I=8903713 (12 should be 0) (CORRECTED) Jul 10 00:43:51 vbook fsck: /dev/ad0s2d: INCORRECT BLOCK COUNT I=9091888 (4 should be 0) (CORRECTED) Jul 10 00:43:51 vbook fsck: /dev/ad0s2d: INCORRECT BLOCK COUNT I=9092284 (324 should be 312) (CORRECTED) Jul 10 00:43:51 vbook fsck: /dev/ad0s2d: MISSING '.' I=7113130 OWNER=root MODE=40755 Jul 10 00:43:51 vbook fsck: /dev/ad0s2d: SIZE=512 MTIME=Jul 3 02:30 2007 Jul 10 00:43:51 vbook fsck: /dev/ad0s2d: DIR=? Jul 10 00:43:51 vbook fsck: Jul 10 00:43:51 vbook fsck: /dev/ad0s2d: UNEXPECTED SOFT UPDATE INCONSISTENCY; RUN fsck MANUALLY. Every time "MISSING '.'" error is reproduced. I am only person expecting that problem ? -- Vladimir B. Grebenschikov SWsoft Inc. vova@swsoft.com From owner-freebsd-current@FreeBSD.ORG Tue Jul 10 10:19:07 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BC84516A46E for ; Tue, 10 Jul 2007 10:19:07 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [210.51.165.229]) by mx1.freebsd.org (Postfix) with ESMTP id 4F3AD13C4C1 for ; Tue, 10 Jul 2007 10:19:06 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from localhost (tarsier.geekcn.org [210.51.165.229]) by tarsier.geekcn.org (Postfix) with ESMTP id 0AE91EB5967; Tue, 10 Jul 2007 18:19:05 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([210.51.165.229]) by localhost (mail.geekcn.org [210.51.165.229]) (amavisd-new, port 10024) with ESMTP id 9214o1WYIXxF; Tue, 10 Jul 2007 18:19:02 +0800 (CST) Received: from LI-Xins-MacBook.local (sina152-194.staff.sina.com.cn [61.135.152.194]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTP id F1686EB40A0; Tue, 10 Jul 2007 18:19:01 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:cc:subject:references:in-reply-to: x-enigmail-version:openpgp:content-type; b=SZHyiAgsX/L9HY6wmMyQe4e8EeAmolS4GdQzRBJR5c/pOfqF1kYuW1KJUKD2PkaCJ VBHRkeu7kg2nejKIUztPg== Message-ID: <46935D0C.6020801@delphij.net> Date: Tue, 10 Jul 2007 18:18:52 +0800 From: LI Xin Organization: The FreeBSD Project User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) MIME-Version: 1.0 To: d@delphij.net References: <4691E8F0.8080005@micom.mng.net> <4691ECDC.8070500@delphij.net> <20070710.182040.184709560.shigeru@iij.ad.jp> <4693509B.3080107@delphij.net> In-Reply-To: <4693509B.3080107@delphij.net> X-Enigmail-Version: 0.95.2 OpenPGP: url=http://www.delphij.net/delphij.asc Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enigB52E582F17D4CDCCF0F2934D" Cc: ganbold@micom.mng.net, freebsd-current@freebsd.org Subject: Re: today's buildworld breaks X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2007 10:19:07 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB52E582F17D4CDCCF0F2934D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable LI Xin wrote: > YAMAMOTO Shigeru wrote: >> Hi, all. >> >> I think, it is better to add 'sed' to cross-tools. >> #because, 'sed' is required to 'make buildworld'. >=20 > Sounds reasonable. I will discuss this with re@ and commit the patch i= f > I got approval. Committed, thanks! Cheers, --=20 Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! --------------enigB52E582F17D4CDCCF0F2934D 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.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGk10MOfuToMruuMARCox0AJ9JjOtUPrCF9LwRyFsJuTEhaZ+q8QCfQMda x2Wv3vvuuH/go/wbjCnWwrA= =aEBi -----END PGP SIGNATURE----- --------------enigB52E582F17D4CDCCF0F2934D-- From owner-freebsd-current@FreeBSD.ORG Tue Jul 10 12:14:47 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 66D5116A468 for ; Tue, 10 Jul 2007 12:14:47 +0000 (UTC) (envelope-from michiel@boland.org) Received: from neerbosch.nijmegen.internl.net (neerbosch.nijmegen.internl.net [217.149.193.38]) by mx1.freebsd.org (Postfix) with ESMTP id E0C4C13C44B for ; Tue, 10 Jul 2007 12:14:46 +0000 (UTC) (envelope-from michiel@boland.org) Received: from neerbosch.nijmegen.internl.net by neerbosch.nijmegen.internl.net via neerbosch.nijmegen.internl.net [217.149.193.38] with ESMTP for id l6ACEj50016177 (8.13.4/1.4); Tue, 10 Jul 2007 14:14:45 +0200 (MEST) Received: from localhost by neerbosch.nijmegen.internl.net via mboland@localhost with ESMTP for id l6ACEjs0016174 (8.13.4/2.02); Tue, 10 Jul 2007 14:14:45 +0200 (MEST) X-Authentication-Warning: neerbosch.nijmegen.internl.net: mboland owned process doing -bs Date: Tue, 10 Jul 2007 14:14:45 +0200 (MEST) From: Michiel Boland To: freebsd-current@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: upgrade 6-STABLE to -CURRENT on sparc64 renders box unusable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2007 12:14:47 -0000 Hi. Yesterday I tried updating a pristine sparc64 box from 6.2-RELEASE via 6-STABLE to -CURRENT. Unfortunately /libexec/ld-elf.so.1 appears to have been broken. I am now left with a box on which every program will dump core. I guess I'll replace ld-elf.so.1 with the old version, but that still does not solve the installworld problems (unless I hack out the install in libexec/rtld-elf) I'm rather surprised noone else is reporting this. I'm pretty sure I followed all the recommended steps in /usr/src/UPDATING. Cheers Michiel From owner-freebsd-current@FreeBSD.ORG Tue Jul 10 12:16:59 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 747D416A469 for ; Tue, 10 Jul 2007 12:16:59 +0000 (UTC) (envelope-from janm@transactionware.com) Received: from mail.transactionware.com (mail.transactionware.com [203.14.245.7]) by mx1.freebsd.org (Postfix) with SMTP id AD18313C455 for ; Tue, 10 Jul 2007 12:16:58 +0000 (UTC) (envelope-from janm@transactionware.com) Received: (qmail 52083 invoked from network); 10 Jul 2007 12:17:15 -0000 Received: from midgard.transactionware.com (192.168.1.55) by dm.transactionware.com with SMTP; 10 Jul 2007 12:17:15 -0000 Received: (qmail 95652 invoked by uid 907); 10 Jul 2007 12:16:56 -0000 Received: from midgard.transactionware.com (HELO jmlaptop) (192.168.1.55) by midgard.transactionware.com (qpsmtpd/0.32) with ESMTP; Tue, 10 Jul 2007 22:16:56 +1000 From: "Jan Mikkelsen" To: , Date: Tue, 10 Jul 2007 22:16:57 +1000 Message-ID: <002001c7c2ec$369fc820$0204a8c0@jmlaptop> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6822 Importance: Normal Thread-Index: AcfC7DW0Q7Dq43l7QxaG/57QHnAShg== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailman-Approved-At: Tue, 10 Jul 2007 12:17:45 +0000 Cc: Subject: amd64/89550: Patch to make sym(4) work on amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2007 12:16:59 -0000 Hi, PR amd64/89550 contains a patch that allows amd64 systems with sym(4) devices to boot and for the controller to be functional. Can this patch be committed? Thanks, Jan Mikkelsen From owner-freebsd-current@FreeBSD.ORG Tue Jul 10 12:17:50 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 38BEB16A503 for ; Tue, 10 Jul 2007 12:17:50 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from ns.trinitel.com (186.161.36.72.static.reverse.layeredtech.com [72.36.161.186]) by mx1.freebsd.org (Postfix) with ESMTP id 0E17713C469 for ; Tue, 10 Jul 2007 12:17:49 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from proton.local (209-163-168-124.static.twtelecom.net [209.163.168.124]) (authenticated bits=0) by ns.trinitel.com (8.14.1/8.14.1) with ESMTP id l6ABtoVo098625; Tue, 10 Jul 2007 06:55:50 -0500 (CDT) (envelope-from anderson@freebsd.org) Message-ID: <469373C5.6070306@freebsd.org> Date: Tue, 10 Jul 2007 06:55:49 -0500 From: Eric Anderson User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) MIME-Version: 1.0 To: John Nielsen References: <200707092201.32209.lists@jnielsen.net> In-Reply-To: <200707092201.32209.lists@jnielsen.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on ns.trinitel.com Cc: current@freebsd.org Subject: Re: geom_fox vs gmultipath X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2007 12:17:50 -0000 John Nielsen wrote: > I was just reading the (pre-) release notes for 7.0 at > http://people.freebsd.org/~bmah/relnotes/CURRENT/relnotes.html and learned > about mjacob's gmultipath(8) implementation, which seems very similar to > phk's older geom_fox(4) but perhaps a bit more polished. > > First off, is that a correct assessment? I haven't used either, but > externally gmultipath is distinguished by having its own control utility > (rather than relying on geom(8)), a manpage (and perhaps other features) > more consistent with other geom utilities, and support for predictable > volume names under /dev/multipath/. > > Assuming I'm basically on target so far, does geom_fox have any features > that are not in gmultipath? If not, should it be considered deprecated? (or > should gmultipath be considered experimental since it's newer?) > > I'm just curious, esp. since I may have a need for one of the two in the > near future. Your assessments are pretty dead on. geom_fox from what I understood was more of a proof of concept, and geom_multipath is the 'real deal'. I played with both, and geom_multipath does well, whereas geom_fox did have some shortcomings. From my (maybe limited) experience, you should be able to use geom_multipath without much issue. Eric From owner-freebsd-current@FreeBSD.ORG Tue Jul 10 12:21:52 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1D87216A41F for ; Tue, 10 Jul 2007 12:21:52 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from ns.trinitel.com (186.161.36.72.static.reverse.layeredtech.com [72.36.161.186]) by mx1.freebsd.org (Postfix) with ESMTP id E720A13C4C2 for ; Tue, 10 Jul 2007 12:21:51 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from proton.local (209-163-168-124.static.twtelecom.net [209.163.168.124]) (authenticated bits=0) by ns.trinitel.com (8.14.1/8.14.1) with ESMTP id l6ACLoUq099588; Tue, 10 Jul 2007 07:21:51 -0500 (CDT) (envelope-from anderson@freebsd.org) Message-ID: <469379DE.2030605@freebsd.org> Date: Tue, 10 Jul 2007 07:21:50 -0500 From: Eric Anderson User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) MIME-Version: 1.0 To: Victor Snezhko References: <46934301.5080302@fer.hr> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on ns.trinitel.com Cc: freebsd-current@freebsd.org Subject: Re: Debugging time X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2007 12:21:52 -0000 Victor Snezhko wrote: > Ivan Voras writes: > >>> For about half a year I have another weirdness with time on my >>> -current box without vmware, maybe it's somehow has common origins >>> with your behaviour. When I boot FreeBSD, ntpdate (which is set up to >>> run via rc.conf) often reports huge time offsets: >>> 10 Jul 12:04:34 ntpdate[51761]: step time server ntp.server.name offset 234456.074166 sec >>> >>> I have so far only noticed that the value of the the offset is roughly >>> equal to the amount of time when FreeBSD isn't running (this is a >>> dual-boot box with windows). The box is pretty old, 600-MHz Celeron >> Is the above number correct (i.e. ~~ 65 hours)? > > Yes, sometimes my FreeBSD is not running for several days - in this > case ntpdate prints such numbers. It looks like kernel stores date and > time values somewhere and then re-reads them. I still don't rule out > some stupidity on my part - the behaviour I'm observing is very > illogic. Maybe I should try installing current from a fresh snapshot > when it's released. > >> I noticed there can be a consistent "shift" of duration equal to >> your timezone when VMWare sets the RTC to the host's local time and >> FreeBSD thinks it's UTC. But if the difference is not constant, it's >> not it. > > When I just reboot FreeBSD, offset doesn't exceed one or two seconds > (notably, bios takes longer to boot, about 5-10 seconds). When BSD is > inactive for several hours, number is much bigger. > > I neglected to debug this deeply before - I assumed I have overlooked > something simple, but now that you have reported another issue in the > similar area, I'll try to collect full information. > When you say 'inactive', do you mean that you have suspended the machine in vmware, or it is 'powered off'? Eric From owner-freebsd-current@FreeBSD.ORG Tue Jul 10 12:35:29 2007 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8920816A468; Tue, 10 Jul 2007 12:35:29 +0000 (UTC) (envelope-from barner@informatik.tu-muenchen.de) Received: from mailout1.informatik.tu-muenchen.de (mailout1.informatik.tu-muenchen.de [131.159.0.18]) by mx1.freebsd.org (Postfix) with ESMTP id 4A7BF13C48A; Tue, 10 Jul 2007 12:35:29 +0000 (UTC) (envelope-from barner@informatik.tu-muenchen.de) Received: by atknoll88.informatik.tu-muenchen.de (Postfix, from userid 1001) id 0522FE043F; Tue, 10 Jul 2007 14:09:02 +0200 (CEST) Date: Tue, 10 Jul 2007 14:09:02 +0200 From: Simon Barner To: ports@FreeBSD.org, current@FreeBSD.org Message-ID: <20070710120901.GA65987@atknoll88.informatik.tu-muenchen.de> Mail-Followup-To: ports@FreeBSD.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="cNdxnHkX5QqsyA0e" Content-Disposition: inline User-Agent: Mutt/1.5.15 (2007-04-06) X-Virus-Scanned: by amavisd-new/sophie/sophos at mailrelay1.informatik.tu-muenchen.de Cc: Subject: Valgrind GCC 4.2 patches X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2007 12:35:29 -0000 --cNdxnHkX5QqsyA0e Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hello, I finally fixed the valgrind build with gcc 4.2. Could you please verify that a) the port also build on 7-current, b) that there are no regressions (I did a quick test on 6.2, and it seems to work). http://home.leo.org/~barner/freebsd/valgrind-snapshot.patch http://home.leo.org/~barner/freebsd/valgrind.patch Thanks for you feedback, Simon (f'up2 freebsd-ports ) --cNdxnHkX5QqsyA0e Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGk3bdCkn+/eutqCoRAqtzAKCz2Q+j3WFLhqGq7+prU1H0N+A6tACeJLER 1AlnjqLBkRtpA0SO2SFjQJ8= =g0ME -----END PGP SIGNATURE----- --cNdxnHkX5QqsyA0e-- From owner-freebsd-current@FreeBSD.ORG Tue Jul 10 13:02:31 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D5F5416A46C for ; Tue, 10 Jul 2007 13:02:31 +0000 (UTC) (envelope-from bseklecki@collaborativefusion.com) Received: from mx00.pub.collaborativefusion.com (mx00.pub.collaborativefusion.com [206.210.89.199]) by mx1.freebsd.org (Postfix) with ESMTP id 80A5913C4C2 for ; Tue, 10 Jul 2007 13:02:31 +0000 (UTC) (envelope-from bseklecki@collaborativefusion.com) Received: from collaborativefusion.com (mx01.pub.collaborativefusion.com [206.210.89.201]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by wingspan with esmtp; Tue, 10 Jul 2007 08:52:28 -0400 id 00056434.4693810C.00017B95 Received: from Internal Mail-Server by mx01 (envelope-from bseklecki@collaborativefusion.com) with RC4-MD5 encrypted SMTP; 10 Jul 2007 07:52:27 -0500 From: "Brian A. Seklecki" To: Max Laier In-Reply-To: <200707031226.18399.max@love2party.net> References: <200707031226.18399.max@love2party.net> Organization: Collaborative Fusion, Inc. Date: Tue, 10 Jul 2007 08:52:27 -0400 Message-Id: <1184071947.44231.61.camel@soundwave.pitbpa0.priv.collaborativefusion.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit X-Mailer: Evolution 2.6.3 FreeBSD GNOME Team Port x-pineapp-mail-mail-from: bseklecki@collaborativefusion.com x-pineapp-mail-rcpt-to: max@love2party.net X-Mailman-Approved-At: Tue, 10 Jul 2007 13:08:59 +0000 Cc: freebsd-current@freebsd.org, freebsd-pf@freebsd.org Subject: re: HEADSUP: pf 4.1 import X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2007 13:02:31 -0000 On Tue, 2007-07-03 at 12:26 +0200, Max Laier wrote: > All, > > in the course of this afternoon (CEST) I'll import the OpenBSD 4.1 version We'll also have to see if Joel Knight's Net-SNMP patches work with our 5.3 in ports/net-mgmnt. ~BAS IMPORTANT: This message contains confidential information and is intended only for the individual named. If the reader of this message is not an intended recipient (or the individual responsible for the delivery of this message to an intended recipient), please be advised that any re-use, dissemination, distribution or copying of this message is prohibited. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. From owner-freebsd-current@FreeBSD.ORG Tue Jul 10 13:12:26 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E2EA516A421 for ; Tue, 10 Jul 2007 13:12:26 +0000 (UTC) (envelope-from henrik@brixandersen.dk) Received: from solow.pil.dk (relay.pil.dk [195.41.47.164]) by mx1.freebsd.org (Postfix) with ESMTP id A182113C4AE for ; Tue, 10 Jul 2007 13:12:26 +0000 (UTC) (envelope-from henrik@brixandersen.dk) Received: from tirith.brixandersen.dk (osgiliath.brixandersen.dk [87.53.223.189]) by solow.pil.dk (Postfix) with ESMTP id 68B471CC0B8; Tue, 10 Jul 2007 15:12:25 +0200 (CEST) Received: by tirith.brixandersen.dk (Postfix, from userid 1001) id D032EB84F; Tue, 10 Jul 2007 15:12:24 +0200 (CEST) Date: Tue, 10 Jul 2007 15:12:24 +0200 From: Henrik Brix Andersen To: Max Laier Message-ID: <20070710131224.GC64775@tirith.brixandersen.dk> Mail-Followup-To: Max Laier , freebsd-pf@freebsd.org, freebsd-net@freebsd.org, freebsd-current@freebsd.org References: <200706160347.33331.max@love2party.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6zdv2QT/q3FMhpsV" Content-Disposition: inline In-Reply-To: <200706160347.33331.max@love2party.net> X-PGP-Key: http://www.brixandersen.dk/files/HenrikBrixAndersen.asc User-Agent: Mutt/1.5.16 (2007-06-09) Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org, freebsd-pf@freebsd.org Subject: Re: pf 4.1 Update available for testing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2007 13:12:27 -0000 --6zdv2QT/q3FMhpsV Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Sat, Jun 16, 2007 at 03:47:24AM +0200, Max Laier wrote: > To make testing easier I'm working on RELENG_6 patches as well, but it=20 > will be a bit to get through the fix/build/repeat-cycles. I can't seem to locate the patches for RELENG_6 on http://people.freebsd.org/~mlaier/PF41/ - are they available for testing? Do you plan on MFC'ing pf-4.1 to RELENG_6 before RELENG_6_3 is branched? Regards, Brix --=20 Henrik Brix Andersen --6zdv2QT/q3FMhpsV Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) Comment: GnuPG signed iD8DBQFGk4W4v+Q4flTiePgRAgaXAJ437APnGT8qoMO5EiSswyzZ5Oo4jgCeL/32 NFejaEnZs+hmVOq8bCAz6do= =940L -----END PGP SIGNATURE----- --6zdv2QT/q3FMhpsV-- From owner-freebsd-current@FreeBSD.ORG Tue Jul 10 13:14:15 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 708A716A46B for ; Tue, 10 Jul 2007 13:14:15 +0000 (UTC) (envelope-from sfpoof@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.229]) by mx1.freebsd.org (Postfix) with ESMTP id 257E813C457 for ; Tue, 10 Jul 2007 13:14:14 +0000 (UTC) (envelope-from sfpoof@gmail.com) Received: by wx-out-0506.google.com with SMTP id i29so1022786wxd for ; Tue, 10 Jul 2007 06:14:12 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=TLQb7OUCahvg4eqPy0zlpoAvxIApGdiLKDswqkbPfK7hjPNaUpUcjFwJ6QF6tmlmy395MZOhBUIJvJKpbZjuWAcHVM+t0JhCgUghyuVtuVanJUmW/94Cljcfz5QQb72ZNB7i+FG6EPUUafszXaEH3Kmxu6GqcofbwEesnvG/AL8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=qXP+ywTUNKE0ZYR9Yb2Z8PmwyGLqdGyT25R8dEkEsk0nqEv8SW0HISJiCjOwq4eLz36ap36jZ5ulwIbau7jIEc+WE/TAUdB+raT1lLD02XcY1DqChBzsu0kEKTNu7rls6BJGMQ2qihZ6tET58xUruxmVSsVzLAT5WvVWE7zMuio= Received: by 10.90.68.15 with SMTP id q15mr2808141aga.1184073252919; Tue, 10 Jul 2007 06:14:12 -0700 (PDT) Received: by 10.90.100.16 with HTTP; Tue, 10 Jul 2007 06:14:12 -0700 (PDT) Message-ID: Date: Tue, 10 Jul 2007 06:14:12 -0700 From: "Kevin Gerry" To: "Sam Leffler" In-Reply-To: <46930F7A.6020007@errno.com> MIME-Version: 1.0 References: <468488B3.7010607@errno.com> <46848C1E.2080404@errno.com> <46930F7A.6020007@errno.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Sepherosa Ziehau , freebsd-current@freebsd.org Subject: Re: Wireless NICs not obeying 'SSID' setting. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2007 13:14:15 -0000 For sure, a mandatory option would be wonderful to be added to the wlan driver. I just find it surprising that after being 'down' for 1-2 seconds, it reassigns to another AP. One of the big 'pains in the butt' is that if I was using that card to NAT off of, I could easily be breaking the law in some US states. On 7/9/07, Sam Leffler wrote: > > Kevin Gerry wrote: > > Well, this is all it gave when it switched: > > > > -- > > messages.0:Jul 9 17:21:22 storage kernel: ral0: sta_roam_check: currssi > > 23 currate 108 roamrssi 14 roamrate 10 > > messages.0:Jul 9 17:21:37 storage kernel: ral0: link state changed to > DOWN > > messages.0:Jul 9 17:21:39 storage kernel: ral0: link state changed to > UP > > messages.0:Jul 9 17:21:54 storage kernel: ral0: sta_roam_check: currssi > > 45 currate 108 roamrssi 14 roamrate 10 > > Looks like you moved to another ap not because of roaming but because > you were dropped from your original ap. This can happen for various > reasons but the fact that you did not go back to it means the station > could not communicate w/ the ap so it chose another one. There are > other wlandebug knobs you can turn on to see exactly what happened (e.g. > state+scan). You can also look at wlanstats output and identify what > happened (probably). > > I changed the behaviour of setting the ssid from being mandatory to > "desired" for various reasons but it's likely I'll have to add back a > way to make it mandatory. But then you'll likely find yourself taking a > long time to re-connect to your ap if the ral card isn't being reset > properly or otherwise getting into a bad state (ral has known issues). > A well-behaved card+driver should locate the ap you want during the > re-scan and/or it should roam quickly if it misses the ap but then picks > it up on a bg scan. > > Sam > From owner-freebsd-current@FreeBSD.ORG Tue Jul 10 13:17:50 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D7EBD16A400; Tue, 10 Jul 2007 13:17:50 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.188]) by mx1.freebsd.org (Postfix) with ESMTP id 65A4213C468; Tue, 10 Jul 2007 13:17:50 +0000 (UTC) (envelope-from max@love2party.net) Received: from [88.66.11.242] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu7) with ESMTP (Nemesis), id 0ML2xA-1I8FbB25Os-0003km; Tue, 10 Jul 2007 15:17:49 +0200 From: Max Laier Organization: FreeBSD To: Henrik Brix Andersen Date: Tue, 10 Jul 2007 15:20:05 +0200 User-Agent: KMail/1.9.7 References: <200706160347.33331.max@love2party.net> <20070710131224.GC64775@tirith.brixandersen.dk> In-Reply-To: <20070710131224.GC64775@tirith.brixandersen.dk> X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGdu+2]; R]*pL,U>^H?)gW@49@wdJ`H<=?utf-8?q?=25=7D*=5FBD=0A=09U=5For=3D=5CmOZf764=26nYj=3DJYbR1PW0ud?=>|!~,,CPC.1-D$FG@0h3#'5"k{V]a~.<=?utf-8?q?mZ=7D44=23Se=7Em=0A=09Fe=7E=5C=5DX5B=5D=5Fxj?=(ykz9QKMw_l0C2AQ]}Ym8)fU MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart8111653.yvzq8WG2mA"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200707101520.12272.max@love2party.net> X-Provags-ID: V01U2FsdGVkX18zaS3Os+RK6qn+/8RLwKXXwe1dYd8nH46MAwo JceD6ExoqvJV5FudkDBjJ4JTH87RMJnK9/+06Tep1YpOW3H/fd cJy3UK2pOQwCu77NLyEDMxFE0vj8/qJ0iUQAWWkY4s= Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org, freebsd-pf@freebsd.org Subject: Re: pf 4.1 Update available for testing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2007 13:17:51 -0000 --nextPart8111653.yvzq8WG2mA Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Tuesday 10 July 2007, Henrik Brix Andersen wrote: > Hi, > > On Sat, Jun 16, 2007 at 03:47:24AM +0200, Max Laier wrote: > > To make testing easier I'm working on RELENG_6 patches as well, but > > it will be a bit to get through the fix/build/repeat-cycles. > > I can't seem to locate the patches for RELENG_6 on > http://people.freebsd.org/~mlaier/PF41/ - are they available for > testing? Oh ... forgot about that ... there are several problems with that. First=20 of all RELENG_6 is missing the interface group infrastructure which is=20 essential to pf now. This makes it difficult to produce patches. I=20 could do it, but ... > Do you plan on MFC'ing pf-4.1 to RELENG_6 before RELENG_6_3 is > branched? =2E.. it can never be MFCed due to the ABI breakage in several essential=20 places (ifnet and pf ioctls). There is some work going on in OpenBSD 4.2 to reduce userland ABI changes=20 in the future, but for now updating pf means breaking ABIs means no MFC=20 unfortunately. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart8111653.yvzq8WG2mA Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQBGk4eMXyyEoT62BG0RAkz/AJ9SANVEvb/S/ELGkp62EyqAqwlC2gCeKZtB 03TEFA6KxpUuFefrEDM5kCs= =Io9k -----END PGP SIGNATURE----- --nextPart8111653.yvzq8WG2mA-- From owner-freebsd-current@FreeBSD.ORG Tue Jul 10 13:22:57 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EAF0C16A46E; Tue, 10 Jul 2007 13:22:57 +0000 (UTC) (envelope-from henrik@brixandersen.dk) Received: from solow.pil.dk (relay.pil.dk [195.41.47.164]) by mx1.freebsd.org (Postfix) with ESMTP id A81CE13C45E; Tue, 10 Jul 2007 13:22:57 +0000 (UTC) (envelope-from henrik@brixandersen.dk) Received: from tirith.brixandersen.dk (osgiliath.brixandersen.dk [87.53.223.189]) by solow.pil.dk (Postfix) with ESMTP id DCA1F1CC0DF; Tue, 10 Jul 2007 15:22:56 +0200 (CEST) Received: by tirith.brixandersen.dk (Postfix, from userid 1001) id 5B6C7B84F; Tue, 10 Jul 2007 15:22:56 +0200 (CEST) Date: Tue, 10 Jul 2007 15:22:56 +0200 From: Henrik Brix Andersen To: Max Laier Message-ID: <20070710132256.GD64775@tirith.brixandersen.dk> Mail-Followup-To: Max Laier , freebsd-pf@freebsd.org, freebsd-net@freebsd.org, freebsd-current@freebsd.org References: <200706160347.33331.max@love2party.net> <20070710131224.GC64775@tirith.brixandersen.dk> <200707101520.12272.max@love2party.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="a2FkP9tdjPU2nyhF" Content-Disposition: inline In-Reply-To: <200707101520.12272.max@love2party.net> X-PGP-Key: http://www.brixandersen.dk/files/HenrikBrixAndersen.asc User-Agent: Mutt/1.5.16 (2007-06-09) Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org, freebsd-pf@freebsd.org Subject: Re: pf 4.1 Update available for testing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2007 13:22:58 -0000 --a2FkP9tdjPU2nyhF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Max, On Tue, Jul 10, 2007 at 03:20:05PM +0200, Max Laier wrote: > On Tuesday 10 July 2007, Henrik Brix Andersen wrote: > Oh ... forgot about that ... there are several problems with that. First= =20 > of all RELENG_6 is missing the interface group infrastructure which is=20 > essential to pf now. This makes it difficult to produce patches. I=20 > could do it, but ... I see. > > Do you plan on MFC'ing pf-4.1 to RELENG_6 before RELENG_6_3 is > > branched? >=20 > ... it can never be MFCed due to the ABI breakage in several essential=20 > places (ifnet and pf ioctls). >=20 > There is some work going on in OpenBSD 4.2 to reduce userland ABI changes= =20 > in the future, but for now updating pf means breaking ABIs means no MFC= =20 > unfortunately. Ah, of course - didn't think of that. Guess we'll just have to wait for 7.0 to hit the streets, then :) Thank you for working on this. Regards, Brix --=20 Henrik Brix Andersen --a2FkP9tdjPU2nyhF Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) Comment: GnuPG signed iD8DBQFGk4gvv+Q4flTiePgRAkFtAJ4gq+NFiEBbKJpn5LEbWipy+1bqZQCgwgYD 8mf3EydbfPIIoXpbnTsQw2o= =qRsq -----END PGP SIGNATURE----- --a2FkP9tdjPU2nyhF-- From owner-freebsd-current@FreeBSD.ORG Tue Jul 10 13:31:40 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1222F16A400 for ; Tue, 10 Jul 2007 13:31:40 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [83.98.131.211]) by mx1.freebsd.org (Postfix) with ESMTP id CCFE613C43E for ; Tue, 10 Jul 2007 13:31:39 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id D58301CCCF; Tue, 10 Jul 2007 15:31:37 +0200 (CEST) Date: Tue, 10 Jul 2007 15:31:37 +0200 From: Ed Schouten To: Michiel Boland Message-ID: <20070710133137.GD55449@hoeg.nl> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5xSkJheCpeK0RUEJ" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.16 (2007-06-09) Cc: FreeBSD Current Subject: Re: upgrade 6-STABLE to -CURRENT on sparc64 renders box unusable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2007 13:31:40 -0000 --5xSkJheCpeK0RUEJ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Michiel Boland wrote: > I'm rather surprised noone else is reporting this. I'm pretty sure I=20 > followed all the recommended steps in /usr/src/UPDATING. Just want to say `me too'! Not sure whether it's related to ld-elf, but I know my SPARC is rendered useless after upgrading world. I can't find a working display (one with sync on green) for my box at the moment, so I can't really investigate this problem. :( --=20 Ed Schouten WWW: http://g-rave.nl/ --5xSkJheCpeK0RUEJ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGk4o552SDGA2eCwURApSXAJ9RDQfXd5eIrLqTVQfssBBWEbrtMgCfaz0z d6J0k9raffF32h99w8xqnkQ= =tQuY -----END PGP SIGNATURE----- --5xSkJheCpeK0RUEJ-- From owner-freebsd-current@FreeBSD.ORG Tue Jul 10 13:42:50 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F32CF16A46E; Tue, 10 Jul 2007 13:42:49 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from pobox.codelabs.ru (pobox.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id A369913C483; Tue, 10 Jul 2007 13:42:49 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=one; d=codelabs.ru; h=Received:Date:From:To:Cc:Message-ID:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:Sender:X-Spam-Status:Subject; b=pOGlJcHmKVh4VFLAezmrJPg8WFpOOGRWf+IjuWFix6yI3Z6RWqNeCrXFSdz87X7kredHYpH0ULntasHPfaPmFSlyV5jlQ5FaXHlcu52f4fhLx7xDnIk4pAE6hraBKK/9w0xrI6qRfw//fPNkfgxAOIRSZQwE45SqOUFvODV5ekk=; Received: from void.codelabs.ru (void.codelabs.ru [144.206.177.25]) by pobox.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1I8FgA-0001Lj-Ib; Tue, 10 Jul 2007 17:22:58 +0400 Date: Tue, 10 Jul 2007 17:22:53 +0400 From: Eygene Ryabinkin To: Mike Silbersack Message-ID: <20070710132253.GJ1038@void.codelabs.ru> References: <20070709234401.S29353@odysseus.silby.com> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20070709234401.S29353@odysseus.silby.com> Sender: rea-fbsd@codelabs.ru X-Spam-Status: No, score=-3.0 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_00 Cc: Andre Oppermann , Robert Watson , current@freebsd.org, net@freebsd.org Subject: Re: FreeBSD 7 TCP syncache fix: request for testers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2007 13:42:50 -0000 Mike, good day. Tue, Jul 10, 2007 at 12:20:49AM -0500, Mike Silbersack wrote: > Anyway, the attached patch simplifies the syncache structure a bit and > makes it retransmit properly. I'd appreciate testing from anyone who > has experienced TCP problems with FreeBSD 7, as well as anyone who is > pushing significant traffic through FreeBSD 7. Can't say that I am pushing much traffic through my box, but after applying your patch and rebuilding the kernel I am still seeing the messages like ----- TCP: [209.132.176.NNN]:NNN to [144.206.NNN.NNN]:NNN tcpflags 0x19; syncache_expand: Segment failed SYNCOOKIE authentication, segment rejected (probably spoofed) TCP: [201.90.65.NNN]:NNN to [144.206.NNN.NNN]:NNN; syncache_timer: Response timeout ----- But what had changed is that the lines with the 'syncache_timer' started to appear. There were no such lines prior to the patch, only the 'failed SYNCOOKIE' ones. But the patch received only half a day of testing, so I will continue the tests and will inform you if some other information will be available. Up to date I don't see problems that had appeared without the patch, but they tend to show up after a midnight ;)) Thank you! -- Eygene From owner-freebsd-current@FreeBSD.ORG Tue Jul 10 14:56:41 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AF9AB16A400 for ; Tue, 10 Jul 2007 14:56:41 +0000 (UTC) (envelope-from philip@paeps.cx) Received: from gateway.nixsys.be (gateway.nixsys.be [195.144.77.42]) by mx1.freebsd.org (Postfix) with ESMTP id 5361E13C448 for ; Tue, 10 Jul 2007 14:56:41 +0000 (UTC) (envelope-from philip@paeps.cx) Received: from wotan.home.paeps.cx (wotan.home.paeps.cx [IPv6:2001:6f8:32f:10:a00:20ff:fe9b:138c]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "wotan.home.paeps.cx", Issuer "NixSys CA" (verified OK)) by gateway.nixsys.be (Postfix) with ESMTP id 65B524051; Tue, 10 Jul 2007 16:37:36 +0200 (CEST) Received: from fasolt.home.paeps.cx (fasolt.home.paeps.cx [IPv6:2001:6f8:32f:10:214:5eff:feca:2496]) by wotan.home.paeps.cx (Postfix) with ESMTP id 9903761F1; Tue, 10 Jul 2007 16:37:34 +0200 (CEST) Received: from fasolt.home.paeps.cx (philip@localhost [127.0.0.1]) by fasolt.home.paeps.cx (8.14.1/8.14.1) with ESMTP id l6AEbYHM034733; Tue, 10 Jul 2007 16:37:34 +0200 (CEST) (envelope-from philip@fasolt.home.paeps.cx) Received: (from philip@localhost) by fasolt.home.paeps.cx (8.14.1/8.14.1/Submit) id l6AEbXks034732; Tue, 10 Jul 2007 16:37:33 +0200 (CEST) (envelope-from philip) Date: Tue, 10 Jul 2007 16:37:33 +0200 From: Philip Paeps To: Ed Schouten Message-ID: <20070710143733.GB1318@fasolt.home.paeps.cx> Mail-Followup-To: Ed Schouten , Michiel Boland , FreeBSD Current References: <20070710133137.GD55449@hoeg.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20070710133137.GD55449@hoeg.nl> X-PGP-Fingerprint: 356B AE02 4763 F739 2FA2 E438 2649 E628 C5D3 4D05 X-Date: Today is Sweetmorn, the 45th day of Confusion in the YOLD 3173 X-Date-in-France: Duodi 22 Messidor CCXV, jour du cumin X-Date-in-Rome: ante diem VI Idus Iulias MMDCCLX ab Urbe Condida X-Phase-of-Moon: The Moon is Waning Crescent (19% of Full) X-Message-Flag: Get a proper mailclient! Organization: Happily Disorganized User-Agent: Mutt/1.5.15 (2007-04-06) Cc: Michiel Boland , FreeBSD Current Subject: Re: upgrade 6-STABLE to -CURRENT on sparc64 renders box unusable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2007 14:56:41 -0000 On 2007-07-10 15:31:37 (+0200), Ed Schouten wrote: > * Michiel Boland wrote: > > I'm rather surprised noone else is reporting this. I'm pretty sure I > > followed all the recommended steps in /usr/src/UPDATING. > > Just want to say `me too'! Not sure whether it's related to ld-elf, but > I know my SPARC is rendered useless after upgrading world. I can't find > a working display (one with sync on green) for my box at the moment, so > I can't really investigate this problem. :( If you absolutely need to use a monitor, you can get the sync on green with fairly minimal electronic tinkering. On sparc64, it should be easier to get a serial cable to work though, no? You can use an LM1881 sync separator to take the sync out of the green and split it into hsync and vsync. A number of schematics can be found online. A serial cable should be simpler though. :-) - Philip -- Philip Paeps Please don't Cc me, I am philip@freebsd.org subscribed to the list. If you're early, it'll be cancelled. If you knock yourself out to be on time, you will have to wait. If you're late, you will be too late. From owner-freebsd-current@FreeBSD.ORG Tue Jul 10 15:07:18 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EE26F16A421; Tue, 10 Jul 2007 15:07:18 +0000 (UTC) (envelope-from se@FreeBSD.org) Received: from frueh.atsec.com (frueh.atsec.com [217.110.13.170]) by mx1.freebsd.org (Postfix) with ESMTP id 6B58C13C43E; Tue, 10 Jul 2007 15:07:18 +0000 (UTC) (envelope-from se@FreeBSD.org) Received: from [10.2.2.88] (se-pad.koeln.atsec [10.2.2.88]) by frueh.atsec.com (omb_smtp 1.5.8) with ESMTP; Tue, 10 Jul 2007 17:52:20 +0200 (CEST) Message-ID: <46939CA5.4080506@FreeBSD.org> Date: Tue, 10 Jul 2007 16:50:13 +0200 From: Stefan Esser User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Jan Mikkelsen References: <002001c7c2ec$369fc820$0204a8c0@jmlaptop> In-Reply-To: <002001c7c2ec$369fc820$0204a8c0@jmlaptop> X-Enigmail-Version: 0.95.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org, freebsd-amd64@FreeBSD.org Subject: Re: amd64/89550: Patch to make sym(4) work on amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2007 15:07:19 -0000 Jan Mikkelsen schrieb: > Hi, > > PR amd64/89550 contains a patch that allows amd64 systems with sym(4) > devices to boot and for the controller to be functional. > > Can this patch be committed? I'll have a look later today and I'll commit the patch if it seems OK. While I still have some Symbios SCSI cards, I have no access to amd64 hardware, currently, and can not verify that the patch works as advertized. Regards, STefan From owner-freebsd-current@FreeBSD.ORG Tue Jul 10 15:42:29 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2857216A421; Tue, 10 Jul 2007 15:42:29 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (nagual.pp.ru [194.87.13.69]) by mx1.freebsd.org (Postfix) with ESMTP id 99C7D13C4C2; Tue, 10 Jul 2007 15:42:28 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.14.1/8.14.1) with ESMTP id l6AFfo5M022922; Tue, 10 Jul 2007 19:41:50 +0400 (MSD) (envelope-from ache@nagual.pp.ru) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nagual.pp.ru; s=default; t=1184082110; bh=u/IwOmJsWQwumAl5y1fHQgyZCYD6v2BwKBviive Z1VM=; l=878; h=Received:Date:From:To:Cc:Subject:Message-ID: Mail-Followup-To:References:MIME-Version:Content-Type: Content-Disposition:In-Reply-To:User-Agent; b=ABQpZJEdAyF4tR34TT9r aJIalXDZ/GaV3WBeFz1qdzZ3HG9RJETqHSewrV1/5R6UJoClNAnAEGq9sBkN+/Cgsgu aZBfsoyrTeqBbuUT4WJoTgKHLm7dVV+Gy0xh59VnN9P2lMQ02wuHfjEVhRBULnb4jAg ZE6NoFzMljkZDglpA= Received: (from ache@localhost) by nagual.pp.ru (8.14.1/8.14.1/Submit) id l6AFfnXA022921; Tue, 10 Jul 2007 19:41:49 +0400 (MSD) (envelope-from ache) Date: Tue, 10 Jul 2007 19:41:48 +0400 From: Andrey Chernov To: "Sean C. Farley" Message-ID: <20070710154148.GA22873@nagual.pp.ru> Mail-Followup-To: Andrey Chernov , "Sean C. Farley" , Dirk Meyer , freebsd-current@freebsd.org References: <20070703182400.Q1449@baba.farley.org> <20070709145418.T52164@thor.farley.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070709145418.T52164@thor.farley.org> User-Agent: Mutt/1.5.16 (2007-06-09) Cc: Dirk Meyer , freebsd-current@freebsd.org Subject: Re: HEADS UP: getenv() and family API change X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2007 15:42:29 -0000 On Mon, Jul 09, 2007 at 03:07:42PM -0500, Sean C. Farley wrote: > On Sun, 8 Jul 2007, Dirk Meyer wrote: > >> Hallo Sean C. Farley, >> >>> Changes in moving to POSIX from historic BSD API: >>> b. putenv takes a char * instead of const char *. >>> c. putenv no longer makes a copy of the input string. >> >> Can you give more details? >> >> An application will break in using this: >> putenv("PATH=/bin") >> >> now taking a char *, this will break with gcc42. > > True. As Andrey said, you should pass a copy of a const string into > putenv(). putenv() is designed to allow changing a value at any time by > manipulating the string. This is why I really wish the Open Group would To say strictly, copying somewhere is not neccessary since this way works too: static char *s = "PATH=/bin"; putenv(s); (don't forget static) -- http://ache.pp.ru/ From owner-freebsd-current@FreeBSD.ORG Tue Jul 10 15:53:14 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2864116A421 for ; Tue, 10 Jul 2007 15:53:14 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (mail.soaustin.net [207.200.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 0EA5913C45E for ; Tue, 10 Jul 2007 15:53:14 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: by mail.soaustin.net (Postfix, from userid 502) id BF907EC4; Tue, 10 Jul 2007 10:53:13 -0500 (CDT) Date: Tue, 10 Jul 2007 10:53:13 -0500 To: Steve Kargl Message-ID: <20070710155313.GB2730@soaustin.net> References: <20070710044902.GA62286@troutmask.apl.washington.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070710044902.GA62286@troutmask.apl.washington.edu> User-Agent: Mutt/1.5.9i From: linimon@lonesome.com (Mark Linimon) X-Mailman-Approved-At: Tue, 10 Jul 2007 16:01:11 +0000 Cc: freebsd-current@freebsd.org Subject: Re: Closing some old bug reports. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2007 15:53:14 -0000 On Mon, Jul 09, 2007 at 09:49:02PM -0700, Steve Kargl wrote: > These have out lived their shelf life. Done. fwiw, you can always email bugmeister@FreeBSD.org with these type of requests and we'll clean them up. Out of curiosity, did the problems get resolved in later releases, or ...? (I only saw the one commit that fixed a problem in the list, but some were so old they would not have gotten the auto-annotation from the commit.) mcl From owner-freebsd-current@FreeBSD.ORG Tue Jul 10 16:09:34 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 04D4A16A46B for ; Tue, 10 Jul 2007 16:09:34 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.freebsd.org (Postfix) with ESMTP id D5A2013C46A for ; Tue, 10 Jul 2007 16:09:33 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.1/8.13.8) with ESMTP id l6AG82L8066366; Tue, 10 Jul 2007 09:08:02 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.1/8.13.8/Submit) id l6AG82mp066365; Tue, 10 Jul 2007 09:08:02 -0700 (PDT) (envelope-from sgk) Date: Tue, 10 Jul 2007 09:08:02 -0700 From: Steve Kargl To: Mark Linimon Message-ID: <20070710160802.GA66351@troutmask.apl.washington.edu> References: <20070710044902.GA62286@troutmask.apl.washington.edu> <20070710155313.GB2730@soaustin.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070710155313.GB2730@soaustin.net> User-Agent: Mutt/1.4.2.2i Cc: freebsd-current@freebsd.org Subject: Re: Closing some old bug reports. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2007 16:09:34 -0000 On Tue, Jul 10, 2007 at 10:53:13AM -0500, Mark Linimon wrote: > On Mon, Jul 09, 2007 at 09:49:02PM -0700, Steve Kargl wrote: > > These have out lived their shelf life. > > Done. fwiw, you can always email bugmeister@FreeBSD.org with these > type of requests and we'll clean them up. Then only bugmeister will see the list of PR. > Out of curiosity, did the problems get resolved in later releases, or ...? > (I only saw the one commit that fixed a problem in the list, but some were > so old they would not have gotten the auto-annotation from the commit.) AFAIK, only one was fixed. -- Steve From owner-freebsd-current@FreeBSD.ORG Tue Jul 10 16:10:10 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2FA6616A46C for ; Tue, 10 Jul 2007 16:10:10 +0000 (UTC) (envelope-from almarrie@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.244]) by mx1.freebsd.org (Postfix) with ESMTP id 9688513C4D9 for ; Tue, 10 Jul 2007 16:10:09 +0000 (UTC) (envelope-from almarrie@gmail.com) Received: by an-out-0708.google.com with SMTP id c14so310850anc for ; Tue, 10 Jul 2007 09:10:08 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=IQOx191qBcsv8s9uHfBnDEuZb5Urxt/hYMo1HpJOXwTH4IUctWEOdkPka9ELrJllVJpunT9z/1xSQQ5FrnKQch4k5Oxsb7dlumM7Doeh/xAawJBIJU3xEo5r5vWFZN09Ap1apOqX55/Qi0YsStv/Z0c0VlB267XV1AFKTcfD3+k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Ha3I8wznTH7VLfl1GQfsCUGF0HHKmOASAnGtpS2vAUZrgOKe2799ayNPl8qN3iugOz+57jZ3l6thHMDqwc+vB3DOSbiTnAajNzxRiRtE63TECwVmgSnUwRDNOEHKwKlQrwe6W8QAGmqDbkcl6c4tVPE1ftVECLjXbn2oTXZgl7U= Received: by 10.100.8.18 with SMTP id 18mr2276646anh.1184083808386; Tue, 10 Jul 2007 09:10:08 -0700 (PDT) Received: by 10.100.9.14 with HTTP; Tue, 10 Jul 2007 09:10:08 -0700 (PDT) Message-ID: <499c70c0707100910i2970c003tb7211c7eff8327b@mail.gmail.com> Date: Tue, 10 Jul 2007 19:10:08 +0300 From: "Abdullah Ibn Hamad Al-Marri" To: "Simon Barner" In-Reply-To: <20070710120901.GA65987@atknoll88.informatik.tu-muenchen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070710120901.GA65987@atknoll88.informatik.tu-muenchen.de> Cc: ports@freebsd.org, current@freebsd.org Subject: Re: Valgrind GCC 4.2 patches X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2007 16:10:10 -0000 On 7/10/07, Simon Barner wrote: > Hello, > > I finally fixed the valgrind build with gcc 4.2. Could you > please verify that > > a) the port also build on 7-current, > b) that there are no regressions (I did a quick test on 6.2, > and it seems to work). > > http://home.leo.org/~barner/freebsd/valgrind-snapshot.patch > http://home.leo.org/~barner/freebsd/valgrind.patch > > Thanks for you feedback, > Simon Thank you, would it build in AMD64? > (f'up2 freebsd-ports ) > > -- Regards, -Abdullah Ibn Hamad Al-Marri Arab Portal http://www.WeArab.Net/ From owner-freebsd-current@FreeBSD.ORG Tue Jul 10 16:23:14 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3460416A421 for ; Tue, 10 Jul 2007 16:23:14 +0000 (UTC) (envelope-from peter@wemm.org) Received: from canning.wemm.org (canning.wemm.org [192.203.228.65]) by mx1.freebsd.org (Postfix) with ESMTP id 1D24513C46A for ; Tue, 10 Jul 2007 16:23:13 +0000 (UTC) (envelope-from peter@wemm.org) Received: from overcee.wemm.org (canning.wemm.org [192.203.228.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by canning.wemm.org (Postfix) with ESMTP id BDABE46B6A for ; Tue, 10 Jul 2007 09:23:13 -0700 (PDT) (envelope-from peter@wemm.org) Received: from overcee.wemm.org (localhost [127.0.0.1]) by overcee.wemm.org (8.14.1/8.14.1) with ESMTP id l6AFCYmk002541 for ; Tue, 10 Jul 2007 08:12:34 -0700 (PDT) (envelope-from peter@wemm.org) Received: from localhost (localhost [[UNIX: localhost]]) by overcee.wemm.org (8.14.1/8.14.1/Submit) id l6AFCY76002540 for current@freebsd.org; Tue, 10 Jul 2007 08:12:34 -0700 (PDT) (envelope-from peter@wemm.org) X-Authentication-Warning: overcee.wemm.org: peter set sender to peter@wemm.org using -f From: Peter Wemm To: current@freebsd.org Date: Tue, 10 Jul 2007 08:12:34 -0700 User-Agent: KMail/1.9.6 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200707100812.34540.peter@wemm.org> Cc: Subject: kqueue bug in 7.x with "things" that go away. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2007 16:23:14 -0000 I've run into a bug in kqueue/tty in 7.x. How to reproduce: open a tty, eg: a usb ftdi ucom device (ttyU0) put a read event on it. sleep in kevent physically remove usb device observe dmesg to say ucom0 went away. Note sleeping program doesn't wake up. ctrl-C (or otherwise exit the program sleeping in kevent) panic! 0xdeadc0de reference or worse. There are probably other ways to make it go boom, but this is pretty graphic. The stack trace I have is a mess due to inlined static function calls, but here are the relevant parts: #7 0xffffffff8042d77e in calltrap () at ../../../amd64/amd64/exception.S:169 #8 0xffffffff802a1645 in knlist_remove_kq (knl=0xdeadc0dedeadc1ae, kn=0xffffff0003bc5b40, knlislocked=0, kqislocked=0) at ../../../kern/kern_event.c:1608 #9 0xffffffff802a41fe in kqueue_close (fp=0xffffff0003d90528, td=0xffffff000e5c29c0) at ../../../kern/kern_event.c:1463 #10 0xffffffff8029c3cc in fdrop (fp=0xffffff0003d90528, td=0xffffff000e5c29c0) at file.h:297 #11 0xffffffff8029d7fb in closef (fp=0xffffff0003d90528, td=0xffffff000e5c29c0) at ../../../kern/kern_descrip.c:1983 #12 0xffffffff8029e32d in fdfree (td=0xffffff000e5c29c0) at ../../../kern/kern_descrip.c:1693 #13 0xffffffff802a70cc in exit1 (td=0xffffff000e5c29c0, rv=2) ---Type to continue, or q to quit--- at ../../../kern/kern_exit.c:272 #14 0xffffffff802c651f in sigexit (td=0xffffff000e5c29c0, sig=0) at ../../../kern/kern_sig.c:2884 #15 0xffffffff802c7378 in postsig (sig=-559038034) at ../../../kern/kern_sig.c:2756 #16 0xffffffff802f4519 in ast (framep=0xffffffffabfe8c70) at ../../../kern/subr_trap.c:259 #17 0xffffffff8042d970 in Xfast_syscall () at ../../../amd64/amd64/exception.S:286 Unfortunately, you don't see the inlined function calls in the trace. I'm not 100% sure what frame 8 and 9 are. The kqueue filter functions dont seem to check TS_GONE. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 From owner-freebsd-current@FreeBSD.ORG Tue Jul 10 16:41:32 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8C0F116A469 for ; Tue, 10 Jul 2007 16:41:32 +0000 (UTC) (envelope-from peter@wemm.org) Received: from canning.wemm.org (canning.wemm.org [192.203.228.65]) by mx1.freebsd.org (Postfix) with ESMTP id 75C8213C44C for ; Tue, 10 Jul 2007 16:41:32 +0000 (UTC) (envelope-from peter@wemm.org) Received: from overcee.wemm.org (canning.wemm.org [192.203.228.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by canning.wemm.org (Postfix) with ESMTP id 2A11B46B69 for ; Tue, 10 Jul 2007 09:41:32 -0700 (PDT) (envelope-from peter@wemm.org) Received: from overcee.wemm.org (localhost [127.0.0.1]) by overcee.wemm.org (8.14.1/8.14.1) with ESMTP id l6AGfVGx002324; Tue, 10 Jul 2007 09:41:31 -0700 (PDT) (envelope-from peter@wemm.org) Received: from localhost (localhost [[UNIX: localhost]]) by overcee.wemm.org (8.14.1/8.14.1/Submit) id l6AGfVM9002323; Tue, 10 Jul 2007 09:41:31 -0700 (PDT) (envelope-from peter@wemm.org) X-Authentication-Warning: overcee.wemm.org: peter set sender to peter@wemm.org using -f From: Peter Wemm To: current@freebsd.org Date: Tue, 10 Jul 2007 09:41:31 -0700 User-Agent: KMail/1.9.6 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200707100941.31421.peter@wemm.org> Cc: peter@wemm.org Subject: Re: kqueue bug in 7.x with "things" that go away. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2007 16:41:32 -0000 Initial patch that fixes the crashes: http://people.freebsd.org/~peter/tty.diff Problems: ttyfree() was freeing the cdev(). But if there were pending kevents, filt_ttyrdetach() etc would later attempt to dereference cdev->si_tty, causing a 0xdeadc0de dereference. Also, ttygone() merely issued a bunch of wakeup() calls. That woke things that were blocked in various states, but nothing was done about getting the attention of select(), sigio or kevent() users. I added code to wake them up. Also, the kevent filters didn't check TS_GONE. If its set, I made it return EV_EOF immediately. Problems not solved: The 'struct tty' obtained by drivers from ttyalloc() is not freed in a bunch of cases. I think ttyfree() should call ttyrel() to release the reference count that ttyalloc() implicitly returned with. If there are still other references, then that is tough luck, we'd have leaked it anyway. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 From owner-freebsd-current@FreeBSD.ORG Tue Jul 10 16:45:03 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D6E6D16A46B for ; Tue, 10 Jul 2007 16:45:03 +0000 (UTC) (envelope-from michiel@boland.org) Received: from neerbosch.nijmegen.internl.net (neerbosch.nijmegen.internl.net [217.149.193.38]) by mx1.freebsd.org (Postfix) with ESMTP id 73B5213C46C for ; Tue, 10 Jul 2007 16:45:03 +0000 (UTC) (envelope-from michiel@boland.org) Received: from neerbosch.nijmegen.internl.net by neerbosch.nijmegen.internl.net via neerbosch.nijmegen.internl.net [217.149.193.38] with ESMTP for id l6AGj28M026199 (8.13.4/1.4); Tue, 10 Jul 2007 18:45:02 +0200 (MEST) Received: from localhost by neerbosch.nijmegen.internl.net via mboland@localhost with ESMTP for id l6AGj1aj026196 (8.13.4/2.02); Tue, 10 Jul 2007 18:45:01 +0200 (MEST) X-Authentication-Warning: neerbosch.nijmegen.internl.net: mboland owned process doing -bs Date: Tue, 10 Jul 2007 18:45:01 +0200 (MEST) From: Michiel Boland To: freebsd-current@freebsd.org In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: upgrade 6-STABLE to -CURRENT on sparc64 renders box unusable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2007 16:45:03 -0000 To follow up on myself, it appears that ld-elf.so.1 crashes somewhere in __getosreldate. I have no idea how to debug this further. 000000000000e140 <__getosreldate>: e140: 9d e3 bf 20 save %sp, -224, %sp e144: 2f 00 04 96 sethi %hi(0x125800), %l7 e148: 7f ff ff f6 call e120 <__sys_mmap+0x40> e14c: ae 05 e0 b8 add %l7, 0xb8, %l7 e150: 03 00 00 01 sethi %hi(0x400), %g1 e154: 82 10 61 f8 or %g1, 0x1f8, %g1 e158: f0 5d c0 01 ldx [ %l7 + %g1 ], %i0 e15c: c2 06 00 00 ld [ %i0 ], %g1 ^ crash appears to be here somewhere From owner-freebsd-current@FreeBSD.ORG Tue Jul 10 16:56:12 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 52EC116A46D for ; Tue, 10 Jul 2007 16:56:12 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [83.98.131.211]) by mx1.freebsd.org (Postfix) with ESMTP id 1D1DD13C46A for ; Tue, 10 Jul 2007 16:56:12 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id 26D4C1CD03; Tue, 10 Jul 2007 18:56:06 +0200 (CEST) Date: Tue, 10 Jul 2007 18:56:06 +0200 From: Ed Schouten To: FreeBSD Current Message-ID: <20070710165606.GE55449@hoeg.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="8JPrznbw0YAQ/KXy" Content-Disposition: inline User-Agent: Mutt/1.5.16 (2007-06-09) Subject: D_NEEDGIANT usage in {amd64,i386}/isa/clock.c X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2007 16:56:12 -0000 --8JPrznbw0YAQ/KXy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello, I was just taking a look at the /dev/nvram code in the isa/clock.c files of the amd64 and i386 architectures. For some reason, the "nvram" device needs D_NEEDGIANT. If I take a look at the nvram_open(), nvram_read() and nvram_write() routines, I see no reason why it should be marked D_NEEDGIANT. Both the nvram_read() and nvram_write() routines both perform some simple bounds checking and then call rtcin() and writertc(). Both of those routines are already protected from concurrent access through the RTC_LOCK and RTC_UNLOCK macro's. Yours, --=20 Ed Schouten WWW: http://g-rave.nl/ --8JPrznbw0YAQ/KXy Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGk7om52SDGA2eCwURAneSAJ4mSLmFkGeG7p+CI/L2nB0Z3iN+WACfbFmQ qMlOePLlwpnjE1977k5SKPY= =c9MT -----END PGP SIGNATURE----- --8JPrznbw0YAQ/KXy-- From owner-freebsd-current@FreeBSD.ORG Tue Jul 10 16:41:11 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3D81216A421 for ; Tue, 10 Jul 2007 16:41:11 +0000 (UTC) (envelope-from serguey-grigoriev@yandex.ru) Received: from webmail35.mail.yandex.net (webmail35.mail.yandex.net [213.180.223.185]) by mx1.freebsd.org (Postfix) with ESMTP id BBAFA13C45A for ; Tue, 10 Jul 2007 16:41:10 +0000 (UTC) (envelope-from serguey-grigoriev@yandex.ru) Received: from YAMAIL (webmail35) by mail.yandex.ru id S6456472AbXGJQlA for ; Tue, 10 Jul 2007 20:41:00 +0400 Received: from [91.122.49.58] ([91.122.49.58]) by mail.yandex.ru with HTTP; Tue, 10 Jul 2007 20:41:00 +0400 From: "S.N.Grigoriev" To: freebsd-current@freebsd.org MIME-Version: 1.0 Message-Id: <669401184085660@webmail35.yandex.ru> Date: Tue, 10 Jul 2007 20:41:00 +0400 X-Mailer: Yamail [ http://yandex.ru ] 5.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailman-Approved-At: Tue, 10 Jul 2007 16:56:17 +0000 Subject: Build error: OpenOffice.org-2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2007 16:41:11 -0000 Hi list, I've got the following error message during building /usr/ports/editors/openoffice.org-2 (my system is 7-Current amd64): mkdir ./unxfbsdx.pro/misc/build/xt-20051206/ cd ./unxfbsdx.pro/misc/build/xt-20051206/ && dmake product="full" && touch /d2/ports/editors/openoffice.org-2/work/OOF680_m18/xt/./unxfbsdx.pro/misc/build/so_built_xt ------------- /usr/local/bin/ant -Dprj=../../../.. -Dprjname=xt -Ddebug=off -Doptimize=on -Dtarget=compile -Dsolar.update=on -Dout=../../../../unxfbsdx.pro -Dinpath=unxfbsdx.pro -Dproext=".pro" -Dsolar.bin=/d2/ports/editors/openoffice.org-2/work/OOF680_m18/solver/680/unxfbsdx.pro/bin -Dsolar.jar=/d2/ports/editors/openoffice.org-2/work/OOF680_m18/solver/680/unxfbsdx.pro/bin -Dsolar.doc=/d2/ports/editors/openoffice.org-2/work/OOF680_m18/solver/680/unxfbsdx.pro/doc -Dcommon.jar=/d2/ports/editors/openoffice.org-2/work/OOF680_m18/solver/680/unxfbsdx.pro/bin -Dcommon.doc= -Dsolar.sourceversion=OOF680 -Dsolar.lastminor=m18 -Dsolar.build=9161 -f build.xml -emacs Buildfile: build.xml /libexec/ld-elf.so.1: /lib/libpthread.so.2: Undefined symbol "_malloc_prefork" dmake: Error code 1, while making 'ANTBUILD' '---* tg_merge.mk *---' dmake: Error code 255, while making './unxfbsdx.pro/misc/build/so_built_xt' '---* tg_merge.mk *---' ERROR: Error 65280 occurred while making /d2/ports/editors/openoffice.org-2/work/OOF680_m18/xt dmake: Error code 1, while making 'build_instsetoo_native' '---* *---' *** Error code 255 Stop in /d2/ports/editors/openoffice.org-2. Any tips? Regards, Serguey. From owner-freebsd-current@FreeBSD.ORG Tue Jul 10 17:05:12 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 380DA16A421 for ; Tue, 10 Jul 2007 17:05:12 +0000 (UTC) (envelope-from casper@web.am) Received: from mx1.web.am (mx1.web.am [217.113.0.68]) by mx1.freebsd.org (Postfix) with ESMTP id 9F3B513C46E for ; Tue, 10 Jul 2007 17:05:11 +0000 (UTC) (envelope-from casper@web.am) Received: from antispam (localhost.web.am [127.0.0.1]) by localhost (Postfix) with ESMTP id 69D2061C32 for ; Tue, 10 Jul 2007 22:04:28 +0500 (AMST) Received: from localhost (localhost.web.am [127.0.0.1]) by localhost (Postfix) with SMTP id 576E661C29; Tue, 10 Jul 2007 22:04:27 +0500 (AMST) Received: from aldan.web.am (unknown [217.113.1.123]) by mx1.web.am (Postfix) with ESMTP id E712D61C05; Tue, 10 Jul 2007 22:04:26 +0500 (AMST) Message-ID: <4693BC3E.1050605@web.am> Date: Tue, 10 Jul 2007 22:05:02 +0500 From: Gaspar Chilingarov User-Agent: Thunderbird 2.0.0.4 (X11/20070619) MIME-Version: 1.0 To: Doug Barton , freebsd-current@freebsd.org References: <20070419133550.GA65054@tirith.brixandersen.dk> <4627C342.2010103@FreeBSD.org> <20070419200929.GA70735@tirith.brixandersen.dk> In-Reply-To: <20070419200929.GA70735@tirith.brixandersen.dk> Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on mx1.web.am X-Spam-Status: No, hits=0.0 required=7.5 tests=none autolearn=no version=2.60 X-Spam-Level: Cc: Subject: Re: RFT: bin/106642: [patch] Allow excluding certain files from mergemaster(8) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2007 17:05:12 -0000 Henrik Brix Andersen wrote: > Hi Doug, > > On Thu, Apr 19, 2007 at 12:30:10PM -0700, Doug Barton wrote: >> This is a slightly easier way of doing something that can already be >> done easily in other ways, so I have given it a very low priority. > > That's perfectly ok with me - I just wondered when I didn't hear from > you for 4 months :) > > While it is true that there are other ways of doing this, it would be > nice to have generic support for this in the official mergemaster(8) - > especially given the limited complexity of the patch, imho. > >> My goal is to review the various suggestions for accomplishing what >> you're suggesting, and then to incorporate the best one(s). While I >> appreciate your enthusiasm, this isn't something that is any way shape >> or form "urgent." > > Thanks. I appreciate you taking the time to get this done right, and I > look forward to seeing this - or a similar - feature being added to > mergemaster(8). Is it possible to have also some configuration for mergemaster to tell it that some files should be installed automatically without asking -- thus I know that I NEVER change /etc/rc.d/ or /etc/mtree or something like this -- so I wish to avoid mergemaster's questions about installing that files. Yes, I know, that this way I can shoot myself in the foot. If this suggestion seems reasonable -- I can write small patch to mergemaster. /Gaspar -- Gaspar Chilingarov System Administrator, Network security consulting t +37493 419763 (mob) i 63174784 e nm@web.am w http://zanazan.am/ From owner-freebsd-current@FreeBSD.ORG Tue Jul 10 17:16:37 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5E07216A41F for ; Tue, 10 Jul 2007 17:16:37 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [83.98.131.211]) by mx1.freebsd.org (Postfix) with ESMTP id 26DFF13C457 for ; Tue, 10 Jul 2007 17:16:36 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id 73FC01CCCF; Tue, 10 Jul 2007 19:16:31 +0200 (CEST) Date: Tue, 10 Jul 2007 19:16:31 +0200 From: Ed Schouten To: FreeBSD Current Message-ID: <20070710171631.GF55449@hoeg.nl> References: <20070710165606.GE55449@hoeg.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="8S1fMsFYqgBC+BN/" Content-Disposition: inline In-Reply-To: <20070710165606.GE55449@hoeg.nl> User-Agent: Mutt/1.5.16 (2007-06-09) Subject: D_NEEDGIANT usage in dev/io/iodev.c X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2007 17:16:37 -0000 --8S1fMsFYqgBC+BN/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello, The same applies to dev/io/iodev.c; according to sys/proc.h, td->td_frame (used in ioopen() and ioclose()) is only accessed by curthread, which means we can use it without acquiring Giant. Yours, --=20 Ed Schouten WWW: http://g-rave.nl/ --8S1fMsFYqgBC+BN/ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGk77v52SDGA2eCwURAsxKAJ43vMLhVXgMtKLnVOLUQtndyDmlJACfes6o +eGhGhZgA323UuxJNO+y4mY= =w9X/ -----END PGP SIGNATURE----- --8S1fMsFYqgBC+BN/-- From owner-freebsd-current@FreeBSD.ORG Tue Jul 10 18:15:18 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8135216A479; Tue, 10 Jul 2007 18:15:18 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 52C4F13C4DA; Tue, 10 Jul 2007 18:15:18 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.13.8/8.13.8) with ESMTP id l6AIFH0B053309; Tue, 10 Jul 2007 14:15:17 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.8/8.13.8) with ESMTP id l6AIFHA4057899; Tue, 10 Jul 2007 14:15:17 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 4B62C73068; Tue, 10 Jul 2007 14:15:17 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070710181517.4B62C73068@freebsd-current.sentex.ca> Date: Tue, 10 Jul 2007 14:15:17 -0400 (EDT) X-Virus-Scanned: ClamAV version devel-20070108, clamav-milter version devel-111206 on news X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2007 18:15:18 -0000 TB --- 2007-07-10 16:49:03 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-07-10 16:49:03 - starting HEAD tinderbox run for i386/pc98 TB --- 2007-07-10 16:49:03 - cleaning the object tree TB --- 2007-07-10 16:49:33 - checking out the source tree TB --- 2007-07-10 16:49:33 - cd /tinderbox/HEAD/i386/pc98 TB --- 2007-07-10 16:49:33 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-07-10 16:58:49 - building world (CFLAGS=-O2 -pipe) TB --- 2007-07-10 16:58:49 - cd /src TB --- 2007-07-10 16:58:49 - /usr/bin/make -B buildworld >>> World build started on Tue Jul 10 16:58:50 UTC 2007 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Tue Jul 10 18:13:24 UTC 2007 TB --- 2007-07-10 18:13:24 - generating LINT kernel config TB --- 2007-07-10 18:13:24 - cd /src/sys/pc98/conf TB --- 2007-07-10 18:13:24 - /usr/bin/make -B LINT TB --- 2007-07-10 18:13:24 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-07-10 18:13:24 - cd /src TB --- 2007-07-10 18:13:24 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jul 10 18:13:24 UTC 2007 >>> 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 [...] awk -f /src/sys/tools/makeobjops.awk /src/sys/libkern/iconv_converter_if.m -h awk -f /src/sys/tools/makeobjops.awk /src/sys/opencrypto/cryptodev_if.m -h awk -f /src/sys/tools/makeobjops.awk /src/sys/pci/agp_if.m -h awk -f /src/sys/tools/makeobjops.awk /src/sys/pc98/pc98/canbus_if.m -h rm -f .newdep /usr/bin/make -V CFILES -V SYSTEM_CFILES -V GEN_CFILES | MKDEP_CPP="cc -E" CC="cc" xargs mkdep -a -f .newdep -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ipfilter -I/src/sys/contrib/pf -I/src/sys/dev/ath -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -I/src/sys/dev/em -I/src/sys/gnu/fs/xfs/FreeBSD -I/src/sys/gnu/fs/xfs/FreeBSD/support -I/src/sys/gnu/fs/xfs -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 /src/sys/netgraph/bluetooth/drivers/h4/ng_h4.c:76:2: error: #error "NET_NEEDS_GIANT" mkdep: compile failed *** Error code 1 Stop in /obj/pc98/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-07-10 18:15:16 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-07-10 18:15:16 - ERROR: failed to build lint kernel TB --- 2007-07-10 18:15:16 - tinderbox aborted TB --- 0.91 user 2.84 system 5173.09 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Tue Jul 10 18:37:02 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8B6AE16A468 for ; Tue, 10 Jul 2007 18:37:02 +0000 (UTC) (envelope-from mvoorhis@cs.wpi.edu) Received: from mail1.wpi.edu (MAIL1.WPI.EDU [130.215.36.91]) by mx1.freebsd.org (Postfix) with ESMTP id 30C8E13C458 for ; Tue, 10 Jul 2007 18:37:01 +0000 (UTC) (envelope-from mvoorhis@cs.wpi.edu) Received: from mcafee.wpi.edu (MCAFEE.WPI.EDU [130.215.36.86]) by mail1.wpi.edu (8.14.1/8.14.1) with SMTP id l6AIb1Jw014424; Tue, 10 Jul 2007 14:37:01 -0400 Received: from (130.215.36.186) by mcafee.wpi.edu via smtp id 456c_8c55115a_2f14_11dc_98c4_0013725b2d50; Tue, 10 Jul 2007 15:37:01 -0300 Received: from cs.wpi.edu (CS.WPI.EDU [130.215.28.181]) by SMTP.WPI.EDU (8.13.8/8.13.8) with ESMTP id l6AIb1IJ004205; Tue, 10 Jul 2007 14:37:01 -0400 (envelope-from mvoorhis@cs.wpi.edu) Received: from cs.wpi.edu (localhost [127.0.0.1]) by cs.wpi.edu (8.13.3/8.13.3) with ESMTP id l6AIb050019681; Tue, 10 Jul 2007 14:37:00 -0400 Received: (from mvoorhis@localhost) by cs.wpi.edu (8.13.3/8.13.3/Submit) id l6AIb08F019678; Tue, 10 Jul 2007 14:37:00 -0400 From: Michael C Voorhis MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18067.53708.882974.602732@cs.wpi.edu> Date: Tue, 10 Jul 2007 14:37:00 -0400 To: "Kevin Gerry" In-Reply-To: References: <20070626022444.GA6571@troutmask.apl.washington.edu> <18049.19912.746062.704028@cs.wpi.edu> X-Mailer: VM 7.07 under Emacs 21.4.1 Cc: Michael C Voorhis , freebsd-current@freebsd.org, Steve Kargl Subject: Re: Issues with 'xl0' keeping link (bge0, em0 as well?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2007 18:37:02 -0000 Kevin Gerry writes: > Did you ever have a result to this issue? What's interesting is my em0 NIC > doesn't seem to have the up/down issue that the xl NICs have. For me, the "em0 watchdog timeout" issue on my SMP machine seems to be tied to the onboard em device, which happens to be a PCI-Express device. I plugged in another Intel gigabit card, a PCI-X card (an Intel 82545GM "Pro/1000 MT Server Adapter"), and all my problems have disappeared. I've got my test case running in a while(1) loop, and I haven't had a watchdog reset or an NFS timeout in several hours. As far as I can tell, both cards are supported by the em driver in FreeBSD. I'll be shutting off the PCI-express devices in BIOS and using the PCI-X card. Mike. From owner-freebsd-current@FreeBSD.ORG Tue Jul 10 18:46:00 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4950E16A46B for ; Tue, 10 Jul 2007 18:46:00 +0000 (UTC) (envelope-from cristi@net.utcluj.ro) Received: from bavaria.utcluj.ro (bavaria.utcluj.ro [193.226.5.35]) by mx1.freebsd.org (Postfix) with ESMTP id F117813C44B for ; Tue, 10 Jul 2007 18:45:59 +0000 (UTC) (envelope-from cristi@net.utcluj.ro) Received: from localhost (localhost [127.0.0.1]) by bavaria.utcluj.ro (Postfix) with ESMTP id E105F5083F for ; Tue, 10 Jul 2007 21:13:24 +0300 (EEST) X-Virus-Scanned: by the daemon playing with your mail on bavaria.utcluj.ro Received: from bavaria.utcluj.ro ([127.0.0.1]) by localhost (bavaria.utcluj.ro [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y6WNTCc6cL-V for ; Tue, 10 Jul 2007 21:13:21 +0300 (EEST) Received: from intranet.utcluj.ro (localhost [IPv6:::1]) by bavaria.utcluj.ro (Postfix) with ESMTP id 5BDC85082A for ; Tue, 10 Jul 2007 21:13:21 +0300 (EEST) Received: from c7.campus.utcluj.ro ([193.226.6.226]) (SquirrelMail authenticated user cristiklein) by intranet.utcluj.ro with HTTP; Tue, 10 Jul 2007 21:13:21 +0300 (EEST) Message-ID: <62195.193.226.6.226.1184091201.squirrel@intranet.utcluj.ro> Date: Tue, 10 Jul 2007 21:13:21 +0300 (EEST) From: "Cristian KLEIN" To: freebsd-current@freebsd.org User-Agent: SquirrelMail/1.5.1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-2 Content-Transfer-Encoding: 8bit References: In-Reply-To: Subject: acpi forced suspending panics X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2007 18:46:00 -0000 Hi everybody, I compiled FreeBSD-CURRENT a few days ago on an IBM Thinkpad R51. Whenever I try to suspend the system using Fn+F4, the system will wait 10 seconds then panic: acpi: suspend request timed out, forcing sleep now panic: Trying sleep, but thread marked as sleeping prohibited I have a handwritten backtrace if anybody is interested. I don't know what requires the forced suspend, but the panic is triggered by the following events: * acpi_ReqSleepState() notifies the userspace that the system is going to sleep and initializes a callout, using callout_reset(), which will call acpi_sleep_force() (dev/acpica/acpi.c:2203) * softclock() will mark the current thread as non-sleepable (kern/kern_timeout.c:280) then call acpi_sleep_force(), through the callout mechanism * acpi_sleep_force() will go on, and suspend all devices * some time later, the cardbus driver will call pause() on this very non-sleepable thread (dev/pccbb/pccbb.c:1242), which, naturally, results in a panic. I don't really know how to solve the problem. If I insert THREAD_SLEEPING_OK() in acpi_sleep_force(), then the system will not panic anymore, but it doesn't suspend either and it becomes unusable. Note that the kernel from 7.0-200706 did not have this issue (although it had other). From owner-freebsd-current@FreeBSD.ORG Tue Jul 10 19:07:16 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 163A516A46D for ; Tue, 10 Jul 2007 19:07:16 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.freebsd.org (Postfix) with ESMTP id 7BBCD13C468 for ; Tue, 10 Jul 2007 19:07:15 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.8/8.13.8) with ESMTP id l6AJ7DQF076531; Tue, 10 Jul 2007 15:07:13 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: current@freebsd.org Date: Tue, 10 Jul 2007 15:07:06 -0400 User-Agent: KMail/1.9.6 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200707101507.06713.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Tue, 10 Jul 2007 15:07:13 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.3/3624/Tue Jul 10 13:00:38 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: gnn@freebsd.org Subject: [PATCH] Restore netstat -M functionality X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2007 19:07:16 -0000 The primary purpose of this patch is to restore -M functionality of netstat so that it can pull information out of crash dumps. Right now it just silently pulls stats from the running kernel for functions that use sysctl which is even worse than missing functionality: it lies. It also fixes a subtle bug in the recent IPSEC changes which didn't renumber the N_xxx constants in the name list after removing a symbol which currently breaks all the IPSec stats. The biggest things the patch does are: - Add a global 'live' variable that is true if netstat is running against the live kernel and false if -M has been specified. - Stop abusing the sysctl flag in the protocol tables to hold the protocol number. Instead, the protocol is now its own field in the tables, and it is passed as a separate parameter to the PCB and stat routines rather than overloading the KVM offset parameter. - Don't run PCB or stats functions who don't have a namelist offset if we are being run against a crash dump (!live). - For the inet and unix PCB routines, we generate the same buffer from KVM that the sysctl usually generates complete with the header and trailer. - Don't run bpf stats for !live (before it would just silently always run live). - kread() no longer trashes memory when opening the buffer if there is an error on open and the passed in buffer is smaller than _POSIX2_LINE_MAX. - The multicast routing code doesn't fallback to kvm on live kernels if the sysctl fails. Keeping this made the code rather hairy, and netstat is already tied to the kernel ABI anyway (even when using sysctl's since things like xinpcb contain an inpcb) so any kernels this is run against that have the multicast routing stuff should have the sysctls. - Don't try to dig around in the kernel linker in the netgraph PCB routine for core dumps. One thing not done: - sctp's PCB routine only works on live kernels, it looked rather complicated to generate all the same stuff via KVM. Someone can always add it later if desired though. Other stuff: - Fix the ipsec removal bug where N_xxx for IPSEC stats weren't renumbered. - Use sysctlbyname() everywhere rather than hardcoded mib values. Patch is at http://www.FreeBSD.org/~jhb/patches/netstat_core_7.patch A patch for 6.x is also available as netstat_core.patch Barring any objections/feedback I will be committing this to CVS in a few days (subject to re@ approval of course). -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Jul 10 19:40:04 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5DCF416A41F; Tue, 10 Jul 2007 19:40:04 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 33F2A13C447; Tue, 10 Jul 2007 19:40:04 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.13.8/8.13.8) with ESMTP id l6AJe3AX063229; Tue, 10 Jul 2007 15:40:03 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.8/8.13.8) with ESMTP id l6AJe3CV059978; Tue, 10 Jul 2007 15:40:03 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 1349E73068; Tue, 10 Jul 2007 15:40:02 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070710194003.1349E73068@freebsd-current.sentex.ca> Date: Tue, 10 Jul 2007 15:40:02 -0400 (EDT) X-Virus-Scanned: ClamAV version devel-20070102, clamav-milter version devel-111206 on clamscanner5 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2007 19:40:04 -0000 TB --- 2007-07-10 18:15:17 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-07-10 18:15:17 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2007-07-10 18:15:17 - cleaning the object tree TB --- 2007-07-10 18:15:40 - checking out the source tree TB --- 2007-07-10 18:15:40 - cd /tinderbox/HEAD/powerpc/powerpc TB --- 2007-07-10 18:15:40 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-07-10 18:23:05 - building world (CFLAGS=-O2 -pipe) TB --- 2007-07-10 18:23:05 - cd /src TB --- 2007-07-10 18:23:05 - /usr/bin/make -B buildworld >>> World build started on Tue Jul 10 18:23:06 UTC 2007 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Tue Jul 10 19:38:35 UTC 2007 TB --- 2007-07-10 19:38:35 - generating LINT kernel config TB --- 2007-07-10 19:38:35 - cd /src/sys/powerpc/conf TB --- 2007-07-10 19:38:35 - /usr/bin/make -B LINT TB --- 2007-07-10 19:38:35 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-07-10 19:38:35 - cd /src TB --- 2007-07-10 19:38:35 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jul 10 19:38:35 UTC 2007 >>> 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 [...] awk -f /src/sys/tools/makeobjops.awk /src/sys/opencrypto/cryptodev_if.m -h awk -f /src/sys/tools/makeobjops.awk /src/sys/powerpc/powerpc/mmu_if.m -h awk -f /src/sys/tools/makeobjops.awk /src/sys/powerpc/powerpc/pic_if.m -h awk -f /src/sys/tools/makeobjops.awk /src/sys/dev/ofw/ofw_bus_if.m -h rm -f .newdep /usr/bin/make -V CFILES -V SYSTEM_CFILES -V GEN_CFILES | MKDEP_CPP="cc -E" CC="cc" xargs mkdep -a -f .newdep -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ipfilter -I/src/sys/contrib/pf -I/src/sys/dev/ath -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -I/src/sys/dev/em -I/src/sys/gnu/fs/xfs/FreeBSD -I/src/sys/gnu/fs/xfs/FreeBSD/support -I/src/sys/gnu/fs/xfs -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding /src/sys/netgraph/bluetooth/drivers/h4/ng_h4.c:76:2: error: #error "NET_NEEDS_GIANT" mkdep: compile failed *** Error code 1 Stop in /obj/powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-07-10 19:40:02 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-07-10 19:40:02 - ERROR: failed to build lint kernel TB --- 2007-07-10 19:40:02 - tinderbox aborted TB --- 0.80 user 2.48 system 5085.42 real http://tinderbox.des.no/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Tue Jul 10 19:46:21 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B543C16A469; Tue, 10 Jul 2007 19:46:21 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 8C30013C45D; Tue, 10 Jul 2007 19:46:21 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.13.8/8.13.8) with ESMTP id l6AJkL8U063737; Tue, 10 Jul 2007 15:46:21 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.8/8.13.8) with ESMTP id l6AJkKot065844; Tue, 10 Jul 2007 15:46:20 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id BC52773068; Tue, 10 Jul 2007 15:46:20 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070710194620.BC52773068@freebsd-current.sentex.ca> Date: Tue, 10 Jul 2007 15:46:20 -0400 (EDT) X-Virus-Scanned: ClamAV version devel-20070102, clamav-milter version devel-111206 on clamscanner5 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2007 19:46:21 -0000 TB --- 2007-07-10 17:54:11 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-07-10 17:54:11 - starting HEAD tinderbox run for ia64/ia64 TB --- 2007-07-10 17:54:11 - cleaning the object tree TB --- 2007-07-10 17:54:44 - checking out the source tree TB --- 2007-07-10 17:54:44 - cd /tinderbox/HEAD/ia64/ia64 TB --- 2007-07-10 17:54:44 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-07-10 18:03:00 - building world (CFLAGS=-O2 -pipe) TB --- 2007-07-10 18:03:00 - cd /src TB --- 2007-07-10 18:03:00 - /usr/bin/make -B buildworld >>> World build started on Tue Jul 10 18:03:01 UTC 2007 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Tue Jul 10 19:43:34 UTC 2007 TB --- 2007-07-10 19:43:34 - generating LINT kernel config TB --- 2007-07-10 19:43:34 - cd /src/sys/ia64/conf TB --- 2007-07-10 19:43:34 - /usr/bin/make -B LINT TB --- 2007-07-10 19:43:34 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-07-10 19:43:34 - cd /src TB --- 2007-07-10 19:43:34 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jul 10 19:43:35 UTC 2007 >>> 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 [...] awk -f /src/sys/tools/makeobjops.awk /src/sys/libkern/iconv_converter_if.m -h awk -f /src/sys/tools/makeobjops.awk /src/sys/opencrypto/cryptodev_if.m -h awk -f /src/sys/tools/makeobjops.awk /src/sys/pci/agp_if.m -h awk -f /src/sys/tools/makeobjops.awk /src/sys/dev/acpica/acpi_if.m -h rm -f .newdep /usr/bin/make -V CFILES -V SYSTEM_CFILES -V GEN_CFILES | MKDEP_CPP="cc -E" CC="cc" xargs mkdep -a -f .newdep -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ipfilter -I/src/sys/contrib/pf -I/src/sys/dev/ath -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -I/src/sys/dev/em -I/src/sys/gnu/fs/xfs/FreeBSD -I/src/sys/gnu/fs/xfs/FreeBSD/support -I/src/sys/gnu/fs/xfs -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding /src/sys/netgraph/bluetooth/drivers/h4/ng_h4.c:76:2: error: #error "NET_NEEDS_GIANT" mkdep: compile failed *** Error code 1 Stop in /obj/ia64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-07-10 19:46:20 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-07-10 19:46:20 - ERROR: failed to build lint kernel TB --- 2007-07-10 19:46:20 - tinderbox aborted TB --- 0.84 user 2.69 system 6728.85 real http://tinderbox.des.no/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Tue Jul 10 20:28:03 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 65DFD16A46B for ; Tue, 10 Jul 2007 20:28:03 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with SMTP id 1D85013C4C1 for ; Tue, 10 Jul 2007 20:28:02 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 3026 invoked by uid 399); 10 Jul 2007 20:28:02 -0000 Received: from localhost (HELO ?192.168.0.6?) (dougb@dougbarton.us@127.0.0.1) by localhost with SMTP; 10 Jul 2007 20:28:02 -0000 X-Originating-IP: 127.0.0.1 Message-ID: <4693EBCD.6030609@FreeBSD.org> Date: Tue, 10 Jul 2007 13:27:57 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Gaspar Chilingarov References: <20070419133550.GA65054@tirith.brixandersen.dk> <4627C342.2010103@FreeBSD.org> <20070419200929.GA70735@tirith.brixandersen.dk> <4693BC3E.1050605@web.am> In-Reply-To: <4693BC3E.1050605@web.am> X-Enigmail-Version: 0.95.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: RFT: bin/106642: [patch] Allow excluding certain files from mergemaster(8) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2007 20:28:03 -0000 Gaspar Chilingarov wrote: > Is it possible to have also some configuration for mergemaster to tell > it that some files should be installed automatically without asking -- > thus I know that I NEVER change /etc/rc.d/ or /etc/mtree or something > like this -- so I wish to avoid mergemaster's questions about installing > that files. There are already ways to do this, and the other things mentioned in the thread with scripts that can be called by mergemaster (see the man page for details). I have stated many times in the past that I do not want to add more bloat (more CLI options, more confusion for the users, more ways to shoot yourself in the foot) to what should still be a pretty simple script. What I would welcome (and commit) is someone coding up some example scripts that I could put in /usr/share/examples and then reference in the man page. To date no one has taken on that challenge, so the door's wide open. For example, if you want to accomplish what you described above you could have a script that looks something like this (copied in part from the script I actually use every day): #!/bin/sh # NOTE: No PATH needed, because mm's PATH is already draconian enough case "${PRE_WORLD}" in '') rm -f /etc/rc.d/* rm -f /etc/mtree/* ;; esac Call that as your MM_PRE_COMPARE_SCRIPT and use the -i option and you're all set. Mergemaster has stood the test of 8 years and 4 major releases in part because I insist on keeping it as simple as possible. If someone wants to write up a different solution from scratch that supplies all the bells, whistles, knobs and frobs that people are looking for, please be my guest. But please don't try to teach a pig to sing. It wastes your time, annoys the pig. :) Doug -- This .signature sanitized for your protection From owner-freebsd-current@FreeBSD.ORG Tue Jul 10 20:41:09 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D0E2016A475 for ; Tue, 10 Jul 2007 20:41:09 +0000 (UTC) (envelope-from michiel@boland.org) Received: from neerbosch.nijmegen.internl.net (neerbosch.nijmegen.internl.net [217.149.193.38]) by mx1.freebsd.org (Postfix) with ESMTP id 69DCD13C465 for ; Tue, 10 Jul 2007 20:41:09 +0000 (UTC) (envelope-from michiel@boland.org) Received: from neerbosch.nijmegen.internl.net by neerbosch.nijmegen.internl.net via neerbosch.nijmegen.internl.net [217.149.193.38] with ESMTP id l6AKf8AX019732 (8.13.4/1.4); Tue, 10 Jul 2007 22:41:08 +0200 (MEST) Received: from localhost by neerbosch.nijmegen.internl.net via mboland@localhost with ESMTP id l6AKf8Tq019728 (8.13.4/2.02); Tue, 10 Jul 2007 22:41:08 +0200 (MEST) X-Authentication-Warning: neerbosch.nijmegen.internl.net: mboland owned process doing -bs Date: Tue, 10 Jul 2007 22:41:08 +0200 (MEST) From: Michiel Boland To: freebsd-current@freebsd.org In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: peter@freebsd.org Subject: Re: upgrade 6-STABLE to -CURRENT on sparc64 renders box unusable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2007 20:41:09 -0000 Well, in fact I did manage to debug this further. :) The problem is that on sparc64 and -CURRENT, every executable segfaults in _rtld init_rtld relocate_objects reloc_non_plt mmap __getosreldate It appears that __getosreldate was added five days ago, which may explain why the breakage on sparc64 hasn't been reported yet. (I am ccing peter@ since he committed this.) If I apply the following patch, then rebuild libc, things are more or less ok again. Of course this patch is very suboptimal, I am just trying to point out where the problem is. --- __getosreldate.c.orig 2007-07-10 22:29:02.000000000 +0200 +++ __getosreldate.c 2007-07-10 22:28:20.000000000 +0200 @@ -42,13 +42,10 @@ int __getosreldate(void) { - static int osreldate; + int osreldate; size_t len; int oid[2]; int error, osrel; - - if (osreldate != 0) - return (osreldate); oid[0] = CTL_KERN; oid[1] = KERN_OSRELDATE; From owner-freebsd-current@FreeBSD.ORG Tue Jul 10 20:43:11 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0553E16A474 for ; Tue, 10 Jul 2007 20:43:11 +0000 (UTC) (envelope-from craig@xfoil.gank.org) Received: from ion.gank.org (ion.gank.org [69.55.238.164]) by mx1.freebsd.org (Postfix) with ESMTP id A41C813C4E3 for ; Tue, 10 Jul 2007 20:43:08 +0000 (UTC) (envelope-from craig@xfoil.gank.org) Received: by ion.gank.org (Postfix, from userid 1001) id 4E6591125D; Tue, 10 Jul 2007 15:43:08 -0500 (CDT) Date: Tue, 10 Jul 2007 15:43:05 -0500 From: Craig Boston To: Michael Bushkov , Alexander Leidinger , current@freebsd.org Message-ID: <20070710204304.GA46022@nowhere> Mail-Followup-To: Craig Boston , Michael Bushkov , Alexander Leidinger , current@freebsd.org References: <20070709104152.rsg4v3hjww8woksk@webmail.leidinger.net> <46933969.7050602@freebsd.org> <20070710082622.GC1221@funkthat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070710082622.GC1221@funkthat.com> User-Agent: Mutt/1.4.2.3i Cc: Subject: Re: cached update flaws... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2007 20:43:11 -0000 On Tue, Jul 10, 2007 at 01:26:22AM -0700, John-Mark Gurney wrote: > If you feel that inspired, include it in the man page, but at startup > is not the place for it. Otherwise we'll end up like Linux with startup messages that look like a halftime special. FreeBSD 8.0-CURRENT - 50 user license VFS subsystem sponsored by IBM(R) Genuine Intel(R) CPU detected! Enabling UltraThreading(TM) support. bge0: Thank you for purchasing a ! atapci0: port 0x1f0-0x1f7, irq 14 Built-in disk I/O too slow? Try a 3Ware RAID controller! ;-) (all of the above is completely fictitious of course) From owner-freebsd-current@FreeBSD.ORG Tue Jul 10 20:53:25 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0A4F216A41F for ; Tue, 10 Jul 2007 20:53:25 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [83.98.131.211]) by mx1.freebsd.org (Postfix) with ESMTP id C127813C43E for ; Tue, 10 Jul 2007 20:53:24 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id 9566E1CD6B; Tue, 10 Jul 2007 22:53:14 +0200 (CEST) Date: Tue, 10 Jul 2007 22:53:14 +0200 From: Ed Schouten To: Michiel Boland Message-ID: <20070710205314.GM55449@hoeg.nl> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="OGW1Z2JKiS9bXo17" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.16 (2007-06-09) Cc: FreeBSD Current , peter@freebsd.org Subject: Re: upgrade 6-STABLE to -CURRENT on sparc64 renders box unusable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2007 20:53:25 -0000 --OGW1Z2JKiS9bXo17 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Michiel Boland wrote: > --- __getosreldate.c.orig 2007-07-10 22:29:02.000000000 +0200 > +++ __getosreldate.c 2007-07-10 22:28:20.000000000 +0200 > @@ -42,13 +42,10 @@ > int > __getosreldate(void) > { > - static int osreldate; > + int osreldate; > size_t len; > int oid[2]; > int error, osrel; > - > - if (osreldate !=3D 0) > - return (osreldate); > > oid[0] =3D CTL_KERN; > oid[1] =3D KERN_OSRELDATE; Isn't the problem solved by just initializing osreldate with zero? --=20 Ed Schouten WWW: http://g-rave.nl/ --OGW1Z2JKiS9bXo17 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGk/G652SDGA2eCwURAk7jAJ9cJU2XN6Juw+6NLsvdzLFRdmRGbQCfdvVr w8M+tREdYiKmKWNk8YNG51g= =4/cE -----END PGP SIGNATURE----- --OGW1Z2JKiS9bXo17-- From owner-freebsd-current@FreeBSD.ORG Tue Jul 10 21:09:31 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4DB2F16A421; Tue, 10 Jul 2007 21:09:31 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 24C6A13C44C; Tue, 10 Jul 2007 21:09:31 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.13.8/8.13.8) with ESMTP id l6AL9UlF070860; Tue, 10 Jul 2007 17:09:30 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.8/8.13.8) with ESMTP id l6AL9ULk062430; Tue, 10 Jul 2007 17:09:30 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 1B7C873068; Tue, 10 Jul 2007 17:09:30 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070710210930.1B7C873068@freebsd-current.sentex.ca> Date: Tue, 10 Jul 2007 17:09:29 -0400 (EDT) X-Virus-Scanned: ClamAV version devel-20070108, clamav-milter version devel-111206 on clamscanner1 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2007 21:09:31 -0000 TB --- 2007-07-10 19:40:03 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-07-10 19:40:03 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2007-07-10 19:40:03 - cleaning the object tree TB --- 2007-07-10 19:40:30 - checking out the source tree TB --- 2007-07-10 19:40:30 - cd /tinderbox/HEAD/sparc64/sparc64 TB --- 2007-07-10 19:40:30 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-07-10 19:54:16 - building world (CFLAGS=-O2 -pipe) TB --- 2007-07-10 19:54:16 - cd /src TB --- 2007-07-10 19:54:16 - /usr/bin/make -B buildworld >>> World build started on Tue Jul 10 19:54:19 UTC 2007 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Tue Jul 10 21:07:53 UTC 2007 TB --- 2007-07-10 21:07:53 - generating LINT kernel config TB --- 2007-07-10 21:07:53 - cd /src/sys/sparc64/conf TB --- 2007-07-10 21:07:53 - /usr/bin/make -B LINT TB --- 2007-07-10 21:07:53 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-07-10 21:07:53 - cd /src TB --- 2007-07-10 21:07:53 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jul 10 21:07:54 UTC 2007 >>> 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 [...] awk -f /src/sys/tools/makeobjops.awk /src/sys/libkern/iconv_converter_if.m -h awk -f /src/sys/tools/makeobjops.awk /src/sys/opencrypto/cryptodev_if.m -h awk -f /src/sys/tools/makeobjops.awk /src/sys/dev/ofw/ofw_bus_if.m -h awk -f /src/sys/tools/makeobjops.awk /src/sys/sparc64/pci/ofw_pci_if.m -h rm -f .newdep /usr/bin/make -V CFILES -V SYSTEM_CFILES -V GEN_CFILES | MKDEP_CPP="cc -E" CC="cc" xargs mkdep -a -f .newdep -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ipfilter -I/src/sys/contrib/pf -I/src/sys/dev/ath -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -I/src/sys/dev/em -I/src/sys/gnu/fs/xfs/FreeBSD -I/src/sys/gnu/fs/xfs/FreeBSD/support -I/src/sys/gnu/fs/xfs -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding /src/sys/netgraph/bluetooth/drivers/h4/ng_h4.c:76:2: error: #error "NET_NEEDS_GIANT" mkdep: compile failed *** Error code 1 Stop in /obj/sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-07-10 21:09:29 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-07-10 21:09:29 - ERROR: failed to build lint kernel TB --- 2007-07-10 21:09:29 - tinderbox aborted TB --- 0.77 user 2.51 system 5366.69 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Tue Jul 10 21:09:36 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3D93916A48F for ; Tue, 10 Jul 2007 21:09:36 +0000 (UTC) (envelope-from erwin@mail.droso.net) Received: from mail.droso.net (koala.droso.net [193.88.12.38]) by mx1.freebsd.org (Postfix) with ESMTP id 080B213C459 for ; Tue, 10 Jul 2007 21:09:30 +0000 (UTC) (envelope-from erwin@mail.droso.net) Received: by mail.droso.net (Postfix, from userid 1001) id B2A391CC96; Tue, 10 Jul 2007 22:44:37 +0200 (CEST) Date: Tue, 10 Jul 2007 22:44:37 +0200 From: Erwin Lansing To: Peter Wemm Message-ID: <20070710204437.GG37472@droso.net> Mail-Followup-To: Peter Wemm , current@freebsd.org References: <200707100941.31421.peter@wemm.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vJ/whQCgo58Oj3Wa" Content-Disposition: inline In-Reply-To: <200707100941.31421.peter@wemm.org> X-Operating-System: FreeBSD/i386 6.2-STABLE User-Agent: Mutt/1.5.15 (2007-04-06) Cc: current@freebsd.org Subject: Re: kqueue bug in 7.x with "things" that go away. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2007 21:09:36 -0000 --vJ/whQCgo58Oj3Wa Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 10, 2007 at 09:41:31AM -0700, Peter Wemm wrote: > Initial patch that fixes the crashes: > http://people.freebsd.org/~peter/tty.diff >=20 A quick and dirty backport to 6.2-STABLE (only one slight difference there), solved the panic I was seeing with my Vodafone UMTS/etc. card. Insert the card (GENERIC kernel, with or without ubsa(4) loaded) and removal of the card, would panic the system. This no longer is the case with this patch. Panic here: http://people.freebsd.org/~erwin/vodafone.panic -erwin --=20 Erwin Lansing http://droso.org Security is like an onion. (o_ _o) It's made up of several layers \\\_\ /_/// erwin@FreeBSD.org And it makes you cry. <____) (____> erwin@aauug.dk --vJ/whQCgo58Oj3Wa Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGk++1qy9aWxUlaZARAmuKAKCK3tNTIfV0tRf5471nfr1wVmYB7ACfd/oT lbhvGEquXzPQAKy4Hj7NNg8= =0V39 -----END PGP SIGNATURE----- --vJ/whQCgo58Oj3Wa-- From owner-freebsd-current@FreeBSD.ORG Tue Jul 10 21:11:24 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8822816A41F; Tue, 10 Jul 2007 21:11:24 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 5FCD613C44B; Tue, 10 Jul 2007 21:11:24 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.13.8/8.13.8) with ESMTP id l6ALBNmd070987; Tue, 10 Jul 2007 17:11:23 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.8/8.13.8) with ESMTP id l6ALBNcX043006; Tue, 10 Jul 2007 17:11:23 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id A235873068; Tue, 10 Jul 2007 17:11:23 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070710211123.A235873068@freebsd-current.sentex.ca> Date: Tue, 10 Jul 2007 17:11:23 -0400 (EDT) X-Virus-Scanned: ClamAV version devel-20070102, clamav-milter version devel-111206 on clamscanner3 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on sparc64/sun4v X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2007 21:11:24 -0000 TB --- 2007-07-10 19:46:20 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-07-10 19:46:20 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2007-07-10 19:46:20 - cleaning the object tree TB --- 2007-07-10 19:46:51 - checking out the source tree TB --- 2007-07-10 19:46:51 - cd /tinderbox/HEAD/sparc64/sun4v TB --- 2007-07-10 19:46:51 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-07-10 19:57:40 - building world (CFLAGS=-O2 -pipe) TB --- 2007-07-10 19:57:40 - cd /src TB --- 2007-07-10 19:57:40 - /usr/bin/make -B buildworld >>> World build started on Tue Jul 10 19:57:41 UTC 2007 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Tue Jul 10 21:10:01 UTC 2007 TB --- 2007-07-10 21:10:01 - generating LINT kernel config TB --- 2007-07-10 21:10:01 - cd /src/sys/sun4v/conf TB --- 2007-07-10 21:10:01 - /usr/bin/make -B LINT TB --- 2007-07-10 21:10:01 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-07-10 21:10:01 - cd /src TB --- 2007-07-10 21:10:01 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jul 10 21:10:01 UTC 2007 >>> 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 [...] awk -f /src/sys/tools/makeobjops.awk /src/sys/opencrypto/cryptodev_if.m -h awk -f /src/sys/tools/makeobjops.awk /src/sys/dev/ofw/ofw_bus_if.m -h awk -f /src/sys/tools/makeobjops.awk /src/sys/sparc64/pci/ofw_pci_if.m -h awk -f /src/sys/tools/makeobjops.awk /src/sys/sun4v/mdesc/mdesc_bus_if.m -h rm -f .newdep /usr/bin/make -V CFILES -V SYSTEM_CFILES -V GEN_CFILES | MKDEP_CPP="cc -E" CC="cc" xargs mkdep -a -f .newdep -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ipfilter -I/src/sys/contrib/pf -I/src/sys/dev/ath -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -I/src/sys/dev/em -I/src/sys/gnu/fs/xfs/FreeBSD -I/src/sys/gnu/fs/xfs/FreeBSD/support -I/src/sys/gnu/fs/xfs -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding /src/sys/netgraph/bluetooth/drivers/h4/ng_h4.c:76:2: error: #error "NET_NEEDS_GIANT" mkdep: compile failed *** Error code 1 Stop in /obj/sun4v/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-07-10 21:11:23 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-07-10 21:11:23 - ERROR: failed to build lint kernel TB --- 2007-07-10 21:11:23 - tinderbox aborted TB --- 0.55 user 2.13 system 5102.84 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From owner-freebsd-current@FreeBSD.ORG Tue Jul 10 21:17:02 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2734C16A41F for ; Tue, 10 Jul 2007 21:17:02 +0000 (UTC) (envelope-from bushman@freebsd.org) Received: from mail.r61.net (mail.r61.net [195.208.245.249]) by mx1.freebsd.org (Postfix) with ESMTP id 9399913C483 for ; Tue, 10 Jul 2007 21:17:01 +0000 (UTC) (envelope-from bushman@freebsd.org) Received: from [127.0.0.1] (user-43.81.118.217.in-addr.arpa [217.118.81.43] (may be forged)) (authenticated bits=0) by mail.r61.net (8.14.1/8.14.1) with ESMTP id l6ALEDeN000852; Wed, 11 Jul 2007 01:16:55 +0400 (MSD) (envelope-from bushman@freebsd.org) Message-ID: <4693F690.2000402@freebsd.org> Date: Wed, 11 Jul 2007 01:13:52 +0400 From: Michael Bushkov User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Craig Boston , Michael Bushkov , Alexander Leidinger , current@freebsd.org References: <20070709104152.rsg4v3hjww8woksk@webmail.leidinger.net> <46933969.7050602@freebsd.org> <20070710082622.GC1221@funkthat.com> <20070710204304.GA46022@nowhere> In-Reply-To: <20070710204304.GA46022@nowhere> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: cached update flaws... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2007 21:17:02 -0000 Hey, I've already said Ok :) Craig Boston wrote: > On Tue, Jul 10, 2007 at 01:26:22AM -0700, John-Mark Gurney wrote: >> If you feel that inspired, include it in the man page, but at startup >> is not the place for it. > > Otherwise we'll end up like Linux with startup messages that look like a > halftime special. > > FreeBSD 8.0-CURRENT - 50 user license > VFS subsystem sponsored by IBM(R) > Genuine Intel(R) CPU detected! Enabling UltraThreading(TM) support. > bge0: Thank you for purchasing a ! > atapci0: port 0x1f0-0x1f7, irq 14 > Built-in disk I/O too slow? Try a 3Ware RAID controller! > > ;-) > > (all of the above is completely fictitious of course) > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" -- With best regards, Michael Bushkov Southern Federal University From owner-freebsd-current@FreeBSD.ORG Tue Jul 10 21:27:06 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 753BA16A400 for ; Tue, 10 Jul 2007 21:27:06 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (c220-239-20-82.belrs4.nsw.optusnet.com.au [220.239.20.82]) by mx1.freebsd.org (Postfix) with ESMTP id 00B7613C480 for ; Tue, 10 Jul 2007 21:27:05 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by turion.vk2pj.dyndns.org (8.14.1/8.14.1) with ESMTP id l6ALR4t3019141; Wed, 11 Jul 2007 07:27:04 +1000 (EST) (envelope-from peter@turion.vk2pj.dyndns.org) Received: (from peter@localhost) by turion.vk2pj.dyndns.org (8.14.1/8.14.1/Submit) id l6ALR3FH019140; Wed, 11 Jul 2007 07:27:03 +1000 (EST) (envelope-from peter) Date: Wed, 11 Jul 2007 07:27:03 +1000 From: Peter Jeremy To: Ed Schouten Message-ID: <20070710212703.GS3434@turion.vk2pj.dyndns.org> References: <20070710205314.GM55449@hoeg.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="aZoGpuMECXJckB41" Content-Disposition: inline In-Reply-To: <20070710205314.GM55449@hoeg.nl> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.16 (2007-06-09) Cc: FreeBSD Current Subject: Re: upgrade 6-STABLE to -CURRENT on sparc64 renders box unusable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2007 21:27:06 -0000 --aZoGpuMECXJckB41 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2007-Jul-10 22:53:14 +0200, Ed Schouten wrote: >* Michiel Boland wrote: >> --- __getosreldate.c.orig 2007-07-10 22:29:02.000000000 +0200 >> +++ __getosreldate.c 2007-07-10 22:28:20.000000000 +0200 >> @@ -42,13 +42,10 @@ >> int >> __getosreldate(void) >> { >> - static int osreldate; >Isn't the problem solved by just initializing osreldate with zero? C standard says static variables are initialised to zero. --=20 Peter Jeremy --aZoGpuMECXJckB41 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGk/mn/opHv/APuIcRAv0CAJsGv3zWi+3oL9YbCy/aCLIdaaeN+ACgm/V2 ZntXrcpjgZ+KLtJ4uQMHEno= =1+vs -----END PGP SIGNATURE----- --aZoGpuMECXJckB41-- From owner-freebsd-current@FreeBSD.ORG Tue Jul 10 21:27:06 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 97D5016A421 for ; Tue, 10 Jul 2007 21:27:06 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 4CE7C13C484 for ; Tue, 10 Jul 2007 21:27:06 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from scott-longs-computer.local (phobos.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.8/8.13.8) with ESMTP id l6AL588U093355; Tue, 10 Jul 2007 15:05:08 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <4693F47C.2040409@samsco.org> Date: Tue, 10 Jul 2007 15:05:00 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.4) Gecko/20070509 SeaMonkey/1.1.2 MIME-Version: 1.0 To: Ed Schouten References: <20070710205314.GM55449@hoeg.nl> In-Reply-To: <20070710205314.GM55449@hoeg.nl> X-Enigmail-Version: 0.95.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (pooker.samsco.org [168.103.85.57]); Tue, 10 Jul 2007 15:05:08 -0600 (MDT) X-Spam-Status: No, score=-1.4 required=5.5 tests=ALL_TRUSTED autolearn=failed version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: Michiel Boland , FreeBSD Current , peter@freebsd.org Subject: Re: upgrade 6-STABLE to -CURRENT on sparc64 renders box unusable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2007 21:27:06 -0000 Ed Schouten wrote: > * Michiel Boland wrote: >> --- __getosreldate.c.orig 2007-07-10 22:29:02.000000000 +0200 >> +++ __getosreldate.c 2007-07-10 22:28:20.000000000 +0200 >> @@ -42,13 +42,10 @@ >> int >> __getosreldate(void) >> { >> - static int osreldate; >> + int osreldate; >> size_t len; >> int oid[2]; >> int error, osrel; >> - >> - if (osreldate != 0) >> - return (osreldate); >> >> oid[0] = CTL_KERN; >> oid[1] = KERN_OSRELDATE; > > Isn't the problem solved by just initializing osreldate with zero? > I'm pretty sure that the osreldate should be automatically initialized to zero since it's static. I wonder if this has been broken on sparc64 somehow. Scott From owner-freebsd-current@FreeBSD.ORG Tue Jul 10 21:24:01 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D82BC16A400 for ; Tue, 10 Jul 2007 21:24:01 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (mail.soaustin.net [207.200.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id BC62E13C448 for ; Tue, 10 Jul 2007 21:24:01 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: by mail.soaustin.net (Postfix, from userid 502) id 4C83CE6A; Tue, 10 Jul 2007 16:24:01 -0500 (CDT) Date: Tue, 10 Jul 2007 16:24:01 -0500 To: Steve Kargl Message-ID: <20070710212401.GB20941@soaustin.net> References: <20070710044902.GA62286@troutmask.apl.washington.edu> <20070710155313.GB2730@soaustin.net> <20070710160802.GA66351@troutmask.apl.washington.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070710160802.GA66351@troutmask.apl.washington.edu> User-Agent: Mutt/1.5.9i From: linimon@lonesome.com (Mark Linimon) X-Mailman-Approved-At: Tue, 10 Jul 2007 21:27:37 +0000 Cc: Mark Linimon , freebsd-current@freebsd.org Subject: Re: Closing some old bug reports. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2007 21:24:01 -0000 On Tue, Jul 10, 2007 at 09:08:02AM -0700, Steve Kargl wrote: > On Tue, Jul 10, 2007 at 10:53:13AM -0500, Mark Linimon wrote: > > Done. fwiw, you can always email bugmeister@FreeBSD.org with these > > type of requests and we'll clean them up. > > Then only bugmeister will see the list of PR. Well, true. > > Out of curiosity, did the problems get resolved in later releases, or ...? > > (I only saw the one commit that fixed a problem in the list, but some were > > so old they would not have gotten the auto-annotation from the commit.) > > AFAIK, only one was fixed. I guess what I'm trying to get at is I like to close PRs that are obsoleted by event (unsupported kernel; hardware no longer available) but am concerned about closing ones that are still problems, no matter that they're old. What I have found in the last few years of working through the PR backlog is that the age of a PR does not necessarily correlate with whether the problem has been resolved. (This is especially true for bin/ PRs, where I am still trying to generate more committer interest in resolving them. The kern/ PRs tend to be of two types, "fix for specific problem" and "can't get XYZ to work"; the latter tend to get stale more than the former). We have a long way to go before we could claim that we respond promptly to PRs, and we are going to have to "evolve" ourselves in that direction. We've actually made a great deal of progress on that so far this year. We are doing better at triaging PRs as they come in, and we now have a way to flag a small subset of PRs that the bugbusting team thinks are ready for committer attention. So what I'm saying is that I hope I didn't just close some PRs for legitimate problems just because you're frustrated with the pace of progress :-/ mcl From owner-freebsd-current@FreeBSD.ORG Tue Jul 10 21:36:04 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 29E4916A400 for ; Tue, 10 Jul 2007 21:36:04 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (c220-239-20-82.belrs4.nsw.optusnet.com.au [220.239.20.82]) by mx1.freebsd.org (Postfix) with ESMTP id AC76113C447 for ; Tue, 10 Jul 2007 21:36:03 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by turion.vk2pj.dyndns.org (8.14.1/8.14.1) with ESMTP id l6ALa2d5019244; Wed, 11 Jul 2007 07:36:02 +1000 (EST) (envelope-from peter@turion.vk2pj.dyndns.org) Received: (from peter@localhost) by turion.vk2pj.dyndns.org (8.14.1/8.14.1/Submit) id l6ALa2mU019243; Wed, 11 Jul 2007 07:36:02 +1000 (EST) (envelope-from peter) Date: Wed, 11 Jul 2007 07:36:02 +1000 From: Peter Jeremy To: Andrey Chernov , freebsd-current@freebsd.org Message-ID: <20070710213602.GX3434@turion.vk2pj.dyndns.org> References: <20070703182400.Q1449@baba.farley.org> <20070709145418.T52164@thor.farley.org> <20070710154148.GA22873@nagual.pp.ru> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mXDO3udm/xYWQeMQ" Content-Disposition: inline In-Reply-To: <20070710154148.GA22873@nagual.pp.ru> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.16 (2007-06-09) Cc: Subject: Re: HEADS UP: getenv() and family API change X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2007 21:36:04 -0000 --mXDO3udm/xYWQeMQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2007-Jul-10 19:41:48 +0400, Andrey Chernov wrote: >To say strictly, copying somewhere is not neccessary since this way works= =20 >too: > >static char *s =3D "PATH=3D/bin"; > >putenv(s); I thought the C compiler was still free to place the string into RO memory and/or coalesce it with other strings in that case. Wouldn't the following be clearer (s is forced to be writable): static char s[] =3D "PATH=3D/bin"; putenv(s); --=20 Peter Jeremy --mXDO3udm/xYWQeMQ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGk/vC/opHv/APuIcRAiGnAJ41L/zJhl2kLTk8F/w8gsVmUSwDCgCfUuKX S47P8kNAHlEgFCKC1Zv5gyA= =NaYV -----END PGP SIGNATURE----- --mXDO3udm/xYWQeMQ-- From owner-freebsd-current@FreeBSD.ORG Tue Jul 10 21:49:29 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7F72F16A421; Tue, 10 Jul 2007 21:49:29 +0000 (UTC) (envelope-from michiel@boland.org) Received: from neerbosch.nijmegen.internl.net (neerbosch.nijmegen.internl.net [217.149.193.38]) by mx1.freebsd.org (Postfix) with ESMTP id 16FC713C43E; Tue, 10 Jul 2007 21:49:28 +0000 (UTC) (envelope-from michiel@boland.org) Received: from neerbosch.nijmegen.internl.net by neerbosch.nijmegen.internl.net via neerbosch.nijmegen.internl.net [217.149.193.38] with ESMTP id l6ALnPbb025674 (8.13.4/1.4); Tue, 10 Jul 2007 23:49:25 +0200 (MEST) Received: from localhost by neerbosch.nijmegen.internl.net via mboland@localhost with ESMTP id l6ALnPux025671 (8.13.4/2.02); Tue, 10 Jul 2007 23:49:25 +0200 (MEST) X-Authentication-Warning: neerbosch.nijmegen.internl.net: mboland owned process doing -bs Date: Tue, 10 Jul 2007 23:49:25 +0200 (MEST) From: Michiel Boland To: Scott Long In-Reply-To: <4693F47C.2040409@samsco.org> Message-ID: References: <20070710205314.GM55449@hoeg.nl> <4693F47C.2040409@samsco.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD Current , Ed Schouten , peter@freebsd.org Subject: Re: upgrade 6-STABLE to -CURRENT on sparc64 renders box unusable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2007 21:49:29 -0000 > I'm pretty sure that the osreldate should be automatically initialized > to zero since it's static. I wonder if this has been broken on sparc64 > somehow. I think the problem is that the address of osreldate is offset by _GLOBAL_OFFSET_TABLE_. From owner-freebsd-current@FreeBSD.ORG Tue Jul 10 21:58:59 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2A6EC16A421 for ; Tue, 10 Jul 2007 21:58:59 +0000 (UTC) (envelope-from michiel@boland.org) Received: from neerbosch.nijmegen.internl.net (neerbosch.nijmegen.internl.net [217.149.193.38]) by mx1.freebsd.org (Postfix) with ESMTP id A6C3313C4C5 for ; Tue, 10 Jul 2007 21:58:58 +0000 (UTC) (envelope-from michiel@boland.org) Received: from neerbosch.nijmegen.internl.net by neerbosch.nijmegen.internl.net via neerbosch.nijmegen.internl.net [217.149.193.38] with ESMTP for id l6ALwviT026598 (8.13.4/1.4); Tue, 10 Jul 2007 23:58:57 +0200 (MEST) Received: from localhost by neerbosch.nijmegen.internl.net via mboland@localhost with ESMTP for id l6ALwvkl026595 (8.13.4/2.02); Tue, 10 Jul 2007 23:58:57 +0200 (MEST) X-Authentication-Warning: neerbosch.nijmegen.internl.net: mboland owned process doing -bs Date: Tue, 10 Jul 2007 23:58:57 +0200 (MEST) From: Michiel Boland To: freebsd-current@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: sshd broken with UsePrivilegeSeparation=yes on sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2007 21:58:59 -0000 See subject. It appears that sshd is broken on sparc64 -CURRENT when UsePrivilegeSeparation=yes. Looks like something is broken with respect to file descriptor passing, though I haven't figured out what yet. From owner-freebsd-current@FreeBSD.ORG Tue Jul 10 22:14:33 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8D60916A469 for ; Tue, 10 Jul 2007 22:14:33 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.freebsd.org (Postfix) with ESMTP id 711AE13C4AD for ; Tue, 10 Jul 2007 22:14:33 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.1/8.13.8) with ESMTP id l6AMCxRP070634; Tue, 10 Jul 2007 15:12:59 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.1/8.13.8/Submit) id l6AMCxqu070633; Tue, 10 Jul 2007 15:12:59 -0700 (PDT) (envelope-from sgk) Date: Tue, 10 Jul 2007 15:12:59 -0700 From: Steve Kargl To: Mark Linimon Message-ID: <20070710221259.GA70449@troutmask.apl.washington.edu> References: <20070710044902.GA62286@troutmask.apl.washington.edu> <20070710155313.GB2730@soaustin.net> <20070710160802.GA66351@troutmask.apl.washington.edu> <20070710212401.GB20941@soaustin.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070710212401.GB20941@soaustin.net> User-Agent: Mutt/1.4.2.2i Cc: freebsd-current@freebsd.org Subject: Re: Closing some old bug reports. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2007 22:14:33 -0000 On Tue, Jul 10, 2007 at 04:24:01PM -0500, Mark Linimon wrote: > > So what I'm saying is that I hope I didn't just close some PRs for > legitimate problems just because you're frustrated with the pace of > progress :-/ > 2002/05/27 gnu/38594 Fortran no longer supported. 2005/06/25 standards/82654 C99 long double math functions. Few uses 'em. 2006/01/20 bin/92074 Patch in audit trail never applied(?) 2006/02/02 kern/92742 No longer relevant (to me) 2006/10/26 standards/104841 Long double sqrt not important to most users 2007/05/04 bin/112408 Don Quixote and windmills. 2007/05/25 ports/112999 Found a workaround 2007/05/30 standards/113147 Fix You closed 112408 that may have potential security implications for all users on the system including root. Having broken signal handling in the default shell seems dangerous to me. No, I haven't tried to build an exploit. I've asked more than once to back out the recent import of tcsh 6.15.0. It's clear from the inertia that this is going to happen. -- Steve From owner-freebsd-current@FreeBSD.ORG Tue Jul 10 22:46:22 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 31E1C16A468 for ; Tue, 10 Jul 2007 22:46:22 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (nagual.pp.ru [194.87.13.69]) by mx1.freebsd.org (Postfix) with ESMTP id A2C0B13C4C3 for ; Tue, 10 Jul 2007 22:46:21 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.14.1/8.14.1) with ESMTP id l6AMkJhd031890; Wed, 11 Jul 2007 02:46:19 +0400 (MSD) (envelope-from ache@nagual.pp.ru) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nagual.pp.ru; s=default; t=1184107579; bh=tZdmOjxirnuWWIX5nTrGtgWtJExYtMr1ZX5YlSz kICY=; l=1165; h=Received:Date:From:To:Cc:Subject:Message-ID: Mail-Followup-To:References:MIME-Version:Content-Type: Content-Disposition:In-Reply-To:User-Agent; b=dEfzueZji4+wYSzNIMVR 1g4XGkkCPRIVpc1VowQ3RlP05oEKBquC3hhXli1rqWvq1paKLnQSJdL9gkuWEQC+miY T7q2pALCqMpzk/bSAWXrg7yo2x7nvxeHy6flkOtO/LxkVvnwYatvjhZBe7W/wigqRA0 4O1Q0NAofa7fpMOGY= Received: (from ache@localhost) by nagual.pp.ru (8.14.1/8.14.1/Submit) id l6AMkJm6031889; Wed, 11 Jul 2007 02:46:19 +0400 (MSD) (envelope-from ache) Date: Wed, 11 Jul 2007 02:46:19 +0400 From: Andrey Chernov To: Peter Jeremy Message-ID: <20070710224619.GA31654@nagual.pp.ru> Mail-Followup-To: Andrey Chernov , Peter Jeremy , freebsd-current@freebsd.org References: <20070703182400.Q1449@baba.farley.org> <20070709145418.T52164@thor.farley.org> <20070710154148.GA22873@nagual.pp.ru> <20070710213602.GX3434@turion.vk2pj.dyndns.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="k1lZvvs/B4yU6o8G" Content-Disposition: inline In-Reply-To: <20070710213602.GX3434@turion.vk2pj.dyndns.org> User-Agent: Mutt/1.5.16 (2007-06-09) Cc: freebsd-current@freebsd.org Subject: Re: HEADS UP: getenv() and family API change X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2007 22:46:22 -0000 --k1lZvvs/B4yU6o8G Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jul 11, 2007 at 07:36:02AM +1000, Peter Jeremy wrote: > On 2007-Jul-10 19:41:48 +0400, Andrey Chernov wrote: > >To say strictly, copying somewhere is not neccessary since this way work= s=20 > >too: > > > >static char *s =3D "PATH=3D/bin"; > > > >putenv(s); >=20 > I thought the C compiler was still free to place the string into RO > memory and/or coalesce it with other strings in that case. >=20 > Wouldn't the following be clearer (s is forced to be writable): >=20 > static char s[] =3D "PATH=3D/bin"; >=20 > putenv(s); This two are the same, since there is no "const", so compiler can't put=20 static char *s into RO memory. --=20 http://ache.pp.ru/ --k1lZvvs/B4yU6o8G Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFGlAw7Vg5YK5ZEdN0RAjl8AJwJ85GF5IJkES6KLfdndc5gZRlCeACgmmeM HEca1pnei6L5KKkIOGhnxas= =LM8H -----END PGP SIGNATURE----- --k1lZvvs/B4yU6o8G-- From owner-freebsd-current@FreeBSD.ORG Tue Jul 10 22:58:03 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6509F16A41F for ; Tue, 10 Jul 2007 22:58:03 +0000 (UTC) (envelope-from erikt@midgard.homeip.net) Received: from ch-smtp02.sth.basefarm.net (ch-smtp02.sth.basefarm.net [80.76.149.213]) by mx1.freebsd.org (Postfix) with ESMTP id E474B13C457 for ; Tue, 10 Jul 2007 22:58:02 +0000 (UTC) (envelope-from erikt@midgard.homeip.net) Received: from c83-253-10-135.bredband.comhem.se ([83.253.10.135]:55323 helo=falcon.midgard.homeip.net) by ch-smtp02.sth.basefarm.net with smtp (Exim 4.66) (envelope-from ) id 1I8OeZ-0003WP-9b for freebsd-current@freebsd.org; Wed, 11 Jul 2007 00:58:02 +0200 Received: (qmail 98378 invoked from network); 11 Jul 2007 00:57:52 +0200 Received: from owl.midgard.homeip.net (10.1.5.7) by falcon.midgard.homeip.net with SMTP; 11 Jul 2007 00:57:52 +0200 Received: (qmail 3059 invoked by uid 1001); 11 Jul 2007 00:57:52 +0200 Date: Wed, 11 Jul 2007 00:57:52 +0200 From: Erik Trulsson To: Andrey Chernov , Peter Jeremy , freebsd-current@freebsd.org Message-ID: <20070710225752.GA3000@owl.midgard.homeip.net> Mail-Followup-To: Andrey Chernov , Peter Jeremy , freebsd-current@freebsd.org References: <20070703182400.Q1449@baba.farley.org> <20070709145418.T52164@thor.farley.org> <20070710154148.GA22873@nagual.pp.ru> <20070710213602.GX3434@turion.vk2pj.dyndns.org> <20070710224619.GA31654@nagual.pp.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070710224619.GA31654@nagual.pp.ru> User-Agent: Mutt/1.5.14 (2007-02-12) X-Originating-IP: 83.253.10.135 X-ACL-Warn: Too high rate of unknown addresses received from you X-Scan-Result: No virus found in message 1I8OeZ-0003WP-9b. X-Scan-Signature: ch-smtp02.sth.basefarm.net 1I8OeZ-0003WP-9b d02cd40d6c494ee38f81f265ce8cab90 Cc: Subject: Re: HEADS UP: getenv() and family API change X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2007 22:58:03 -0000 On Wed, Jul 11, 2007 at 02:46:19AM +0400, Andrey Chernov wrote: > On Wed, Jul 11, 2007 at 07:36:02AM +1000, Peter Jeremy wrote: > > On 2007-Jul-10 19:41:48 +0400, Andrey Chernov wrote: > > >To say strictly, copying somewhere is not neccessary since this way works > > >too: > > > > > >static char *s = "PATH=/bin"; > > > > > >putenv(s); > > > > I thought the C compiler was still free to place the string into RO > > memory and/or coalesce it with other strings in that case. > > > > Wouldn't the following be clearer (s is forced to be writable): > > > > static char s[] = "PATH=/bin"; > > > > putenv(s); > > This two are the same, since there is no "const", so compiler can't put > static char *s > into RO memory. Not the pointer, but the string it points to can be put into read-only memory. Example: static char *s = "PATH=/bin"; static char *t = "PATH=/bin"; Here both 's', and 't' can point into read-only memory where the string "PATH=/bin" has been placed. Not only that, they may point to the same place, i.e. there need only be one copy of the string "PATH=/bin" in the program (but there may be two distinct copies if the compiler does not coalesce identical string constants.) If on the other hand you use static char s[] = "PATH=/bin"; static char t[] = "PATH=/bin"; Then 's' and 't' are no longer pointers to a string constant, but arrays that are initialized with the string "PATH=/bin". These arrays are modifiable and distinct - i.e. there will be (at least) two copies of the string "PATH=/bin" in memory. -- Erik Trulsson ertr1013@student.uu.se From owner-freebsd-current@FreeBSD.ORG Tue Jul 10 23:14:30 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BAB8216A41F; Tue, 10 Jul 2007 23:14:30 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 926A913C44B; Tue, 10 Jul 2007 23:14:30 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.13.8/8.13.8) with ESMTP id l6ANEUVg076694; Tue, 10 Jul 2007 19:14:30 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.8/8.13.8) with ESMTP id l6ANEUnK019538; Tue, 10 Jul 2007 19:14:30 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id BF4A773068; Tue, 10 Jul 2007 19:14:29 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070710231429.BF4A773068@freebsd-current.sentex.ca> Date: Tue, 10 Jul 2007 19:14:29 -0400 (EDT) X-Virus-Scanned: ClamAV version devel-20070108, clamav-milter version devel-111206 on news X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2007 23:14:30 -0000 TB --- 2007-07-10 21:15:00 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-07-10 21:15:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2007-07-10 21:15:00 - cleaning the object tree TB --- 2007-07-10 21:15:41 - checking out the source tree TB --- 2007-07-10 21:15:41 - cd /tinderbox/HEAD/amd64/amd64 TB --- 2007-07-10 21:15:41 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-07-10 21:27:02 - building world (CFLAGS=-O2 -pipe) TB --- 2007-07-10 21:27:02 - cd /src TB --- 2007-07-10 21:27:02 - /usr/bin/make -B buildworld >>> World build started on Tue Jul 10 21:27:03 UTC 2007 >>> 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 Tue Jul 10 23:12:28 UTC 2007 TB --- 2007-07-10 23:12:28 - generating LINT kernel config TB --- 2007-07-10 23:12:28 - cd /src/sys/amd64/conf TB --- 2007-07-10 23:12:28 - /usr/bin/make -B LINT TB --- 2007-07-10 23:12:28 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-07-10 23:12:28 - cd /src TB --- 2007-07-10 23:12:28 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jul 10 23:12:28 UTC 2007 >>> 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 [...] awk -f /src/sys/tools/makeobjops.awk /src/sys/libkern/iconv_converter_if.m -h awk -f /src/sys/tools/makeobjops.awk /src/sys/opencrypto/cryptodev_if.m -h awk -f /src/sys/tools/makeobjops.awk /src/sys/pci/agp_if.m -h awk -f /src/sys/tools/makeobjops.awk /src/sys/dev/acpica/acpi_if.m -h rm -f .newdep /usr/bin/make -V CFILES -V SYSTEM_CFILES -V GEN_CFILES | MKDEP_CPP="cc -E" CC="cc" xargs mkdep -a -f .newdep -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ipfilter -I/src/sys/contrib/pf -I/src/sys/dev/ath -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -I/src/sys/dev/em -I/src/sys/gnu/fs/xfs/FreeBSD -I/src/sys/gnu/fs/xfs/FreeBSD/support -I/src/sys/gnu/fs/xfs -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-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding /src/sys/netgraph/bluetooth/drivers/h4/ng_h4.c:76:2: error: #error "NET_NEEDS_GIANT" mkdep: compile failed *** Error code 1 Stop in /obj/amd64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-07-10 23:14:29 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-07-10 23:14:29 - ERROR: failed to build lint kernel TB --- 2007-07-10 23:14:29 - tinderbox aborted TB --- 0.88 user 3.78 system 7168.80 real http://tinderbox.des.no/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Tue Jul 10 23:29:19 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 751AA16A41F for ; Tue, 10 Jul 2007 23:29:19 +0000 (UTC) (envelope-from pieter@degoeje.nl) Received: from smtp.utwente.nl (smtp1.utsp.utwente.nl [130.89.2.8]) by mx1.freebsd.org (Postfix) with ESMTP id ED16E13C465 for ; Tue, 10 Jul 2007 23:29:18 +0000 (UTC) (envelope-from pieter@degoeje.nl) Received: from lux.student.utwente.nl (lux.student.utwente.nl [130.89.170.81]) by smtp.utwente.nl (8.12.10/SuSE Linux 0.7) with ESMTP id l6ANFg1R021897; Wed, 11 Jul 2007 01:15:42 +0200 From: Pieter de Goeje To: freebsd-current@freebsd.org Date: Wed, 11 Jul 2007 01:15:41 +0200 User-Agent: KMail/1.9.7 References: <20070419133550.GA65054@tirith.brixandersen.dk> <20070419200929.GA70735@tirith.brixandersen.dk> <4693BC3E.1050605@web.am> In-Reply-To: <4693BC3E.1050605@web.am> MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200707110115.42139.pieter@degoeje.nl> X-UTwente-MailScanner-Information: Scanned by MailScanner. Contact helpdesk@ITBE.utwente.nl for more information. X-UTwente-MailScanner: Found to be clean X-UTwente-MailScanner-From: pieter@degoeje.nl X-Spam-Status: No Cc: Gaspar Chilingarov Subject: Re: RFT: bin/106642: [patch] Allow excluding certain files from mergemaster (8) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2007 23:29:19 -0000 On Tuesday 10 July 2007, Gaspar Chilingarov wrote: > Is it possible to have also some configuration for mergemaster to tell > it that some files should be installed automatically without asking -- > thus I know that I NEVER change /etc/rc.d/ or /etc/mtree or something > like this -- so I wish to avoid mergemaster's questions about installing > that files. Do you know of mergemaster's -U option? This does (almost) exactly what you want. Regards, Pieter de Goeje From owner-freebsd-current@FreeBSD.ORG Tue Jul 10 23:35:45 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6831116A400 for ; Tue, 10 Jul 2007 23:35:45 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with SMTP id 0A2B013C458 for ; Tue, 10 Jul 2007 23:35:44 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 22540 invoked by uid 399); 10 Jul 2007 23:35:44 -0000 Received: from localhost (HELO ?192.168.0.6?) (dougb@dougbarton.us@127.0.0.1) by localhost with SMTP; 10 Jul 2007 23:35:44 -0000 X-Originating-IP: 127.0.0.1 Message-ID: <469417CB.7010705@FreeBSD.org> Date: Tue, 10 Jul 2007 16:35:39 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Pieter de Goeje References: <20070419133550.GA65054@tirith.brixandersen.dk> <20070419200929.GA70735@tirith.brixandersen.dk> <4693BC3E.1050605@web.am> <200707110115.42139.pieter@degoeje.nl> In-Reply-To: <200707110115.42139.pieter@degoeje.nl> X-Enigmail-Version: 0.95.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Gaspar Chilingarov Subject: Re: RFT: bin/106642: [patch] Allow excluding certain files from mergemaster (8) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2007 23:35:45 -0000 Pieter de Goeje wrote: > On Tuesday 10 July 2007, Gaspar Chilingarov wrote: >> Is it possible to have also some configuration for mergemaster to tell >> it that some files should be installed automatically without asking -- >> thus I know that I NEVER change /etc/rc.d/ or /etc/mtree or something >> like this -- so I wish to avoid mergemaster's questions about installing >> that files. > Do you know of mergemaster's -U option? This does (almost) exactly what you > want. Yeah, that too. :) (Thanks Gordon) Doug -- This .signature sanitized for your protection From owner-freebsd-current@FreeBSD.ORG Wed Jul 11 00:05:15 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D4E3016A400 for ; Wed, 11 Jul 2007 00:05:15 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from mxout5.cac.washington.edu (mxout5.cac.washington.edu [140.142.32.135]) by mx1.freebsd.org (Postfix) with ESMTP id A6D5713C455 for ; Wed, 11 Jul 2007 00:05:14 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from hymn07.u.washington.edu (hymn07.u.washington.edu [140.142.8.53]) by mxout5.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.06) with ESMTP id l6B05EBJ013404 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 10 Jul 2007 17:05:14 -0700 Received: from localhost (localhost [127.0.0.1]) by hymn07.u.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l6B05DXI005820 for ; Tue, 10 Jul 2007 17:05:13 -0700 X-Auth-Received: from [192.55.52.3] by hymn07.u.washington.edu via HTTP; Tue, 10 Jul 2007 17:05:13 PDT Date: Tue, 10 Jul 2007 17:05:13 -0700 (PDT) From: youshi10@u.washington.edu To: current@freebsd.org In-Reply-To: <20070710225752.GA3000@owl.midgard.homeip.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-PMX-Version: 5.3.2.304607, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.7.10.164834 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='NO_REAL_NAME 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' Cc: Subject: Re: HEADS UP: getenv() and family API change X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2007 00:05:15 -0000 On Wed, 11 Jul 2007, Erik Trulsson wrote: > On Wed, Jul 11, 2007 at 02:46:19AM +0400, Andrey Chernov wrote: >> On Wed, Jul 11, 2007 at 07:36:02AM +1000, Peter Jeremy wrote: >>> On 2007-Jul-10 19:41:48 +0400, Andrey Chernov wrote: >>> >To say strictly, copying somewhere is not neccessary since this way works >>> >too: >>> > >>> >static char *s = "PATH=/bin"; >>> > >>> >putenv(s); >>> >>> I thought the C compiler was still free to place the string into RO >>> memory and/or coalesce it with other strings in that case. >>> >>> Wouldn't the following be clearer (s is forced to be writable): >>> >>> static char s[] = "PATH=/bin"; >>> >>> putenv(s); >> >> This two are the same, since there is no "const", so compiler can't put >> static char *s >> into RO memory. > > Not the pointer, but the string it points to can be put into read-only > memory. > > Example: > > static char *s = "PATH=/bin"; > static char *t = "PATH=/bin"; > > > Here both 's', and 't' can point into read-only memory where the string > "PATH=/bin" has been placed. Not only that, they may point to the same > place, i.e. there need only be one copy of the string "PATH=/bin" in > the program (but there may be two distinct copies if the compiler does not > coalesce identical string constants.) > > > If on the other hand you use > > static char s[] = "PATH=/bin"; > static char t[] = "PATH=/bin"; > > > Then 's' and 't' are no longer pointers to a string constant, but arrays > that are initialized with the string "PATH=/bin". These arrays are > modifiable and distinct - i.e. there will be (at least) two copies of the > string "PATH=/bin" in memory. > > > > > -- > > Erik Trulsson > ertr1013@student.uu.se I'm confused what you're referring to as RO memory -- I thought that only const applied in this case: #include int main () { static char *s = "PATH=/bin"; s = "PATH=/sbin"; printf("%s\n", s); return 0; } filc9175[409]% gcc -o try try.c filc9175[410]% ./try PATH=/sbin Doesn't static (in terms of variables) only state that the memory address and values are not to be released to the heap again after the function scope exits? -Garrett From owner-freebsd-current@FreeBSD.ORG Wed Jul 11 00:08:14 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4735A16A400; Wed, 11 Jul 2007 00:08:14 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 1A67E13C4BB; Wed, 11 Jul 2007 00:08:13 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.13.8/8.13.8) with ESMTP id l6B08DEc078537; Tue, 10 Jul 2007 20:08:13 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.8/8.13.8) with ESMTP id l6B08D2f020658; Tue, 10 Jul 2007 20:08:13 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 3A73B73068; Tue, 10 Jul 2007 20:08:13 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070711000813.3A73B73068@freebsd-current.sentex.ca> Date: Tue, 10 Jul 2007 20:08:13 -0400 (EDT) X-Virus-Scanned: ClamAV version devel-20070108, clamav-milter version devel-111206 on clamscanner4 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2007 00:08:14 -0000 TB --- 2007-07-10 22:38:58 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-07-10 22:38:58 - starting HEAD tinderbox run for i386/i386 TB --- 2007-07-10 22:38:58 - cleaning the object tree TB --- 2007-07-10 22:39:33 - checking out the source tree TB --- 2007-07-10 22:39:33 - cd /tinderbox/HEAD/i386/i386 TB --- 2007-07-10 22:39:33 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-07-10 22:48:40 - building world (CFLAGS=-O2 -pipe) TB --- 2007-07-10 22:48:40 - cd /src TB --- 2007-07-10 22:48:40 - /usr/bin/make -B buildworld >>> World build started on Tue Jul 10 22:48:42 UTC 2007 >>> 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 Jul 11 00:06:07 UTC 2007 TB --- 2007-07-11 00:06:07 - generating LINT kernel config TB --- 2007-07-11 00:06:07 - cd /src/sys/i386/conf TB --- 2007-07-11 00:06:07 - /usr/bin/make -B LINT TB --- 2007-07-11 00:06:08 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-07-11 00:06:08 - cd /src TB --- 2007-07-11 00:06:08 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Jul 11 00:06:08 UTC 2007 >>> 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 [...] awk -f /src/sys/tools/makeobjops.awk /src/sys/libkern/iconv_converter_if.m -h awk -f /src/sys/tools/makeobjops.awk /src/sys/opencrypto/cryptodev_if.m -h awk -f /src/sys/tools/makeobjops.awk /src/sys/pci/agp_if.m -h awk -f /src/sys/tools/makeobjops.awk /src/sys/dev/acpica/acpi_if.m -h rm -f .newdep /usr/bin/make -V CFILES -V SYSTEM_CFILES -V GEN_CFILES | MKDEP_CPP="cc -E" CC="cc" xargs mkdep -a -f .newdep -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ipfilter -I/src/sys/contrib/pf -I/src/sys/dev/ath -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -I/src/sys/dev/em -I/src/sys/gnu/fs/xfs/FreeBSD -I/src/sys/gnu/fs/xfs/FreeBSD/support -I/src/sys/gnu/fs/xfs -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 /src/sys/netgraph/bluetooth/drivers/h4/ng_h4.c:76:2: error: #error "NET_NEEDS_GIANT" mkdep: compile failed *** Error code 1 Stop in /obj/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-07-11 00:08:12 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-07-11 00:08:12 - ERROR: failed to build lint kernel TB --- 2007-07-11 00:08:12 - tinderbox aborted TB --- 0.91 user 2.98 system 5353.98 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Wed Jul 11 00:37:54 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D4C2016A41F for ; Wed, 11 Jul 2007 00:37:54 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by mx1.freebsd.org (Postfix) with ESMTP id BFD2313C458 for ; Wed, 11 Jul 2007 00:37:54 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from relay8.apple.com (relay8.apple.com [17.128.113.38]) by mail-out3.apple.com (Postfix) with ESMTP id 83C4FB6A0CD; Tue, 10 Jul 2007 17:37:54 -0700 (PDT) Received: from relay8.apple.com (unknown [127.0.0.1]) by relay8.apple.com (Symantec Mail Security) with ESMTP id 6DAC94008B; Tue, 10 Jul 2007 17:37:54 -0700 (PDT) X-AuditID: 11807126-a20cdbb0000007dd-6e-4694266203a1 Received: from [17.214.13.96] (int-si-a.apple.com [17.128.113.41]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by relay8.apple.com (Apple SCV relay) with ESMTP id 4E9CC4004E; Tue, 10 Jul 2007 17:37:54 -0700 (PDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <94B3BCF3-D490-48A5-8488-2E931E30C07B@mac.com> Content-Transfer-Encoding: 7bit From: Chuck Swiger Date: Tue, 10 Jul 2007 17:37:53 -0700 To: youshi10@u.washington.edu X-Mailer: Apple Mail (2.752.2) X-Brightmail-Tracker: AAAAAA== Cc: current@freebsd.org Subject: Re: HEADS UP: getenv() and family API change X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2007 00:37:54 -0000 On Jul 10, 2007, at 5:05 PM, youshi10@u.washington.edu wrote: > On Wed, 11 Jul 2007, Erik Trulsson wrote: >> Not the pointer, but the string it points to can be put into read- >> only >> memory. >> >> Example: >> >> static char *s = "PATH=/bin"; >> static char *t = "PATH=/bin"; >> >> >> Here both 's', and 't' can point into read-only memory where the >> string >> "PATH=/bin" has been placed. Not only that, they may point to the >> same >> place, i.e. there need only be one copy of the string "PATH=/bin" in >> the program (but there may be two distinct copies if the compiler >> does not >> coalesce identical string constants.) >> >> >> If on the other hand you use >> >> static char s[] = "PATH=/bin"; >> static char t[] = "PATH=/bin"; >> >> >> Then 's' and 't' are no longer pointers to a string constant, but >> arrays >> that are initialized with the string "PATH=/bin". These arrays are >> modifiable and distinct - i.e. there will be (at least) two copies >> of the >> string "PATH=/bin" in memory. >> >> >> >> >> -- >> >> Erik Trulsson >> ertr1013@student.uu.se > > I'm confused what you're referring to as RO memory -- I thought > that only const applied in this case: It means that the string can be placed in a section of the executable file which is loaded with read-only memory protection set so that attempts to write to it fail; ELF calls this .rodata in contrast to the normal .bss and .data sections which contain (respectively) zero- filled memory and preinitialized but writable data. > #include > > int main () { > > static char *s = "PATH=/bin"; > s = "PATH=/sbin"; > > printf("%s\n", s); > > return 0; > > } > > filc9175[409]% gcc -o try try.c > filc9175[410]% ./try > PATH=/sbin > > Doesn't static (in terms of variables) only state that the > memory address and values are not to be released to the heap again > after the function scope exits? static implies that the variables are held in memory address space which is made permanently available, either from pages mapped in from the executable file (that's the .data segment) or from zero-filled heap pages (.bss), rather than going away after the enclosing function has returned. The default automatic scope actually typically uses the stack, not the heap... -- -Chuck From owner-freebsd-current@FreeBSD.ORG Wed Jul 11 00:40:46 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4A99B16A41F; Wed, 11 Jul 2007 00:40:46 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 1C07813C487; Wed, 11 Jul 2007 00:40:45 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.13.8/8.13.8) with ESMTP id l6B0ejVC079602; Tue, 10 Jul 2007 20:40:45 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.8/8.13.8) with ESMTP id l6B0ej3H083495; Tue, 10 Jul 2007 20:40:45 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id D522A73068; Tue, 10 Jul 2007 20:40:44 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070711004044.D522A73068@freebsd-current.sentex.ca> Date: Tue, 10 Jul 2007 20:40:44 -0400 (EDT) X-Virus-Scanned: ClamAV version devel-20070108, clamav-milter version devel-111206 on news X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2007 00:40:46 -0000 TB --- 2007-07-10 23:14:29 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-07-10 23:14:29 - starting HEAD tinderbox run for i386/pc98 TB --- 2007-07-10 23:14:29 - cleaning the object tree TB --- 2007-07-10 23:14:48 - checking out the source tree TB --- 2007-07-10 23:14:48 - cd /tinderbox/HEAD/i386/pc98 TB --- 2007-07-10 23:14:48 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-07-10 23:24:12 - building world (CFLAGS=-O2 -pipe) TB --- 2007-07-10 23:24:12 - cd /src TB --- 2007-07-10 23:24:12 - /usr/bin/make -B buildworld >>> World build started on Tue Jul 10 23:24:14 UTC 2007 >>> 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 Jul 11 00:38:53 UTC 2007 TB --- 2007-07-11 00:38:53 - generating LINT kernel config TB --- 2007-07-11 00:38:53 - cd /src/sys/pc98/conf TB --- 2007-07-11 00:38:53 - /usr/bin/make -B LINT TB --- 2007-07-11 00:38:54 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-07-11 00:38:54 - cd /src TB --- 2007-07-11 00:38:54 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Jul 11 00:38:54 UTC 2007 >>> 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 [...] awk -f /src/sys/tools/makeobjops.awk /src/sys/libkern/iconv_converter_if.m -h awk -f /src/sys/tools/makeobjops.awk /src/sys/opencrypto/cryptodev_if.m -h awk -f /src/sys/tools/makeobjops.awk /src/sys/pci/agp_if.m -h awk -f /src/sys/tools/makeobjops.awk /src/sys/pc98/pc98/canbus_if.m -h rm -f .newdep /usr/bin/make -V CFILES -V SYSTEM_CFILES -V GEN_CFILES | MKDEP_CPP="cc -E" CC="cc" xargs mkdep -a -f .newdep -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ipfilter -I/src/sys/contrib/pf -I/src/sys/dev/ath -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -I/src/sys/dev/em -I/src/sys/gnu/fs/xfs/FreeBSD -I/src/sys/gnu/fs/xfs/FreeBSD/support -I/src/sys/gnu/fs/xfs -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 /src/sys/netgraph/bluetooth/drivers/h4/ng_h4.c:76:2: error: #error "NET_NEEDS_GIANT" mkdep: compile failed *** Error code 1 Stop in /obj/pc98/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-07-11 00:40:44 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-07-11 00:40:44 - ERROR: failed to build lint kernel TB --- 2007-07-11 00:40:44 - tinderbox aborted TB --- 0.58 user 1.89 system 5174.73 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Wed Jul 11 01:21:34 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 24A7316A421 for ; Wed, 11 Jul 2007 01:21:34 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from mxout7.cac.washington.edu (mxout7.cac.washington.edu [140.142.32.178]) by mx1.freebsd.org (Postfix) with ESMTP id 0694213C465 for ; Wed, 11 Jul 2007 01:21:34 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from hymn07.u.washington.edu (hymn07.u.washington.edu [140.142.8.53]) by mxout7.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.06) with ESMTP id l6B1LX8T007361 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 10 Jul 2007 18:21:33 -0700 Received: from localhost (localhost [127.0.0.1]) by hymn07.u.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l6B1LXCV021048 for ; Tue, 10 Jul 2007 18:21:33 -0700 X-Auth-Received: from [192.55.52.3] by hymn07.u.washington.edu via HTTP; Tue, 10 Jul 2007 18:21:33 PDT Date: Tue, 10 Jul 2007 18:21:33 -0700 (PDT) From: youshi10@u.washington.edu To: current@freebsd.org In-Reply-To: <94B3BCF3-D490-48A5-8488-2E931E30C07B@mac.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-PMX-Version: 5.3.2.304607, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.7.10.180536 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='NO_REAL_NAME 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' Cc: Subject: Re: HEADS UP: getenv() and family API change X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2007 01:21:34 -0000 On Tue, 10 Jul 2007, Chuck Swiger wrote: > On Jul 10, 2007, at 5:05 PM, youshi10@u.washington.edu wrote: >> On Wed, 11 Jul 2007, Erik Trulsson wrote: >>> Not the pointer, but the string it points to can be put into read-only >>> memory. >>> >>> Example: >>> >>> static char *s = "PATH=/bin"; >>> static char *t = "PATH=/bin"; >>> >>> >>> Here both 's', and 't' can point into read-only memory where the string >>> "PATH=/bin" has been placed. Not only that, they may point to the same >>> place, i.e. there need only be one copy of the string "PATH=/bin" in >>> the program (but there may be two distinct copies if the compiler does not >>> coalesce identical string constants.) >>> >>> >>> If on the other hand you use >>> >>> static char s[] = "PATH=/bin"; >>> static char t[] = "PATH=/bin"; >>> >>> >>> Then 's' and 't' are no longer pointers to a string constant, but arrays >>> that are initialized with the string "PATH=/bin". These arrays are >>> modifiable and distinct - i.e. there will be (at least) two copies of the >>> string "PATH=/bin" in memory. >>> >>> >>> >>> >>> -- >>> >>> Erik Trulsson >>> ertr1013@student.uu.se >> >> I'm confused what you're referring to as RO memory -- I thought that only >> const applied in this case: > > It means that the string can be placed in a section of the executable file > which is loaded with read-only memory protection set so that attempts to write > to it fail; ELF calls this .rodata in contrast to the normal .bss and .data > sections which contain (respectively) zero-filled memory and preinitialized but > writable data. Ok, thanks for the explanation :). >> #include >> >> int main () { >> >> static char *s = "PATH=/bin"; >> s = "PATH=/sbin"; >> >> printf("%s\n", s); >> >> return 0; >> >> } >> >> filc9175[409]% gcc -o try try.c >> filc9175[410]% ./try >> PATH=/sbin >> >> Doesn't static (in terms of variables) only state that the memory >> address and values are not to be released to the heap again after the >> function scope exits? > > static implies that the variables are held in memory address space which is > made permanently available, either from pages mapped in from the executable > file (that's the .data segment) or from zero-filled heap pages (.bss), rather > than going away after the enclosing function has returned. The default > automatic scope actually typically uses the stack, not the heap... > > -- > -Chuck Ok :). -Garrett From owner-freebsd-current@FreeBSD.ORG Wed Jul 11 01:29:30 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4190F16A421 for ; Wed, 11 Jul 2007 01:29:30 +0000 (UTC) (envelope-from silby@silby.com) Received: from relay03.pair.com (relay03.pair.com [209.68.5.17]) by mx1.freebsd.org (Postfix) with SMTP id 97F3913C4AD for ; Wed, 11 Jul 2007 01:29:29 +0000 (UTC) (envelope-from silby@silby.com) Received: (qmail 57230 invoked from network); 11 Jul 2007 01:29:28 -0000 Received: from 209.68.2.70 (HELO localhost) (209.68.2.70) by relay03.pair.com with SMTP; 11 Jul 2007 01:29:28 -0000 X-pair-Authenticated: 209.68.2.70 Date: Tue, 10 Jul 2007 20:29:14 -0500 (CDT) From: Mike Silbersack To: Eygene Ryabinkin In-Reply-To: <20070710132253.GJ1038@void.codelabs.ru> Message-ID: <20070710202028.I34890@odysseus.silby.com> References: <20070709234401.S29353@odysseus.silby.com> <20070710132253.GJ1038@void.codelabs.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Andre Oppermann , Robert Watson , current@freebsd.org, net@freebsd.org Subject: Re: FreeBSD 7 TCP syncache fix: request for testers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2007 01:29:30 -0000 On Tue, 10 Jul 2007, Eygene Ryabinkin wrote: > Can't say that I am pushing much traffic through my box, but after > applying your patch and rebuilding the kernel I am still seeing the > messages like > ----- > TCP: [209.132.176.NNN]:NNN to [144.206.NNN.NNN]:NNN tcpflags 0x19; syncache_expand: Segment failed SYNCOOKIE authentication, segment rejected (probably spoofed) > TCP: [201.90.65.NNN]:NNN to [144.206.NNN.NNN]:NNN; syncache_timer: Response timeout > ----- > But what had changed is that the lines with the 'syncache_timer' > started to appear. There were no such lines prior to the patch, > only the 'failed SYNCOOKIE' ones. The "syncache_timer: Response timeout" message means that the syncache sent a SYN-ACK response four times, but still didn't receive a response. This probably means that someone tried using a port scanner or was going through a faulty firewall. We'll definitely have to take that log message out before 7.0 is released. The fact that you're still getting the syncache_expand message tells me that there's another bug which I have not yet fixed still present. My suspicion is that the "Segment failed SYNCOOKIE authentication" message is the aftereffect of FreeBSD 7 randomly dropping TCP connections, and not the problem itself. My theory is that the connection is silently dropped, without the other endpoint knowing. That other endpoint then sends an ACK packet, which is then believed to be a syncookie. Since it is not, it obviously fails the verification. Finding that bug is my next goal. > But the patch received only half a day of testing, so I will continue > the tests and will inform you if some other information will be > available. Up to date I don't see problems that had appeared without > the patch, but they tend to show up after a midnight ;)) > > Thank you! Thanks for testing, I look forward to hearing how things work for you. Mike "Silby" Silbersack From owner-freebsd-current@FreeBSD.ORG Wed Jul 11 01:58:33 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E4E1B16A400; Wed, 11 Jul 2007 01:58:32 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id BD21613C44C; Wed, 11 Jul 2007 01:58:32 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.13.8/8.13.8) with ESMTP id l6B1wWFf082624; Tue, 10 Jul 2007 21:58:32 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.8/8.13.8) with ESMTP id l6B1wWcM029046; Tue, 10 Jul 2007 21:58:32 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id CDFAF73068; Tue, 10 Jul 2007 21:58:31 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070711015831.CDFAF73068@freebsd-current.sentex.ca> Date: Tue, 10 Jul 2007 21:58:31 -0400 (EDT) X-Virus-Scanned: ClamAV version devel-20070108, clamav-milter version devel-111206 on clamscanner2 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2007 01:58:33 -0000 TB --- 2007-07-11 00:08:13 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-07-11 00:08:13 - starting HEAD tinderbox run for ia64/ia64 TB --- 2007-07-11 00:08:13 - cleaning the object tree TB --- 2007-07-11 00:08:31 - checking out the source tree TB --- 2007-07-11 00:08:31 - cd /tinderbox/HEAD/ia64/ia64 TB --- 2007-07-11 00:08:31 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-07-11 00:15:51 - building world (CFLAGS=-O2 -pipe) TB --- 2007-07-11 00:15:51 - cd /src TB --- 2007-07-11 00:15:51 - /usr/bin/make -B buildworld >>> World build started on Wed Jul 11 00:15:52 UTC 2007 >>> 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 Jul 11 01:56:49 UTC 2007 TB --- 2007-07-11 01:56:49 - generating LINT kernel config TB --- 2007-07-11 01:56:49 - cd /src/sys/ia64/conf TB --- 2007-07-11 01:56:49 - /usr/bin/make -B LINT TB --- 2007-07-11 01:56:49 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-07-11 01:56:49 - cd /src TB --- 2007-07-11 01:56:49 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Jul 11 01:56:49 UTC 2007 >>> 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 [...] awk -f /src/sys/tools/makeobjops.awk /src/sys/libkern/iconv_converter_if.m -h awk -f /src/sys/tools/makeobjops.awk /src/sys/opencrypto/cryptodev_if.m -h awk -f /src/sys/tools/makeobjops.awk /src/sys/pci/agp_if.m -h awk -f /src/sys/tools/makeobjops.awk /src/sys/dev/acpica/acpi_if.m -h rm -f .newdep /usr/bin/make -V CFILES -V SYSTEM_CFILES -V GEN_CFILES | MKDEP_CPP="cc -E" CC="cc" xargs mkdep -a -f .newdep -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ipfilter -I/src/sys/contrib/pf -I/src/sys/dev/ath -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -I/src/sys/dev/em -I/src/sys/gnu/fs/xfs/FreeBSD -I/src/sys/gnu/fs/xfs/FreeBSD/support -I/src/sys/gnu/fs/xfs -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding /src/sys/netgraph/bluetooth/drivers/h4/ng_h4.c:76:2: error: #error "NET_NEEDS_GIANT" mkdep: compile failed *** Error code 1 Stop in /obj/ia64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-07-11 01:58:31 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-07-11 01:58:31 - ERROR: failed to build lint kernel TB --- 2007-07-11 01:58:31 - tinderbox aborted TB --- 0.48 user 1.80 system 6618.23 real http://tinderbox.des.no/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Wed Jul 11 02:22:19 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DA5E716A474 for ; Wed, 11 Jul 2007 02:22:19 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (c220-239-20-82.belrs4.nsw.optusnet.com.au [220.239.20.82]) by mx1.freebsd.org (Postfix) with ESMTP id 4376C13C45A for ; Wed, 11 Jul 2007 02:22:18 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by turion.vk2pj.dyndns.org (8.14.1/8.14.1) with ESMTP id l6B2MHHc020141; Wed, 11 Jul 2007 12:22:17 +1000 (EST) (envelope-from peter@turion.vk2pj.dyndns.org) Received: (from peter@localhost) by turion.vk2pj.dyndns.org (8.14.1/8.14.1/Submit) id l6B2MHAe020140; Wed, 11 Jul 2007 12:22:17 +1000 (EST) (envelope-from peter) Date: Wed, 11 Jul 2007 12:22:17 +1000 From: Peter Jeremy To: Andrey Chernov , freebsd-current@freebsd.org Message-ID: <20070711022217.GA19840@turion.vk2pj.dyndns.org> References: <20070703182400.Q1449@baba.farley.org> <20070709145418.T52164@thor.farley.org> <20070710154148.GA22873@nagual.pp.ru> <20070710213602.GX3434@turion.vk2pj.dyndns.org> <20070710224619.GA31654@nagual.pp.ru> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jRHKVT23PllUwdXP" Content-Disposition: inline In-Reply-To: <20070710224619.GA31654@nagual.pp.ru> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.16 (2007-06-09) Cc: Subject: Re: HEADS UP: getenv() and family API change X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2007 02:22:19 -0000 --jRHKVT23PllUwdXP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2007-Jul-11 02:46:19 +0400, Andrey Chernov wrote: >On Wed, Jul 11, 2007 at 07:36:02AM +1000, Peter Jeremy wrote: >> On 2007-Jul-10 19:41:48 +0400, Andrey Chernov wrote: >> >To say strictly, copying somewhere is not neccessary since this way wor= ks=20 >> >too: >> > >> >static char *s =3D "PATH=3D/bin"; >> > >> >putenv(s); >>=20 >> I thought the C compiler was still free to place the string into RO >> memory and/or coalesce it with other strings in that case. >>=20 >> Wouldn't the following be clearer (s is forced to be writable): >>=20 >> static char s[] =3D "PATH=3D/bin"; >>=20 >> putenv(s); > >This two are the same, since there is no "const", so compiler can't put=20 >static char *s >into RO memory. Maybe that's the theory but neither gcc 4.2.0 (as in -current) or gcc 3.4.6 (as in 6-stable) work that way. The following program shows that both 's' and 't' are initialised to point to the same read-only string. ----8<------ #include int main () { static char *s =3D "PATH=3D/bin"; static char *t =3D "PATH=3D/bin"; static char u[] =3D "PATH=3D/bin"; if (s =3D=3D t) printf("s & t are common\n"); s =3D "PATH=3D/sbin"; printf("%s\n", s); u[4] =3D ':'; printf("u=3D\"%s\"\n", u); t[4] =3D ':'; printf("t=3D\"%s\"\n", t); s[4] =3D ':'; printf("s=3D\"%s\"\n", s); return 0; } ----8<------ gives the following results (-current shown, 6-stable is the same): cc -O2 -fno-strict-aliasing -pipe -march=3Dathlon-xp x.c -o x server% ./x s & t are common PATH=3D/sbin u=3D"PATH:/bin" zsh: segmentation fault (core dumped) ./x server% gcc -v Using built-in specs. Target: i386-undermydesk-freebsd Configured with: FreeBSD/i386 system compiler Thread model: posix gcc version 4.2.0 20070514 [FreeBSD] server%=20 --=20 Peter Jeremy --jRHKVT23PllUwdXP Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGlD7Z/opHv/APuIcRAoo/AJ93bYmcX1mkNEkrRnwiRWydKzSnRQCcDT5A tXQa5LhMIo/kKrjAGsDD5Rg= =4D42 -----END PGP SIGNATURE----- --jRHKVT23PllUwdXP-- From owner-freebsd-current@FreeBSD.ORG Wed Jul 11 02:58:23 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AA82B16A421 for ; Wed, 11 Jul 2007 02:58:23 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (nagual.pp.ru [194.87.13.69]) by mx1.freebsd.org (Postfix) with ESMTP id 2A65B13C483 for ; Wed, 11 Jul 2007 02:58:22 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.14.1/8.14.1) with ESMTP id l6B2wLaP035717; Wed, 11 Jul 2007 06:58:21 +0400 (MSD) (envelope-from ache@nagual.pp.ru) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nagual.pp.ru; s=default; t=1184122701; bh=ZtWyXiIDbLl1MkpzfyF/rhnPEfFO9uylxh8AZgY +9gE=; l=1128; h=Received:Date:From:To:Subject:Message-ID: Mail-Followup-To:References:MIME-Version:Content-Type: Content-Disposition:In-Reply-To:User-Agent; b=FGROEYLPe0pqoZuhd4NY NsDFtPuzk+uX3HRplo2la0V9v0ZMM9BjRI74gulXY8qYWGjOyffcSwsUmA9ZjzaSaJj FRTr8B/kAXgU+QTifBD1zui2EUiCzo37ZUvY8nTRJVBwJDESyR7YigoZH6GlhsmgyM2 14Nod53VwUpqnBFw4= Received: (from ache@localhost) by nagual.pp.ru (8.14.1/8.14.1/Submit) id l6B2wLdg035716; Wed, 11 Jul 2007 06:58:21 +0400 (MSD) (envelope-from ache) Date: Wed, 11 Jul 2007 06:58:21 +0400 From: Andrey Chernov To: Peter Jeremy , freebsd-current@freebsd.org Message-ID: <20070711025820.GA35503@nagual.pp.ru> Mail-Followup-To: Andrey Chernov , Peter Jeremy , freebsd-current@freebsd.org References: <20070703182400.Q1449@baba.farley.org> <20070709145418.T52164@thor.farley.org> <20070710154148.GA22873@nagual.pp.ru> <20070710213602.GX3434@turion.vk2pj.dyndns.org> <20070710224619.GA31654@nagual.pp.ru> <20070710225752.GA3000@owl.midgard.homeip.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070710225752.GA3000@owl.midgard.homeip.net> User-Agent: Mutt/1.5.16 (2007-06-09) Cc: Subject: Re: HEADS UP: getenv() and family API change X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2007 02:58:23 -0000 On Wed, Jul 11, 2007 at 12:57:52AM +0200, Erik Trulsson wrote: > Not the pointer, but the string it points to can be put into read-only > memory. > > Example: > > static char *s = "PATH=/bin"; > static char *t = "PATH=/bin"; > > > Here both 's', and 't' can point into read-only memory where the string > "PATH=/bin" has been placed. Not only that, they may point to the same > place, i.e. there need only be one copy of the string "PATH=/bin" in > the program (but there may be two distinct copies if the compiler does not > coalesce identical string constants.) > > > If on the other hand you use > > static char s[] = "PATH=/bin"; > static char t[] = "PATH=/bin"; > > > Then 's' and 't' are no longer pointers to a string constant, but arrays > that are initialized with the string "PATH=/bin". These arrays are > modifiable and distinct - i.e. there will be (at least) two copies of the > string "PATH=/bin" in memory. Yes, I agree. Moreover, currently gcc 4.2.0 coalesce "char *" pointed to identical string constants and move them to .rodata, so s[] way is better. -- http://ache.pp.ru/ From owner-freebsd-current@FreeBSD.ORG Wed Jul 11 03:25:57 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B391616A400 for ; Wed, 11 Jul 2007 03:25:57 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from heff.fud.org.nz (203-109-251-39.static.bliink.ihug.co.nz [203.109.251.39]) by mx1.freebsd.org (Postfix) with ESMTP id 12EBB13C455 for ; Wed, 11 Jul 2007 03:25:57 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: by heff.fud.org.nz (Postfix, from userid 1001) id A298A1CC58; Wed, 11 Jul 2007 15:25:55 +1200 (NZST) Date: Wed, 11 Jul 2007 15:25:55 +1200 From: Andrew Thompson To: Kostik Belousov , freebsd-current@freebsd.org Message-ID: <20070711032555.GA93888@heff.fud.org.nz> References: <20070511020555.GA5097@heff.fud.org.nz> <20070511034942.GE77635@deviant.kiev.zoral.com.ua> <20070511043547.GB5097@heff.fud.org.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070511043547.GB5097@heff.fud.org.nz> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: Subject: Re: SMP panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2007 03:25:57 -0000 On Fri, May 11, 2007 at 04:35:47PM +1200, Andrew Thompson wrote: > On Fri, May 11, 2007 at 06:49:42AM +0300, Kostik Belousov wrote: > > On Fri, May 11, 2007 at 02:05:55PM +1200, Andrew Thompson wrote: > > > Hi, > > > > > > > > > I am having the following panic on my dual p3-500 box. I have tracked it > > > back to this commit[1], a HEAD cvs checkout of '2006-12-06 06:30 UTC' works > > > and '2006-12-06 06:35 UTC' panics. Removing SMP also avoids this panic. > > > = DPL 0, pres 1, def32 1, gran 1 > > > processor eflags = interrupt enabled, resume, IOPL = 0 > > > current process = 1 (swapper) > > > [thread pid 1 tid 100007 ] > > > Stopped at uma_zalloc_arg+0x31: pushl 0(%esi) > > > db> tr > > > Tracing pid 1 tid 100007 td 0xc298d360 > > > uma_zalloc_arg(0,0,2) at uma_zalloc_arg+0x31 > > > vfs_mount_alloc(0,c09a6940,c0913d40,c298d360,c0661a14,...) at vfs_mount_alloc+0x18 > > > devfs_first(c0661a14,c0661a14,0,d3b38d04,c0661a5f,...) at devfs_first+0x36 > > > vfs_mountroot(c298f000,c298d360,0,c0879c93,20,...) at vfs_mountroot+0x3e > > > start_init(0,d3b38d38) at start_init+0x4b > > > fork_exit(c0661a14,0,d3b38d38) at fork_exit+0xa8 > > > fork_trampoline() at fork_trampoline+0x8 > > > --- trap 0x1, eip = 0, esp = 0xd3b38d6c, ebp = 0 --- > > > db> > > Creation of mount_zone in vfs_mount_root() failed, no idea why. > > I have been looking into this and its failing on this section of code > > sys/vm/uma_core.c:uma_zone_slab > if (keg->uk_flags & UMA_ZFLAG_INTERNAL && keg->uk_recurse != 0) > if ((zone != slabzone) && (zone != slabrefzone)) > return (NULL); > > > I am able to boot now if I add (zone != zones) to the list of checks. > This only happens on SMP so is there some race? Is there a fix for this? Andrew From owner-freebsd-current@FreeBSD.ORG Wed Jul 11 04:45:33 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A0BBF16A468 for ; Wed, 11 Jul 2007 04:45:33 +0000 (UTC) (envelope-from snezhko@indorsoft.ru) Received: from indorsoft.ru (indor.net.tomline.ru [213.183.100.90]) by mx1.freebsd.org (Postfix) with ESMTP id 0E18B13C44B for ; Wed, 11 Jul 2007 04:45:31 +0000 (UTC) (envelope-from snezhko@indorsoft.ru) Received: from SNEZHKO by indorsoft.ru (MDaemon.PRO.v7.2.2.R) with ESMTP id md50000219096.msg; Wed, 11 Jul 2007 11:45:24 +0700 From: Victor Snezhko To: Eric Anderson References: <46934301.5080302@fer.hr> <469379DE.2030605@freebsd.org> Date: Wed, 11 Jul 2007 11:45:21 +0700 In-Reply-To: <469379DE.2030605@freebsd.org> (Eric Anderson's message of "Tue, 10 Jul 2007 07:21:50 -0500") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.3 (windows-nt) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Processed: indor.net.tomline.ru, Wed, 11 Jul 2007 11:45:24 +0700 (not processed: spam filter disabled) X-Return-Path: snezhko@indorsoft.ru Cc: freebsd-current@freebsd.org, Ivan Voras Subject: Re: Debugging time X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2007 04:45:33 -0000 Hi, Eric, >>>> For about half a year I have another weirdness with time on my >>>> -current box without vmware, maybe it's somehow has common origins >>>> ... >> When I just reboot FreeBSD, offset doesn't exceed one or two seconds >> (notably, bios takes longer to boot, about 5-10 seconds). When BSD is >> inactive for several hours, number is much bigger. >> >> I neglected to debug this deeply before - I assumed I have overlooked >> something simple, but now that you have reported another issue in the >> similar area, I'll try to collect full information. > > When you say 'inactive', do you mean that you have suspended the > machine in vmware, or it is 'powered off'? My machine isn't on vmware, it's a hardware box. I just power it off. Nevertheless, yesterday all the evening I hadn't internet access - thunderstorm has broken my wires. And guess what - ntpdate couldn't find ntp servers, but the system date was correct anyway. So I guess my issue has something to do with ntpdate. I didn't set any unusual flags, just ntpdate_enable="YES" and ntpdate_hosts="ntp.example.com". As the second invocation of ntpdate (by hand) always reported much offset which is less than a second, I think ntp servers (I tried two or three) is OK too. -- WBR, Victor V. Snezhko E-mail: snezhko@indorsoft.ru From owner-freebsd-current@FreeBSD.ORG Wed Jul 11 06:04:31 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F29C016A46B; Wed, 11 Jul 2007 06:04:30 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from pobox.codelabs.ru (pobox.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id A226413C448; Wed, 11 Jul 2007 06:04:30 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=one; d=codelabs.ru; h=Received:Date:From:To:Cc:Message-ID:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:Sender:X-Spam-Status:Subject; b=HI7NO6lta9Avbq1p2gObXk7MZd7AniavOXlkgISsvE1X6NrseJOIMH4JS1oy+Z9S4NCEz47Rxh6DsjTR5bRrjf3fwzQwguDgMEvYdnyiIoFT0Anq8T+0XQFy53nSOrqe55rKXqkNQ2ib7wop1STmhOI+x1fRehG3TeUQTwjBuZ8=; Received: from void.codelabs.ru (void.codelabs.ru [144.206.177.25]) by pobox.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1I8VJM-0007wC-7S; Wed, 11 Jul 2007 10:04:28 +0400 Date: Wed, 11 Jul 2007 10:04:23 +0400 From: Eygene Ryabinkin To: Mike Silbersack Message-ID: <20070711060423.GV1038@void.codelabs.ru> References: <20070709234401.S29353@odysseus.silby.com> <20070710132253.GJ1038@void.codelabs.ru> <20070710202028.I34890@odysseus.silby.com> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20070710202028.I34890@odysseus.silby.com> Sender: rea-fbsd@codelabs.ru X-Spam-Status: No, score=-3.0 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_00 Cc: Andre Oppermann , Robert Watson , current@freebsd.org, net@freebsd.org Subject: Re: FreeBSD 7 TCP syncache fix: request for testers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2007 06:04:31 -0000 Mike, good day. Tue, Jul 10, 2007 at 08:29:14PM -0500, Mike Silbersack wrote: > The fact that you're still getting the syncache_expand message tells me that > there's another bug which I have not yet fixed still present. > > My suspicion is that the "Segment failed SYNCOOKIE authentication" message is > the aftereffect of FreeBSD 7 randomly dropping TCP connections, and not the > problem itself. My theory is that the connection is silently dropped, without > the other endpoint knowing. That other endpoint then sends an ACK packet, > which is then believed to be a syncookie. Since it is not, it obviously fails > the verification. OK, maybe I have something that can be related to this bug. It provokes another message, 'Spurious RST', but can be correlated with your guess. What is happening is that when one side closes the connection and releases the socket (running -CURRENT) while the other one is still pushing data through the connection, we are getting 'Spurious RST' messages. This happens, because we are checking the 'so->so_state' for the presence of the 'SS_NOFDREF' flag (tcp_input.c, version 1.361, line 1581) and dropping such connections with RST. But the connection was already closed (living in the FIN-WAIT-2 state, to be precise) from that side, so it provokes the debug message. If you're interested, I have the tcpdump trace and the relevant dmesg output for such a session: http://codelabs.ru/fbsd/session-with-close.tar.bz2 It was produced on the lo0 with client connecting to Apache instance and performing the close() on the socket after some (but not all) bytes of HTTP reply were received. > >But the patch received only half a day of testing, so I will continue > >the tests and will inform you if some other information will be > >available. Up to date I don't see problems that had appeared without > >the patch, but they tend to show up after a midnight ;)) > > Thanks for testing, You're welcome ;)) > I look forward to hearing how things work for you. My problem, as usual, showed up after midnight -- the sockets with the weird state: ----- tcp4 0 0 127.0.0.1.* 127.0.0.1.40001 CLOSED tcp4 0 0 127.0.0.1.* 127.0.0.1.40001 CLOSED ----- 127.0.0.1:40001 used to be the real connections to the service on the port 40001, but they lose their port association from the client side and are stuck in the CLOSED state. The effect is that I can not connect to the service listening to 127.0.0.1:40001 anymore. Only service restart helps. Perhaps that can give you some clue. Perhaps not: it may be totally unrelated to the syncache issues :(( This is also documented in the thread http://lists.freebsd.org/pipermail/freebsd-net/2007-June/014406.html Thank you! -- Eygene From owner-freebsd-current@FreeBSD.ORG Wed Jul 11 10:03:50 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E818716A46C for ; Wed, 11 Jul 2007 10:03:50 +0000 (UTC) (envelope-from casper@web.am) Received: from mx1.web.am (mx1.web.am [217.113.0.68]) by mx1.freebsd.org (Postfix) with ESMTP id 5998B13C45B for ; Wed, 11 Jul 2007 10:03:50 +0000 (UTC) (envelope-from casper@web.am) Received: from antispam (localhost.web.am [127.0.0.1]) by localhost (Postfix) with ESMTP id EFD3161C6A for ; Wed, 11 Jul 2007 15:03:08 +0500 (AMST) Received: from localhost (localhost.web.am [127.0.0.1]) by localhost (Postfix) with SMTP id 7F76061C8A; Wed, 11 Jul 2007 15:03:06 +0500 (AMST) Received: from aldan.web.am (unknown [217.113.1.123]) by mx1.web.am (Postfix) with ESMTP id 1E64861C58; Wed, 11 Jul 2007 15:02:53 +0500 (AMST) Message-ID: <4694AAF1.6050302@web.am> Date: Wed, 11 Jul 2007 15:03:29 +0500 From: Gaspar Chilingarov User-Agent: Thunderbird 2.0.0.4 (X11/20070619) MIME-Version: 1.0 To: Doug Barton References: <20070419133550.GA65054@tirith.brixandersen.dk> <20070419200929.GA70735@tirith.brixandersen.dk> <4693BC3E.1050605@web.am> <200707110115.42139.pieter@degoeje.nl> <469417CB.7010705@FreeBSD.org> In-Reply-To: <469417CB.7010705@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on mx1.web.am X-Spam-Status: No, hits=0.0 required=7.5 tests=none autolearn=no version=2.60 X-Spam-Level: Cc: Pieter de Goeje , freebsd-current@freebsd.org Subject: Re: RFT: bin/106642: [patch] Allow excluding certain files from mergemaster (8) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2007 10:03:51 -0000 Doug Barton wrote: > Pieter de Goeje wrote: >> On Tuesday 10 July 2007, Gaspar Chilingarov wrote: >>> Is it possible to have also some configuration for mergemaster to tell >>> it that some files should be installed automatically without asking -- >>> thus I know that I NEVER change /etc/rc.d/ or /etc/mtree or something >>> like this -- so I wish to avoid mergemaster's questions about installing >>> that files. >> Do you know of mergemaster's -U option? This does (almost) exactly what you >> want. > > Yeah, that too. :) (Thanks Gordon) > > Doug > Sure, it's *almost* what I want, but not exactly :). Well another question -- is it possible teach somehow mergemaster, that it should never touch passwd, groups, /etc/ttys or bunch of another files? About pre-script which you suggested, there is another problem -- I MAY have new scripts in /etc/rc.d, but NEVER change the system's scripts. In other hand running rm /etc/rc.d/* before mergermaster's start can render system unusable, if mergemaster will fail for some reason. -- Gaspar Chilingarov System Administrator, Network security consulting t +37493 419763 (mob) i 63174784 e nm@web.am w http://zanazan.am/ From owner-freebsd-current@FreeBSD.ORG Wed Jul 11 10:34:24 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DB12A16A400 for ; Wed, 11 Jul 2007 10:34:24 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from pne-smtpout1-sn1.fre.skanova.net (pne-smtpout1-sn1.fre.skanova.net [81.228.11.98]) by mx1.freebsd.org (Postfix) with ESMTP id 9BD8113C469 for ; Wed, 11 Jul 2007 10:34:24 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from [192.168.1.5] (217.211.83.81) by pne-smtpout1-sn1.fre.skanova.net (7.2.076.2) id 46758F190053756D; Wed, 11 Jul 2007 12:34:23 +0200 In-Reply-To: <4694AAF1.6050302@web.am> References: <20070419133550.GA65054@tirith.brixandersen.dk> <20070419200929.GA70735@tirith.brixandersen.dk> <4693BC3E.1050605@web.am> <200707110115.42139.pieter@degoeje.nl> <469417CB.7010705@FreeBSD.org> <4694AAF1.6050302@web.am> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4C8E02EE-1026-4B2A-90D1-B9227816AA2B@exscape.org> Content-Transfer-Encoding: 7bit From: Thomas Backman Date: Wed, 11 Jul 2007 12:34:19 +0200 To: Gaspar Chilingarov X-Mailer: Apple Mail (2.752.3) Cc: freebsd-current Subject: Re: RFT: bin/106642: [patch] Allow excluding certain files from mergemaster (8) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2007 10:34:24 -0000 On Jul 11, 2007, at 12:03 PM, Gaspar Chilingarov wrote: > In other hand running rm /etc/rc.d/* before mergermaster's start > can render system unusable, if mergemaster will fail for some reason. > > -- > Gaspar Chilingarov What about the opposite, i.e. removing etc/rc.d/* from the temproot? It might be a horrible solution, but it should work, no? ... make installworld mkdir /var/tmp/root cd /usr/src/etc make DESTDIR=/var/tmp/root distrib-dirs distribution cd /var/tmp/root find -d . -type d | xargs rmdir 2>/dev/null rm -rf /var/tmp/root/etc/rc.d mergemaster Obviously, tell mergemaster to use the current temproot. Again, this might be a horrible solution, I don't know. ;) /Thomas From owner-freebsd-current@FreeBSD.ORG Wed Jul 11 12:08:15 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 993C816A469; Wed, 11 Jul 2007 12:08:15 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 6872D13C4BC; Wed, 11 Jul 2007 12:08:15 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 1583F46E5E; Wed, 11 Jul 2007 08:08:15 -0400 (EDT) Date: Wed, 11 Jul 2007 13:08:15 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Mike Silbersack In-Reply-To: <20070710202028.I34890@odysseus.silby.com> Message-ID: <20070711130719.S68820@fledge.watson.org> References: <20070709234401.S29353@odysseus.silby.com> <20070710132253.GJ1038@void.codelabs.ru> <20070710202028.I34890@odysseus.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Andre Oppermann , current@freebsd.org, net@freebsd.org Subject: Re: FreeBSD 7 TCP syncache fix: request for testers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2007 12:08:15 -0000 On Tue, 10 Jul 2007, Mike Silbersack wrote: > On Tue, 10 Jul 2007, Eygene Ryabinkin wrote: > >> Can't say that I am pushing much traffic through my box, but after applying >> your patch and rebuilding the kernel I am still seeing the messages like >> ----- TCP: [209.132.176.NNN]:NNN to [144.206.NNN.NNN]:NNN tcpflags >> 0x19; syncache_expand: Segment failed SYNCOOKIE >> authentication, segment rejected (probably spoofed) TCP: >> [201.90.65.NNN]:NNN to [144.206.NNN.NNN]:NNN; syncache_timer: Response >> timeout ----- But what had changed is that the lines with the >> 'syncache_timer' started to appear. There were no such lines prior to the >> patch, only the 'failed SYNCOOKIE' ones. > > The "syncache_timer: Response timeout" message means that the syncache sent > a SYN-ACK response four times, but still didn't receive a response. This > probably means that someone tried using a port scanner or was going through > a faulty firewall. We'll definitely have to take that log message out > before 7.0 is released. As I mentioned to Andre before he committed the log message support, there needs to be an administrative twiddle for it, and pretty much all need to either be rate-limited or turned off by default when we get to the release. Otherwise they make very easy DoS opportunities, especially for systems with serial consoles. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Wed Jul 11 13:21:53 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A32B516A468 for ; Wed, 11 Jul 2007 13:21:53 +0000 (UTC) (envelope-from mwlucas@bewilderbeast.blackhelicopters.org) Received: from bewilderbeast.blackhelicopters.org (bewilderbeast.blackhelicopters.org [198.22.63.8]) by mx1.freebsd.org (Postfix) with ESMTP id 504AE13C4B7 for ; Wed, 11 Jul 2007 13:21:53 +0000 (UTC) (envelope-from mwlucas@bewilderbeast.blackhelicopters.org) Received: from bewilderbeast.blackhelicopters.org (localhost [127.0.0.1]) by bewilderbeast.blackhelicopters.org (8.14.1/8.13.8) with ESMTP id l6BCwtqm023809 for ; Wed, 11 Jul 2007 08:58:55 -0400 (EDT) (envelope-from mwlucas@bewilderbeast.blackhelicopters.org) Received: (from mwlucas@localhost) by bewilderbeast.blackhelicopters.org (8.14.1/8.13.8/Submit) id l6BCwttO023808 for current@freebsd.org; Wed, 11 Jul 2007 08:58:55 -0400 (EDT) (envelope-from mwlucas) Date: Wed, 11 Jul 2007 08:58:54 -0400 From: "Michael W. Lucas" To: current@freebsd.org Message-ID: <20070711125854.GA23787@bewilderbeast.blackhelicopters.org> Mime-Version: 1.0 Content-Type: text/plain; charset=unknown-8bit Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.4.2.2i X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (bewilderbeast.blackhelicopters.org [127.0.0.1]); Wed, 11 Jul 2007 08:58:55 -0400 (EDT) Cc: Subject: panic: _mtx_lock_sleep: recursed on non-recursive mutex ahc_lock @ /usr/src/sys/dev/aic7xxx/aic7xxx_osm.h:203 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2007 13:21:53 -0000 Hi, Got this panic on a July 4 -current when writing to a SCSI device. I can read just fine, and occasionally write. I can consistently panic the system within 30 seconds by running "fdisk -BI /dev/daX" three or four times. More complicated writes make the panic faster. Full verbose dmesg, etc, in pr/114489. ==ml sardines/boot/kernel;kgdb kernel.symbols /var/crash/vmcore.0 [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd". Unread portion of the kernel message buffer: panic: _mtx_lock_sleep: recursed on non-recursive mutex ahc_lock @ /usr/src/sys/dev/aic7xxx/aic7xxx_osm.h:203 cpuid = 0 KDB: enter: panic Physical memory: 243 MB Dumping 62 MB: 47 31 15 #0 doadump () at pcpu.h:195 195 pcpu.h: No such file or directory. in pcpu.h (kgdb) backtrace #0 doadump () at pcpu.h:195 #1 0xc048c629 in db_fncall (dummy1=-875263368, dummy2=0, dummy3=524358, dummy4=0xcbd489e4 "ÐèHÀ") at /usr/src/sys/ddb/db_command.c:486 #2 0xc048cb95 in db_command_loop () at /usr/src/sys/ddb/db_command.c:401 #3 0xc048e305 in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_main.c:222 #4 0xc0772426 in kdb_trap (type=3, code=0, tf=0xcbd48b88) at /usr/src/sys/kern/subr_kdb.c:502 #5 0xc09faa2b in trap (frame=0xcbd48b88) at /usr/src/sys/i386/i386/trap.c:620 #6 0xc09e053b in calltrap () at /usr/src/sys/i386/i386/exception.s:139 #7 0xc07725a2 in kdb_enter (msg=0xc0a908ed "panic") at cpufunc.h:60 #8 0xc074b954 in panic (fmt=0xc0a8f7ce "_mtx_lock_sleep: recursed on non-recursive mutex %s @ %s:%d\n") at /usr/src/sys/kern/kern_shutdown.c:547 #9 0xc07400b7 in _mtx_lock_sleep (m=0xc228ca30, tid=3255925760, opts=0, file=0xc0a51887 "/usr/src/sys/dev/aic7xxx/aic7xxx_osm.h", line=203) at /usr/src/sys/kern/kern_mutex.c:311 #10 0xc07402df in _mtx_lock_flags (m=0xc228ca30, opts=0, file=0xc0a51887 "/usr/src/sys/dev/aic7xxx/aic7xxx_osm.h", line=203) at /usr/src/sys/kern/kern_mutex.c:187 #11 0xc04c95f7 in ahc_timeout (scb=0xc22a67b0) at aic7xxx_osm.h:203 #12 0xc04d6f1e in ahc_platform_timeout (arg=0xc22a67b0) at aic_osm_lib.c:72 #13 0xc075d1c9 in softclock (dummy=0x0) at /usr/src/sys/kern/kern_timeout.c:281 #14 0xc07308a5 in ithread_loop (arg=0xc2115310) at /usr/src/sys/kern/kern_intr.c:1036 #15 0xc072dd28 in fork_exit (callout=0xc07306f0 , arg=0xc2115310, frame=0xcbd48d38) at /usr/src/sys/kern/kern_fork.c:797 #16 0xc09e05b0 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:205 (kgdb) up 9 #9 0xc07400b7 in _mtx_lock_sleep (m=0xc228ca30, tid=3255925760, opts=0, file=0xc0a51887 "/usr/src/sys/dev/aic7xxx/aic7xxx_osm.h", line=203) at /usr/src/sys/kern/kern_mutex.c:311 311 KASSERT((m->lock_object.lo_flags & LO_RECURSABLE) != 0, -- Michael W. Lucas mwlucas@BlackHelicopters.org, mwlucas@FreeBSD.org http://www.BlackHelicopters.org/~mwlucas/ Coming Soon: "Absolute FreeBSD" -- http://www.AbsoluteFreeBSD.com On 5/4/2007, the TSA kept 3 pairs of my soiled undies "for security reasons." From owner-freebsd-current@FreeBSD.ORG Wed Jul 11 13:22:04 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7003F16A477; Wed, 11 Jul 2007 13:22:04 +0000 (UTC) (envelope-from dwmalone@maths.tcd.ie) Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by mx1.freebsd.org (Postfix) with SMTP id 9BB1313C4CC; Wed, 11 Jul 2007 13:22:03 +0000 (UTC) (envelope-from dwmalone@maths.tcd.ie) Received: from walton.maths.tcd.ie ([134.226.81.10] helo=walton.maths.tcd.ie) by salmon.maths.tcd.ie with SMTP id ; 11 Jul 2007 14:22:02 +0100 (BST) Date: Wed, 11 Jul 2007 14:22:02 +0100 From: David Malone To: Ivan Voras Message-ID: <20070711132202.GA95487@walton.maths.tcd.ie> References: <20070709214216.GA72912@walton.maths.tcd.ie> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i Sender: dwmalone@maths.tcd.ie Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: Debugging times X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2007 13:22:04 -0000 On Tue, Jul 10, 2007 at 12:29:26AM +0200, Ivan Voras wrote: > Yes, I'll test them. > > The problem is - the same kernel works when booted off a hard drive, so > unless the VMWare BIOS is very messed up (it's the first time I see such > problems) it may not help. Please, scatter debug printf's around so I > can see what's going on :) Try the patch at: http://www.maths.tcd.ie/~dwmalone/clock.patch It checks the return values of the various clock reading functions in the kernel and prints an error message if it finds that it can't set the clock OK. Some machines have a BIOS that doesn't count the day-of-week correctly, and recently FreeBSD has started treating this as an error on some platforms. (This patch won't fix anything, but might produce a more informative error message.) David. From owner-freebsd-current@FreeBSD.ORG Wed Jul 11 14:50:40 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 12E9016A41F; Wed, 11 Jul 2007 14:50:40 +0000 (UTC) (envelope-from peter.blok@bsd4all.org) Received: from hatert.nijmegen.internl.net (mailrelay1.nijmegen.internl.net [217.149.192.44]) by mx1.freebsd.org (Postfix) with ESMTP id 95EDD13C4B0; Wed, 11 Jul 2007 14:50:37 +0000 (UTC) (envelope-from peter.blok@bsd4all.org) Received: from smtp20.nijmegen.internl.net by hatert.nijmegen.internl.net via smtp20.nijmegen.internl.net [217.149.192.18] with ESMTP id l6BBxJTU015696 (8.13.6/2.04); Wed, 11 Jul 2007 13:59:19 +0200 (MEST) Received: from mail.bsd4all.org (113-9.bbned.dsl.internl.net [82.215.9.113]) by smtp20.nijmegen.internl.net (8.13.8/2.04) with ESMTP id l6BBxHld016265; Wed, 11 Jul 2007 13:59:17 +0200 (CEST) Received: from localhost (localhost.homebrew.bsd4all.org [127.0.0.1]) by mail.bsd4all.org (Postfix) with ESMTP id 9E8541151E; Wed, 11 Jul 2007 13:59:16 +0200 (CEST) X-Virus-Scanned: amavisd-new at bsd4all.org Received: from mail.bsd4all.org ([127.0.0.1]) by localhost (fwgw.homebrew.bsd4all.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 62SXczRNku34; Wed, 11 Jul 2007 13:59:01 +0200 (CEST) Received: from bsd4all.org (adexlinge10 [192.168.10.16]) by mail.bsd4all.org (Postfix) with ESMTP id 2823B1150E; Wed, 11 Jul 2007 13:59:01 +0200 (CEST) Date: Wed, 11 Jul 2007 13:49:37 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MS-TNEF-Correlator: Thread-Topic: FAST_IPSEC is now IPSEC, please be advised... Thread-Index: Ace9bWLf7Lz0rglzS5WQjb6tKGpYKQGQ42zw Content-class: urn:content-classes:message References: From: "Peter Blok" X-MimeOLE: Produced By Microsoft Exchange V6.5.7235.2 To: , , X-Mailman-Approved-At: Wed, 11 Jul 2007 14:54:41 +0000 Cc: Subject: RE: FAST_IPSEC is now IPSEC, please be advised... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2007 14:50:40 -0000 Hi George, Is somebody looking at ipsec-tools? As far as I can see it requires a lot of kame definitions, although not used most of the times. I have tried to make sense of this, but it wasn't easy. Peter From owner-freebsd-current@FreeBSD.ORG Wed Jul 11 14:58:10 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7DD9B16A400 for ; Wed, 11 Jul 2007 14:58:10 +0000 (UTC) (envelope-from cristi@net.utcluj.ro) Received: from bavaria.utcluj.ro (bavaria.utcluj.ro [193.226.5.35]) by mx1.freebsd.org (Postfix) with ESMTP id 36BB913C457 for ; Wed, 11 Jul 2007 14:58:10 +0000 (UTC) (envelope-from cristi@net.utcluj.ro) Received: from localhost (localhost [127.0.0.1]) by bavaria.utcluj.ro (Postfix) with ESMTP id 2801450834 for ; Wed, 11 Jul 2007 17:58:09 +0300 (EEST) X-Virus-Scanned: by the daemon playing with your mail on bavaria.utcluj.ro Received: from bavaria.utcluj.ro ([127.0.0.1]) by localhost (bavaria.utcluj.ro [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CUxsdr+i4Gzm for ; Wed, 11 Jul 2007 17:58:02 +0300 (EEST) Received: from hades.local (hades.utcluj.ro [193.226.5.46]) by bavaria.utcluj.ro (Postfix) with ESMTP id 964B05082E for ; Wed, 11 Jul 2007 17:58:02 +0300 (EEST) Message-ID: <4694EFF9.2060505@net.utcluj.ro> Date: Wed, 11 Jul 2007 17:58:01 +0300 From: Cristian KLEIN User-Agent: Thunderbird 2.0.0.4 (X11/20070711) MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <62195.193.226.6.226.1184091201.squirrel@intranet.utcluj.ro> In-Reply-To: <62195.193.226.6.226.1184091201.squirrel@intranet.utcluj.ro> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: acpi forced suspending panics X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2007 14:58:10 -0000 Cristian KLEIN wrote: > Hi everybody, > > I compiled FreeBSD-CURRENT a few days ago on an IBM Thinkpad R51. Whenever > I try to suspend the system using Fn+F4, the system will wait 10 seconds > then panic: > > acpi: suspend request timed out, forcing sleep now > panic: Trying sleep, but thread marked as sleeping prohibited > > I have a handwritten backtrace if anybody is interested. I don't know what > requires the forced suspend, but the panic is triggered by the following > events: > > * acpi_ReqSleepState() notifies the userspace that the system is going to > sleep and initializes a callout, using callout_reset(), which will call > acpi_sleep_force() (dev/acpica/acpi.c:2203) > * softclock() will mark the current thread as non-sleepable > (kern/kern_timeout.c:280) then call acpi_sleep_force(), through the > callout mechanism > * acpi_sleep_force() will go on, and suspend all devices > * some time later, the cardbus driver will call pause() on this very > non-sleepable thread (dev/pccbb/pccbb.c:1242), which, naturally, results > in a panic. > > I don't really know how to solve the problem. If I insert > THREAD_SLEEPING_OK() in acpi_sleep_force(), then the system will not panic > anymore, but it doesn't suspend either and it becomes unusable. > > Note that the kernel from 7.0-200706 did not have this issue (although it > had other). This problem was caused by world not being up-to-date, espacially acpiconf, devd and /etc/rc.suspend. Sorry for the noise. There are however other suspending issues which I will highlight in another thread. From owner-freebsd-current@FreeBSD.ORG Wed Jul 11 16:24:56 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0B54E16A46C for ; Wed, 11 Jul 2007 16:24:56 +0000 (UTC) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id E0CED13C487 for ; Wed, 11 Jul 2007 16:24:55 +0000 (UTC) (envelope-from sam@errno.com) Received: from trouble.errno.com (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id l6BGOtRY021175 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 11 Jul 2007 09:24:55 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <469504D2.8000200@errno.com> Date: Wed, 11 Jul 2007 09:26:58 -0700 From: Sam Leffler User-Agent: Thunderbird 2.0.0.0 (X11/20070530) MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: HEADSUP: new wpa_supplicant and hostapd [ndis users read] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2007 16:24:56 -0000 These applications have been updated to the 0.5.8 "stable release" from Jouni Malinen. This gets us back on Jouni's stable release branch (as opposed to the abandoned code base we were using). There are many new features (read the docs in contrib) and you should now be able to use 802.1x over wired nic's though it may not be configured by default (please send patches after testing and I will try stuff updated). ndis support in wpa_supplicant has been tested but requires fixups in the kernel that are pending. However people using ndis should also be aware that the in-kernel ndis support has badly rotted and appears chock-a-block with issues. Unless someone steps up to work on it expect instability. Thanks to Andrew Thompson for patching things up. Sam From owner-freebsd-current@FreeBSD.ORG Wed Jul 11 17:08:33 2007 Return-Path: X-Original-To: Current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 83FA016A400; Wed, 11 Jul 2007 17:08:33 +0000 (UTC) (envelope-from h.schmalzbauer@omnisec.de) Received: from host.omnisec.de (host.omnisec.de [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id F3B7D13C43E; Wed, 11 Jul 2007 17:08:32 +0000 (UTC) (envelope-from h.schmalzbauer@omnisec.de) Received: from tek.flintsbach.schmalzbauer.de (tek.flintsbach.schmalzbauer.de [172.21.2.3]) by host.omnisec.de (8.13.8/8.13.8) with ESMTP id l6BH3sJ2094073 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Jul 2007 19:03:59 +0200 (CEST) (envelope-from h.schmalzbauer@omnisec.de) Received: from titan.flintsbach.schmalzbauer.de (titan.flintsbach.schmalzbauer.de [IPv6:fec0::1:0:0:1:1]) by tek.flintsbach.schmalzbauer.de (8.13.8/8.13.8) with ESMTP id l6BH8Qoj030565; Wed, 11 Jul 2007 19:08:26 +0200 (CEST) (envelope-from h.schmalzbauer@omnisec.de) Received: by titan.flintsbach.schmalzbauer.de (8.14.1/8.14.1/Submit) id l6BH3rhV001260; Wed, 11 Jul 2007 19:03:53 +0200 (CEST) (envelope-from h.schmalzbauer@omnisec.de) From: Harald Schmalzbauer Organization: OmniSEC To: freebsd-current@freebsd.org Date: Wed, 11 Jul 2007 19:03:52 +0200 User-Agent: KMail/1.9.6 References: <468345F2.1060209@freebsd.org> <46838649.3060405@freebsd.org> <46839A99.3030805@freebsd.org> In-Reply-To: <46839A99.3030805@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200707111903.53790.h.schmalzbauer@omnisec.de> Cc: speconly@post.ru, Daichi GOTO , Current@freebsd.org Subject: Re: Nvidia-driver and current lead system reboot with no error message X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2007 17:08:33 -0000 Am Donnerstag, 28. Juni 2007 schrieb Daichi GOTO: > Daichi GOTO wrote: > > speconly@post.ru wrote: > >> On Thu, Jun 28, 2007 at 02:24:02PM +0900, Daichi GOTO wrote: > >>> current (Jun 27 2007) and nvidia-driver (GeForce 7300 GT) lead > >>> system reboot 3d feature used without some error messages, > >>> for example, beryl leads reboot, glxinfo too, and something > >>> like that. 2D features work looks fine. > >>> > >>> Have someone any idea? Thanks. > >> > >> Updating driver to something 100.14.xx didn't solve this? > > > > yeah, alright. 100.14.xx is new nvidia-drvier number. > > > > http://www.nvidia.com/object/unix.html > > > > have you installed manually? or make a new port to install? ;) > > I have tried 100.14.11 and it works great fine :) Thanks! It doesn't compile for me. The #error in nv-freebsd.h was not that problem, but some pci code breaks. Have you had the same error and some workarround? Could you please tell me your patch? Thanks, -Harry From owner-freebsd-current@FreeBSD.ORG Wed Jul 11 17:08:33 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 83FA016A400; Wed, 11 Jul 2007 17:08:33 +0000 (UTC) (envelope-from h.schmalzbauer@omnisec.de) Received: from host.omnisec.de (host.omnisec.de [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id F3B7D13C43E; Wed, 11 Jul 2007 17:08:32 +0000 (UTC) (envelope-from h.schmalzbauer@omnisec.de) Received: from tek.flintsbach.schmalzbauer.de (tek.flintsbach.schmalzbauer.de [172.21.2.3]) by host.omnisec.de (8.13.8/8.13.8) with ESMTP id l6BH3sJ2094073 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Jul 2007 19:03:59 +0200 (CEST) (envelope-from h.schmalzbauer@omnisec.de) Received: from titan.flintsbach.schmalzbauer.de (titan.flintsbach.schmalzbauer.de [IPv6:fec0::1:0:0:1:1]) by tek.flintsbach.schmalzbauer.de (8.13.8/8.13.8) with ESMTP id l6BH8Qoj030565; Wed, 11 Jul 2007 19:08:26 +0200 (CEST) (envelope-from h.schmalzbauer@omnisec.de) Received: by titan.flintsbach.schmalzbauer.de (8.14.1/8.14.1/Submit) id l6BH3rhV001260; Wed, 11 Jul 2007 19:03:53 +0200 (CEST) (envelope-from h.schmalzbauer@omnisec.de) From: Harald Schmalzbauer Organization: OmniSEC To: freebsd-current@freebsd.org Date: Wed, 11 Jul 2007 19:03:52 +0200 User-Agent: KMail/1.9.6 References: <468345F2.1060209@freebsd.org> <46838649.3060405@freebsd.org> <46839A99.3030805@freebsd.org> In-Reply-To: <46839A99.3030805@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200707111903.53790.h.schmalzbauer@omnisec.de> Cc: speconly@post.ru, Daichi GOTO , Current@freebsd.org Subject: Re: Nvidia-driver and current lead system reboot with no error message X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2007 17:08:33 -0000 Am Donnerstag, 28. Juni 2007 schrieb Daichi GOTO: > Daichi GOTO wrote: > > speconly@post.ru wrote: > >> On Thu, Jun 28, 2007 at 02:24:02PM +0900, Daichi GOTO wrote: > >>> current (Jun 27 2007) and nvidia-driver (GeForce 7300 GT) lead > >>> system reboot 3d feature used without some error messages, > >>> for example, beryl leads reboot, glxinfo too, and something > >>> like that. 2D features work looks fine. > >>> > >>> Have someone any idea? Thanks. > >> > >> Updating driver to something 100.14.xx didn't solve this? > > > > yeah, alright. 100.14.xx is new nvidia-drvier number. > > > > http://www.nvidia.com/object/unix.html > > > > have you installed manually? or make a new port to install? ;) > > I have tried 100.14.11 and it works great fine :) Thanks! It doesn't compile for me. The #error in nv-freebsd.h was not that problem, but some pci code breaks. Have you had the same error and some workarround? Could you please tell me your patch? Thanks, -Harry From owner-freebsd-current@FreeBSD.ORG Wed Jul 11 17:24:48 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D039F16A400 for ; Wed, 11 Jul 2007 17:24:48 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from bunrab.catwhisker.org (adsl-63-193-123-122.dsl.snfc21.pacbell.net [63.193.123.122]) by mx1.freebsd.org (Postfix) with ESMTP id 9895D13C457 for ; Wed, 11 Jul 2007 17:24:48 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from bunrab.catwhisker.org (localhost [127.0.0.1]) by bunrab.catwhisker.org (8.13.3/8.13.3) with ESMTP id l6BHOmE5043013 for ; Wed, 11 Jul 2007 10:24:48 -0700 (PDT) (envelope-from david@bunrab.catwhisker.org) Received: (from david@localhost) by bunrab.catwhisker.org (8.13.3/8.13.1/Submit) id l6BHOmZ4043012 for current@freebsd.org; Wed, 11 Jul 2007 10:24:48 -0700 (PDT) (envelope-from david) Date: Wed, 11 Jul 2007 10:24:48 -0700 From: David Wolfskill To: current@freebsd.org Message-ID: <20070711172448.GA42994@bunrab.catwhisker.org> Mail-Followup-To: David Wolfskill , current@freebsd.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="J2SCkAp4GZ/dPZZf" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Cc: Subject: Oddity with an(4): Channel reported by ifconfig is wrong X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2007 17:24:48 -0000 --J2SCkAp4GZ/dPZZf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable This may be an off-by-one issue: I have two APs with the same SSID; one on channel 1; the other on channel 6. But: g1-1(7.0-C)[1] uname -a FreeBSD g1-1.catwhisker.org. 7.0-CURRENT FreeBSD 7.0-CURRENT #480: Wed Jul = 11 09:44:13 PDT 2007 root@g1-1.catwhisker.org.:/common/S4/obj/usr/src/s= ys/CANARY i386 g1-1(7.0-C)[2]=20 g1-1(7.0-C)[3] ifconfig xl0: flags=3D8802 metric 0 mtu 1500 options=3D9 ether 00:08:74:e5:95:cb media: Ethernet autoselect (none) status: no carrier fwe0: flags=3D8802 metric 0 mtu 1500 options=3D8 ether 46:4f:c0:76:40:41 ch 1 dma -1 fwip0: flags=3D8802 metric 0 mtu 1500 lladdr 44.4f.c0.0.30.76.40.41.a.2.ff.fe.0.0.0.0 plip0: flags=3D108810 metric 0 mt= u 1500 lo0: flags=3D8049 metric 0 mtu 16384 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5=20 inet6 ::1 prefixlen 128=20 inet 127.0.0.1 netmask 0xff000000=20 wi0: flags=3D8802 metric 0 mtu 1500 ether 00:02:2d:5b:2c:78 media: IEEE 802.11 Wireless Ethernet autoselect (none) status: no carrier ssid catwhisker channel 1 (2412 Mhz 11b) stationname "FreeBSD WaveLAN/IEEE node" authmode OPEN privacy ON deftxkey 1 wepkey 1:40-bit txpowmax 100 bmiss 7 scanvalid 60 an0: flags=3D8843 metric 0 mtu 1500 ether 00:40:96:32:19:a9 inet 172.17.1.1 netmask 0xffff0000 broadcast 172.17.255.255 media: IEEE 802.11 Wireless Ethernet autoselect (DS/11Mbps) status: associated ssid 1:lmdhw-net channel 5 (56992 Mhz Turbo) stationname FreeBSD authmode OPEN privacy ON deftxkey 1 txpowmax 0 rtsthreshold 0 fragthreshold 0 bmiss 0 mcastrate 0 roaming DEVICE g1-1(7.0-C)[4]=20 As you see, the an0 NIC (a PCMCIA part) is the only one in use (as the miniPCI wi0 still doesn't associate). I don't expect that this is a critical issue, but it could be confusing. Peace, david --=20 David H. Wolfskill david@catwhisker.org Anything and everything is a (potential) cat toy. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --J2SCkAp4GZ/dPZZf Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iEYEARECAAYFAkaVEl8ACgkQmprOCmdXAD1lIQCfeXrFY7JOxPUskSKa//TaUNLg mT8An2tpg9gyBXKMOviu1nBM+5i138ue =SemH -----END PGP SIGNATURE----- --J2SCkAp4GZ/dPZZf-- From owner-freebsd-current@FreeBSD.ORG Wed Jul 11 18:09:11 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A6CD116A469 for ; Wed, 11 Jul 2007 18:09:11 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with SMTP id 5BFB513C455 for ; Wed, 11 Jul 2007 18:09:11 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 17029 invoked by uid 399); 11 Jul 2007 18:09:10 -0000 Received: from localhost (HELO ?192.168.0.6?) (dougb@dougbarton.us@127.0.0.1) by localhost with SMTP; 11 Jul 2007 18:09:10 -0000 X-Originating-IP: 127.0.0.1 Message-ID: <46951CC2.5050602@FreeBSD.org> Date: Wed, 11 Jul 2007 11:09:06 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Gaspar Chilingarov References: <20070419133550.GA65054@tirith.brixandersen.dk> <20070419200929.GA70735@tirith.brixandersen.dk> <4693BC3E.1050605@web.am> <200707110115.42139.pieter@degoeje.nl> <469417CB.7010705@FreeBSD.org> <4694AAF1.6050302@web.am> In-Reply-To: <4694AAF1.6050302@web.am> X-Enigmail-Version: 0.95.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Pieter de Goeje , freebsd-current@freebsd.org Subject: Re: RFT: bin/106642: [patch] Allow excluding certain files from mergemaster (8) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2007 18:09:11 -0000 Gaspar Chilingarov wrote: > Well another question -- is it possible teach somehow mergemaster, that > it should never touch passwd, groups, /etc/ttys or bunch of another files? Sure, you just do the opposite of what I did in the last script. If the file doesn't exist in the temproot when it's time to start comparing, mergemaster will never do anything with it. So here is some more out of the script that I actually use: #!/bin/sh # NOTE: No PATH needed, because mm's PATH is already draconian enough case "${PRE_WORLD}" in '') rm -f /etc/defaults/pccard.conf rm -f ${TEMPROOT}/etc/motd rm -f ${TEMPROOT}/etc/printcap rm -f ${TEMPROOT}/etc/namedb/named.* ;; esac > About pre-script which you suggested, there is another problem -- I MAY > have new scripts in /etc/rc.d, but NEVER change the system's scripts. Simple answer, don't do that. Put your scripts in /usr/local/etc/rc.d instead, and as of 6.1 and newer they will be included in the base rcorder. Therefore there will be no difference in when they are run. There is a default assumption that stuff in /etc/rc.d is the systems, and the systems only. Now that local scripts (including ports) are in the base rcorder, there is no reason not to do it that way. > In other hand running rm /etc/rc.d/* before mergermaster's start can > render system unusable, if mergemaster will fail for some reason. That's a good reason to do the update in single user mode, and always keep good backups. :) Please understand that I am not advocating that anyone actually DO what I suggested, I'm just pointing out that there are alternatives that already exist that can accomplish what people want to do here. Having given it a little more thought, it would probably be safer to do something like: case "${PRE_WORLD}" in '') mv ${TEMPROOT}/etc/rc.d/* /etc/rc.d/ ;; esac But my basic point is the same. I added MM_PRE_COMPARE_SCRIPT and MM_EXIT_SCRIPT to give users MORE flexibility than adding more (and more complex) CLI options would do. Please take advantage of it. :) Doug -- This .signature sanitized for your protection From owner-freebsd-current@FreeBSD.ORG Wed Jul 11 18:28:51 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B472E16A41F for ; Wed, 11 Jul 2007 18:28:51 +0000 (UTC) (envelope-from marcus@FreeBSD.org) Received: from av-tac-rtp.cisco.com (hen.cisco.com [64.102.19.198]) by mx1.freebsd.org (Postfix) with ESMTP id 67E2B13C44C for ; Wed, 11 Jul 2007 18:28:51 +0000 (UTC) (envelope-from marcus@FreeBSD.org) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost [127.0.0.1]) by av-tac-rtp.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id l6BI2A613609; Wed, 11 Jul 2007 14:02:10 -0400 (EDT) Received: from [64.102.193.121] (dhcp-64-102-193-121.cisco.com [64.102.193.121]) by rooster.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id l6BI21q20248; Wed, 11 Jul 2007 14:02:10 -0400 (EDT) Message-ID: <46951B50.3020601@FreeBSD.org> Date: Wed, 11 Jul 2007 14:02:56 -0400 From: Joe Marcus Clarke Organization: FreeBSD, Inc. User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) MIME-Version: 1.0 To: Sam Leffler References: <469504D2.8000200@errno.com> In-Reply-To: <469504D2.8000200@errno.com> X-Enigmail-Version: 0.95.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: HEADSUP: new wpa_supplicant and hostapd [ndis users read] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2007 18:28:51 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Sam Leffler wrote: > These applications have been updated to the 0.5.8 "stable release" from > Jouni Malinen. This gets us back on Jouni's stable release branch (as > opposed to the abandoned code base we were using). There are many new > features (read the docs in contrib) and you should now be able to use > 802.1x over wired nic's though it may not be configured by default > (please send patches after testing and I will try stuff updated). > > ndis support in wpa_supplicant has been tested but requires fixups in > the kernel that are pending. However people using ndis should also be > aware that the in-kernel ndis support has badly rotted and appears > chock-a-block with issues. Unless someone steps up to work on it expect > instability. Thanks to Andrew Thompson for patching things up. Are there plans to add the patch to the base system OpenSSL needed to enable EAP-FAST? This would greatly help me at work. Joe - -- Joe Marcus Clarke FreeBSD GNOME Team :: gnome@FreeBSD.org FreeNode / #freebsd-gnome http://www.FreeBSD.org/gnome -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGlRtQb2iPiv4Uz4cRAsOLAKCbR5Nmz4BelgA1x0OOMfPvY2suXQCfSaIR 9BE/OIK8gT2Z3ABmbjr8eWQ= =SR9H -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Wed Jul 11 19:00:00 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 389D116A400; Wed, 11 Jul 2007 19:00:00 +0000 (UTC) (envelope-from henrik@brixandersen.dk) Received: from solow.pil.dk (relay.pil.dk [195.41.47.164]) by mx1.freebsd.org (Postfix) with ESMTP id EE5AF13C46E; Wed, 11 Jul 2007 18:59:59 +0000 (UTC) (envelope-from henrik@brixandersen.dk) Received: from tirith.brixandersen.dk (osgiliath.brixandersen.dk [87.53.223.189]) by solow.pil.dk (Postfix) with ESMTP id 379141CC0F2; Wed, 11 Jul 2007 20:59:59 +0200 (CEST) Received: by tirith.brixandersen.dk (Postfix, from userid 1001) id 732D4B813; Wed, 11 Jul 2007 20:59:58 +0200 (CEST) Date: Wed, 11 Jul 2007 20:59:58 +0200 From: Henrik Brix Andersen To: Gaspar Chilingarov Message-ID: <20070711185958.GA37496@tirith.brixandersen.dk> Mail-Followup-To: Gaspar Chilingarov , Doug Barton , Pieter de Goeje , freebsd-current@freebsd.org References: <20070419133550.GA65054@tirith.brixandersen.dk> <20070419200929.GA70735@tirith.brixandersen.dk> <4693BC3E.1050605@web.am> <200707110115.42139.pieter@degoeje.nl> <469417CB.7010705@FreeBSD.org> <4694AAF1.6050302@web.am> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="OgqxwSJOaUobr8KG" Content-Disposition: inline In-Reply-To: <4694AAF1.6050302@web.am> X-PGP-Key: http://www.brixandersen.dk/files/HenrikBrixAndersen.asc User-Agent: Mutt/1.5.16 (2007-06-09) Cc: Pieter de Goeje , Doug Barton , freebsd-current@freebsd.org Subject: Re: RFT: bin/106642: [patch] Allow excluding certain files from mergemaster (8) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2007 19:00:00 -0000 --OgqxwSJOaUobr8KG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jul 11, 2007 at 03:03:29PM +0500, Gaspar Chilingarov wrote: > Well another question -- is it possible teach somehow mergemaster, that i= t=20 > should never touch passwd, groups, /etc/ttys or bunch of another files? That's actually the exact functionality added by the patch mentioned in the Subject line of this thread. Regards, Brix --=20 Henrik Brix Andersen --OgqxwSJOaUobr8KG Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) Comment: GnuPG signed iD8DBQFGlSitv+Q4flTiePgRAtQBAKDGVLNRO94sNg7S98kwCDWJq3FQNgCfYxX8 aVhcf9LuDIpDtMN5e4DEWaE= =TRHz -----END PGP SIGNATURE----- --OgqxwSJOaUobr8KG-- From owner-freebsd-current@FreeBSD.ORG Wed Jul 11 20:12:12 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8414416A421 for ; Wed, 11 Jul 2007 20:12:12 +0000 (UTC) (envelope-from sfourman@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.244]) by mx1.freebsd.org (Postfix) with ESMTP id 3DF1913C43E for ; Wed, 11 Jul 2007 20:12:12 +0000 (UTC) (envelope-from sfourman@gmail.com) Received: by an-out-0708.google.com with SMTP id c14so419720anc for ; Wed, 11 Jul 2007 13:12:11 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=TlUH7uI+IJg+6jcqFYHiGxqRDZXWPvDWPWl29mTIj+BWw1hQ6wCTKpXn1U7tcB31uN4Te/1OG9YxkDIuPnosrwJScTRRQTrb+eURGeG8nd4khP/fxotWJi1yDKyPkR95u5Bs0znM3f/uTnlhwuNVHb90+dYUaUmGUDJtK1HIDz4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=mFTqRXw/hlY8NGAK6hDTUd1kHWOVEeKgcJxzrHXOnCcWjeRIiBU0dladw86uMjkp1n8rpIwKPKM3CQ/TjJreKL85tJKMZACrWq162Gu6inXRANAV0X4x5pjyNH6kPb/AHBuBibPsCY+dCgigaBMYJVnQNWw/CMOeFVx7iz/P91s= Received: by 10.100.191.5 with SMTP id o5mr2979855anf.1184184731502; Wed, 11 Jul 2007 13:12:11 -0700 (PDT) Received: by 10.100.144.1 with HTTP; Wed, 11 Jul 2007 13:12:11 -0700 (PDT) Message-ID: <11167f520707111312r3ff0fd83qe0943ae88668e8ef@mail.gmail.com> Date: Wed, 11 Jul 2007 15:12:11 -0500 From: "Sam Fourman Jr." To: "Harald Schmalzbauer" In-Reply-To: <200707111903.53790.h.schmalzbauer@omnisec.de> MIME-Version: 1.0 References: <468345F2.1060209@freebsd.org> <46838649.3060405@freebsd.org> <46839A99.3030805@freebsd.org> <200707111903.53790.h.schmalzbauer@omnisec.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: speconly@post.ru, freebsd-current@freebsd.org, Current@freebsd.org, Daichi GOTO Subject: Re: Nvidia-driver and current lead system reboot with no error message X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2007 20:12:12 -0000 On 7/11/07, Harald Schmalzbauer wrote: > > Am Donnerstag, 28. Juni 2007 schrieb Daichi GOTO: > > Daichi GOTO wrote: > > > speconly@post.ru wrote: > > >> On Thu, Jun 28, 2007 at 02:24:02PM +0900, Daichi GOTO wrote: > > >>> current (Jun 27 2007) and nvidia-driver (GeForce 7300 GT) lead > > >>> system reboot 3d feature used without some error messages, > > >>> for example, beryl leads reboot, glxinfo too, and something > > >>> like that. 2D features work looks fine. > > >>> > > >>> Have someone any idea? Thanks. > > >> > > >> Updating driver to something 100.14.xx didn't solve this? > > > > > > yeah, alright. 100.14.xx is new nvidia-drvier number. > > > > > > http://www.nvidia.com/object/unix.html > > > > > > have you installed manually? or make a new port to install? ;) > > > > I have tried 100.14.11 and it works great fine :) Thanks! Does anyone have a diff for the new nvidia Driver? I have tried to email the port maintainer awhile back but did not get a response. I have a few 8800GTS cards and I would love to use them in FreeBSD beryl locs up my computer It doesn't compile for me. > The #error in nv-freebsd.h was not that problem, but some pci code breaks. > Have you had the same error and some workarround? Could you please tell me > your patch? > > Thanks, > > -Harry > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Wed Jul 11 20:38:57 2007 Return-Path: X-Original-To: Current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 307AB16A400 for ; Wed, 11 Jul 2007 20:38:57 +0000 (UTC) (envelope-from sfourman@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.241]) by mx1.freebsd.org (Postfix) with ESMTP id DE52E13C44B for ; Wed, 11 Jul 2007 20:38:56 +0000 (UTC) (envelope-from sfourman@gmail.com) Received: by an-out-0708.google.com with SMTP id c14so421684anc for ; Wed, 11 Jul 2007 13:38:56 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=TlUH7uI+IJg+6jcqFYHiGxqRDZXWPvDWPWl29mTIj+BWw1hQ6wCTKpXn1U7tcB31uN4Te/1OG9YxkDIuPnosrwJScTRRQTrb+eURGeG8nd4khP/fxotWJi1yDKyPkR95u5Bs0znM3f/uTnlhwuNVHb90+dYUaUmGUDJtK1HIDz4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=mFTqRXw/hlY8NGAK6hDTUd1kHWOVEeKgcJxzrHXOnCcWjeRIiBU0dladw86uMjkp1n8rpIwKPKM3CQ/TjJreKL85tJKMZACrWq162Gu6inXRANAV0X4x5pjyNH6kPb/AHBuBibPsCY+dCgigaBMYJVnQNWw/CMOeFVx7iz/P91s= Received: by 10.100.191.5 with SMTP id o5mr2979855anf.1184184731502; Wed, 11 Jul 2007 13:12:11 -0700 (PDT) Received: by 10.100.144.1 with HTTP; Wed, 11 Jul 2007 13:12:11 -0700 (PDT) Message-ID: <11167f520707111312r3ff0fd83qe0943ae88668e8ef@mail.gmail.com> Date: Wed, 11 Jul 2007 15:12:11 -0500 From: "Sam Fourman Jr." To: "Harald Schmalzbauer" In-Reply-To: <200707111903.53790.h.schmalzbauer@omnisec.de> MIME-Version: 1.0 References: <468345F2.1060209@freebsd.org> <46838649.3060405@freebsd.org> <46839A99.3030805@freebsd.org> <200707111903.53790.h.schmalzbauer@omnisec.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: speconly@post.ru, freebsd-current@freebsd.org, Current@freebsd.org, Daichi GOTO Subject: Re: Nvidia-driver and current lead system reboot with no error message X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2007 20:38:57 -0000 On 7/11/07, Harald Schmalzbauer wrote: > > Am Donnerstag, 28. Juni 2007 schrieb Daichi GOTO: > > Daichi GOTO wrote: > > > speconly@post.ru wrote: > > >> On Thu, Jun 28, 2007 at 02:24:02PM +0900, Daichi GOTO wrote: > > >>> current (Jun 27 2007) and nvidia-driver (GeForce 7300 GT) lead > > >>> system reboot 3d feature used without some error messages, > > >>> for example, beryl leads reboot, glxinfo too, and something > > >>> like that. 2D features work looks fine. > > >>> > > >>> Have someone any idea? Thanks. > > >> > > >> Updating driver to something 100.14.xx didn't solve this? > > > > > > yeah, alright. 100.14.xx is new nvidia-drvier number. > > > > > > http://www.nvidia.com/object/unix.html > > > > > > have you installed manually? or make a new port to install? ;) > > > > I have tried 100.14.11 and it works great fine :) Thanks! Does anyone have a diff for the new nvidia Driver? I have tried to email the port maintainer awhile back but did not get a response. I have a few 8800GTS cards and I would love to use them in FreeBSD beryl locs up my computer It doesn't compile for me. > The #error in nv-freebsd.h was not that problem, but some pci code breaks. > Have you had the same error and some workarround? Could you please tell me > your patch? > > Thanks, > > -Harry > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Wed Jul 11 20:52:06 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4216516A400; Wed, 11 Jul 2007 20:52:06 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 3440E13C455; Wed, 11 Jul 2007 20:52:06 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id C45D01A4D80; Wed, 11 Jul 2007 13:26:40 -0700 (PDT) Date: Wed, 11 Jul 2007 13:26:40 -0700 From: Alfred Perlstein To: current@freebsd.org, fs@freebsd.org Message-ID: <20070711202640.GV45894@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: Subject: bgfsck hosed (lockups) in -current? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2007 20:52:06 -0000 I have current as of last week. I noticed that if I needed a bgfsck on ufs when rebooting my system would lock up almost immediately. Everything would deadlock. If I rebooted single user and did a regular "fsck -y" then continued to boot, I'd be OK. Has anyone else experienced this? I'm going to update to the most recent current and get more information (which wait channels etc) but wanted to know if anyone knew about this. I recall seeing a LOT of fixes for various deadlocks in snapshots and bgfsck going in lately, but nothing that looked to me as if it'd trigger a regression. -- - Alfred Perlstein From owner-freebsd-current@FreeBSD.ORG Wed Jul 11 21:04:06 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EC02016A421 for ; Wed, 11 Jul 2007 21:04:06 +0000 (UTC) (envelope-from rhurlin@gwdg.de) Received: from amailer.gwdg.de (amailer.gwdg.de [134.76.10.18]) by mx1.freebsd.org (Postfix) with ESMTP id AE1F613C46A for ; Wed, 11 Jul 2007 21:04:06 +0000 (UTC) (envelope-from rhurlin@gwdg.de) Received: from p578b68b8.dip0.t-ipconnect.de ([87.139.104.184] helo=krabat.raven.hur) by mailer.gwdg.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.66) (envelope-from ) id 1I8iLt-0004bD-Ms; Wed, 11 Jul 2007 21:59:57 +0200 Message-ID: <469536BA.5090306@gwdg.de> Date: Wed, 11 Jul 2007 21:59:54 +0200 From: Rainer Hurling User-Agent: Thunderbird 2.0.0.4 (X11/20070615) MIME-Version: 1.0 To: Harald Schmalzbauer References: <468345F2.1060209@freebsd.org> <46838649.3060405@freebsd.org> <46839A99.3030805@freebsd.org> <200707111903.53790.h.schmalzbauer@omnisec.de> In-Reply-To: <200707111903.53790.h.schmalzbauer@omnisec.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated: Id:rhurlin X-Spam-Level: - X-Virus-Scanned: (clean) by exiscan+sophie Cc: freebsd-current@freebsd.org Subject: Re: Nvidia-driver and current lead system reboot with no error message X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2007 21:04:07 -0000 Hallo Harry, for version 100.14.11 (after unpacking the tarball) I had to make four changes before I had been able to install: 1. set environment variable 'X11BASE' to '/usr/local' 2. Delete lines 24-26 in 'src/nv-freebsd.h' (test for FreeBSD version >=70000) 3. Change '${X11BASE}/lib/modules[...]' to '${X11BASE}/lib/xorg/modules[...]' in Makefiles under x11/[driver,extension,lib] 4. Change '/usr/X11R6/lib/modules[...]' to '/usr/local/lib/xorg/modules[...]' in 'doc/html/appendix-b.html' Don't forget to delete any installed x11/nvidia-driver* port before installing this new driver version. Hope this helps, Rainer Harald Schmalzbauer schrieb: > Am Donnerstag, 28. Juni 2007 schrieb Daichi GOTO: >> Daichi GOTO wrote: >>> speconly@post.ru wrote: >>>> On Thu, Jun 28, 2007 at 02:24:02PM +0900, Daichi GOTO wrote: >>>>> current (Jun 27 2007) and nvidia-driver (GeForce 7300 GT) lead >>>>> system reboot 3d feature used without some error messages, >>>>> for example, beryl leads reboot, glxinfo too, and something >>>>> like that. 2D features work looks fine. >>>>> >>>>> Have someone any idea? Thanks. >>>> Updating driver to something 100.14.xx didn't solve this? >>> yeah, alright. 100.14.xx is new nvidia-drvier number. >>> >>> http://www.nvidia.com/object/unix.html >>> >>> have you installed manually? or make a new port to install? ;) >> I have tried 100.14.11 and it works great fine :) Thanks! > > It doesn't compile for me. > The #error in nv-freebsd.h was not that problem, but some pci code breaks. > Have you had the same error and some workarround? Could you please tell me > your patch? > > Thanks, > > -Harry From owner-freebsd-current@FreeBSD.ORG Wed Jul 11 21:06:26 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A0FB216A400; Wed, 11 Jul 2007 21:06:26 +0000 (UTC) (envelope-from dan@dan.emsphone.com) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.freebsd.org (Postfix) with ESMTP id 3ED8813C45E; Wed, 11 Jul 2007 21:06:05 +0000 (UTC) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.14.1/8.13.8) id l6BL5vbK045584; Wed, 11 Jul 2007 16:05:57 -0500 (CDT) (envelope-from dan) Date: Wed, 11 Jul 2007 16:05:56 -0500 From: Dan Nelson To: Alfred Perlstein Message-ID: <20070711210556.GD45534@dan.emsphone.com> References: <20070711202640.GV45894@elvis.mu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070711202640.GV45894@elvis.mu.org> X-OS: FreeBSD 7.0-CURRENT User-Agent: Mutt/1.5.16 (2007-06-09) Cc: current@freebsd.org, fs@freebsd.org Subject: Re: bgfsck hosed (lockups) in -current? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2007 21:06:26 -0000 In the last episode (Jul 11), Alfred Perlstein said: > I have current as of last week. > > I noticed that if I needed a bgfsck on ufs when rebooting my system > would lock up almost immediately. Everything would deadlock. I've been suffering from trap 12's in rt_check() every day for the last week or so (will post to the list once I get a good coredump) but haven't had the subsequent bgfsck lock up on me yet. -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-current@FreeBSD.ORG Wed Jul 11 21:07:08 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EF26F16A480; Wed, 11 Jul 2007 21:07:08 +0000 (UTC) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.freebsd.org (Postfix) with ESMTP id D6DB313C480; Wed, 11 Jul 2007 21:07:08 +0000 (UTC) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.13.8/8.13.7) with ESMTP id l6BL78A0061859; Wed, 11 Jul 2007 14:07:08 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.13.8/8.13.4/Submit) id l6BL77Gj061858; Wed, 11 Jul 2007 14:07:07 -0700 (PDT) Date: Wed, 11 Jul 2007 14:07:07 -0700 (PDT) From: Matthew Dillon Message-Id: <200707112107.l6BL77Gj061858@apollo.backplane.com> To: Zhouyi Zhou References: <20070709105547.71827eb8.zhouzhouyi@FreeBSD.org> <20070709115637.sapzl5uq3osw4gc4@webmail.leidinger.net> <00d901c7c222$109cb310$f100a8c0@iosdf17a8152bc> Cc: Alexander Leidinger , freebsd-current@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: rewrite src/sys/i386/i386/in_cksum.c X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2007 21:07:09 -0000 Here's a reference to the DragonFly code: http://www.dragonflybsd.org/cvsweb/src/sys/cpu/i386/misc/in_cksum2.s http://www.dragonflybsd.org/cvsweb/src/sys/netinet/in_cksum.c It's pretty simple. The core 1's complement checksum is now written in machine-dependant assembly and ONLY handles multiples of 32 bit words. In otherwords, no special cases. The mbuf wrapper is written in machine-independant C, calls the assembly for the bulk of the work, and handles all the edge cases. The rewrite is much cleaner and the code documentation is actually understandable. Plus only a very simple core needs to be written in assembly and the C wrapper is machine independant, instead of embedding the assembly with the C and praying the compiler doesn't blow things up. -Matt Matthew Dillon From owner-freebsd-current@FreeBSD.ORG Wed Jul 11 21:10:07 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0ABD516A41F; Wed, 11 Jul 2007 21:10:07 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id EAE4C13C44C; Wed, 11 Jul 2007 21:10:06 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id CF5291A4DA7; Wed, 11 Jul 2007 14:10:06 -0700 (PDT) Date: Wed, 11 Jul 2007 14:10:06 -0700 From: Alfred Perlstein To: Dan Nelson Message-ID: <20070711211006.GW45894@elvis.mu.org> References: <20070711202640.GV45894@elvis.mu.org> <20070711210556.GD45534@dan.emsphone.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070711210556.GD45534@dan.emsphone.com> User-Agent: Mutt/1.4.2.3i Cc: current@freebsd.org, fs@freebsd.org Subject: Re: bgfsck hosed (lockups) in -current? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2007 21:10:07 -0000 * Dan Nelson [070711 14:06] wrote: > In the last episode (Jul 11), Alfred Perlstein said: > > I have current as of last week. > > > > I noticed that if I needed a bgfsck on ufs when rebooting my system > > would lock up almost immediately. Everything would deadlock. > > I've been suffering from trap 12's in rt_check() every day for the last > week or so (will post to the list once I get a good coredump) but > haven't had the subsequent bgfsck lock up on me yet. Interesting. It may just be heavy IO on my machine or on current in general. thank you, -Alfred From owner-freebsd-current@FreeBSD.ORG Wed Jul 11 21:19:39 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4A18B16A421 for ; Wed, 11 Jul 2007 21:19:39 +0000 (UTC) (envelope-from cristi@net.utcluj.ro) Received: from bavaria.utcluj.ro (bavaria.utcluj.ro [193.226.5.35]) by mx1.freebsd.org (Postfix) with ESMTP id E569013C458 for ; Wed, 11 Jul 2007 21:19:38 +0000 (UTC) (envelope-from cristi@net.utcluj.ro) Received: from localhost (localhost [127.0.0.1]) by bavaria.utcluj.ro (Postfix) with ESMTP id C5CF850853 for ; Thu, 12 Jul 2007 00:19:34 +0300 (EEST) X-Virus-Scanned: by the daemon playing with your mail on bavaria.utcluj.ro Received: from bavaria.utcluj.ro ([127.0.0.1]) by localhost (bavaria.utcluj.ro [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pzMl8a3MqT-V for ; Thu, 12 Jul 2007 00:19:30 +0300 (EEST) Received: from hades.local (c7.campus.utcluj.ro [193.226.6.226]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bavaria.utcluj.ro (Postfix) with ESMTP id 7539750842 for ; Thu, 12 Jul 2007 00:19:30 +0300 (EEST) Message-ID: <4695495A.8080009@net.utcluj.ro> Date: Thu, 12 Jul 2007 00:19:22 +0300 From: Cristian KLEIN User-Agent: Thunderbird 2.0.0.4 (X11/20070711) MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [patch] suspend problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2007 21:19:39 -0000 Hi everybody, I have buildworld/kernel yesterday. When I try to suspend using the ACPI sleep button, the following errors occur. After several suspend / resume cycles, the system repeatedly prints this error message: fwohci0: device physically ejected? On my system fwohci seems to use poll (tested using a printf), so the message is printed so often that the system becomes unusable. My solution rate-limits this message, however I don't think that the firewire device is resumed correctly. --- cut here --- diff -ur sys.orig/dev/firewire/fwohci.c sys/dev/firewire/fwohci.c --- sys.orig/dev/firewire/fwohci.c 2007-06-08 12:04:30.000000000 +0300 +++ sys/dev/firewire/fwohci.c 2007-07-11 17:31:10.898954755 +0300 @@ -2064,8 +2064,13 @@ stat = OREAD(sc, FWOHCI_INTSTAT); if (stat == 0xffffffff) { - device_printf(sc->fc.dev, - "device physically ejected?\n"); + /* Rate limit this message */ + static int verbose = 10; + if (verbose != 0) { + device_printf(sc->fc.dev, + "device physically ejected?\n"); + verbose--; + } return (FILTER_STRAY); } if (stat) --- and here --- After solving this problem, during resume, the kernel panics with something like "recursing on non-recursive mutex ". The problem seems to be in ACPI vendor code, which assumes that the OS supplied lock functions allow recursion. The following patch modifies the OS layer to match ACPI vendor code's assumption: --- cut here --- diff -ur sys.orig/dev/acpica/Osd/OsdSynch.c sys/dev/acpica/Osd/OsdSynch.c --- sys.orig/dev/acpica/Osd/OsdSynch.c 2007-03-27 02:04:02.000000000 +0300 +++ sys/dev/acpica/Osd/OsdSynch.c 2007-07-11 17:29:47.497655148 +0300 @@ -346,7 +346,7 @@ snprintf(h->name, sizeof(h->name), "acpi subsystem HW lock"); else snprintf(h->name, sizeof(h->name), "acpi subsys %p", OutHandle); - mtx_init(&h->lock, h->name, NULL, MTX_DEF); + mtx_init(&h->lock, h->name, NULL, MTX_DEF | MTX_RECURSE); *OutHandle = (ACPI_SPINLOCK)h; return (AE_OK); } --- and here --- E.g. * AcpiEvGpeDetect() calls AcpiOsAcquireLock(AcpiGbl_GpeLock) in contrib/dev/acpica/evgpe.c:511, then calls AcpiEvGpeDispatch() * AcpiEvGpeDispatch() calls AcpiHwDisableAllGpes() in evgpe.c:762 * AcpiHwDisableAllGpes() calls AcpiEvWalkGpeList in hwgpe.c:487 * AcpiEvWalkGpeList() calls AcpiOsAcquireLock(AcpiGbl_GpeLock) aaagain in evgpeblk.c:237 Thanks. From owner-freebsd-current@FreeBSD.ORG Wed Jul 11 21:35:58 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F269516A400 for ; Wed, 11 Jul 2007 21:35:58 +0000 (UTC) (envelope-from h.schmalzbauer@omnisec.de) Received: from host.omnisec.de (host.omnisec.de [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id 54A9013C468 for ; Wed, 11 Jul 2007 21:35:57 +0000 (UTC) (envelope-from h.schmalzbauer@omnisec.de) Received: from tek.flintsbach.schmalzbauer.de (tek.flintsbach.schmalzbauer.de [172.21.2.3]) by host.omnisec.de (8.13.8/8.13.8) with ESMTP id l6BLVJkW096780 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Jul 2007 23:31:24 +0200 (CEST) (envelope-from h.schmalzbauer@omnisec.de) Received: from titan.flintsbach.schmalzbauer.de (titan.flintsbach.schmalzbauer.de [IPv6:fec0::1:0:0:1:1]) by tek.flintsbach.schmalzbauer.de (8.13.8/8.13.8) with ESMTP id l6BLZpXw032339; Wed, 11 Jul 2007 23:35:51 +0200 (CEST) (envelope-from h.schmalzbauer@omnisec.de) Received: by titan.flintsbach.schmalzbauer.de (8.14.1/8.14.1/Submit) id l6BLVJ2E001280; Wed, 11 Jul 2007 23:31:19 +0200 (CEST) (envelope-from h.schmalzbauer@omnisec.de) From: Harald Schmalzbauer Organization: OmniSEC To: Rainer Hurling Date: Wed, 11 Jul 2007 23:31:18 +0200 User-Agent: KMail/1.9.6 References: <468345F2.1060209@freebsd.org> <200707111903.53790.h.schmalzbauer@omnisec.de> <469536BA.5090306@gwdg.de> In-Reply-To: <469536BA.5090306@gwdg.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200707112331.19068.h.schmalzbauer@omnisec.de> Cc: freebsd-current@freebsd.org Subject: Re: Nvidia-driver and current lead system reboot with no error message X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2007 21:35:59 -0000 Am Mittwoch, 11. Juli 2007 schrieb Rainer Hurling: > Hallo Harry, > > for version 100.14.11 (after unpacking the tarball) I had to make four > changes before I had been able to install: > > 1. set environment variable 'X11BASE' to '/usr/local' > > 2. Delete lines 24-26 in 'src/nv-freebsd.h' (test for FreeBSD version > > >=70000) > > 3. Change '${X11BASE}/lib/modules[...]' to > '${X11BASE}/lib/xorg/modules[...]' in Makefiles under > x11/[driver,extension,lib] > > 4. Change '/usr/X11R6/lib/modules[...]' to > '/usr/local/lib/xorg/modules[...]' in 'doc/html/appendix-b.html' > > > Don't forget to delete any installed x11/nvidia-driver* port before > installing this new driver version. > > Hope this helps, > Rainer Hello Rainer, thanks for your hints. Unfortunately it's not just a matter of paths. Here's the compiler showstopper: cc -O1 -pipe -march=prescott -march=prescott -DNV_VERSION_STRING=\"100.14.11\" - D__KERNEL__ -DNVRM -UDEBUG -U_DEBUG -DNDEBUG -O -fno-common -msoft-float -fno-unit-at-a-time -minline-all-stringops -D_KERNEL -DKLD_MODULE -std=c99 -nostdinc -I/src -I. -I@ -I@/contrib/altq -finline-limit=8000 --paraminline-unit-growth=100 --paramlarge-function-growth=1000 -fno-common -mno-align-long-strings -mpre ferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffree standing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing -prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -ffo rmat-extensions -c nvidia_pci.c nvidia_pci.c: In function 'nvidia_pci_setup_intr': nvidia_pci.c:56: warning: passing argument 7 of 'bus_setup_intr' from incompatible pointer type nvidia_pci.c:56: error: too many arguments to function 'bus_setup_intr' *** Error code 1 Stop in /usr/ports/x11/nvidia-driver/work/NVIDIA-FreeBSD-x86-100.14.11/src. *** Error code 1 Stop in /usr/ports/x11/nvidia-driver/work/NVIDIA-FreeBSD-x86-100.14.11. *** Error code 1 Thansk in advance for any hint. -Harry From owner-freebsd-current@FreeBSD.ORG Wed Jul 11 21:37:55 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 23DAC16A41F; Wed, 11 Jul 2007 21:37:55 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id D08A813C480; Wed, 11 Jul 2007 21:37:54 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 3B1FF47CA4; Wed, 11 Jul 2007 17:37:54 -0400 (EDT) Date: Wed, 11 Jul 2007 22:37:54 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Alfred Perlstein In-Reply-To: <20070711202640.GV45894@elvis.mu.org> Message-ID: <20070711223720.C97304@fledge.watson.org> References: <20070711202640.GV45894@elvis.mu.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: current@freebsd.org, fs@freebsd.org Subject: Re: bgfsck hosed (lockups) in -current? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2007 21:37:55 -0000 On Wed, 11 Jul 2007, Alfred Perlstein wrote: > I have current as of last week. > > I noticed that if I needed a bgfsck on ufs when rebooting my system would > lock up almost immediately. Everything would deadlock. > > If I rebooted single user and did a regular "fsck -y" then continued to > boot, I'd be OK. > > Has anyone else experienced this? I'm going to update to the most recent > current and get more information (which wait channels etc) but wanted to > know if anyone knew about this. > > I recall seeing a LOT of fixes for various deadlocks in snapshots and bgfsck > going in lately, but nothing that looked to me as if it'd trigger a > regression. I'm not seeing this either -- have you tried running a manual fsck to see if it turns up anything deeply unsatisfying that could be causing bgfsck some bother? Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Wed Jul 11 22:05:08 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5E47F16A421; Wed, 11 Jul 2007 22:05:08 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 4994213C4C3; Wed, 11 Jul 2007 22:05:08 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 2EB471A4DA7; Wed, 11 Jul 2007 15:05:08 -0700 (PDT) Date: Wed, 11 Jul 2007 15:05:08 -0700 From: Alfred Perlstein To: Robert Watson Message-ID: <20070711220508.GY45894@elvis.mu.org> References: <20070711202640.GV45894@elvis.mu.org> <20070711223720.C97304@fledge.watson.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070711223720.C97304@fledge.watson.org> User-Agent: Mutt/1.4.2.3i Cc: current@freebsd.org, fs@freebsd.org Subject: Re: bgfsck hosed (lockups) in -current? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2007 22:05:08 -0000 * Robert Watson [070711 14:37] wrote: > > On Wed, 11 Jul 2007, Alfred Perlstein wrote: > > >I have current as of last week. > > > >I noticed that if I needed a bgfsck on ufs when rebooting my system would > >lock up almost immediately. Everything would deadlock. > > > >If I rebooted single user and did a regular "fsck -y" then continued to > >boot, I'd be OK. > > > >Has anyone else experienced this? I'm going to update to the most recent > >current and get more information (which wait channels etc) but wanted to > >know if anyone knew about this. > > > >I recall seeing a LOT of fixes for various deadlocks in snapshots and > >bgfsck going in lately, but nothing that looked to me as if it'd trigger a > >regression. > > I'm not seeing this either -- have you tried running a manual fsck to see > if it turns up anything deeply unsatisfying that could be causing bgfsck > some bother? Of course, nothing comes up that's interesting. I'll try to reproduce this and give better feedback in the next few days. -- - Alfred Perlstein From owner-freebsd-current@FreeBSD.ORG Wed Jul 11 22:14:56 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B532416A400 for ; Wed, 11 Jul 2007 22:14:56 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 6FD7013C46C for ; Wed, 11 Jul 2007 22:14:56 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1I8kSS-0006g5-4S for freebsd-current@freebsd.org; Thu, 12 Jul 2007 00:14:52 +0200 Received: from 78-1-126-227.adsl.net.t-com.hr ([78.1.126.227]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 12 Jul 2007 00:14:52 +0200 Received: from ivoras by 78-1-126-227.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 12 Jul 2007 00:14:52 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Ivan Voras Date: Thu, 12 Jul 2007 00:14:43 +0200 Lines: 20 Message-ID: References: <20070709214216.GA72912@walton.maths.tcd.ie> <20070711132202.GA95487@walton.maths.tcd.ie> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 78-1-126-227.adsl.net.t-com.hr User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) In-Reply-To: <20070711132202.GA95487@walton.maths.tcd.ie> Sender: news Cc: freebsd-hackers@freebsd.org Subject: Re: Debugging times X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2007 22:14:56 -0000 David Malone wrote: > http://www.maths.tcd.ie/~dwmalone/clock.patch > > It checks the return values of the various clock reading functions > in the kernel and prints an error message if it finds that it can't > set the clock OK. Some machines have a BIOS that doesn't count the > day-of-week correctly, and recently FreeBSD has started treating > this as an error on some platforms. > > (This patch won't fix anything, but might produce a more informative > error message.) I've got interesting results (in the bad sense of the phrase): I do get the message "Invalid time in real time clock. Check and reset the time immediately" (the i386 message) BUT my time gets reset to 0 (midnight 1970.) I see your patch and it shouldn't do that. Could it be a compiler bug, so the effects change after trivial code has been changed? From owner-freebsd-current@FreeBSD.ORG Wed Jul 11 22:36:22 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AE29A16A46D for ; Wed, 11 Jul 2007 22:36:22 +0000 (UTC) (envelope-from freebsd@superhero.nl) Received: from superman.superhero.nl (superhero.nl [82.95.198.17]) by mx1.freebsd.org (Postfix) with ESMTP id 1D35013C44C for ; Wed, 11 Jul 2007 22:36:21 +0000 (UTC) (envelope-from freebsd@superhero.nl) Received: (qmail 89192 invoked by uid 80); 11 Jul 2007 22:07:00 -0000 Received: from robin.ad.superhero.nl ([10.202.77.103]) (SquirrelMail authenticated user gelsemap) by webmail.superhero.nl with HTTP; Thu, 12 Jul 2007 00:07:00 +0200 (CEST) Message-ID: <4686.10.202.77.103.1184191620.squirrel@webmail.superhero.nl> Date: Thu, 12 Jul 2007 00:07:00 +0200 (CEST) From: "Gelsema, P \(Patrick\) - FreeBSD" To: current@freebsd.org User-Agent: SquirrelMail/1.4.8 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: Subject: -current AMD64 unable to mount root after buildworld/kernel reboot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2007 22:36:22 -0000 Hi, I have got the following issue. I have installed Current June AMD64 snapshot without any issues. I can reboot and the machine comes back up without any issues. /etc/make.conf is copied from /usr/share/examples/etc/make.conf and the only changed made are: cputype?=athlon64 cflags= -O2 -fno-strict-aliasing -pipe (only removed the # in front of the line) coptflags=-O -pipe (only removed the # in front of the line) and the settings regarding cvsup are enabled. yes and cvsup3.nl.freebsd.org, and only the standard-cvsupfile is uncommented. using the /usr/share/examples/cvsup/standard-supfile with no changes. First thing I do is a make update (as of this evening) after which I execute the following commands; #chflags -R noschg /usr/obj #rm -rf /usr/obj #make cleandir #make cleandir #make -j8 buildworld #make -j8 buildkernel #make -j8 installkernel #make -j8 installworld #mergemaster #shutdown -r now After this the machine reboots, starts FreeBSD and detects everything as it ought to. However the moment it tries to mount root from ufs:/dev/da0s1a it seems to fail and asks for; manual root filesystem specification. When I type in manually ufs:/dev/da0s1a it continues with the following error; ELF interpreter /libexec/ld-elf.so.1 not found init: /bin/sh on /etc/rc terminated abnormally, going to single user mode. Enter full pathname of shell or RETURN for /bin/sh. Hitting enter I get; ELF interpreter /libexec/ld-elf.so.1 not found init: single user shell terminated, restarting. Enter full pathname of shell or RETURN for /bin/sh. When rebooting with kernel.old everything goes ok and I am able to log on. Any help much appreciated. Rgds, Patrick From owner-freebsd-current@FreeBSD.ORG Wed Jul 11 22:41:40 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6994D16A468; Wed, 11 Jul 2007 22:41:40 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from mxout5.cac.washington.edu (mxout5.cac.washington.edu [140.142.32.135]) by mx1.freebsd.org (Postfix) with ESMTP id 2EDDC13C457; Wed, 11 Jul 2007 22:41:40 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.7] (may be forged)) by mxout5.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.06) with ESMTP id l6BMfZnR006237 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 11 Jul 2007 15:41:36 -0700 X-Auth-Received: from [192.168.10.45] (c-24-10-12-194.hsd1.ca.comcast.net [24.10.12.194]) (authenticated authid=youshi10) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l6BMfY9B003458 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 11 Jul 2007 15:41:35 -0700 Message-ID: <46955C9E.6090101@u.washington.edu> Date: Wed, 11 Jul 2007 15:41:34 -0700 From: Garrett Cooper User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Doug Barton References: <20070419133550.GA65054@tirith.brixandersen.dk> <20070419200929.GA70735@tirith.brixandersen.dk> <4693BC3E.1050605@web.am> <200707110115.42139.pieter@degoeje.nl> <469417CB.7010705@FreeBSD.org> <4694AAF1.6050302@web.am> <46951CC2.5050602@FreeBSD.org> In-Reply-To: <46951CC2.5050602@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 5.3.2.304607, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.7.11.152433 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' Cc: Pieter de Goeje , Gaspar Chilingarov , freebsd-current@freebsd.org Subject: Re: RFT: bin/106642: [patch] Allow excluding certain files from mergemaster (8) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2007 22:41:40 -0000 Doug Barton wrote: > Gaspar Chilingarov wrote: > > >> Well another question -- is it possible teach somehow mergemaster, that >> it should never touch passwd, groups, /etc/ttys or bunch of another files? >> > > Sure, you just do the opposite of what I did in the last script. If > the file doesn't exist in the temproot when it's time to start > comparing, mergemaster will never do anything with it. So here is some > more out of the script that I actually use: > > #!/bin/sh > # NOTE: No PATH needed, because mm's PATH is already draconian enough > case "${PRE_WORLD}" in > '') rm -f /etc/defaults/pccard.conf > rm -f ${TEMPROOT}/etc/motd > rm -f ${TEMPROOT}/etc/printcap > rm -f ${TEMPROOT}/etc/namedb/named.* > ;; > esac > > What if a user or group was added to /etc/group or /etc/passwd that was required for the updated version of the OS? I would see this behavior a bit counterproductive in this case. >> About pre-script which you suggested, there is another problem -- I MAY >> have new scripts in /etc/rc.d, but NEVER change the system's scripts. >> > > Simple answer, don't do that. Put your scripts in /usr/local/etc/rc.d > instead, and as of 6.1 and newer they will be included in the base > rcorder. Therefore there will be no difference in when they are run. > There is a default assumption that stuff in /etc/rc.d is the systems, > and the systems only. Now that local scripts (including ports) are in > the base rcorder, there is no reason not to do it that way. > Agreed. Stuff should stay out of /etc/rc.d. Why not have mergemaster overwrite those scripts by default? >> In other hand running rm /etc/rc.d/* before mergermaster's start can >> render system unusable, if mergemaster will fail for some reason. >> > > That's a good reason to do the update in single user mode, and always > keep good backups. :) Please understand that I am not advocating that > anyone actually DO what I suggested, I'm just pointing out that there > are alternatives that already exist that can accomplish what people > want to do here. > > Having given it a little more thought, it would probably be safer to > do something like: > case "${PRE_WORLD}" in > '') mv ${TEMPROOT}/etc/rc.d/* /etc/rc.d/ > ;; > esac > > But my basic point is the same. I added MM_PRE_COMPARE_SCRIPT and > MM_EXIT_SCRIPT to give users MORE flexibility than adding more (and > more complex) CLI options would do. Please take advantage of it. :) > > Doug Agreed, once again. -Garrett From owner-freebsd-current@FreeBSD.ORG Wed Jul 11 22:45:37 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9007916A41F for ; Wed, 11 Jul 2007 22:45:37 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from mxout3.cac.washington.edu (mxout3.cac.washington.edu [140.142.32.166]) by mx1.freebsd.org (Postfix) with ESMTP id 6CBA113C447 for ; Wed, 11 Jul 2007 22:45:37 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.7] (may be forged)) by mxout3.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.06) with ESMTP id l6BMjafT021877 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 11 Jul 2007 15:45:36 -0700 X-Auth-Received: from [192.168.10.45] (c-24-10-12-194.hsd1.ca.comcast.net [24.10.12.194]) (authenticated authid=youshi10) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l6BMjZk3004348 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 11 Jul 2007 15:45:36 -0700 Message-ID: <46955D8F.8040900@u.washington.edu> Date: Wed, 11 Jul 2007 15:45:35 -0700 From: Garrett Cooper User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: "Gelsema, P \(Patrick\) - FreeBSD" References: <4686.10.202.77.103.1184191620.squirrel@webmail.superhero.nl> In-Reply-To: <4686.10.202.77.103.1184191620.squirrel@webmail.superhero.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 5.3.2.304607, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.7.11.152433 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' Cc: current@freebsd.org Subject: Re: -current AMD64 unable to mount root after buildworld/kernel reboot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2007 22:45:37 -0000 Gelsema, P (Patrick) - FreeBSD wrote: > Hi, > > I have got the following issue. > > I have installed Current June AMD64 snapshot without any issues. I can > reboot and the machine comes back up without any issues. > > /etc/make.conf is copied from /usr/share/examples/etc/make.conf and the > only changed made are: > cputype?=athlon64 > cflags= -O2 -fno-strict-aliasing -pipe (only removed the # in front of the > line) > coptflags=-O -pipe (only removed the # in front of the line) > > and the settings regarding cvsup are enabled. yes and > cvsup3.nl.freebsd.org, and only the standard-cvsupfile is uncommented. > > using the /usr/share/examples/cvsup/standard-supfile with no changes. > > First thing I do is a make update (as of this evening) after which I > execute the following commands; > > #chflags -R noschg /usr/obj > #rm -rf /usr/obj > #make cleandir > #make cleandir > #make -j8 buildworld > #make -j8 buildkernel > #make -j8 installkernel > #make -j8 installworld > #mergemaster > #shutdown -r now > > After this the machine reboots, starts FreeBSD and detects everything as > it ought to. However the moment it tries to mount root from > ufs:/dev/da0s1a it seems to fail and asks for; > > manual root filesystem specification. When I type in manually > ufs:/dev/da0s1a it continues with the following error; > > ELF interpreter /libexec/ld-elf.so.1 not found > init: /bin/sh on /etc/rc terminated abnormally, going to single user mode. > Enter full pathname of shell or RETURN for /bin/sh. > > Hitting enter I get; > ELF interpreter /libexec/ld-elf.so.1 not found > init: single user shell terminated, restarting. > Enter full pathname of shell or RETURN for /bin/sh. > > When rebooting with kernel.old everything goes ok and I am able to log on. > > Any help much appreciated. > > Rgds, > > Patrick You're most likely missing some key components in specifying your disk controller. Do you have SCSI, SATA, PATA? If you have SCSI/SATA, did you perhaps install your system with GEOM enabled? Booting into the backup kernel (single user mode), will be extremely helpful in determining your issue, in particular what disk configuration you're using. -Garrett From owner-freebsd-current@FreeBSD.ORG Wed Jul 11 23:35:12 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B61FF16A421 for ; Wed, 11 Jul 2007 23:35:12 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 2A7A113C44B for ; Wed, 11 Jul 2007 23:35:11 +0000 (UTC) (envelope-from andre@freebsd.org) Received: (qmail 48603 invoked from network); 11 Jul 2007 23:06:25 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 11 Jul 2007 23:06:25 -0000 Message-ID: <469562F9.4060700@freebsd.org> Date: Thu, 12 Jul 2007 01:08:41 +0200 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Robert Watson References: <20070709234401.S29353@odysseus.silby.com> <20070710132253.GJ1038@void.codelabs.ru> <20070710202028.I34890@odysseus.silby.com> <20070711130719.S68820@fledge.watson.org> In-Reply-To: <20070711130719.S68820@fledge.watson.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Mike Silbersack , current@freebsd.org, net@freebsd.org Subject: Re: FreeBSD 7 TCP syncache fix: request for testers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2007 23:35:12 -0000 Robert Watson wrote: > On Tue, 10 Jul 2007, Mike Silbersack wrote: > >> On Tue, 10 Jul 2007, Eygene Ryabinkin wrote: >> >>> Can't say that I am pushing much traffic through my box, but after >>> applying your patch and rebuilding the kernel I am still seeing the >>> messages like ----- TCP: [209.132.176.NNN]:NNN to >>> [144.206.NNN.NNN]:NNN tcpflags 0x19; syncache_expand: >>> Segment failed SYNCOOKIE authentication, segment rejected (probably >>> spoofed) TCP: [201.90.65.NNN]:NNN to [144.206.NNN.NNN]:NNN; >>> syncache_timer: Response timeout ----- But what had changed is that >>> the lines with the 'syncache_timer' started to appear. There were no >>> such lines prior to the patch, only the 'failed SYNCOOKIE' ones. >> >> The "syncache_timer: Response timeout" message means that the syncache >> sent a SYN-ACK response four times, but still didn't receive a >> response. This probably means that someone tried using a port scanner >> or was going through a faulty firewall. We'll definitely have to take >> that log message out before 7.0 is released. > > As I mentioned to Andre before he committed the log message support, > there needs to be an administrative twiddle for it, and pretty much all > need to either be rate-limited or turned off by default when we get to > the release. Otherwise they make very easy DoS opportunities, especially > for systems with serial consoles. Yes, I'm aware of that and will provide an appropriate patch shortly. -- Andre From owner-freebsd-current@FreeBSD.ORG Thu Jul 12 00:14:11 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AED0B16A400 for ; Thu, 12 Jul 2007 00:14:11 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with SMTP id 441AF13C459 for ; Thu, 12 Jul 2007 00:14:11 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 22025 invoked by uid 399); 12 Jul 2007 00:06:48 -0000 Received: from localhost (HELO ?192.168.0.6?) (dougb@dougbarton.us@127.0.0.1) by localhost with SMTP; 12 Jul 2007 00:06:48 -0000 X-Originating-IP: 127.0.0.1 Message-ID: <46957093.2030701@FreeBSD.org> Date: Wed, 11 Jul 2007 17:06:43 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Garrett Cooper References: <20070419133550.GA65054@tirith.brixandersen.dk> <20070419200929.GA70735@tirith.brixandersen.dk> <4693BC3E.1050605@web.am> <200707110115.42139.pieter@degoeje.nl> <469417CB.7010705@FreeBSD.org> <4694AAF1.6050302@web.am> <46951CC2.5050602@FreeBSD.org> <46955C9E.6090101@u.washington.edu> In-Reply-To: <46955C9E.6090101@u.washington.edu> X-Enigmail-Version: 0.95.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Pieter de Goeje , Gaspar Chilingarov , freebsd-current@freebsd.org Subject: Re: RFT: bin/106642: [patch] Allow excluding certain files from mergemaster (8) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2007 00:14:11 -0000 Garrett Cooper wrote: > Doug Barton wrote: >> Gaspar Chilingarov wrote: >> >> >>> Well another question -- is it possible teach somehow mergemaster, that >>> it should never touch passwd, groups, /etc/ttys or bunch of another >>> files? >>> >> >> Sure, you just do the opposite of what I did in the last script. If >> the file doesn't exist in the temproot when it's time to start >> comparing, mergemaster will never do anything with it. So here is some >> more out of the script that I actually use: >> >> #!/bin/sh >> # NOTE: No PATH needed, because mm's PATH is already draconian enough >> case "${PRE_WORLD}" in >> '') rm -f /etc/defaults/pccard.conf >> rm -f ${TEMPROOT}/etc/motd >> rm -f ${TEMPROOT}/etc/printcap >> rm -f ${TEMPROOT}/etc/namedb/named.* >> ;; >> esac >> >> > What if a user or group was added to /etc/group or /etc/passwd that was > required for the updated version of the OS? I would see this behavior a > bit counterproductive in this case. That's what the -p (PRE_WORLD) option is for. Doug -- This .signature sanitized for your protection From owner-freebsd-current@FreeBSD.ORG Thu Jul 12 00:41:57 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E143416A468 for ; Thu, 12 Jul 2007 00:41:57 +0000 (UTC) (envelope-from nslay@comcast.net) Received: from sccrmhc15.comcast.net (sccrmhc15.comcast.net [63.240.77.85]) by mx1.freebsd.org (Postfix) with ESMTP id B0D7213C447 for ; Thu, 12 Jul 2007 00:41:57 +0000 (UTC) (envelope-from nslay@comcast.net) Received: from lightbulb.local (c-68-35-224-189.hsd1.fl.comcast.net[68.35.224.189]) by comcast.net (sccrmhc15) with ESMTP id <2007071200415601500ivecme>; Thu, 12 Jul 2007 00:41:56 +0000 Message-ID: <46957878.1060001@comcast.net> Date: Wed, 11 Jul 2007 20:40:24 -0400 From: Nathan Lay User-Agent: Thunderbird 2.0.0.4 (X11/20070620) MIME-Version: 1.0 To: "M. Warner Losh" References: <4693131B.8090306@comcast.net> <20070710.012927.-300782446.imp@bsdimp.com> In-Reply-To: <20070710.012927.-300782446.imp@bsdimp.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-current@freebsd.org Subject: Re: ums, Microsoft Wireless Presenter mouse X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2007 00:41:58 -0000 M. Warner Losh wrote: > In message: <4693131B.8090306@comcast.net> > Nathan Lay writes: > : Hi list, > : I was pleased that my Microsoft Wireless Presenter mouse successfully > : attaches with CURRENT ums without fiddling with the source. I had to > : write a patch to use it with 6.2 (I submitted it to the drivers > : list...probably the wrong place to submit it). However, button bit > : positions and x,y,z,t positions do not register properly (This mouse > : reports mostly lies). I see a newly added quirks section for the > : Microsoft wireless optical mouse, though, is there a way I can > : gracefully add the quirks for this particular mouse too? > : Additionally, this mouse has 5 extra buttons on the bottom that serve > : for presentation purposes, though the mouse doesn't actually report > : them. The mouse has some sort of mode or status byte that can indicate > : whether the bottom 5 presentation buttons are in use or if the normal > : buttons are in use. I don't think this support would be too difficult > : to add, I'm just not sure how useful it is or how to add the support > : such that it isn't disruptive to other mice. > : > : http://www.microsoft.com/hardware/mouseandkeyboard/ProductDetails.aspx?pid=085 > : > > Please send me a usbdevs -v output and I'll get you started. > > Warner > > Sorry for the delay, I've been pretty busy these days. Here is the output of 'usbdevs -v' Controller /dev/usb0: addr 1: full speed, self powered, config 1, UHCI root hub(0x0000), Intel(0x0000), rev 1.00 port 1 addr 3: full speed, self powered, config 1, Microsoft® USB Hub(0x0707), Microsoft(0x045e), rev 1.00 port 1 powered port 2 powered port 3 addr 4: full speed, self powered, config 1, Microsoft® Wireless Notebook Presenter Mouse 8000(0x0713), Microsoft(0x045e), rev 1.00 port 2 addr 2: low speed, power 98 mA, config 1, USB-PS/2 Optical Mouse(0xc03d), Logitech(0x046d), rev 20.00 Best Regards, Nathan Lay From owner-freebsd-current@FreeBSD.ORG Thu Jul 12 00:45:55 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EC73616A421; Thu, 12 Jul 2007 00:45:54 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id B02B113C45B; Thu, 12 Jul 2007 00:45:54 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.13.8/8.13.8) with ESMTP id l6C0DC3U072322; Wed, 11 Jul 2007 20:13:12 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.8/8.13.8) with ESMTP id l6C0DBwg053948; Wed, 11 Jul 2007 20:13:11 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 99F4473068; Wed, 11 Jul 2007 20:13:11 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070712001311.99F4473068@freebsd-current.sentex.ca> Date: Wed, 11 Jul 2007 20:13:11 -0400 (EDT) X-Virus-Scanned: ClamAV version devel-20070108, clamav-milter version devel-111206 on news X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2007 00:45:55 -0000 TB --- 2007-07-11 22:00:00 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-07-11 22:00:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2007-07-11 22:00:00 - cleaning the object tree TB --- 2007-07-11 22:00:41 - checking out the source tree TB --- 2007-07-11 22:00:41 - cd /tinderbox/HEAD/amd64/amd64 TB --- 2007-07-11 22:00:41 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-07-11 22:11:53 - building world (CFLAGS=-O2 -pipe) TB --- 2007-07-11 22:11:53 - cd /src TB --- 2007-07-11 22:11:53 - /usr/bin/make -B buildworld >>> World build started on Wed Jul 11 22:11:55 UTC 2007 >>> 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 Jul 11 23:58:08 UTC 2007 TB --- 2007-07-11 23:58:08 - generating LINT kernel config TB --- 2007-07-11 23:58:08 - cd /src/sys/amd64/conf TB --- 2007-07-11 23:58:08 - /usr/bin/make -B LINT TB --- 2007-07-11 23:58:08 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-07-11 23:58:08 - cd /src TB --- 2007-07-11 23:58:08 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Jul 11 23:58:09 UTC 2007 >>> 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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/dev/if_ndis/if_ndis.c /src/sys/dev/if_ndis/if_ndis.c: In function 'ndis_wi_ioctl_get': /src/sys/dev/if_ndis/if_ndis.c:2989: error: storage size of 'wreq' isn't known cc1: warnings being treated as errors /src/sys/dev/if_ndis/if_ndis.c:2989: warning: unused variable 'wreq' /src/sys/dev/if_ndis/if_ndis.c: In function 'ndis_wi_ioctl_set': /src/sys/dev/if_ndis/if_ndis.c:3070: error: storage size of 'wreq' isn't known /src/sys/dev/if_ndis/if_ndis.c:3070: warning: unused variable 'wreq' *** Error code 1 Stop in /obj/amd64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-07-12 00:13:11 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-07-12 00:13:11 - ERROR: failed to build lint kernel TB --- 2007-07-12 00:13:11 - tinderbox aborted TB --- 0.92 user 3.75 system 7990.59 real http://tinderbox.des.no/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Thu Jul 12 00:53:27 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E0FD016A41F for ; Thu, 12 Jul 2007 00:53:27 +0000 (UTC) (envelope-from enderbsd@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.235]) by mx1.freebsd.org (Postfix) with ESMTP id 3AA7C13C457 for ; Thu, 12 Jul 2007 00:53:27 +0000 (UTC) (envelope-from enderbsd@gmail.com) Received: by wx-out-0506.google.com with SMTP id i29so1463499wxd for ; Wed, 11 Jul 2007 17:53:25 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=KphupzDGhTpIWz1IoKHp0GRgrPsJlxX5V8n2YPknasCio0jq8FV5S5pKBkeEg/lNZOoRJuL9XhghsaJK9/Bj66U6yqKeB53iPNxiesPwIyuBBWxHw1sEUP9I+3BV+bGeYfiQQ/lEJXM9j8uV4zy+xqw0I1beXVh+0J6pml48LNA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=CxVtMt0QuqhNeB6H3QzLCAc1/unYSrXQx2g/7SNLTWQj8TvX7tF9myj1tKRW9YPpDX2qbW5DyC8F258yz0mC25tZpVtNEQ5ZDQHhDDZdBMiH7sJdlGxNC7AOVyCSUB+XL9jCQYObzAEn/5Vj4bbGRXJPcYRmMmHGVtE4UzDT6V4= Received: by 10.90.99.20 with SMTP id w20mr14700agb.1184199881584; Wed, 11 Jul 2007 17:24:41 -0700 (PDT) Received: by 10.90.56.12 with HTTP; Wed, 11 Jul 2007 17:24:41 -0700 (PDT) Message-ID: <15d429c0707111724w76d47529v4c5fad6ac7892875@mail.gmail.com> Date: Wed, 11 Jul 2007 20:24:41 -0400 From: "Simon Dircks" To: "Huang wen hui" In-Reply-To: <46922D75.4010006@gddsn.org.cn> MIME-Version: 1.0 References: <200707071426.18202.dfr@rabson.org> <20070709000918.GD1208@garage.freebsd.pl> <46922D75.4010006@gddsn.org.cn> Content-Type: text/plain; charset=ISO-2022-JP; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Pawel Jakub Dawidek , current@freebsd.org Subject: Re: ZFS leaking vnodes (sort of) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2007 00:53:28 -0000 On 7/9/07, Huang wen hui wrote: > > Pawel Jakub Dawidek $B > On Sat, Jul 07, 2007 at 02:26:17PM +0100, Doug Rabson wrote: > > > >> I've been testing ZFS recently and I noticed some performance issues > >> while doing large-scale port builds on a ZFS mounted /usr/ports tree. > >> Eventually I realised that virtually nothing ever ended up on the vnode > >> free list. This meant that when the system reached its maximum vnode > >> limit, it had to resort to reclaiming vnodes from the various > >> filesystem's active vnode lists (via vlrureclaim). Since those lists > >> are not sorted in LRU order, this led to pessimal cache performance > >> after the system got into that state. > >> > >> I looked a bit closer at the ZFS code and poked around with DDB and I > >> think the problem was caused by a couple of extraneous calls to vhold > >> when creating a new ZFS vnode. On FreeBSD, getnewvnode returns a vnode > >> which is already held (not on the free list) so there is no need to > >> call vhold again. > >> > > > > Whoa! Nice catch... The patch works here - I did some pretty heavy > > tests, so please commit it ASAP. > > > > I also wonder if this can help with some of those 'kmem_map too small' > > panics. I was observing that ARC cannot reclaim memory and this may be > > because all vnodes and thus associated data are beeing held. > > > > To ZFS users having problems with performance and/or stability of ZFS: > > Can you test the patch and see if it helps? > > > my T60p notebook, -CURRENT amd64: > buildworld time before patch: 58xx second. > buildworld time after path: 28xx second. > > Thanks! With this patch i am still able to reproduce my ZFS crash. controllera# uname -a FreeBSD controllera.storage.ksdhost.com 7.0-CURRENT FreeBSD 7.0-CURRENT #0: Thu Jul 12 02:28:52 UTC 2007 graff@controllera.storage.ksdhost.com:/usr/obj/usr/src/sys/CONTROLLERA amd64 panic: ZFS: bad checksum (read on off 0: zio 0xffffff001d729810 [LO SP A space map] 1000L/800P DVA[0]=<0:1600421800:800> DVA[1]=<0:2c000f7000:800> DVA[ 2]=<0:4200013800:800> fletcher4 lzjb LE contiguous birth=566 fill=1 chsum=5d3276 7b98:635ff7022f8b:4251 cpuid = 0 KDB: enter: panic [thread pid 802 tid 100066 ] stopped at kdb_enter+0x31: leave From owner-freebsd-current@FreeBSD.ORG Thu Jul 12 00:57:33 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D8B1F16A469; Thu, 12 Jul 2007 00:57:33 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from heff.fud.org.nz (203-109-251-39.static.bliink.ihug.co.nz [203.109.251.39]) by mx1.freebsd.org (Postfix) with ESMTP id F282813C447; Thu, 12 Jul 2007 00:57:32 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: by heff.fud.org.nz (Postfix, from userid 1001) id B311B1CC5E; Thu, 12 Jul 2007 12:57:30 +1200 (NZST) Date: Thu, 12 Jul 2007 12:57:30 +1200 From: Andrew Thompson To: FreeBSD Tinderbox Message-ID: <20070712005730.GA1285@heff.fud.org.nz> References: <20070712001311.99F4473068@freebsd-current.sentex.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070712001311.99F4473068@freebsd-current.sentex.ca> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: amd64@freebsd.org, re@freebsd.org, current@freebsd.org Subject: Re: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2007 00:57:33 -0000 On Wed, Jul 11, 2007 at 08:13:11PM -0400, FreeBSD Tinderbox wrote: > TB --- 2007-07-11 22:00:00 - tinderbox 2.3 running on freebsd-current.sentex.ca > TB --- 2007-07-11 22:00:00 - starting HEAD tinderbox run for amd64/amd64 > TB --- 2007-07-11 22:00:00 - cleaning the object tree > TB --- 2007-07-11 22:00:41 - checking out the source tree > TB --- 2007-07-11 22:00:41 - cd /tinderbox/HEAD/amd64/amd64 > TB --- 2007-07-11 22:00:41 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src > [...] > 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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/dev/if_ndis/if_ndis.c > /src/sys/dev/if_ndis/if_ndis.c: In function 'ndis_wi_ioctl_get': > /src/sys/dev/if_ndis/if_ndis.c:2989: error: storage size of 'wreq' isn't known > cc1: warnings being treated as errors > /src/sys/dev/if_ndis/if_ndis.c:2989: warning: unused variable 'wreq' > /src/sys/dev/if_ndis/if_ndis.c: In function 'ndis_wi_ioctl_set': > /src/sys/dev/if_ndis/if_ndis.c:3070: error: storage size of 'wreq' isn't known > /src/sys/dev/if_ndis/if_ndis.c:3070: warning: unused variable 'wreq' Oops, I have a pending patch for ndis with re@ that removes this. I forgot that both changes were in my test build. Andrew From owner-freebsd-current@FreeBSD.ORG Thu Jul 12 01:04:29 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7029C16A46B; Thu, 12 Jul 2007 01:04:29 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 4196013C45D; Thu, 12 Jul 2007 01:04:29 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.13.8/8.13.8) with ESMTP id l6C14StF077507; Wed, 11 Jul 2007 21:04:28 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.8/8.13.8) with ESMTP id l6C14SxY058992; Wed, 11 Jul 2007 21:04:28 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 5AD8473068; Wed, 11 Jul 2007 21:04:28 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070712010428.5AD8473068@freebsd-current.sentex.ca> Date: Wed, 11 Jul 2007 21:04:28 -0400 (EDT) X-Virus-Scanned: ClamAV version devel-20070108, clamav-milter version devel-111206 on clamscanner4 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2007 01:04:29 -0000 TB --- 2007-07-11 23:24:13 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-07-11 23:24:13 - starting HEAD tinderbox run for i386/i386 TB --- 2007-07-11 23:24:13 - cleaning the object tree TB --- 2007-07-11 23:24:45 - checking out the source tree TB --- 2007-07-11 23:24:45 - cd /tinderbox/HEAD/i386/i386 TB --- 2007-07-11 23:24:45 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-07-11 23:33:21 - building world (CFLAGS=-O2 -pipe) TB --- 2007-07-11 23:33:21 - cd /src TB --- 2007-07-11 23:33:21 - /usr/bin/make -B buildworld >>> World build started on Wed Jul 11 23:33:22 UTC 2007 >>> 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 Jul 12 00:47:47 UTC 2007 TB --- 2007-07-12 00:47:47 - generating LINT kernel config TB --- 2007-07-12 00:47:47 - cd /src/sys/i386/conf TB --- 2007-07-12 00:47:47 - /usr/bin/make -B LINT TB --- 2007-07-12 00:47:48 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-07-12 00:47:48 - cd /src TB --- 2007-07-12 00:47:48 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Jul 12 00:47:48 UTC 2007 >>> 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 -Werror -pg -mprofiler-epilogue /src/sys/dev/if_ndis/if_ndis.c /src/sys/dev/if_ndis/if_ndis.c: In function 'ndis_wi_ioctl_get': /src/sys/dev/if_ndis/if_ndis.c:2989: error: storage size of 'wreq' isn't known cc1: warnings being treated as errors /src/sys/dev/if_ndis/if_ndis.c:2989: warning: unused variable 'wreq' /src/sys/dev/if_ndis/if_ndis.c: In function 'ndis_wi_ioctl_set': /src/sys/dev/if_ndis/if_ndis.c:3070: error: storage size of 'wreq' isn't known /src/sys/dev/if_ndis/if_ndis.c:3070: warning: unused variable 'wreq' *** Error code 1 Stop in /obj/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-07-12 01:04:28 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-07-12 01:04:28 - ERROR: failed to build lint kernel TB --- 2007-07-12 01:04:28 - tinderbox aborted TB --- 0.88 user 2.96 system 6014.90 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Thu Jul 12 01:12:27 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DF39F16A47E for ; Thu, 12 Jul 2007 01:12:27 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from heff.fud.org.nz (203-109-251-39.static.bliink.ihug.co.nz [203.109.251.39]) by mx1.freebsd.org (Postfix) with ESMTP id 7787913C483 for ; Thu, 12 Jul 2007 01:12:27 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: by heff.fud.org.nz (Postfix, from userid 1001) id 0F3311CC5D; Thu, 12 Jul 2007 13:12:26 +1200 (NZST) Date: Thu, 12 Jul 2007 13:12:26 +1200 From: Andrew Thompson To: David Wolfskill , current@freebsd.org Message-ID: <20070712011226.GB1285@heff.fud.org.nz> References: <20070711172448.GA42994@bunrab.catwhisker.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070711172448.GA42994@bunrab.catwhisker.org> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: Subject: Re: Oddity with an(4): Channel reported by ifconfig is wrong X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2007 01:12:28 -0000 On Wed, Jul 11, 2007 at 10:24:48AM -0700, David Wolfskill wrote: > This may be an off-by-one issue: I have two APs with the same SSID; > one on channel 1; the other on channel 6. But: > > g1-1(7.0-C)[1] uname -a > FreeBSD g1-1.catwhisker.org. 7.0-CURRENT FreeBSD 7.0-CURRENT #480: Wed Jul 11 09:44:13 PDT 2007 root@g1-1.catwhisker.org.:/common/S4/obj/usr/src/sys/CANARY i386 > g1-1(7.0-C)[2] > > g1-1(7.0-C)[3] ifconfig > xl0: flags=8802 metric 0 mtu 1500 > options=9 > ether 00:08:74:e5:95:cb > media: Ethernet autoselect (none) > status: no carrier > fwe0: flags=8802 metric 0 mtu 1500 > options=8 > ether 46:4f:c0:76:40:41 > ch 1 dma -1 > fwip0: flags=8802 metric 0 mtu 1500 > lladdr 44.4f.c0.0.30.76.40.41.a.2.ff.fe.0.0.0.0 > plip0: flags=108810 metric 0 mtu 1500 > lo0: flags=8049 metric 0 mtu 16384 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5 > inet6 ::1 prefixlen 128 > inet 127.0.0.1 netmask 0xff000000 > wi0: flags=8802 metric 0 mtu 1500 > ether 00:02:2d:5b:2c:78 > media: IEEE 802.11 Wireless Ethernet autoselect (none) > status: no carrier > ssid catwhisker channel 1 (2412 Mhz 11b) > stationname "FreeBSD WaveLAN/IEEE node" > authmode OPEN privacy ON deftxkey 1 wepkey 1:40-bit txpowmax 100 > bmiss 7 scanvalid 60 > > As you see, the an0 NIC (a PCMCIA part) is the only one in use (as > the miniPCI wi0 still doesn't associate). So wi is still not working at all? Can you post the log again with debug.wi set to 2. Does 'ifconfig wi0 scan' show anything? Andrew From owner-freebsd-current@FreeBSD.ORG Thu Jul 12 01:53:13 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9BE2716A421; Thu, 12 Jul 2007 01:53:13 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 720EC13C447; Thu, 12 Jul 2007 01:53:13 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.13.8/8.13.8) with ESMTP id l6C1rC9p079248; Wed, 11 Jul 2007 21:53:12 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.8/8.13.8) with ESMTP id l6C1rCGa035386; Wed, 11 Jul 2007 21:53:12 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 7794173068; Wed, 11 Jul 2007 21:53:12 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070712015312.7794173068@freebsd-current.sentex.ca> Date: Wed, 11 Jul 2007 21:53:12 -0400 (EDT) X-Virus-Scanned: ClamAV version devel-20070102, clamav-milter version devel-111206 on clamscanner4 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2007 01:53:13 -0000 TB --- 2007-07-12 00:13:11 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-07-12 00:13:11 - starting HEAD tinderbox run for i386/pc98 TB --- 2007-07-12 00:13:11 - cleaning the object tree TB --- 2007-07-12 00:13:37 - checking out the source tree TB --- 2007-07-12 00:13:37 - cd /tinderbox/HEAD/i386/pc98 TB --- 2007-07-12 00:13:37 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-07-12 00:21:14 - building world (CFLAGS=-O2 -pipe) TB --- 2007-07-12 00:21:14 - cd /src TB --- 2007-07-12 00:21:14 - /usr/bin/make -B buildworld >>> World build started on Thu Jul 12 00:21:15 UTC 2007 >>> 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 Jul 12 01:35:12 UTC 2007 TB --- 2007-07-12 01:35:12 - generating LINT kernel config TB --- 2007-07-12 01:35:12 - cd /src/sys/pc98/conf TB --- 2007-07-12 01:35:12 - /usr/bin/make -B LINT TB --- 2007-07-12 01:35:13 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-07-12 01:35:13 - cd /src TB --- 2007-07-12 01:35:13 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Jul 12 01:35:13 UTC 2007 >>> 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 [...] ===> if_ndis (all) cc -O2 -pipe -DPC98 -fno-strict-aliasing -D_KERNEL -DKLD_MODULE -std=c99 -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/pc98/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/pc98/src/sys/LINT -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c /src/sys/modules/if_ndis/../../dev/if_ndis/if_ndis.c /src/sys/modules/if_ndis/../../dev/if_ndis/if_ndis.c: In function 'ndis_wi_ioctl_get': /src/sys/modules/if_ndis/../../dev/if_ndis/if_ndis.c:2989: error: storage size of 'wreq' isn't known /src/sys/modules/if_ndis/../../dev/if_ndis/if_ndis.c:2989: warning: unused variable 'wreq' /src/sys/modules/if_ndis/../../dev/if_ndis/if_ndis.c: In function 'ndis_wi_ioctl_set': /src/sys/modules/if_ndis/../../dev/if_ndis/if_ndis.c:3070: error: storage size of 'wreq' isn't known /src/sys/modules/if_ndis/../../dev/if_ndis/if_ndis.c:3070: warning: unused variable 'wreq' *** Error code 1 Stop in /src/sys/modules/if_ndis. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/pc98/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-07-12 01:53:11 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-07-12 01:53:11 - ERROR: failed to build lint kernel TB --- 2007-07-12 01:53:11 - tinderbox aborted TB --- 0.84 user 2.84 system 6000.24 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Thu Jul 12 02:37:56 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 12A3C16A421 for ; Thu, 12 Jul 2007 02:37:56 +0000 (UTC) (envelope-from lists@swaggi.com) Received: from rusty.swaggy.net (rusty.swaggy.net [204.14.85.196]) by mx1.freebsd.org (Postfix) with ESMTP id E599713C46A for ; Thu, 12 Jul 2007 02:37:55 +0000 (UTC) (envelope-from lists@swaggi.com) Received: from localhost ([127.0.0.1] helo=swaggi.com) by rusty.swaggy.net with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I8oBS-000LLb-SO for freebsd-current@freebsd.org; Wed, 11 Jul 2007 22:13:36 -0400 From: "Yuri Lukin" To: freebsd-current@freebsd.org Date: Wed, 11 Jul 2007 22:13:34 -0400 Message-Id: <20070712021057.M59188@swaggi.com> In-Reply-To: <469504D2.8000200@errno.com> References: <469504D2.8000200@errno.com> X-Mailer: swaggi.com MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Subject: Re: HEADSUP: new wpa_supplicant and hostapd [ndis users read] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2007 02:37:56 -0000 On Wed, 11 Jul 2007 09:26:58 -0700, Sam Leffler wrote > These applications have been updated to the 0.5.8 "stable release" > from Jouni Malinen. This gets us back on Jouni's stable release > branch (as opposed to the abandoned code base we were using). There > are many new features (read the docs in contrib) and you should now > be able to use 802.1x over wired nic's though it may not be > configured by default > (please send patches after testing and I will try stuff updated). > > ndis support in wpa_supplicant has been tested but requires fixups > in the kernel that are pending. However people using ndis should > also be aware that the in-kernel ndis support has badly rotted and > appears chock-a-block with issues. Unless someone steps up to work > on it expect instability. Thanks to Andrew Thompson for patching > things up. > Hi Sam, Great work, thank you. Does this update include multi-bss support? There's mention of it in the ChangeLog for hostapd but "only for Devicescape and test driver interfaces"? Regards, Yuri From owner-freebsd-current@FreeBSD.ORG Thu Jul 12 02:58:16 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3FE1F16A46B for ; Thu, 12 Jul 2007 02:58:16 +0000 (UTC) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id 18E1E13C46C for ; Thu, 12 Jul 2007 02:58:16 +0000 (UTC) (envelope-from sam@errno.com) Received: from trouble.errno.com (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id l6C2wFt5025176 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Jul 2007 19:58:15 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <46959946.9010607@errno.com> Date: Wed, 11 Jul 2007 20:00:22 -0700 From: Sam Leffler User-Agent: Thunderbird 2.0.0.0 (X11/20070530) MIME-Version: 1.0 To: Joe Marcus Clarke References: <469504D2.8000200@errno.com> <46951B50.3020601@FreeBSD.org> In-Reply-To: <46951B50.3020601@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: HEADSUP: new wpa_supplicant and hostapd [ndis users read] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2007 02:58:16 -0000 Joe Marcus Clarke wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Sam Leffler wrote: >> These applications have been updated to the 0.5.8 "stable release" from >> Jouni Malinen. This gets us back on Jouni's stable release branch (as >> opposed to the abandoned code base we were using). There are many new >> features (read the docs in contrib) and you should now be able to use >> 802.1x over wired nic's though it may not be configured by default >> (please send patches after testing and I will try stuff updated). >> >> ndis support in wpa_supplicant has been tested but requires fixups in >> the kernel that are pending. However people using ndis should also be >> aware that the in-kernel ndis support has badly rotted and appears >> chock-a-block with issues. Unless someone steps up to work on it expect >> instability. Thanks to Andrew Thompson for patching things up. > > Are there plans to add the patch to the base system OpenSSL needed to > enable EAP-FAST? This would greatly help me at work. I have no plans. I don't know who's looking after openssl these days but I'm loathe to take bits off the vendor branch. OTOH having EAP-FAST work would be very useful. Sam From owner-freebsd-current@FreeBSD.ORG Thu Jul 12 02:59:31 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 312F416A46D for ; Thu, 12 Jul 2007 02:59:31 +0000 (UTC) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id 0962313C484 for ; Thu, 12 Jul 2007 02:59:30 +0000 (UTC) (envelope-from sam@errno.com) Received: from trouble.errno.com (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id l6C2xUBp025187 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Jul 2007 19:59:30 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <46959990.3000907@errno.com> Date: Wed, 11 Jul 2007 20:01:36 -0700 From: Sam Leffler User-Agent: Thunderbird 2.0.0.0 (X11/20070530) MIME-Version: 1.0 To: Yuri Lukin References: <469504D2.8000200@errno.com> <20070712021057.M59188@swaggi.com> In-Reply-To: <20070712021057.M59188@swaggi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: HEADSUP: new wpa_supplicant and hostapd [ndis users read] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2007 02:59:31 -0000 Yuri Lukin wrote: > On Wed, 11 Jul 2007 09:26:58 -0700, Sam Leffler wrote >> These applications have been updated to the 0.5.8 "stable release" >> from Jouni Malinen. This gets us back on Jouni's stable release >> branch (as opposed to the abandoned code base we were using). There >> are many new features (read the docs in contrib) and you should now >> be able to use 802.1x over wired nic's though it may not be >> configured by default >> (please send patches after testing and I will try stuff updated). >> >> ndis support in wpa_supplicant has been tested but requires fixups >> in the kernel that are pending. However people using ndis should >> also be aware that the in-kernel ndis support has badly rotted and >> appears chock-a-block with issues. Unless someone steps up to work >> on it expect instability. Thanks to Andrew Thompson for patching >> things up. >> > > Hi Sam, > > Great work, thank you. > > Does this update include multi-bss support? There's mention of it in the > ChangeLog for hostapd but "only for Devicescape and test driver interfaces"? multi-bss support in hostapd is present but nothing is in the kernel and it's unlikely any multi-bss code will go into 7.x because it would require api changes. More likely the vap code will appear in 8.x. Sam From owner-freebsd-current@FreeBSD.ORG Thu Jul 12 03:01:29 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AAFC516A400 for ; Thu, 12 Jul 2007 03:01:29 +0000 (UTC) (envelope-from dwhite@gumbysoft.com) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.freebsd.org (Postfix) with ESMTP id 9921113C447 for ; Thu, 12 Jul 2007 03:01:29 +0000 (UTC) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id 622DF72DA5; Wed, 11 Jul 2007 19:28:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id 5C05972DA1; Wed, 11 Jul 2007 19:28:55 -0700 (PDT) Date: Wed, 11 Jul 2007 19:28:55 -0700 (PDT) From: Doug White To: current@freebsd.org, tcsh-bugs@mx.gw.com Message-ID: <20070711191310.M90716@carver.gumbysoft.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Subject: tcsh backtick hang info X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2007 03:01:29 -0000 (note: freebsd-current@freebsd.org and tcsh-bugs@mx.gw.com are in the To: on this message. Restrict replies accordingly.) Hey folks, I spent several hours today pawing through the tcsh source in an effort to figure out whats going on with tcsh hangs with backticked commands in tcsh 6.15.00. The canonical example is something like: kill `ps ax | grep foo | awk '{print $1}'` where a builtin gets its arguments from a backticked expression composed of non-builtins. tcsh 6.15.00 introduced a new reference-counted signal management facility where, instead of manipulating the signal mask directly, functions increment a variable that is polled to see whether to perform the action associated with SIGINT, SIGCHLD, SIGALRM, or SIGHUP. The signal handler function itself sets a pending flag for each named signal and returns, so only a few instructions are executed in signal context. At some future point the pending flags are polled by a call to handle_pending_signals(), usually in a loop where the shell goes to sleep waiting for an external action to occur. When the function no longer needs the signal to be blocked it decrements the count via a stack of cleanup handlers. When a count reaches zero then a poll is immediately triggered. If the disabled count is >1 for a signal when a handle_pending_signals() poll occurs, then the signal is not "handled". In the case above, the disabled count for SIGCHLD is 1 when SIGCHLD fires from the completion of the backticked commands. The sigsuspend() in pjwait() is correctly woken up by the kernel but, because the disabled count is 1, the shell goes back into sigsuspend() and appears to hang. In this case it appears to be an improperly placed bump to the SIGCHLD disable count that is held over a call to pjwait(). I haven't yet determined the call stack (and gdb cannot debug tcsh at the moment) so I need to continue instrumenting the code to figure out what higher level function is disabling SIGCHLD and then calling something that eventually calls pjwait(). -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Thu Jul 12 03:50:49 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 30E4116A46D for ; Thu, 12 Jul 2007 03:50:49 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.freebsd.org (Postfix) with ESMTP id 1549513C480 for ; Thu, 12 Jul 2007 03:50:49 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.1/8.13.8) with ESMTP id l6C3n3VG084599; Wed, 11 Jul 2007 20:49:03 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.1/8.13.8/Submit) id l6C3msEc084598; Wed, 11 Jul 2007 20:48:54 -0700 (PDT) (envelope-from sgk) Date: Wed, 11 Jul 2007 20:48:54 -0700 From: Steve Kargl To: Doug White Message-ID: <20070712034854.GA84554@troutmask.apl.washington.edu> References: <20070711191310.M90716@carver.gumbysoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070711191310.M90716@carver.gumbysoft.com> User-Agent: Mutt/1.4.2.2i Cc: tcsh-bugs@mx.gw.com, current@freebsd.org Subject: Re: tcsh backtick hang info X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2007 03:50:49 -0000 On Wed, Jul 11, 2007 at 07:28:55PM -0700, Doug White wrote: > > In this case it appears to be an improperly placed bump to the SIGCHLD > disable count that is held over a call to pjwait(). I haven't yet > determined the call stack (and gdb cannot debug tcsh at the moment) so I > need to continue instrumenting the code to figure out what higher level > function is disabling SIGCHLD and then calling something that eventually > calls pjwait(). > Signal handling is completely and utterly messed up in tcsh 6.15.0. I've asked more than once to have the 6.15.0 import reverted in the FreeBSD tree. Having broken signal handling for the default shell of root suggests that there is a likely exploit waiting in the wings. -- Steve From owner-freebsd-current@FreeBSD.ORG Thu Jul 12 04:01:23 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1317816A400; Thu, 12 Jul 2007 04:01:23 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from pobox.codelabs.ru (pobox.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id B3CB313C44C; Thu, 12 Jul 2007 04:01:22 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=one; d=codelabs.ru; h=Received:Date:From:To:Cc:Message-ID:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:Sender:X-Spam-Status:Subject; b=NFQraD/xZ20H3b8HoXlrxZXWQ+1LkdQXJV0Kww7AbGb+ngbkxGtsCo+eLTJUGoW9eifJwz3wufgMzvxpiKFge8aND+Tc5D6l53dQlKSLrg78NsdaVb5q5MQUVnOcMcT7eyPMeXCe14goiXETj49cIHC/oKFAnGq7ps/Y5/m8bqM=; Received: from void.codelabs.ru (void.codelabs.ru [144.206.177.25]) by pobox.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1I8prk-0007wB-He; Thu, 12 Jul 2007 08:01:20 +0400 Date: Thu, 12 Jul 2007 08:01:15 +0400 From: Eygene Ryabinkin To: Mike Silbersack Message-ID: <20070712040115.GK1038@void.codelabs.ru> References: <20070709234401.S29353@odysseus.silby.com> <20070710132253.GJ1038@void.codelabs.ru> <20070710202028.I34890@odysseus.silby.com> <20070711060423.GV1038@void.codelabs.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20070711060423.GV1038@void.codelabs.ru> Sender: rea-fbsd@codelabs.ru X-Spam-Status: No, score=-3.0 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_00 Cc: Robert Watson , Andre Oppermann , current@freebsd.org, net@freebsd.org Subject: Re: FreeBSD 7 TCP syncache fix: request for testers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2007 04:01:23 -0000 Good day. Wed, Jul 11, 2007 at 10:04:23AM +0400, Eygene Ryabinkin wrote: > OK, maybe I have something that can be related to this bug. It > provokes another message, 'Spurious RST', but can be correlated > with your guess. What is happening is that when one side closes > the connection and releases the socket (running -CURRENT) while the > other one is still pushing data through the connection, we are > getting 'Spurious RST' messages. This happens, because we are > checking the 'so->so_state' for the presence of the 'SS_NOFDREF' > flag (tcp_input.c, version 1.361, line 1581) and dropping such > connections with RST. But the connection was already closed (living > in the FIN-WAIT-2 state, to be precise) from that side, so it > provokes the debug message. To clarify one point: the first RST is due to the SS_NOFDREF flag. The rest of RSTs are spitted out because the corresponding connection was closed by tcp_close() just before the first RST. -- Eygene From owner-freebsd-current@FreeBSD.ORG Thu Jul 12 04:23:30 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5D15F16A469 for ; Thu, 12 Jul 2007 04:23:30 +0000 (UTC) (envelope-from mp@FreeBSD.org) Received: from relay02.pair.com (relay02.pair.com [209.68.5.16]) by mx1.freebsd.org (Postfix) with SMTP id 0E9AB13C46E for ; Thu, 12 Jul 2007 04:23:29 +0000 (UTC) (envelope-from mp@FreeBSD.org) Received: (qmail 75081 invoked by uid 0); 12 Jul 2007 03:56:48 -0000 Received: from 24.4.239.7 (HELO mp.peek.org) (24.4.239.7) by relay02.pair.com with SMTP; 12 Jul 2007 03:56:48 -0000 X-pair-Authenticated: 24.4.239.7 Message-ID: <4695A66A.8030903@FreeBSD.org> Date: Wed, 11 Jul 2007 20:56:26 -0700 From: Mark Peek User-Agent: Thunderbird 2.0.0.0pre (Macintosh/20070419) MIME-Version: 1.0 To: Doug White References: <20070711191310.M90716@carver.gumbysoft.com> In-Reply-To: <20070711191310.M90716@carver.gumbysoft.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: tcsh-bugs@mx.gw.com, current@freebsd.org Subject: Re: tcsh backtick hang info X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2007 04:23:30 -0000 On 7/11/07 7:28 PM, Doug White wrote: > (note: freebsd-current@freebsd.org and tcsh-bugs@mx.gw.com are in the > To: on this message. Restrict replies accordingly.) > > Hey folks, > > I spent several hours today pawing through the tcsh source in an effort > to figure out whats going on with tcsh hangs with backticked commands in > tcsh 6.15.00. > > The canonical example is something like: > > kill `ps ax | grep foo | awk '{print $1}'` > > where a builtin gets its arguments from a backticked expression composed > of non-builtins. > > tcsh 6.15.00 introduced a new reference-counted signal management > facility where, instead of manipulating the signal mask directly, > functions increment a variable that is polled to see whether to perform > the action associated with SIGINT, SIGCHLD, SIGALRM, or SIGHUP. The > signal handler function itself sets a pending flag for each named signal > and returns, so only a few instructions are executed in signal context. > At some future point the pending flags are polled by a call to > handle_pending_signals(), usually in a loop where the shell goes to > sleep waiting for an external action to occur. When the function no > longer needs the signal to be blocked it decrements the count via a > stack of cleanup handlers. When a count reaches zero then a poll is > immediately triggered. > > If the disabled count is >1 for a signal when a handle_pending_signals() > poll occurs, then the signal is not "handled". > > In the case above, the disabled count for SIGCHLD is 1 when SIGCHLD > fires from the completion of the backticked commands. The sigsuspend() > in pjwait() is correctly woken up by the kernel but, because the > disabled count is 1, the shell goes back into sigsuspend() and appears > to hang. > > In this case it appears to be an improperly placed bump to the SIGCHLD > disable count that is held over a call to pjwait(). I haven't yet > determined the call stack (and gdb cannot debug tcsh at the moment) so I > need to continue instrumenting the code to figure out what higher level > function is disabling SIGCHLD and then calling something that eventually > calls pjwait(). > There appears to be two different issues. One is with the builtin kill and the other is the gdb issue. I sent off a tentative patch to the reporter of the builtin kill issue and am awaiting onfirmation. The patch is here: http://people.freebsd.org/~mp/tcsh_kill.patch The gdb issue, much to my dismay, is still alluding my debugging skill given the interaction with gdb and issues with actually debugging what is happening. Mark From owner-freebsd-current@FreeBSD.ORG Thu Jul 12 05:36:55 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E69CF16A400 for ; Thu, 12 Jul 2007 05:36:55 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.169]) by mx1.freebsd.org (Postfix) with ESMTP id 6F95C13C458 for ; Thu, 12 Jul 2007 05:36:55 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: by ug-out-1314.google.com with SMTP id o4so296271uge for ; Wed, 11 Jul 2007 22:36:54 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=bE3KK1aGT6Et5DWYmLqTxNwfeHOcPiD3JBQisjl4gfB8I7qSopxXCWi1zRv921xy/j1WSKrxFGqU9lpWkqhYqic7CKZrVRNcpu4jomqLR86emVFUgtylLJkKfLRdGCa/8wvz35lRf/UTObLgm4cBAeOtSMj4G3YEE8FnpQPd0v0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Df1u+rfpje+bwicwqG6ITUwgZPyhBCqjphloGGTB1XDpIi5GEWPiJM+66HVzeMMSJxFf3oXUXVUne5zWRBT6rrSoc6f+BH59X4n3nvNOvRBBZQYetb3gfY7KJ0ljZnCeAcr/Rc5RpQC04RQXlDBnmHdfYIaf7brDy6HNn6HUMnA= Received: by 10.78.137.7 with SMTP id k7mr57790hud.1184218613908; Wed, 11 Jul 2007 22:36:53 -0700 (PDT) Received: by 10.78.162.18 with HTTP; Wed, 11 Jul 2007 22:36:53 -0700 (PDT) Message-ID: Date: Wed, 11 Jul 2007 22:36:53 -0700 From: "Kip Macy" To: "Simon Dircks" In-Reply-To: <15d429c0707111724w76d47529v4c5fad6ac7892875@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200707071426.18202.dfr@rabson.org> <20070709000918.GD1208@garage.freebsd.pl> <46922D75.4010006@gddsn.org.cn> <15d429c0707111724w76d47529v4c5fad6ac7892875@mail.gmail.com> Cc: Pawel Jakub Dawidek , current@freebsd.org Subject: Re: ZFS leaking vnodes (sort of) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2007 05:36:56 -0000 That looks more like bad disk than a file system bug. On 7/11/07, Simon Dircks wrote: > On 7/9/07, Huang wen hui wrote: > > > > Pawel Jakub Dawidek $B > > On Sat, Jul 07, 2007 at 02:26:17PM +0100, Doug Rabson wrote: > > > > > >> I've been testing ZFS recently and I noticed some performance issues > > >> while doing large-scale port builds on a ZFS mounted /usr/ports tree. > > >> Eventually I realised that virtually nothing ever ended up on the vnode > > >> free list. This meant that when the system reached its maximum vnode > > >> limit, it had to resort to reclaiming vnodes from the various > > >> filesystem's active vnode lists (via vlrureclaim). Since those lists > > >> are not sorted in LRU order, this led to pessimal cache performance > > >> after the system got into that state. > > >> > > >> I looked a bit closer at the ZFS code and poked around with DDB and I > > >> think the problem was caused by a couple of extraneous calls to vhold > > >> when creating a new ZFS vnode. On FreeBSD, getnewvnode returns a vnode > > >> which is already held (not on the free list) so there is no need to > > >> call vhold again. > > >> > > > > > > Whoa! Nice catch... The patch works here - I did some pretty heavy > > > tests, so please commit it ASAP. > > > > > > I also wonder if this can help with some of those 'kmem_map too small' > > > panics. I was observing that ARC cannot reclaim memory and this may be > > > because all vnodes and thus associated data are beeing held. > > > > > > To ZFS users having problems with performance and/or stability of ZFS: > > > Can you test the patch and see if it helps? > > > > > my T60p notebook, -CURRENT amd64: > > buildworld time before patch: 58xx second. > > buildworld time after path: 28xx second. > > > > Thanks! > > > > With this patch i am still able to reproduce my ZFS crash. > > controllera# uname -a > FreeBSD controllera.storage.ksdhost.com 7.0-CURRENT FreeBSD 7.0-CURRENT #0: > Thu Jul 12 02:28:52 UTC 2007 > graff@controllera.storage.ksdhost.com:/usr/obj/usr/src/sys/CONTROLLERA > amd64 > > > panic: ZFS: bad checksum (read on off 0: zio 0xffffff001d729810 > [LO SP > A space map] 1000L/800P DVA[0]=<0:1600421800:800> DVA[1]=<0:2c000f7000:800> > DVA[ > 2]=<0:4200013800:800> fletcher4 lzjb LE contiguous birth=566 fill=1 > chsum=5d3276 > 7b98:635ff7022f8b:4251 > cpuid = 0 > KDB: enter: panic > [thread pid 802 tid 100066 ] > stopped at kdb_enter+0x31: leave > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Thu Jul 12 05:44:09 2007 Return-Path: X-Original-To: Current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DE8D916A468 for ; Thu, 12 Jul 2007 05:44:09 +0000 (UTC) (envelope-from daichi@freebsd.org) Received: from natial.ongs.co.jp (natial.ongs.co.jp [202.216.232.58]) by mx1.freebsd.org (Postfix) with ESMTP id 784C713C447 for ; Thu, 12 Jul 2007 05:44:09 +0000 (UTC) (envelope-from daichi@freebsd.org) Received: from parancell.ongs.co.jp (dullmdaler.ongs.co.jp [202.216.232.62]) by natial.ongs.co.jp (Postfix) with ESMTP id 5731E244C19; Thu, 12 Jul 2007 14:44:06 +0900 (JST) Message-ID: <4695BFA6.7000505@freebsd.org> Date: Thu, 12 Jul 2007 14:44:06 +0900 From: Daichi GOTO User-Agent: Thunderbird 2.0.0.4 (X11/20070615) MIME-Version: 1.0 To: Harald Schmalzbauer References: <468345F2.1060209@freebsd.org> <46838649.3060405@freebsd.org> <46839A99.3030805@freebsd.org> <200707111903.53790.h.schmalzbauer@omnisec.de> In-Reply-To: <200707111903.53790.h.schmalzbauer@omnisec.de> Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: speconly@post.ru, freebsd-current@freebsd.org, Current@freebsd.org Subject: Re: Nvidia-driver and current lead system reboot with no error message X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2007 05:44:10 -0000 Harald Schmalzbauer wrote: > Am Donnerstag, 28. Juni 2007 schrieb Daichi GOTO: >> Daichi GOTO wrote: >>> speconly@post.ru wrote: >>>> On Thu, Jun 28, 2007 at 02:24:02PM +0900, Daichi GOTO wrote: >>>>> current (Jun 27 2007) and nvidia-driver (GeForce 7300 GT) lead >>>>> system reboot 3d feature used without some error messages, >>>>> for example, beryl leads reboot, glxinfo too, and something >>>>> like that. 2D features work looks fine. >>>>> >>>>> Have someone any idea? Thanks. >>>> Updating driver to something 100.14.xx didn't solve this? >>> yeah, alright. 100.14.xx is new nvidia-drvier number. >>> >>> http://www.nvidia.com/object/unix.html >>> >>> have you installed manually? or make a new port to install? ;) >> I have tried 100.14.11 and it works great fine :) Thanks! > > It doesn't compile for me. > The #error in nv-freebsd.h was not that problem, but some pci code breaks. > Have you had the same error and some workarround? Could you please tell me > your patch? Have you installed nvidia related libraries and applications? Install x11/nvidia-driver and deinstall it. And try to install 100.14.11 manuarly. > Thanks, > > -Harry -- Daichi GOTO, http://people.freebsd.org/~daichi From owner-freebsd-current@FreeBSD.ORG Thu Jul 12 06:09:59 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9C7FD16A421 for ; Thu, 12 Jul 2007 06:09:59 +0000 (UTC) (envelope-from daichi@freebsd.org) Received: from natial.ongs.co.jp (natial.ongs.co.jp [202.216.232.58]) by mx1.freebsd.org (Postfix) with ESMTP id 6329813C448 for ; Thu, 12 Jul 2007 06:09:59 +0000 (UTC) (envelope-from daichi@freebsd.org) Received: from parancell.ongs.co.jp (dullmdaler.ongs.co.jp [202.216.232.62]) by natial.ongs.co.jp (Postfix) with ESMTP id 5731E244C19; Thu, 12 Jul 2007 14:44:06 +0900 (JST) Message-ID: <4695BFA6.7000505@freebsd.org> Date: Thu, 12 Jul 2007 14:44:06 +0900 From: Daichi GOTO User-Agent: Thunderbird 2.0.0.4 (X11/20070615) MIME-Version: 1.0 To: Harald Schmalzbauer References: <468345F2.1060209@freebsd.org> <46838649.3060405@freebsd.org> <46839A99.3030805@freebsd.org> <200707111903.53790.h.schmalzbauer@omnisec.de> In-Reply-To: <200707111903.53790.h.schmalzbauer@omnisec.de> Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: speconly@post.ru, freebsd-current@freebsd.org, Current@freebsd.org Subject: Re: Nvidia-driver and current lead system reboot with no error message X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2007 06:09:59 -0000 Harald Schmalzbauer wrote: > Am Donnerstag, 28. Juni 2007 schrieb Daichi GOTO: >> Daichi GOTO wrote: >>> speconly@post.ru wrote: >>>> On Thu, Jun 28, 2007 at 02:24:02PM +0900, Daichi GOTO wrote: >>>>> current (Jun 27 2007) and nvidia-driver (GeForce 7300 GT) lead >>>>> system reboot 3d feature used without some error messages, >>>>> for example, beryl leads reboot, glxinfo too, and something >>>>> like that. 2D features work looks fine. >>>>> >>>>> Have someone any idea? Thanks. >>>> Updating driver to something 100.14.xx didn't solve this? >>> yeah, alright. 100.14.xx is new nvidia-drvier number. >>> >>> http://www.nvidia.com/object/unix.html >>> >>> have you installed manually? or make a new port to install? ;) >> I have tried 100.14.11 and it works great fine :) Thanks! > > It doesn't compile for me. > The #error in nv-freebsd.h was not that problem, but some pci code breaks. > Have you had the same error and some workarround? Could you please tell me > your patch? Have you installed nvidia related libraries and applications? Install x11/nvidia-driver and deinstall it. And try to install 100.14.11 manuarly. > Thanks, > > -Harry -- Daichi GOTO, http://people.freebsd.org/~daichi From owner-freebsd-current@FreeBSD.ORG Thu Jul 12 06:11:21 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A701D16A469 for ; Thu, 12 Jul 2007 06:11:21 +0000 (UTC) (envelope-from casper@web.am) Received: from mx1.web.am (mx1.web.am [217.113.0.68]) by mx1.freebsd.org (Postfix) with ESMTP id 18A8F13C46E for ; Thu, 12 Jul 2007 06:11:20 +0000 (UTC) (envelope-from casper@web.am) Received: from antispam (localhost.web.am [127.0.0.1]) by localhost (Postfix) with ESMTP id 6788161C0C for ; Thu, 12 Jul 2007 11:10:36 +0500 (AMST) Received: from localhost (localhost.web.am [127.0.0.1]) by localhost (Postfix) with SMTP id 8531061C22; Thu, 12 Jul 2007 11:10:35 +0500 (AMST) Received: from aldan.web.am (unknown [217.113.1.123]) by mx1.web.am (Postfix) with ESMTP id C031D61C0C; Thu, 12 Jul 2007 11:10:31 +0500 (AMST) Message-ID: <4695C5FD.6010802@web.am> Date: Thu, 12 Jul 2007 11:11:09 +0500 From: Gaspar Chilingarov User-Agent: Thunderbird 2.0.0.4 (X11/20070619) MIME-Version: 1.0 To: Doug Barton References: <20070419133550.GA65054@tirith.brixandersen.dk> <20070419200929.GA70735@tirith.brixandersen.dk> <4693BC3E.1050605@web.am> <200707110115.42139.pieter@degoeje.nl> <469417CB.7010705@FreeBSD.org> <4694AAF1.6050302@web.am> <46951CC2.5050602@FreeBSD.org> <46955C9E.6090101@u.washington.edu> <46957093.2030701@FreeBSD.org> In-Reply-To: <46957093.2030701@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on mx1.web.am X-Spam-Status: No, hits=0.0 required=7.5 tests=none autolearn=no version=2.60 X-Spam-Level: Cc: Pieter de Goeje , Garrett Cooper , freebsd-current@freebsd.org Subject: Re: RFT: bin/106642: [patch] Allow excluding certain files from mergemaster (8) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2007 06:11:21 -0000 Just fine, I can see solution to all the questions I've asked. May be it's better to include such scripts in mergemaster's man page in examples section? This will make many people happy and will allow author of MM just say RTFM when someone like me asks a question :) With best regards, Gaspar -- Gaspar Chilingarov System Administrator, Network security consulting t +37493 419763 (mob) i 63174784 e nm@web.am w http://zanazan.am/ From owner-freebsd-current@FreeBSD.ORG Thu Jul 12 06:48:29 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E50E316A400 for ; Thu, 12 Jul 2007 06:48:29 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.freebsd.org (Postfix) with ESMTP id 8801813C457 for ; Thu, 12 Jul 2007 06:48:29 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id A137E45B26; Thu, 12 Jul 2007 08:48:26 +0200 (CEST) Received: from localhost (154.81.datacomsa.pl [195.34.81.154]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 5D2EA45696; Thu, 12 Jul 2007 08:48:21 +0200 (CEST) Date: Thu, 12 Jul 2007 08:48:08 +0200 From: Pawel Jakub Dawidek To: Simon Dircks Message-ID: <20070712064807.GC1227@garage.freebsd.pl> References: <200707071426.18202.dfr@rabson.org> <20070709000918.GD1208@garage.freebsd.pl> <46922D75.4010006@gddsn.org.cn> <15d429c0707111724w76d47529v4c5fad6ac7892875@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="kfjH4zxOES6UT95V" Content-Disposition: inline In-Reply-To: <15d429c0707111724w76d47529v4c5fad6ac7892875@mail.gmail.com> X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 User-Agent: mutt-ng/devel-r804 (FreeBSD) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-2.6 required=3.0 tests=BAYES_00 autolearn=ham version=3.0.4 Cc: current@freebsd.org Subject: Re: ZFS leaking vnodes (sort of) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2007 06:48:30 -0000 --kfjH4zxOES6UT95V Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jul 11, 2007 at 08:24:41PM -0400, Simon Dircks wrote: > With this patch i am still able to reproduce my ZFS crash. >=20 > controllera# uname -a > FreeBSD controllera.storage.ksdhost.com 7.0-CURRENT FreeBSD 7.0-CURRENT #= 0: > Thu Jul 12 02:28:52 UTC 2007 > graff@controllera.storage.ksdhost.com:/usr/obj/usr/src/sys/CONTROLLERA > amd64 >=20 >=20 > panic: ZFS: bad checksum (read on off 0: zio 0xffffff001d729810 > [LO SP > A space map] 1000L/800P DVA[0]=3D<0:1600421800:800> DVA[1]=3D<0:2c000f700= 0:800> > DVA[ > 2]=3D<0:4200013800:800> fletcher4 lzjb LE contiguous birth=3D566 fill=3D1 > chsum=3D5d3276 > 7b98:635ff7022f8b:4251 > cpuid =3D 0 > KDB: enter: panic > [thread pid 802 tid 100066 ] > stopped at kdb_enter+0x31: leave This isn't related to the patch, actually. It looks like you don't have enough redundancy. Can you paste 'zpool status' output? --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --kfjH4zxOES6UT95V Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFGlc6nForvXbEpPzQRAlmoAJ0QimRBYXOnh1cr2QCy4dNF6jnKrQCfQLpQ 4VtoftK9BvZVxVJoHmU/S7Q= =xyxJ -----END PGP SIGNATURE----- --kfjH4zxOES6UT95V-- From owner-freebsd-current@FreeBSD.ORG Thu Jul 12 07:14:30 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EFC8616A421 for ; Thu, 12 Jul 2007 07:14:30 +0000 (UTC) (envelope-from avatar@mmlab.cse.yzu.edu.tw) Received: from www.mmlab.cse.yzu.edu.tw (www.mmlab.cse.yzu.edu.tw [140.138.150.166]) by mx1.freebsd.org (Postfix) with ESMTP id BFFD913C455 for ; Thu, 12 Jul 2007 07:14:30 +0000 (UTC) (envelope-from avatar@mmlab.cse.yzu.edu.tw) Received: by www.mmlab.cse.yzu.edu.tw (qmail, from userid 1000) id F283B8CA067; Thu, 12 Jul 2007 15:14:29 +0800 (CST) Received: from localhost (localhost [127.0.0.1]) by www.mmlab.cse.yzu.edu.tw (qmail) with ESMTP id DC3868CA05E; Thu, 12 Jul 2007 15:14:29 +0800 (CST) Date: Thu, 12 Jul 2007 15:14:29 +0800 (CST) From: Tai-hwa Liang To: David Wolfskill In-Reply-To: <20070711172448.GA42994@bunrab.catwhisker.org> Message-ID: <07071215124918.11674@www.mmlab.cse.yzu.edu.tw> References: <20070711172448.GA42994@bunrab.catwhisker.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: current@freebsd.org Subject: Re: Oddity with an(4): Channel reported by ifconfig is wrong X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2007 07:14:31 -0000 On Wed, 11 Jul 2007, David Wolfskill wrote: [...] > an0: flags=8843 metric 0 mtu 1500 > ether 00:40:96:32:19:a9 > inet 172.17.1.1 netmask 0xffff0000 broadcast 172.17.255.255 > media: IEEE 802.11 Wireless Ethernet autoselect (DS/11Mbps) > status: associated > ssid 1:lmdhw-net channel 5 (56992 Mhz Turbo) > stationname FreeBSD > authmode OPEN privacy ON deftxkey 1 txpowmax 0 rtsthreshold 0 > fragthreshold 0 bmiss 0 mcastrate 0 roaming DEVICE > g1-1(7.0-C)[4] > > As you see, the an0 NIC (a PCMCIA part) is the only one in use (as > the miniPCI wi0 still doesn't associate). > > I don't expect that this is a critical issue, but it could be confusing. Thanks for reporting, I happened to have an Aironet miniPCI. Will look into this later. -- Thanks, Tai-hwa Liang From owner-freebsd-current@FreeBSD.ORG Thu Jul 12 08:42:53 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7D30816A46C; Thu, 12 Jul 2007 08:42:53 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from relay02.kiev.sovam.com (relay02.kiev.sovam.com [62.64.120.197]) by mx1.freebsd.org (Postfix) with ESMTP id 0B62013C448; Thu, 12 Jul 2007 08:42:52 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from [89.162.146.170] (helo=skuns.kiev.zoral.com.ua) by relay02.kiev.sovam.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1I8uG8-0004Ac-3F; Thu, 12 Jul 2007 11:42:51 +0300 Received: from deviant.kiev.zoral.com.ua (root@[10.1.1.148]) by skuns.kiev.zoral.com.ua (8.14.1/8.14.1) with ESMTP id l6C8geIc088958 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Jul 2007 11:42:40 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.1/8.14.1) with ESMTP id l6C8geW5056191; Thu, 12 Jul 2007 11:42:40 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.1/8.14.1/Submit) id l6C8geCY056190; Thu, 12 Jul 2007 11:42:40 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 12 Jul 2007 11:42:40 +0300 From: Kostik Belousov To: Alfred Perlstein Message-ID: <20070712084240.GB2200@deviant.kiev.zoral.com.ua> References: <20070711202640.GV45894@elvis.mu.org> <20070711223720.C97304@fledge.watson.org> <20070711220508.GY45894@elvis.mu.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="XPTkPaWipqgB+utH" Content-Disposition: inline In-Reply-To: <20070711220508.GY45894@elvis.mu.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.90.3, clamav-milter version 0.90.3 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=0.6 required=5.0 tests=ALL_TRUSTED, DNS_FROM_AHBL_RHSBL autolearn=no version=3.2.1 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on skuns.kiev.zoral.com.ua X-Scanner-Signature: e04e44772e0ad72f7751591e8aa1bd99 X-DrWeb-checked: yes X-SpamTest-Envelope-From: kostikbel@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Header: Not Detected X-SpamTest-Info: Profiles 1209 [July 11 2007] X-SpamTest-Info: helo_type=3 X-SpamTest-Method: none X-SpamTest-Rate: 0 X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0255], KAS30/Release Cc: Robert Watson , current@freebsd.org, fs@freebsd.org Subject: Re: bgfsck hosed (lockups) in -current? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2007 08:42:53 -0000 --XPTkPaWipqgB+utH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jul 11, 2007 at 03:05:08PM -0700, Alfred Perlstein wrote: > * Robert Watson [070711 14:37] wrote: > >=20 > > On Wed, 11 Jul 2007, Alfred Perlstein wrote: > >=20 > > >I have current as of last week. > > > > > >I noticed that if I needed a bgfsck on ufs when rebooting my system wo= uld=20 > > >lock up almost immediately. Everything would deadlock. > > > > > >If I rebooted single user and did a regular "fsck -y" then continued t= o=20 > > >boot, I'd be OK. > > > > > >Has anyone else experienced this? I'm going to update to the most rec= ent=20 > > >current and get more information (which wait channels etc) but wanted = to=20 > > >know if anyone knew about this. > > > > > >I recall seeing a LOT of fixes for various deadlocks in snapshots and= =20 > > >bgfsck going in lately, but nothing that looked to me as if it'd trigg= er a=20 > > >regression. > >=20 > > I'm not seeing this either -- have you tried running a manual fsck to s= ee=20 > > if it turns up anything deeply unsatisfying that could be causing bgfsc= k=20 > > some bother? >=20 > Of course, nothing comes up that's interesting. >=20 > I'll try to reproduce this and give better feedback in the next few > days. Please. Deadlock debugging chapter from dev handbook contains enumeration of the needed things. --XPTkPaWipqgB+utH Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGlel/C3+MBN1Mb4gRAt1vAKDBMQRWJB1T/YomwXl7VXo1Wj25mQCeLRB8 WksXrTP5X2bqmVVhv6k93uU= =kGEQ -----END PGP SIGNATURE----- --XPTkPaWipqgB+utH-- From owner-freebsd-current@FreeBSD.ORG Thu Jul 12 08:51:37 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D73B216A421; Thu, 12 Jul 2007 08:51:37 +0000 (UTC) (envelope-from dwmalone@maths.tcd.ie) Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by mx1.freebsd.org (Postfix) with SMTP id 11F9713C44B; Thu, 12 Jul 2007 08:51:36 +0000 (UTC) (envelope-from dwmalone@maths.tcd.ie) Received: from walton.maths.tcd.ie ([134.226.81.10] helo=walton.maths.tcd.ie) by salmon.maths.tcd.ie with SMTP id ; 12 Jul 2007 09:51:36 +0100 (BST) Date: Thu, 12 Jul 2007 09:51:35 +0100 From: David Malone To: Ivan Voras Message-ID: <20070712085135.GA5332@walton.maths.tcd.ie> References: <20070709214216.GA72912@walton.maths.tcd.ie> <20070711132202.GA95487@walton.maths.tcd.ie> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i Sender: dwmalone@maths.tcd.ie Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: Debugging times X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2007 08:51:37 -0000 On Thu, Jul 12, 2007 at 12:14:43AM +0200, Ivan Voras wrote: > I've got interesting results (in the bad sense of the phrase): I do get > the message "Invalid time in real time clock. Check and reset the time > immediately" (the i386 message) BUT my time gets reset to 0 (midnight > 1970.) Ah - that's interesting. Could you look for the comment in src/sys/i386/isa/clock.c that says: /* Should we set dow = -1 because some clocks don't set it correctly? */ and add a line afterwards to say: ct.dow = -1; and see if that helps? > I see your patch and it shouldn't do that. Could it be a compiler bug, > so the effects change after trivial code has been changed? I think that without the patch, the clock is initialised using a chunk of uninitialised memory on the stack, which could result in all sorts of random values being used. With the patch, things may be a little more deterministic. David. From owner-freebsd-current@FreeBSD.ORG Thu Jul 12 09:25:06 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EAEB716A400 for ; Thu, 12 Jul 2007 09:25:06 +0000 (UTC) (envelope-from Rainer.Hurling@nw-fva.de) Received: from wald.nfv.gwdg.de (Wald.NFV.gwdg.de [134.76.242.31]) by mx1.freebsd.org (Postfix) with ESMTP id 7DC3013C46A for ; Thu, 12 Jul 2007 09:25:06 +0000 (UTC) (envelope-from Rainer.Hurling@nw-fva.de) Received: from pc11b.nfv (Pc11B.nfv [192.168.2.111]) by wald.nfv.gwdg.de (Postfix) with ESMTP id 16ECC60903F; Thu, 12 Jul 2007 10:54:54 +0200 (CEST) Message-ID: <4695EC5D.4020504@nw-fva.de> Date: Thu, 12 Jul 2007 10:54:53 +0200 From: Rainer Hurling Organization: Nordwestdeutsche Forstliche Versuchsanstalt User-Agent: Thunderbird 2.0.0.4 (X11/20070615) MIME-Version: 1.0 To: Harald Schmalzbauer References: <468345F2.1060209@freebsd.org> <200707111903.53790.h.schmalzbauer@omnisec.de> <469536BA.5090306@gwdg.de> <200707112331.19068.h.schmalzbauer@omnisec.de> In-Reply-To: <200707112331.19068.h.schmalzbauer@omnisec.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Nvidia-driver and current lead system reboot with no error message X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "rhurlin@gwdg.de >> \"Hurling, Rainer\"" List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2007 09:25:07 -0000 Hello Harry, Harald Schmalzbauer schrieb: > Am Mittwoch, 11. Juli 2007 schrieb Rainer Hurling: >> Hallo Harry, >> >> for version 100.14.11 (after unpacking the tarball) I had to make four >> changes before I had been able to install: >> >> 1. set environment variable 'X11BASE' to '/usr/local' >> >> 2. Delete lines 24-26 in 'src/nv-freebsd.h' (test for FreeBSD version >> >> >=70000) >> >> 3. Change '${X11BASE}/lib/modules[...]' to >> '${X11BASE}/lib/xorg/modules[...]' in Makefiles under >> x11/[driver,extension,lib] >> >> 4. Change '/usr/X11R6/lib/modules[...]' to >> '/usr/local/lib/xorg/modules[...]' in 'doc/html/appendix-b.html' >> >> >> Don't forget to delete any installed x11/nvidia-driver* port before >> installing this new driver version. >> >> Hope this helps, >> Rainer > > Hello Rainer, > > thanks for your hints. > Unfortunately it's not just a matter of paths. > > Here's the compiler showstopper: > cc -O1 -pipe -march=prescott -march=prescott -DNV_VERSION_STRING=\"100.14.11\" - > D__KERNEL__ -DNVRM -UDEBUG -U_DEBUG -DNDEBUG -O -fno-common -msoft-float > -fno-unit-at-a-time -minline-all-stringops -D_KERNEL -DKLD_MODULE -std=c99 -nostdinc > -I/src -I. -I@ -I@/contrib/altq -finline-limit=8000 --paraminline-unit-growth=100 > --paramlarge-function-growth=1000 -fno-common -mno-align-long-strings -mpre > ferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffree > standing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing > -prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -ffo > rmat-extensions -c nvidia_pci.c > nvidia_pci.c: In function 'nvidia_pci_setup_intr': > nvidia_pci.c:56: warning: passing argument 7 of 'bus_setup_intr' from > incompatible pointer type > nvidia_pci.c:56: error: too many arguments to function 'bus_setup_intr' > *** Error code 1 This error in src/nvidia_pci.c originates by testing the version of 7.0-CURRENT: -------------- #if __FreeBSD_version >= 700031 status = bus_setup_intr(dev, sc->irq, flags, NULL, nvidia_intr, sc, &sc->irq_ih); #else status = bus_setup_intr(dev, sc->irq, flags, nvidia_intr, sc, &sc->irq_ih); #endif -------------- Do you use newest CURRENT? With my FreeBSD version from yesterday the nvidia driver 100.14.11 compiles fine, there are no problems with version testing. #sysctl -a | grep osreldate kern.osreldate: 700052 Rainer > > Stop in /usr/ports/x11/nvidia-driver/work/NVIDIA-FreeBSD-x86-100.14.11/src. > *** Error code 1 > > Stop in /usr/ports/x11/nvidia-driver/work/NVIDIA-FreeBSD-x86-100.14.11. > *** Error code 1 > > Thansk in advance for any hint. > > -Harry From owner-freebsd-current@FreeBSD.ORG Thu Jul 12 10:36:40 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A3C5916A400; Thu, 12 Jul 2007 10:36:40 +0000 (UTC) (envelope-from oyvind@kolbu.ws) Received: from smtp.bluecom.no (smtp.bluecom.no [193.75.75.28]) by mx1.freebsd.org (Postfix) with ESMTP id 3580B13C455; Thu, 12 Jul 2007 10:36:40 +0000 (UTC) (envelope-from oyvind@kolbu.ws) Received: from putsch.kolbu.ws (putsch.kolbu.ws [195.0.155.50]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.bluecom.no (Postfix) with ESMTP id AD2D412C097; Thu, 12 Jul 2007 12:05:21 +0200 (CEST) Received: from oyvind by putsch.kolbu.ws with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I8vY1-000OD4-AY; Thu, 12 Jul 2007 12:05:21 +0200 Date: Thu, 12 Jul 2007 12:05:21 +0200 From: =?iso-8859-1?Q?=D8yvind?= Kolbu To: Andrew Thompson Message-ID: <20070712100521.GB83674@putsch.kolbu.ws> References: <20070711172448.GA42994@bunrab.catwhisker.org> <20070712011226.GB1285@heff.fud.org.nz> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3uo+9/B/ebqu+fSQ" Content-Disposition: inline In-Reply-To: <20070712011226.GB1285@heff.fud.org.nz> X-Operating-System: FreeBSD/6.2-RELEASE-p4 (i386) X-PGP-Key: http://folk.uio.no/kolbu/kolbu.asc Organization: Universitas Osloensis User-Agent: mutt-ng/devel-r804 (FreeBSD) Cc: current@freebsd.org Subject: Re: Oddity with an(4): Channel reported by ifconfig is wrong X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2007 10:36:40 -0000 --3uo+9/B/ebqu+fSQ Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2007-07-12 at 13:12, Andrew Thompson wrote: > So wi is still not working at all? Can you post the log again with > debug.wi set to 2. I can't get my wi to work either. Didn't find debug.wi, but used: kolbu# sysctl hw.wi.debug=3D2 hw.wi.debug: 0 -> 2 > Does 'ifconfig wi0 scan' show anything? kolbu# ifconfig wi0 scan SSID BSSID CHAN RATE S:N INT CAPS uio 00:1c:0e:42:59:90 9 1M 6:3 100 EPS=20 uio 00:1c:0e:42:5c:70 2 1M 3:2 100 EPS=20 If I bring the interface up and then scan again, ifconfig never return the result, even though the log says "scan complete". Jul 12 11:53:43 kolbu kernel: wi_info_intr: LINK_STAT 0x6 Jul 12 11:53:43 kolbu kernel: wi_newstate: INIT -> INIT Jul 12 11:53:45 kolbu kernel: wi_info_intr: LINK_STAT 0x6 Jul 12 11:53:45 kolbu kernel: wi_newstate: INIT -> INIT Jul 12 11:53:46 kolbu kernel: wi_info_intr: LINK_STAT 0x6 Jul 12 11:53:46 kolbu kernel: wi_newstate: INIT -> INIT Jul 12 11:53:48 kolbu kernel: wi_scan_ap: start scanning, chamask 0x3fff tx= rate 0xf Jul 12 11:53:48 kolbu kernel: wi_info_intr: LINK_STAT 0x6 Jul 12 11:53:48 kolbu kernel: wi_newstate: INIT -> INIT Jul 12 11:53:50 kolbu kernel: wi_info_intr: LINK_STAT 0x6 Jul 12 11:53:50 kolbu kernel: wi_newstate: INIT -> INIT Jul 12 11:53:51 kolbu kernel: wi_watchdog: inquire scan Jul 12 11:53:51 kolbu kernel: wi_scan_result: #0: off 8 bssid 00:1c:0e:42:5= 9:90 Jul 12 11:53:51 kolbu kernel: calling add_scan, bssid 00:1c:0e:42:59:90 cha= n 9 signal 10 Jul 12 11:53:51 kolbu kernel: wi_scan_result: #1: off 70 bssid 00:1c:0e:42:= 5c:70 Jul 12 11:53:51 kolbu kernel: calling add_scan, bssid 00:1c:0e:42:5c:70 cha= n 2 signal 2 Jul 12 11:53:51 kolbu kernel: wi_scan_result: scan complete: ap 2 Jul 12 11:53:51 kolbu kernel: wi_info_intr: LINK_STAT 0x6 Jul 12 11:53:51 kolbu kernel: wi_newstate: INIT -> INIT Jul 12 11:53:53 kolbu kernel: wi_info_intr: LINK_STAT 0x6 kolbu# uname -a FreeBSD kolbu.uio.no 7.0-CURRENT FreeBSD 7.0-CURRENT #1: Thu Jul 12 10:56:20 CEST 2007 kolbu@kolbu.uio.no:/usr/obj/usr/src/sys/LAP i386 kolbu# dmesg |grep wi0 wi0: mem 0xf8000000-0xf8000fff irq 11 at device 2.0 on pci2 wi0: [ITHREAD] wi0: using RF:PRISM2.5 MAC:ISL3874A(Mini-PCI) wi0: Intersil Firmware: Primary (1.1.0), Station (1.4.9) wi0: Ethernet address: 00:05:3c:04:89:1c --=20 =D8yvind Kolbu --3uo+9/B/ebqu+fSQ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGlfzh1tozuWhBuIIRAvZYAJ9EXvY65HjR9Fydg60x/JRR+BwRHACg1l4N rzBFZ5M8B9aCHVlzlmuvZOU= =wYZT -----END PGP SIGNATURE----- --3uo+9/B/ebqu+fSQ-- From owner-freebsd-current@FreeBSD.ORG Thu Jul 12 11:18:50 2007 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B494916A46C for ; Thu, 12 Jul 2007 11:18:50 +0000 (UTC) (envelope-from bsd@kuehlbox.de) Received: from samael.qmail-ldap.de (mail.kuehlbox.de [62.159.47.22]) by mx1.freebsd.org (Postfix) with ESMTP id DE4AE13C4BF for ; Thu, 12 Jul 2007 11:18:49 +0000 (UTC) (envelope-from bsd@kuehlbox.de) Received: (qmail 26823 invoked from network); 12 Jul 2007 10:52:06 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlbox.de; b=qtHYFYNnfnjxbGVqIv2x7YwHoU5pEkObnqzV9X1ARink9dcYmSKy6ZA+ozUL+kD3ioUVMF2ffP/trwS/MlGqPIHiGno257hzAYKLjTLgtI2zW+ja7Zebre4ZSfWBWUG2 ; Received: from unknown (HELO [192.168.200.128]) (bsd@kuehlbox.de@[217.5.182.116]) (envelope-sender ) by samael.qmail-ldap.de (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 12 Jul 2007 10:52:06 -0000 Message-ID: <469608E2.3040804@kuehlbox.de> Date: Thu, 12 Jul 2007 12:56:34 +0200 From: Teufel User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Simon Barner , current@FreeBSD.org References: <20070710120901.GA65987@atknoll88.informatik.tu-muenchen.de> In-Reply-To: <20070710120901.GA65987@atknoll88.informatik.tu-muenchen.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: Valgrind GCC 4.2 patches X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2007 11:18:50 -0000 Hi, tried both patches on today's 7-CURRENT. Both compile, but using valgrind ends in a crash with unhandled syscalls. I think there is a bit more left to fix. But I still hope to see soon a working valgrind on 7-CURRENT. Greetings, Stephan a simple valgrind /bin/ls puts out: ==66330== Memcheck, a memory error detector for x86-linux. ==66330== Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward. ==66330== Using valgrind-2.1.0, a program supervision framework for x86-linux. ==66330== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward. ==66330== Estimated CPU clock rate is 2440 MHz ==66330== For more details, rerun with: -v ==66330== --66330-- WARNING: unhandled syscall: 477 --66330-- Do not panic. You may be able to fix this easily. --66330-- Read the file README_MISSING_SYSCALL_OR_IOCTL. ==66330== Warning: client syscall munmap tried to modify addresses 0xFFFFFFDA-0xE2 --66330-- WARNING: unhandled syscall: 477 --66330-- Do not panic. You may be able to fix this easily. --66330-- Read the file README_MISSING_SYSCALL_OR_IOCTL. ==66330== Invalid write of size 4 ==66330== at 0x3C007B93: (within /libexec/ld-elf.so.1) ==66330== by 0x3C0179B5: (within /libexec/ld-elf.so.1) ==66330== by 0x3C007D9C: (within /libexec/ld-elf.so.1) ==66330== by 0x3C005F7B: (within /libexec/ld-elf.so.1) ==66330== Address 0xFFFFFFFC is not stack'd, malloc'd or free'd ==66330== ==66330== Process terminating with default action of signal 10 (SIGBUS): dumping core ==66330== at 0x3C007B93: (within /libexec/ld-elf.so.1) ==66330== by 0x3C0179B5: (within /libexec/ld-elf.so.1) ==66330== by 0x3C007D9C: (within /libexec/ld-elf.so.1) ==66330== by 0x3C005F7B: (within /libexec/ld-elf.so.1) ==66330== Core dumping not implemented. Please re-run valgrind after fixing the crash. ==66330== ==66330== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0) ==66330== malloc/free: in use at exit: 0 bytes in 0 blocks. ==66330== malloc/free: 0 allocs, 0 frees, 0 bytes allocated. ==66330== For a detailed leak analysis, rerun with: --leak-check=yes ==66330== For counts of detected errors, rerun with: -v Simon Barner wrote: > Hello, > > I finally fixed the valgrind build with gcc 4.2. Could you > please verify that > > http://home.leo.org/~barner/freebsd/valgrind-snapshot.patch > http://home.leo.org/~barner/freebsd/valgrind.patch > > Thanks for you feedback, > Simon > > (f'up2 freebsd-ports ) > From owner-freebsd-current@FreeBSD.ORG Thu Jul 12 11:52:10 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E263116A400 for ; Thu, 12 Jul 2007 11:52:10 +0000 (UTC) (envelope-from enderbsd@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.226]) by mx1.freebsd.org (Postfix) with ESMTP id 9F92F13C447 for ; Thu, 12 Jul 2007 11:52:10 +0000 (UTC) (envelope-from enderbsd@gmail.com) Received: by wx-out-0506.google.com with SMTP id i29so101175wxd for ; Thu, 12 Jul 2007 04:52:10 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=aGmlby2x/PseoJbpcteJN2XCZRH4gGfZw2nqh2ucROV6GY7Gbo3mJhzJNxeXTu6VjwnYAyBgXjHjL+PlV+A5TGZhtDGT1T1FVRxfnfC0jl3s+tv7eHaEVSzEStj9H7UgRk+zZS/roOOaDkk/51gFcj2/k2TjnYWC8hAiyCiuDXo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=evRngPihelNoei3Ltf/MbaiweQhuLF6/T18SaBAl2jKme1W2Hgky1oTpvmbp1JG6I0+rkSUq0E5Y6JilzxTy1OB6f2SyANvjuMouMwrB78/tvRS/GFBbVPMSlTxs1FAluFul66hyI5FeC/K5P43SEyq9I0S/jVd5OQSJvrvOpic= Received: by 10.90.79.6 with SMTP id c6mr235024agb.1184241129161; Thu, 12 Jul 2007 04:52:09 -0700 (PDT) Received: by 10.90.56.12 with HTTP; Thu, 12 Jul 2007 04:52:08 -0700 (PDT) Message-ID: <15d429c0707120452g5308aedcx301d32c387396a65@mail.gmail.com> Date: Thu, 12 Jul 2007 07:52:08 -0400 From: "Simon Dircks" To: "Pawel Jakub Dawidek" In-Reply-To: <20070712064807.GC1227@garage.freebsd.pl> MIME-Version: 1.0 References: <200707071426.18202.dfr@rabson.org> <20070709000918.GD1208@garage.freebsd.pl> <46922D75.4010006@gddsn.org.cn> <15d429c0707111724w76d47529v4c5fad6ac7892875@mail.gmail.com> <20070712064807.GC1227@garage.freebsd.pl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: current@freebsd.org Subject: Re: ZFS leaking vnodes (sort of) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2007 11:52:11 -0000 On 7/12/07, Pawel Jakub Dawidek wrote: > > On Wed, Jul 11, 2007 at 08:24:41PM -0400, Simon Dircks wrote: > > With this patch i am still able to reproduce my ZFS crash. > > > > controllera# uname -a > > FreeBSD controllera.storage.ksdhost.com 7.0-CURRENT FreeBSD 7.0-CURRENT#0: > > Thu Jul 12 02:28:52 UTC 2007 > > graff@controllera.storage.ksdhost.com:/usr/obj/usr/src/sys/CONTROLLERA > > amd64 > > > > > > panic: ZFS: bad checksum (read on off 0: zio > 0xffffff001d729810 > > [LO SP > > A space map] 1000L/800P DVA[0]=<0:1600421800:800> > DVA[1]=<0:2c000f7000:800> > > DVA[ > > 2]=<0:4200013800:800> fletcher4 lzjb LE contiguous birth=566 fill=1 > > chsum=5d3276 > > 7b98:635ff7022f8b:4251 > > cpuid = 0 > > KDB: enter: panic > > [thread pid 802 tid 100066 ] > > stopped at kdb_enter+0x31: leave > > This isn't related to the patch, actually. It looks like you don't have > enough redundancy. Can you paste 'zpool status' output? > > Sure controllera# zpool status pool: tank state: UNAVAIL status: One or more devices could not be opened. There are insufficient replicas for the pool to continue functioning. action: Attach the missing device and online it using 'zpool online'. see: http://www.sun.com/msg/ZFS-8000-D3 scrub: none requested config: NAME STATE READ WRITE CKSUM tank UNAVAIL 0 0 0 insufficient replicas mirror UNAVAIL 0 0 0 insufficient replicas ggate111 UNAVAIL 0 0 0 cannot open ggate211 UNAVAIL 0 0 0 cannot open Now here is another interesting thing: I can cause a crash now by just reattaching the disks. I can repeat this without fail in just a few mins. So for every test i have been typing zpool destroy tank, and making a fresh pool. Kip Macy wrote: That looks more like bad disk than a file system bug. That could be, my "disks" are actually ggatec devices on other machines. And for some reason when they are under ZFS i get alot of packet loss (and ping spike) over the gigabit interface even when it is not maxed out. But should this still cause a panic? my / and /usr are a normal local disk on UFS. Using the same ggate111 and ggate112 devices with gmirror + mount -o async and copying file.XXX over to the gmirror I get no packet loss, no ping spikes, and the checksum matches after i move the file over. All the machines in question are the same version of freebsd, and all have full debugging on and are not in production or running anything else. From owner-freebsd-current@FreeBSD.ORG Thu Jul 12 13:26:12 2007 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6232F16A46C for ; Thu, 12 Jul 2007 13:26:12 +0000 (UTC) (envelope-from barner@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id AD30413C458 for ; Thu, 12 Jul 2007 13:26:11 +0000 (UTC) (envelope-from barner@gmx.de) Received: (qmail invoked by alias); 12 Jul 2007 12:59:30 -0000 Received: from ppp-88-217-18-195.dynamic.mnet-online.de (EHLO dose.local.invalid) [88.217.18.195] by mail.gmx.net (mp044) with SMTP; 12 Jul 2007 14:59:30 +0200 X-Authenticated: #147403 X-Provags-ID: V01U2FsdGVkX1/FCmNxuYbFOvFSThA1TAXOfXJye/DsW+bYCZxYZ0 WV7kNshAwrRjUW Received: by dose.local.invalid (Postfix, from userid 1000) id BE856C20C; Thu, 12 Jul 2007 15:02:13 +0200 (CEST) Date: Thu, 12 Jul 2007 15:02:13 +0200 From: Simon Barner To: Teufel Message-ID: <20070712130213.GA3028@dose.local.invalid> References: <20070710120901.GA65987@atknoll88.informatik.tu-muenchen.de> <469608E2.3040804@kuehlbox.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="SUOF0GtieIMvvwua" Content-Disposition: inline In-Reply-To: <469608E2.3040804@kuehlbox.de> User-Agent: Mutt/1.5.12-2006-07-14 X-Y-GMX-Trusted: 0 Cc: ports@FreeBSD.org, current@FreeBSD.org Subject: Re: Valgrind GCC 4.2 patches X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2007 13:26:12 -0000 --SUOF0GtieIMvvwua Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Teufel wrote: > Hi, >=20 > tried both patches on today's 7-CURRENT. Both compile, but using=20 > valgrind ends in a crash with unhandled syscalls. Ok, thanks for the report. > >http://home.leo.org/~barner/freebsd/valgrind-snapshot.patch > >http://home.leo.org/~barner/freebsd/valgrind.patch I've updated the patches. Could you please try again? --=20 Best regards / Viele Gr=FC=DFe, barner@FreeBSD.= org Simon Barner barner@gmx.de --SUOF0GtieIMvvwua Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD4DBQFGliZVCkn+/eutqCoRApdRAKD59vjwHdPDKevVVPWmap0EPJs/bACY0NwH Mnwiv5v+1mOhQiH1Z17A6w== =+6Dc -----END PGP SIGNATURE----- --SUOF0GtieIMvvwua-- From owner-freebsd-current@FreeBSD.ORG Thu Jul 12 14:32:04 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 30BCF16A400; Thu, 12 Jul 2007 14:32:04 +0000 (UTC) (envelope-from christos@zoulas.com) Received: from rebar.astron.com (rebar.astron.com [38.117.134.202]) by mx1.freebsd.org (Postfix) with ESMTP id 0E73F13C46E; Thu, 12 Jul 2007 14:32:03 +0000 (UTC) (envelope-from christos@zoulas.com) Received: by rebar.astron.com (Postfix, from userid 10080) id 7D67756539; Thu, 12 Jul 2007 10:11:10 -0400 (EDT) From: christos@zoulas.com (Christos Zoulas) Date: Thu, 12 Jul 2007 10:11:10 -0400 In-Reply-To: <4695A66A.8030903@FreeBSD.org> from Mark Peek (Jul 11, 8:56pm) Organization: Astron Software X-Mailer: Mail User's Shell (7.2.6 beta(4.pl1)+dynamic 20000103) To: Mark Peek , Doug White Message-Id: <20070712141110.7D67756539@rebar.astron.com> X-Mailman-Approved-At: Thu, 12 Jul 2007 15:07:04 +0000 Cc: tcsh-bugs@mx.gw.com, current@freebsd.org Subject: Re: tcsh backtick hang info X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2007 14:32:04 -0000 On Jul 11, 8:56pm, mp@FreeBSD.org (Mark Peek) wrote: -- Subject: Re: tcsh backtick hang info | There appears to be two different issues. One is with the builtin kill and the | other is the gdb issue. I sent off a tentative patch to the reporter of the | builtin kill issue and am awaiting onfirmation. The patch is here: | | http://people.freebsd.org/~mp/tcsh_kill.patch | | The gdb issue, much to my dismay, is still alluding my debugging skill given | the interaction with gdb and issues with actually debugging what is happening. | | Mark Thanks for all the work and time spent tracking this! The fix is definitely correct. You must be able to receive sigchld from the glob command otherwise the shell will not be able to reap the `` job. So blocking after globbing is the way to go. Good luck with gdb :-) Best, christos From owner-freebsd-current@FreeBSD.ORG Thu Jul 12 18:49:19 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B633416A473 for ; Thu, 12 Jul 2007 18:49:19 +0000 (UTC) (envelope-from dwhite@gumbysoft.com) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.freebsd.org (Postfix) with ESMTP id 008D013C465 for ; Thu, 12 Jul 2007 18:49:15 +0000 (UTC) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id 4B4EB72DA5; Thu, 12 Jul 2007 11:48:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id 45B7C72DA1; Thu, 12 Jul 2007 11:48:14 -0700 (PDT) Date: Thu, 12 Jul 2007 11:48:14 -0700 (PDT) From: Doug White To: Christos Zoulas In-Reply-To: <20070712141110.7D67756539@rebar.astron.com> Message-ID: <20070712114328.F4608@carver.gumbysoft.com> References: <20070712141110.7D67756539@rebar.astron.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Mark Peek , tcsh-bugs@mx.gw.com, current@freebsd.org Subject: Re: tcsh backtick hang info X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2007 18:49:19 -0000 On Thu, 12 Jul 2007, Christos Zoulas wrote: > On Jul 11, 8:56pm, mp@FreeBSD.org (Mark Peek) wrote: > -- Subject: Re: tcsh backtick hang info > > | There appears to be two different issues. One is with the builtin kill and the > | other is the gdb issue. I sent off a tentative patch to the reporter of the > | builtin kill issue and am awaiting onfirmation. The patch is here: > | > | http://people.freebsd.org/~mp/tcsh_kill.patch > | > | The gdb issue, much to my dismay, is still alluding my debugging skill given > | the interaction with gdb and issues with actually debugging what is happening. > | > | Mark > > Thanks for all the work and time spent tracking this! The fix is > definitely correct. You must be able to receive sigchld from the glob > command otherwise the shell will not be able to reap the `` job. So > blocking after globbing is the way to go. Good luck with gdb :-) Thanks for the good words, Christos! If you can confirm this will be the official patch then we can apply it to our vendor sources. If there are any other fixes for nasty bugs in 6.15.00 that you're hanging on to it'd be good to get those out and imported as well. We'll keep banging on the gdb issue. -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Thu Jul 12 19:13:00 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E2CFC16A46B for ; Thu, 12 Jul 2007 19:13:00 +0000 (UTC) (envelope-from almarrie@gmail.com) Received: from ag-out-0708.google.com (ag-out-0708.google.com [72.14.246.241]) by mx1.freebsd.org (Postfix) with ESMTP id A3B3813C459 for ; Thu, 12 Jul 2007 19:13:00 +0000 (UTC) (envelope-from almarrie@gmail.com) Received: by ag-out-0708.google.com with SMTP id 35so193003aga for ; Thu, 12 Jul 2007 12:13:00 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=Cu3GpilmLI9wZTYOPYMQ/h6ki+goLBUQO5DJ48+ujx7iozVCrZGvfSKNfKj1t9yteD/eO/eazTWM4yPBqqBCE1qJ8gNI+IrYQHNdP5cTOqgUIautDPmnot70AwZwGKZwMccOBTtfif4xrD0CXPf7IB2cqmJbBAbcP/4l7DLU7As= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=nVmkLAHM56rCOG+ER0/dlwYOKJAPIpgK+yxQqq6ut8OKQD0cVmxQ/KD9fWQ8UzuEajpOqwHXWtm/WMk1pFgBjpkR8HCMdq+P3Wy78Z3inp8TjVegJplTUzbZ2D05PgMm4v+k3ASNHkymu3Xi4+AhaCuW6vbGuPIWGuDmM42ZeTk= Received: by 10.100.142.12 with SMTP id p12mr479296and.1184267579939; Thu, 12 Jul 2007 12:12:59 -0700 (PDT) Received: by 10.100.9.14 with HTTP; Thu, 12 Jul 2007 12:12:59 -0700 (PDT) Message-ID: <499c70c0707121212t446c52b1o9f6e930b756f75e5@mail.gmail.com> Date: Thu, 12 Jul 2007 22:12:59 +0300 From: "Abdullah Ibn Hamad Al-Marri" To: "FreeBSD Current" MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: FreeBSD 7.0 with corrupted sh in AMD64 MySQL issue X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2007 19:13:01 -0000 Hello, FreeBSD 7.0-CURRENT #1: Thu Jul 12 18:55:28 GMT 2007 checking whether isinf() can be used in C++ code... yes checking for fseeko... yes checking style of gethost* routines... checking whether madvise is declared... yes other checking style of gethostname_r routines... glibc2 checking 3 argument to gethostname_r routines... char checking "args to pthread_getspecific"... POSIX checking "args to pthread_mutex_init"... POSIX checking "args to readdir_r"... POSIX checking "style of sigwait"... POSIX checking "for pthread_attr_setscope"... yes checking "can netinet files be included"... "yes" checking for OpenSSL... no checking for yaSSL... no checking libedit variant of rl_completion_entry_function... yes checking defined rl_compentry_func_t and rl_completion_func_t... yes checking HIST_ENTRY is declared in readline/readline.h... checking for big tables support... no checking max indexes per table... 64 checking for BerkeleyDB... no Not using Berkeley DB checking for Innodb... Using Innodb checking for aio_read in -lrt... yes checking for example storage engine... no checking for archive storage engine... no checking for csv storage engine... no checking for blackhole storage engine... no checking for NDB Cluster... Not using NDB Cluster checking for MySQL federated storage engine... no checking "for man pages to remove"... dropping ndbcluster embedded configure: creating ./config.status sh: environment corrupt; missing value for LC_TIME sh: environment corrupt; missing value for LC_MONETARY sh: environment corrupt; missing value for LC_CTYPE sh: environment corrupt; missing value for LC_COLLATE sh: environment corrupt; missing value for LANG sh: environment corrupt; missing value for LC_ALL sh: environment corrupt; missing value for LC_NUMERIC config.status: creating extra/yassl/Makefile config.status: creating extra/yassl/taocrypt/Makefile config.status: creating extra/yassl/taocrypt/src/Makefile config.status: creating extra/yassl/src/Makefile config.status: creating extra/yassl/testsuite/Makefile config.status: creating extra/yassl/taocrypt/test/Makefile config.status: creating extra/yassl/taocrypt/benchmark/Makefile config.status: creating libmysql/libmysql.ver config.status: creating libmysql_r/Makefile -- Regards, -Abdullah Ibn Hamad Al-Marri Arab Portal http://www.WeArab.Net/ From owner-freebsd-current@FreeBSD.ORG Thu Jul 12 18:56:17 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 763E316A41F; Thu, 12 Jul 2007 18:56:17 +0000 (UTC) (envelope-from christos@zoulas.com) Received: from rebar.astron.com (rebar.astron.com [38.117.134.202]) by mx1.freebsd.org (Postfix) with ESMTP id 290F613C44B; Thu, 12 Jul 2007 18:56:16 +0000 (UTC) (envelope-from christos@zoulas.com) Received: by rebar.astron.com (Postfix, from userid 10080) id 2BA2D56539; Thu, 12 Jul 2007 14:56:16 -0400 (EDT) From: christos@zoulas.com (Christos Zoulas) Date: Thu, 12 Jul 2007 14:56:16 -0400 In-Reply-To: <20070712114328.F4608@carver.gumbysoft.com> from Doug White (Jul 12, 11:48am) Organization: Astron Software X-Mailer: Mail User's Shell (7.2.6 beta(4.pl1)+dynamic 20000103) To: Doug White Message-Id: <20070712185616.2BA2D56539@rebar.astron.com> X-Mailman-Approved-At: Thu, 12 Jul 2007 19:38:23 +0000 Cc: Mark Peek , tcsh-bugs@mx.gw.com, current@freebsd.org Subject: Re: tcsh backtick hang info X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2007 18:56:17 -0000 On Jul 12, 11:48am, dwhite@gumbysoft.com (Doug White) wrote: -- Subject: Re: tcsh backtick hang info | Thanks for the good words, Christos! If you can confirm this will be the | official patch then we can apply it to our vendor sources. If there are | any other fixes for nasty bugs in 6.15.00 that you're hanging on to it'd | be good to get those out and imported as well. You are welcome! This will be the official patch, and yes I have another 9 bug fixes since 6.15.00. In general, I don't make 6.15.XX generally available, but the severity of some of those problems fixed is high enough to possibly justify a 6.16.00 sooner than later. Here's the list of fixes: 10. kill `foo` got stuck because sigchld was disabled too soon (Mark Peek) 9. Avoid null pointer dereference in proc cwd (Kurt Miller) 8. eval "foreach a b c" exits (Anthony Menasse) 7. Quoting was broken in substitutions (Joe Wells) 6. QNX patches via pkgsrc 5. cd - twice from a directory that contained a glob pattern, expands the glob twice (Mark Santcroos) 4. MidnightBsd support (Lucas Holt) 3. Fix history substitution core-dump with no history entries 2. Merge two character tables that are the same (Martin Kraemer) 1. On ancient 7 bit locales, punctuation characters are used to denote special characters such as umlaut, adiaresis, etc. These characters return true for isalpha/isalnum. Ignore them because they break parsing (Martin Kraemer) | We'll keep banging on the gdb issue. Good luck. christos From owner-freebsd-current@FreeBSD.ORG Thu Jul 12 19:37:51 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AC36B16A400 for ; Thu, 12 Jul 2007 19:37:51 +0000 (UTC) (envelope-from almarrie@gmail.com) Received: from ag-out-0708.google.com (ag-out-0708.google.com [72.14.246.250]) by mx1.freebsd.org (Postfix) with ESMTP id 6AFBF13C4BB for ; Thu, 12 Jul 2007 19:37:51 +0000 (UTC) (envelope-from almarrie@gmail.com) Received: by ag-out-0708.google.com with SMTP id 35so199038aga for ; Thu, 12 Jul 2007 12:37:50 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=k4Pd3ig1CuvEzHphhwIyUb5Xju8I+DXjGIFmvWfBI9AVRWBubbrh0Ob53sE9f6MXXdtN0PxTR20AZtaxuTD6ysxX6ALsfWa45yAg/cbUGt/UESIJ5/o7imhDYwGH71Y8KGhgVHGJ6hn04+2wTDz770uehWSbhZ1+XTI0y41/SsQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=knVvSW1si/uA1JryUjg5GHYxksZBF9Q1QFrkSuaV6qB4apnPeaFUY4qJudqVzAoRLL1DLkwGShcL4dyb7gpj/b6kDXP/BUjcACSG1OlLC0FEE/+CFkT3CwxKSy2I0SjdD3xPgOUhQDnER9IC+qcGgAGC4AHD7DAv4xwkfH441Ew= Received: by 10.100.110.16 with SMTP id i16mr492854anc.1184269070644; Thu, 12 Jul 2007 12:37:50 -0700 (PDT) Received: by 10.100.9.14 with HTTP; Thu, 12 Jul 2007 12:37:50 -0700 (PDT) Message-ID: <499c70c0707121237vf6901b7of83d5764c6c2ca15@mail.gmail.com> Date: Thu, 12 Jul 2007 22:37:50 +0300 From: "Abdullah Ibn Hamad Al-Marri" To: "Doug White" In-Reply-To: <20070712114328.F4608@carver.gumbysoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070712141110.7D67756539@rebar.astron.com> <20070712114328.F4608@carver.gumbysoft.com> Cc: tcsh-bugs@mx.gw.com, Christos Zoulas , current@freebsd.org Subject: Re: tcsh backtick hang info X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2007 19:37:51 -0000 On 7/12/07, Doug White wrote: > On Thu, 12 Jul 2007, Christos Zoulas wrote: > > > On Jul 11, 8:56pm, mp@FreeBSD.org (Mark Peek) wrote: > > -- Subject: Re: tcsh backtick hang info > > > > | There appears to be two different issues. One is with the builtin kill and the > > | other is the gdb issue. I sent off a tentative patch to the reporter of the > > | builtin kill issue and am awaiting onfirmation. The patch is here: > > | > > | http://people.freebsd.org/~mp/tcsh_kill.patch > > | > > | The gdb issue, much to my dismay, is still alluding my debugging skill given > > | the interaction with gdb and issues with actually debugging what is happening. > > | > > | Mark > > > > Thanks for all the work and time spent tracking this! The fix is > > definitely correct. You must be able to receive sigchld from the glob > > command otherwise the shell will not be able to reap the `` job. So > > blocking after globbing is the way to go. Good luck with gdb :-) > > Thanks for the good words, Christos! If you can confirm this will be the > official patch then we can apply it to our vendor sources. If there are > any other fixes for nasty bugs in 6.15.00 that you're hanging on to it'd > be good to get those out and imported as well. > > We'll keep banging on the gdb issue. > > -- > Doug White | FreeBSD: The Power to Serve > dwhite@gumbysoft.com | www.FreeBSD.org As for GDB, why don't you import 6.6? it's already in the ports and works smoothly in 7.0 and 6.2-stable as well. -- Regards, -Abdullah Ibn Hamad Al-Marri Arab Portal http://www.WeArab.Net/ From owner-freebsd-current@FreeBSD.ORG Thu Jul 12 20:25:30 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6760916A46B for ; Thu, 12 Jul 2007 20:25:30 +0000 (UTC) (envelope-from peter@wemm.org) Received: from canning.wemm.org (canning.wemm.org [192.203.228.65]) by mx1.freebsd.org (Postfix) with ESMTP id 4DF3913C468 for ; Thu, 12 Jul 2007 20:25:30 +0000 (UTC) (envelope-from peter@wemm.org) Received: from overcee.wemm.org (canning.wemm.org [192.203.228.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by canning.wemm.org (Postfix) with ESMTP id 4FE5846B77; Thu, 12 Jul 2007 13:09:26 -0700 (PDT) (envelope-from peter@wemm.org) Received: from overcee.wemm.org (localhost [127.0.0.1]) by overcee.wemm.org (8.14.1/8.14.1) with ESMTP id l6CK9ONN078657; Thu, 12 Jul 2007 13:09:24 -0700 (PDT) (envelope-from peter@wemm.org) Received: from localhost (localhost [[UNIX: localhost]]) by overcee.wemm.org (8.14.1/8.14.1/Submit) id l6CK9NXg078655; Thu, 12 Jul 2007 13:09:23 -0700 (PDT) (envelope-from peter@wemm.org) X-Authentication-Warning: overcee.wemm.org: peter set sender to peter@wemm.org using -f From: Peter Wemm To: freebsd-current@freebsd.org Date: Thu, 12 Jul 2007 13:09:23 -0700 User-Agent: KMail/1.9.6 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200707121309.23820.peter@wemm.org> Cc: Michiel Boland , peter@freebsd.org Subject: Re: upgrade 6-STABLE to -CURRENT on sparc64 renders box unusable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2007 20:25:30 -0000 On Tuesday 10 July 2007, Michiel Boland wrote: > Well, in fact I did manage to debug this further. :) > > The problem is that on sparc64 and -CURRENT, every executable > segfaults in > > _rtld > init_rtld > relocate_objects > reloc_non_plt > mmap > __getosreldate > > It appears that __getosreldate was added five days ago, which may > explain why the breakage on sparc64 hasn't been reported yet. (I am > ccing peter@ since he committed this.) > > If I apply the following patch, then rebuild libc, things are more or > less ok again. Of course this patch is very suboptimal, I am just > trying to point out where the problem is. > > --- __getosreldate.c.orig 2007-07-10 22:29:02.000000000 +0200 > +++ __getosreldate.c 2007-07-10 22:28:20.000000000 +0200 > @@ -42,13 +42,10 @@ > int > __getosreldate(void) > { > - static int osreldate; > + int osreldate; > size_t len; > int oid[2]; > int error, osrel; > - > - if (osreldate != 0) > - return (osreldate); > > oid[0] = CTL_KERN; > oid[1] = KERN_OSRELDATE; Your other option would be to add WITHOUT_SYSCALL_COMPAT=yes to /etc/make.conf. That gets rid of the __getosreldate() calls entirely, but at the expense of being able to boot an older kernel after userland has been updated. We could make this option default on sparc64 if it was acceptable. Another option might to hack rtld given the unusual circumstances: Index: libexec/rtld-elf/sparc64/reloc.c @@ -247,6 +247,9 @@ return (0); } + +void *__sys_freebsd6_mmap(void *, size_t, int, int, int, int, off_t); + int reloc_non_plt(Obj_Entry *obj, Obj_Entry *obj_rtld) { @@ -260,7 +263,8 @@ * The dynamic loader may be called from a thread, we have * limited amounts of stack available so we cannot use alloca(). */ - cache = mmap(NULL, bytes, PROT_READ|PROT_WRITE, MAP_ANON, -1, 0); + cache = __sys_freebsd6_mmap(NULL, bytes, PROT_READ|PROT_WRITE, MAP_ANON, + -1, 0, 0); if (cache == MAP_FAILED) cache = NULL; This would avoid the pre-reloc-fixup use of __getosreldate() via mmap. In spite of the name, freebsd6_mmap is "standard" in the tree right now and isn't going to become 'compat6' till comfortably after the release. The __getosreldate() thing would go away at the same time, so the problem would be "solved". The catch would be that a slightly out-of-date userland would depend on COMPAT_FREEBSD6 on sparc64. sparc64 boxes would be able to boot/run relatively old kernel.old's even after a fresh build/install world. PS: I've been told the same problem applies to powerpc.. PPS: I tried for 4 days to get a sun4v box to build world (shared with sparc64). I ended up giving up and just building/installing a new libc. I forgot that ld-elf.so.1 was statically linked against libc_pic.a. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 From owner-freebsd-current@FreeBSD.ORG Thu Jul 12 20:28:48 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6BB8916A46B for ; Thu, 12 Jul 2007 20:28:48 +0000 (UTC) (envelope-from scf@FreeBSD.org) Received: from mail.farley.org (farley.org [67.64.95.201]) by mx1.freebsd.org (Postfix) with ESMTP id 350AF13C484 for ; Thu, 12 Jul 2007 20:28:48 +0000 (UTC) (envelope-from scf@FreeBSD.org) Received: from thor.farley.org (thor.farley.org [192.168.1.5]) by mail.farley.org (8.14.1/8.14.1) with ESMTP id l6CKUcYa031059; Thu, 12 Jul 2007 15:30:38 -0500 (CDT) (envelope-from scf@FreeBSD.org) Date: Thu, 12 Jul 2007 15:28:30 -0500 (CDT) From: "Sean C. Farley" To: Abdullah Ibn Hamad Al-Marri In-Reply-To: <499c70c0707121212t446c52b1o9f6e930b756f75e5@mail.gmail.com> Message-ID: <20070712152607.P8789@thor.farley.org> References: <499c70c0707121212t446c52b1o9f6e930b756f75e5@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.1 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on mail.farley.org Cc: FreeBSD Current Subject: Re: FreeBSD 7.0 with corrupted sh in AMD64 MySQL issue X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2007 20:28:48 -0000 On Thu, 12 Jul 2007, Abdullah Ibn Hamad Al-Marri wrote: > Hello, > > FreeBSD 7.0-CURRENT #1: Thu Jul 12 18:55:28 GMT 2007 *snip* > sh: environment corrupt; missing value for LC_TIME > sh: environment corrupt; missing value for LC_MONETARY > sh: environment corrupt; missing value for LC_CTYPE > sh: environment corrupt; missing value for LC_COLLATE > sh: environment corrupt; missing value for LANG > sh: environment corrupt; missing value for LC_ALL > sh: environment corrupt; missing value for LC_NUMERIC That was my mistake related to the *env() function updates. It was fixed in r1.37 of src/bin/sh/var.c. Here is the patch[1]. Sean 1. http://www.freebsd.org/cgi/cvsweb.cgi/src/bin/sh/var.c.diff?r1=1.36;r2=1.37 -- scf@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Thu Jul 12 20:29:13 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7BDCB16A46B for ; Thu, 12 Jul 2007 20:29:13 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.freebsd.org (Postfix) with ESMTP id 45C9B13C484 for ; Thu, 12 Jul 2007 20:29:13 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.1/8.13.8) with ESMTP id l6CKRK8l091722; Thu, 12 Jul 2007 13:27:20 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.1/8.13.8/Submit) id l6CKR73w091716; Thu, 12 Jul 2007 13:27:07 -0700 (PDT) (envelope-from sgk) Date: Thu, 12 Jul 2007 13:27:07 -0700 From: Steve Kargl To: Abdullah Ibn Hamad Al-Marri Message-ID: <20070712202707.GA91647@troutmask.apl.washington.edu> References: <20070712141110.7D67756539@rebar.astron.com> <20070712114328.F4608@carver.gumbysoft.com> <499c70c0707121237vf6901b7of83d5764c6c2ca15@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <499c70c0707121237vf6901b7of83d5764c6c2ca15@mail.gmail.com> User-Agent: Mutt/1.4.2.2i Cc: tcsh-bugs@mx.gw.com, Christos Zoulas , current@freebsd.org Subject: Re: tcsh backtick hang info X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2007 20:29:13 -0000 On Thu, Jul 12, 2007 at 10:37:50PM +0300, Abdullah Ibn Hamad Al-Marri wrote: > > As for GDB, why don't you import 6.6? it's already in the ports and > works smoothly in 7.0 and 6.2-stable as well. > GDB 6.6 doesn't magically fix tcsh. -- Steve From owner-freebsd-current@FreeBSD.ORG Thu Jul 12 20:45:04 2007 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 479A816A47A for ; Thu, 12 Jul 2007 20:45:04 +0000 (UTC) (envelope-from bsd@kuehlbox.de) Received: from samael.qmail-ldap.de (mail.kuehlbox.de [62.159.47.22]) by mx1.freebsd.org (Postfix) with ESMTP id 3D4D013C4B0 for ; Thu, 12 Jul 2007 20:45:02 +0000 (UTC) (envelope-from bsd@kuehlbox.de) Received: (qmail 26695 invoked from network); 12 Jul 2007 20:45:00 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlbox.de; b=MiiOq3NFrqLQoflW1cryKQn1BKl2cjXBZI2NcqvhJaqYDIDBkdo7oKPg4WvseUUWl/rTV8LXqnEYtUoqnheAcYLkSbw+B57pkdMeC926I8XV6idpmDW7cAyNWGX6kWML ; Received: from unknown (HELO [192.168.200.128]) (bsd@kuehlbox.de@[82.135.93.20]) (envelope-sender ) by samael.qmail-ldap.de (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 12 Jul 2007 20:45:00 -0000 Message-ID: <469693EB.8050802@kuehlbox.de> Date: Thu, 12 Jul 2007 22:49:47 +0200 From: Teufel User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Simon Barner , current@FreeBSD.org References: <20070710120901.GA65987@atknoll88.informatik.tu-muenchen.de> <469608E2.3040804@kuehlbox.de> <20070712130213.GA3028@dose.local.invalid> In-Reply-To: <20070712130213.GA3028@dose.local.invalid> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: Valgrind GCC 4.2 patches X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2007 20:45:04 -0000 Hi again, we got a bit further... I guess its a prob with symbol versioning. Greetings, Stephan valgrind /bin/ls ==98005== Memcheck, a memory error detector for x86-linux. ==98005== Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward. ==98005== Using valgrind-2.1.0, a program supervision framework for x86-linux. ==98005== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward. ==98005== Estimated CPU clock rate is 2464 MHz ==98005== For more details, rerun with: -v ==98005== /libexec/ld-elf.so.1: /lib/libc.so.7: version FBSD_1.0 required by /bin/ls not defined ==98005== ==98005== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) ==98005== malloc/free: in use at exit: 0 bytes in 0 blocks. ==98005== malloc/free: 0 allocs, 0 frees, 0 bytes allocated. ==98005== For a detailed leak analysis, rerun with: --leak-check=yes ==98005== For counts of detected errors, rerun with: -v Simon Barner wrote: > Teufel wrote: > > I've updated the patches. Could you please try again? > From owner-freebsd-current@FreeBSD.ORG Thu Jul 12 20:58:36 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 164E216A400 for ; Thu, 12 Jul 2007 20:58:36 +0000 (UTC) (envelope-from freebsd@superhero.nl) Received: from superman.superhero.nl (superhero.nl [82.95.198.17]) by mx1.freebsd.org (Postfix) with ESMTP id 69F5A13C469 for ; Thu, 12 Jul 2007 20:58:34 +0000 (UTC) (envelope-from freebsd@superhero.nl) Received: (qmail 49028 invoked by uid 80); 12 Jul 2007 20:58:37 -0000 Received: from robin.ad.superhero.nl ([10.202.77.103]) (SquirrelMail authenticated user gelsemap) by webmail.superhero.nl with HTTP; Thu, 12 Jul 2007 22:58:37 +0200 (CEST) Message-ID: <3371.10.202.77.103.1184273917.squirrel@webmail.superhero.nl> Date: Thu, 12 Jul 2007 22:58:37 +0200 (CEST) From: "Gelsema, P \(Patrick\) - FreeBSD" To: current@freebsd.org User-Agent: SquirrelMail/1.4.8 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal References: <4686.10.202.77.103.1184191620.squirrel@webmail.superhero.nl> <46955D8F.8040900@u.washington.edu> In-Reply-To: <46955D8F.8040900@u.washington.edu> Cc: Subject: Re: -current AMD64 unable to mount root after buildworld/kernel reboot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2007 20:58:36 -0000 On Thu, July 12, 2007 00:45, Garrett Cooper wrote: > Gelsema, P (Patrick) - FreeBSD wrote: >> Hi, >> I have got the following issue. >> I have installed Current June AMD64 snapshot without any issues. I can reboot and the machine comes back up without any issues. >> /etc/make.conf is copied from /usr/share/examples/etc/make.conf and the only changed made are: >> cputype?=athlon64 >> cflags= -O2 -fno-strict-aliasing -pipe (only removed the # in front of the >> line) >> coptflags=-O -pipe (only removed the # in front of the line) >> and the settings regarding cvsup are enabled. yes and >> cvsup3.nl.freebsd.org, and only the standard-cvsupfile is uncommented. using the /usr/share/examples/cvsup/standard-supfile with no changes. First thing I do is a make update (as of this evening) after which I execute the following commands; >> #chflags -R noschg /usr/obj >> #rm -rf /usr/obj >> #make cleandir >> #make cleandir >> #make -j8 buildworld >> #make -j8 buildkernel >> #make -j8 installkernel >> #make -j8 installworld >> #mergemaster >> #shutdown -r now >> After this the machine reboots, starts FreeBSD and detects everything as >> it ought to. However the moment it tries to mount root from >> ufs:/dev/da0s1a it seems to fail and asks for; >> manual root filesystem specification. When I type in manually >> ufs:/dev/da0s1a it continues with the following error; >> ELF interpreter /libexec/ld-elf.so.1 not found >> init: /bin/sh on /etc/rc terminated abnormally, going to single user mode. >> Enter full pathname of shell or RETURN for /bin/sh. >> Hitting enter I get; >> ELF interpreter /libexec/ld-elf.so.1 not found >> init: single user shell terminated, restarting. >> Enter full pathname of shell or RETURN for /bin/sh. >> When rebooting with kernel.old everything goes ok and I am able to log on. >> Any help much appreciated. >> Rgds, >> Patrick > > You're most likely missing some key components in specifying your > disk controller. > > Do you have SCSI, SATA, PATA? If you have SCSI/SATA, did you perhaps > install your system with GEOM enabled? SCSI, Adaptec 39320D controller with Seagate SCSI disk. I used GENERIC kernel without any modifications. Controller is detected as aic7902 which is part of GENERIC. I swapped Harddisks and now I get the following error when building the kernel ( I did get this on the other harddisk as well): panic: ufs_dirbad: /usr: bad dir ino 2638106 at offset 0: mangled entry cpuid = 1 KDB: enter: panic [thread pid 9704 tid 100056 ] Stopped at kdb_enter+0x31:leave db> what could be causing this? Patrick > Booting into the backup kernel (single user mode), will be extremely > helpful in determining your issue, in particular what disk configuration you're using. > > -Garrett From owner-freebsd-current@FreeBSD.ORG Thu Jul 12 21:19:40 2007 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4115716A468; Thu, 12 Jul 2007 21:19:40 +0000 (UTC) (envelope-from root@mail.monkeytower.net) Received: from mail.monkeytower.net (mail.monkeytower.net [217.24.215.50]) by mx1.freebsd.org (Postfix) with ESMTP id C39F513C44C; Thu, 12 Jul 2007 21:19:39 +0000 (UTC) (envelope-from root@mail.monkeytower.net) Received: from root by mail.monkeytower.net with local Exim id 1I95d2-0005HV-0C; Thu, 12 Jul 2007 22:51:12 +0200 Received: from mx2.freebsd.org ([69.147.83.53]) by mail.monkeytower.net with esmtp Exim id 1I8yIU-0004kB-QN for mailinglists@suntsu.org; Thu, 12 Jul 2007 15:01:30 +0200 Received: from hub.freebsd.org (hub.freebsd.org [69.147.83.54]) by mx2.freebsd.org (Postfix) with ESMTP id 3F10F5C80D; Thu, 12 Jul 2007 12:59:36 +0000 (UTC) (envelope-from owner-freebsd-ports@freebsd.org) Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 2E55416A485; Thu, 12 Jul 2007 12:59:36 +0000 (UTC) (envelope-from owner-freebsd-ports@freebsd.org) X-Original-To: ports@FreeBSD.org Delivered-To: freebsd-ports@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AF4AD16A46E for ; Thu, 12 Jul 2007 12:59:32 +0000 (UTC) (envelope-from barner@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id 05C6F13C483 for ; Thu, 12 Jul 2007 12:59:31 +0000 (UTC) (envelope-from barner@gmx.de) Received: (qmail invoked by alias); 12 Jul 2007 12:59:30 -0000 Received: from ppp-88-217-18-195.dynamic.mnet-online.de (EHLO dose.local.invalid) [88.217.18.195] by mail.gmx.net (mp044) with SMTP; 12 Jul 2007 14:59:30 +0200 X-Authenticated: #147403 X-Provags-ID: V01U2FsdGVkX1/FCmNxuYbFOvFSThA1TAXOfXJye/DsW+bYCZxYZ0 WV7kNshAwrRjUW Received: by dose.local.invalid (Postfix, from userid 1000) id BE856C20C; Thu, 12 Jul 2007 15:02:13 +0200 (CEST) Date: Thu, 12 Jul 2007 15:02:13 +0200 From: Simon Barner To: Teufel Message-ID: <20070712130213.GA3028@dose.local.invalid> References: <20070710120901.GA65987@atknoll88.informatik.tu-muenchen.de> <469608E2.3040804@kuehlbox.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="SUOF0GtieIMvvwua" Content-Disposition: inline In-Reply-To: <469608E2.3040804@kuehlbox.de> User-Agent: Mutt/1.5.12-2006-07-14 X-Y-GMX-Trusted: 0 X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Sender: owner-freebsd-ports@freebsd.org Errors-To: owner-freebsd-ports@freebsd.org X-monkeytower-MailScanner-Information: contact information at http://www.monkeytower.net X-monkeytower-MailScanner: Found to be clean X-monkeytower-MailScanner-From: root@mail.monkeytower.net X-Spam-Status: No Cc: ports@FreeBSD.org, current@FreeBSD.org Subject: Re: Valgrind GCC 4.2 patches X-BeenThere: freebsd-current@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2007 21:19:40 -0000 --SUOF0GtieIMvvwua Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Teufel wrote: > Hi, >=20 > tried both patches on today's 7-CURRENT. Both compile, but using=20 > valgrind ends in a crash with unhandled syscalls. Ok, thanks for the report. > >http://home.leo.org/~barner/freebsd/valgrind-snapshot.patch > >http://home.leo.org/~barner/freebsd/valgrind.patch I've updated the patches. Could you please try again? --=20 Best regards / Viele Gr=FC=DFe, barner@FreeBSD.= org Simon Barner barner@gmx.de --SUOF0GtieIMvvwua Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD4DBQFGliZVCkn+/eutqCoRApdRAKD59vjwHdPDKevVVPWmap0EPJs/bACY0NwH Mnwiv5v+1mOhQiH1Z17A6w== =+6Dc -----END PGP SIGNATURE----- --SUOF0GtieIMvvwua-- From owner-freebsd-current@FreeBSD.ORG Thu Jul 12 23:08:43 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 046AC16A468 for ; Thu, 12 Jul 2007 23:08:43 +0000 (UTC) (envelope-from stevenschlansker@berkeley.edu) Received: from smtp-out1.berkeley.edu (smtp-out1.Berkeley.EDU [128.32.61.106]) by mx1.freebsd.org (Postfix) with ESMTP id E730D13C459 for ; Thu, 12 Jul 2007 23:08:42 +0000 (UTC) (envelope-from stevenschlansker@berkeley.edu) Received: from h-74-1-188-242.snfccasy.covad.net ([74.1.188.242] helo=[192.168.2.104]) by fe1.calmail with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (auth plain:stevenschlansker@berkeley.edu) (envelope-from ) id 1I97XG-0003sj-5o for freebsd-current@freebsd.org; Thu, 12 Jul 2007 15:53:22 -0700 Message-ID: <4696B0DF.8030909@berkeley.edu> Date: Thu, 12 Jul 2007 15:53:19 -0700 From: Steven Schlansker User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Removing an accidentally incorrect vdev from a ZFS pool X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2007 23:08:43 -0000 Hello everyone, I've been using ZFS on -CURRENT for a few weeks now with quite decent results. I'm really glad that this apparently awesome filesystem is available, and want to register my thanks for everyone who put work into it :) That being said, I've just run into a little snag. I wanted to extend my zpool from 3 drives to 6 drives. My first hope was that I could automagically extend the RAIDZ. My hope was to extend the vdev to be a raidz1 with 6 devices, and then restripe it to raidz2. That would have been pretty neat, and a great way to manage drives. After reading the man pages and not finding that functionality, I found many mailing list posts with everyone chatting about exactly that. I hope the functionality finds its way into 7.0. I'd add it myself, but I tried to read the ZFS code and a good percentage off it flew over my non-filesystem-geek programmer's head :) So then I settled on the next-best thing - adding another raidz1 vdev with the three new drives. Not quite as flexible, but still adequate. I checked the dmesg to find my drives - ad12, ad16, ad19. I ran sudo zpool add universe raidz1 ad12 ad16 ad19, and then checked zfs list to find my brand new double-sized zfs.... huh? It only grew by 40G? That's strange. Maybe the zpool grew... nope. About here is where I started to panic a bit. Checked the dmesg... oops! it was ad18, not 19... Anyway, my questions now are: Am I correct in concluding there is no way to reshape a raidz1 to a raidz2? Is this functionality planned? I now need to remove this broken vdev from my array. I haven't added any data, so there shouldn't even be any data at all on it. However all the remove/delete options to zpool seem to exclusively work on mirrors and hot spares. I really need to get this vdev off the zfs - it's entirely useless. How can I do that? I've already taken out the accidental drive - I want to try to recover the old filesystem off of it. Lucky it wasn't too important, though it'd be nice to have. Now i have an array stuck permanently degraded. On a related note, perhaps zpool should do a bit of sanity checking. I know the Linux md tools require you to 'force' array creation if the drives differ by +/- 5% or thereabouts. I just created a 400G/400G/40G raidz, which is a totally stupid array layout. Maybe it should try to catch it. (Yes, I should have caught it, but it's easy to miss the extra digit when you see 4xxxxx and 4xxxx next to each other, especially when they don't line up) Thank you so much for any advice anyone can offer! Steven Schlansker From owner-freebsd-current@FreeBSD.ORG Thu Jul 12 23:28:11 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BEB5616A421 for ; Thu, 12 Jul 2007 23:28:11 +0000 (UTC) (envelope-from joao.barros@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.173]) by mx1.freebsd.org (Postfix) with ESMTP id 48C7D13C447 for ; Thu, 12 Jul 2007 23:28:10 +0000 (UTC) (envelope-from joao.barros@gmail.com) Received: by ug-out-1314.google.com with SMTP id o4so512123uge for ; Thu, 12 Jul 2007 16:28:10 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=RDIVxHZmJnOfazbRJFa8fg+k32bJ9lAteSJymbRhmqw5DUWKZeQCnaPrg3k5r7+zFbW41gIWGJBVL1mYz9IlhXeuIgzx2FMGrSda1rAwFjOA/i9SjLrgaff/mSR5QLfhDVwjhH+mCOMDcggoEdDi/Y80T2bK+2+olAVGUNJhTVY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=IlC/B39VIYoU3wXnibWM5Ui7iz7PLpZvPTRfUhy4Lpj/E81ImO649OG7cMGJ/bfmoRpLHSqxNCbPQwhIWHKFhhjVc+F13KMFUy67KgsZc968XUYJrOL0kc2oYF2QM/GwWzCusFmn147fZO3NxiPdKG+dkLgWHrNEUZ3224ylBI4= Received: by 10.78.204.20 with SMTP id b20mr338807hug.1184282889437; Thu, 12 Jul 2007 16:28:09 -0700 (PDT) Received: by 10.78.187.16 with HTTP; Thu, 12 Jul 2007 16:28:09 -0700 (PDT) Message-ID: <70e8236f0707121628v7821be44w285b6070dff473c1@mail.gmail.com> Date: Fri, 13 Jul 2007 00:28:09 +0100 From: "Joao Barros" To: "Steven Schlansker" In-Reply-To: <4696B0DF.8030909@berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4696B0DF.8030909@berkeley.edu> Cc: freebsd-current@freebsd.org Subject: Re: Removing an accidentally incorrect vdev from a ZFS pool X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2007 23:28:11 -0000 On 7/12/07, Steven Schlansker wrote: > Hello everyone, > I've been using ZFS on -CURRENT for a few weeks now with quite decent > results. I'm really glad that this apparently awesome filesystem is > available, and want to register my thanks for everyone who put work into > it :) > > That being said, I've just run into a little snag. I wanted to extend > my zpool from 3 drives to 6 drives. > > My first hope was that I could automagically extend the RAIDZ. My hope > was to extend the vdev to be a raidz1 with 6 devices, and then restripe > it to raidz2. That would have been pretty neat, and a great way to > manage drives. After reading the man pages and not finding that > functionality, I found many mailing list posts with everyone chatting > about exactly that. I hope the functionality finds its way into 7.0. > I'd add it myself, but I tried to read the ZFS code and a good > percentage off it flew over my non-filesystem-geek programmer's head :) > > So then I settled on the next-best thing - adding another raidz1 vdev > with the three new drives. Not quite as flexible, but still adequate. > > I checked the dmesg to find my drives - ad12, ad16, ad19. I ran > sudo zpool add universe raidz1 ad12 ad16 ad19, and then checked zfs list > to find my brand new double-sized zfs.... huh? It only grew by 40G? > That's strange. Maybe the zpool grew... nope. About here is where I > started to panic a bit. Checked the dmesg... oops! it was ad18, not 19... > > Anyway, my questions now are: > Am I correct in concluding there is no way to reshape a raidz1 to a > raidz2? Is this functionality planned? > > I now need to remove this broken vdev from my array. I haven't added > any data, so there shouldn't even be any data at all on it. However all > the remove/delete options to zpool seem to exclusively work on mirrors > and hot spares. I really need to get this vdev off the zfs - it's > entirely useless. How can I do that? I've already taken out the > accidental drive - I want to try to recover the old filesystem off of > it. Lucky it wasn't too important, though it'd be nice to have. Now i > have an array stuck permanently degraded. > > On a related note, perhaps zpool should do a bit of sanity checking. I > know the Linux md tools require you to 'force' array creation if the > drives differ by +/- 5% or thereabouts. I just created a 400G/400G/40G > raidz, which is a totally stupid array layout. Maybe it should try to > catch it. (Yes, I should have caught it, but it's easy to miss the > extra digit when you see 4xxxxx and 4xxxx next to each other, especially > when they don't line up) > > Thank you so much for any advice anyone can offer! > > Steven Schlansker There is still no way to expand a raidz. The way ZFS was created makes this a difficult task. Still the ZFS developers say they are working on that. Removing a device from a raidz is not supported as well. Again it's being worked on. I can't say if for sure about raidz to raidz2 being supported, but I guess it isn't. Everything else I pretty much learned a couple of months ago in Sun's online docs and forum which I recommend you do browse. As for new features hitting 7.0 I wouldn't get my hopes up, new features come from Sun, not FreeBSD developers. You might see some small updates and/or fixes for 7.0 but that's it. My words, don't take them for granted :> -- Joao Barros From owner-freebsd-current@FreeBSD.ORG Thu Jul 12 23:39:49 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CD48C16A400 for ; Thu, 12 Jul 2007 23:39:49 +0000 (UTC) (envelope-from joao.barros@gmail.com) Received: from ik-out-1112.google.com (ik-out-1112.google.com [66.249.90.180]) by mx1.freebsd.org (Postfix) with ESMTP id 642A013C45A for ; Thu, 12 Jul 2007 23:39:49 +0000 (UTC) (envelope-from joao.barros@gmail.com) Received: by ik-out-1112.google.com with SMTP id c21so296759ika for ; Thu, 12 Jul 2007 16:39:48 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=BuxmsIilUQlm4g3TyTvvSFPQ0+nq/DU+wFj6i+x9/BL3MenlkXqL3SnQJxhJ9CQFBbcxRBtvl6OfGxfbCFv6j7flziZe/IjfkoAJ4oRKKLJ4y6S+yagzA9lpqz7FFQEhd7Ni6xiYHz5/yHBt1x+yoPHjelb5AI+EDKMRPtM/+jA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ZfI+cqO4KTGkbWO32tV02upqeYX4wrrTgZHK5tF/0YO6RYzAY9sB2HQeCZVdE/sAqt6P0sbivwIXchVemZ6ATRnB5bkahXNDkgHTYdodpOmb2tyqCFHkMA5veSqq8LY8b85affFWRyipJDfqfaHxJXt+rfUDtcrrmg2VeF6GQ38= Received: by 10.78.142.14 with SMTP id p14mr335926hud.1184281848759; Thu, 12 Jul 2007 16:10:48 -0700 (PDT) Received: by 10.78.187.16 with HTTP; Thu, 12 Jul 2007 16:10:48 -0700 (PDT) Message-ID: <70e8236f0707121610v65bacaa0pcaf45c62516ab424@mail.gmail.com> Date: Fri, 13 Jul 2007 00:10:48 +0100 From: "Joao Barros" To: "Pawel Jakub Dawidek" In-Reply-To: <20070709000918.GD1208@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200707071426.18202.dfr@rabson.org> <20070709000918.GD1208@garage.freebsd.pl> Cc: current@freebsd.org Subject: Re: ZFS leaking vnodes (sort of) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2007 23:39:49 -0000 On 7/9/07, Pawel Jakub Dawidek wrote: > On Sat, Jul 07, 2007 at 02:26:17PM +0100, Doug Rabson wrote: > > I've been testing ZFS recently and I noticed some performance issues > > while doing large-scale port builds on a ZFS mounted /usr/ports tree. > > Eventually I realised that virtually nothing ever ended up on the vnode > > free list. This meant that when the system reached its maximum vnode > > limit, it had to resort to reclaiming vnodes from the various > > filesystem's active vnode lists (via vlrureclaim). Since those lists > > are not sorted in LRU order, this led to pessimal cache performance > > after the system got into that state. > > > > I looked a bit closer at the ZFS code and poked around with DDB and I > > think the problem was caused by a couple of extraneous calls to vhold > > when creating a new ZFS vnode. On FreeBSD, getnewvnode returns a vnode > > which is already held (not on the free list) so there is no need to > > call vhold again. > > Whoa! Nice catch... The patch works here - I did some pretty heavy > tests, so please commit it ASAP. > > I also wonder if this can help with some of those 'kmem_map too small' > panics. I was observing that ARC cannot reclaim memory and this may be > because all vnodes and thus associated data are beeing held. > > To ZFS users having problems with performance and/or stability of ZFS: > Can you test the patch and see if it helps? > I've recompiled my system after Doug committed this patch 3 days ago and I can panic my machine as soon as I don't set kern.maxvnodes to 50000 while doing a ls -R after a recursive chown on some thousands of files and dirs: panic: kmem_malloc(16384): kmem_map too small: 326066176 total allocated I noticed that before this patch the system panicked very easily and soon in the chown process. Now it completes the chown on the thousands of files and dirs I have in it and only panics after in the ls -R process. It's an improvement, but something else is still there... -- Joao Barros From owner-freebsd-current@FreeBSD.ORG Thu Jul 12 23:40:15 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AA4EC16A400 for ; Thu, 12 Jul 2007 23:40:15 +0000 (UTC) (envelope-from gelsemap@superhero.nl) Received: from superman.superhero.nl (superhero.nl [82.95.198.17]) by mx1.freebsd.org (Postfix) with ESMTP id DC3C913C44B for ; Thu, 12 Jul 2007 23:40:14 +0000 (UTC) (envelope-from gelsemap@superhero.nl) Received: (qmail 54939 invoked by uid 80); 12 Jul 2007 23:40:17 -0000 Received: from robin.ad.superhero.nl ([10.202.77.103]) (SquirrelMail authenticated user gelsemap) by webmail.superhero.nl with HTTP; Fri, 13 Jul 2007 01:40:17 +0200 (CEST) Message-ID: <3711.10.202.77.103.1184283617.squirrel@webmail.superhero.nl> In-Reply-To: <3371.10.202.77.103.1184273917.squirrel@webmail.superhero.nl> References: <4686.10.202.77.103.1184191620.squirrel@webmail.superhero.nl> <46955D8F.8040900@u.washington.edu> <3371.10.202.77.103.1184273917.squirrel@webmail.superhero.nl> Date: Fri, 13 Jul 2007 01:40:17 +0200 (CEST) From: "Gelsema, P \(Patrick\)" To: current@freebsd.org User-Agent: SquirrelMail/1.4.8 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: Subject: Re: -current AMD64 unable to mount root after buildworld/kernel reboot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2007 23:40:15 -0000 On Thu, July 12, 2007 22:58, Gelsema, P \(Patrick\) - FreeBSD wrote: > On Thu, July 12, 2007 00:45, Garrett Cooper wrote: >> Gelsema, P (Patrick) - FreeBSD wrote: >>> Hi, >>> I have got the following issue. >>> I have installed Current June AMD64 snapshot without any issues. I can > reboot and the machine comes back up without any issues. >>> /etc/make.conf is copied from /usr/share/examples/etc/make.conf and the > only changed made are: >>> cputype?=athlon64 >>> cflags= -O2 -fno-strict-aliasing -pipe (only removed the # in front of >>> the >>> line) >>> coptflags=-O -pipe (only removed the # in front of the line) >>> and the settings regarding cvsup are enabled. yes and >>> cvsup3.nl.freebsd.org, and only the standard-cvsupfile is uncommented. > using the /usr/share/examples/cvsup/standard-supfile with no changes. > First thing I do is a make update (as of this evening) after which I > execute the following commands; >>> #chflags -R noschg /usr/obj >>> #rm -rf /usr/obj >>> #make cleandir >>> #make cleandir >>> #make -j8 buildworld >>> #make -j8 buildkernel >>> #make -j8 installkernel >>> #make -j8 installworld >>> #mergemaster >>> #shutdown -r now >>> After this the machine reboots, starts FreeBSD and detects everything > as >>> it ought to. However the moment it tries to mount root from >>> ufs:/dev/da0s1a it seems to fail and asks for; >>> manual root filesystem specification. When I type in manually >>> ufs:/dev/da0s1a it continues with the following error; >>> ELF interpreter /libexec/ld-elf.so.1 not found >>> init: /bin/sh on /etc/rc terminated abnormally, going to single user >>> mode. >>> Enter full pathname of shell or RETURN for /bin/sh. >>> Hitting enter I get; >>> ELF interpreter /libexec/ld-elf.so.1 not found >>> init: single user shell terminated, restarting. >>> Enter full pathname of shell or RETURN for /bin/sh. >>> When rebooting with kernel.old everything goes ok and I am able to log >>> on. >>> Any help much appreciated. >>> Rgds, >>> Patrick >> >> You're most likely missing some key components in specifying your >> disk controller. >> >> Do you have SCSI, SATA, PATA? If you have SCSI/SATA, did you perhaps >> install your system with GEOM enabled? > > SCSI, Adaptec 39320D controller with Seagate SCSI disk. I used GENERIC > kernel without any modifications. Controller is detected as aic7902 which > is part of GENERIC. > > I swapped Harddisks and now I get the following error when building the > kernel ( I did get this on the other harddisk as well): > > panic: ufs_dirbad: /usr: bad dir ino 2638106 at offset 0: mangled entry > cpuid = 1 > KDB: enter: panic > [thread pid 9704 tid 100056 ] > Stopped at kdb_enter+0x31:leave > db> > > what could be causing this? > > Patrick Swapped cables, started from scratch, resulting in the manual mount filesystem question. Tomorrow I will try to install the I386 version and see if that goes ok. It might be interesting to mention that this box has been upgraded to 4GB of memory. Maybe memory allocation, contention? Which tool from ports can I use to test the memory? Bios (Asus M2N board) does not complain about memory. > >> Booting into the backup kernel (single user mode), will be extremely >> helpful in determining your issue, in particular what disk configuration > you're using. >> >> -Garrett > > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Thu Jul 12 23:50:09 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9A50A16A476; Thu, 12 Jul 2007 23:50:09 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from mrout1.yahoo.com (mrout1.yahoo.com [216.145.54.171]) by mx1.freebsd.org (Postfix) with ESMTP id 6E06713C459; Thu, 12 Jul 2007 23:50:09 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from 185.32.61.10.in-addr.arpa.neville-neil.com (proxy8.corp.yahoo.com [216.145.48.13]) by mrout1.yahoo.com (8.13.6/8.13.6/y.out) with ESMTP id l6CNnpDr025898; Thu, 12 Jul 2007 16:49:51 -0700 (PDT) Date: Thu, 12 Jul 2007 16:49:37 -0700 Message-ID: From: gnn@freebsd.org To: "Peter Blok" In-Reply-To: References: User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.7 Emacs/22.0.95 (i386-apple-darwin8.8.2) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: current@freebsd.org, net@freebsd.org Subject: Re: FAST_IPSEC is now IPSEC, please be advised... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2007 23:50:09 -0000 At Wed, 11 Jul 2007 13:49:37 +0200, Peter Blok wrote: > > Hi George, > > Is somebody looking at ipsec-tools? As far as I can see it requires a > lot of kame definitions, although not used most of the times. I have > tried to make sense of this, but it wasn't easy. I am not right now, if you have interest and or patches I (we) would love to see them. Thanks, George From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 00:26:18 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0B2B216A400 for ; Fri, 13 Jul 2007 00:26:18 +0000 (UTC) (envelope-from craig@xfoil.gank.org) Received: from ion.gank.org (ion.gank.org [69.55.238.164]) by mx1.freebsd.org (Postfix) with ESMTP id EB8F413C448 for ; Fri, 13 Jul 2007 00:26:15 +0000 (UTC) (envelope-from craig@xfoil.gank.org) Received: by ion.gank.org (Postfix, from userid 1001) id 9772E111F3; Thu, 12 Jul 2007 19:26:15 -0500 (CDT) Date: Thu, 12 Jul 2007 19:26:11 -0500 From: Craig Boston To: Steven Schlansker Message-ID: <20070713002611.GA86925@nowhere> Mail-Followup-To: Craig Boston , Steven Schlansker , freebsd-current@freebsd.org References: <4696B0DF.8030909@berkeley.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4696B0DF.8030909@berkeley.edu> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: Removing an accidentally incorrect vdev from a ZFS pool X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2007 00:26:18 -0000 On Thu, Jul 12, 2007 at 03:53:19PM -0700, Steven Schlansker wrote: > I now need to remove this broken vdev from my array. I haven't added > any data, so there shouldn't even be any data at all on it. However all > the remove/delete options to zpool seem to exclusively work on mirrors > and hot spares. I really need to get this vdev off the zfs - it's > entirely useless. How can I do that? I've already taken out the > accidental drive - I want to try to recover the old filesystem off of > it. Lucky it wasn't too important, though it'd be nice to have. Now i > have an array stuck permanently degraded. I don't think it's currently possible to remove a vdev from a pool without destroying the pool and re-creating it. That being said, it may be possible to salvage your situation. The first thing I would try would be zpool replace [pool] ad19 ad18 Once the resilver completes, your pool should magically get bigger, though you may have to export/import the pool first (or reboot if you can't unmount what's on it). If that fails, could you please post the output of 'zpool status' to the list? Craig From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 00:59:35 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DDEF416A469 for ; Fri, 13 Jul 2007 00:59:35 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 95C6C13C45D for ; Fri, 13 Jul 2007 00:59:35 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1I99VM-0003O5-Ny for freebsd-current@freebsd.org; Fri, 13 Jul 2007 02:59:33 +0200 Received: from 89-172-35-182.adsl.net.t-com.hr ([89.172.35.182]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 13 Jul 2007 02:59:32 +0200 Received: from ivoras by 89-172-35-182.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 13 Jul 2007 02:59:32 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Ivan Voras Date: Fri, 13 Jul 2007 02:59:26 +0200 Lines: 16 Message-ID: References: <20070709214216.GA72912@walton.maths.tcd.ie> <20070711132202.GA95487@walton.maths.tcd.ie> <20070712085135.GA5332@walton.maths.tcd.ie> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 89-172-35-182.adsl.net.t-com.hr User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) In-Reply-To: <20070712085135.GA5332@walton.maths.tcd.ie> Sender: news Cc: freebsd-hackers@freebsd.org Subject: Re: Debugging times X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2007 00:59:35 -0000 David Malone wrote: > Ah - that's interesting. Could you look for the comment in > src/sys/i386/isa/clock.c that says: > > /* Should we set dow = -1 because some clocks don't set it correctly? */ > > and add a line afterwards to say: > > ct.dow = -1; > > and see if that helps? Yes, it does! Setting ct.dow to -1 fixes the time in a correct way. I vote this gets committed as soon as possible :) From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 01:55:25 2007 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C314216A401 for ; Fri, 13 Jul 2007 01:55:25 +0000 (UTC) (envelope-from nate@root.org) Received: from root.org (root.org [67.118.192.226]) by mx1.freebsd.org (Postfix) with ESMTP id A899313C494 for ; Fri, 13 Jul 2007 01:55:25 +0000 (UTC) (envelope-from nate@root.org) Received: (qmail 80978 invoked from network); 13 Jul 2007 01:55:27 -0000 Received: from ppp-71-139-42-13.dsl.snfc21.pacbell.net (HELO ?10.0.5.18?) (nate-mail@71.139.42.13) by root.org with ESMTPA; 13 Jul 2007 01:55:27 -0000 Message-ID: <4696DB83.4000803@root.org> Date: Thu, 12 Jul 2007 18:55:15 -0700 From: Nate Lawson User-Agent: Thunderbird 2.0.0.4 (X11/20070617) MIME-Version: 1.0 To: current@FreeBSD.org X-Enigmail-Version: 0.95.0 Content-Type: multipart/mixed; boundary="------------040802030100070704070802" Cc: Subject: patch to catch non-working hpet X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2007 01:55:25 -0000 This is a multi-part message in MIME format. --------------040802030100070704070802 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I need someone to test this code. You have to have an HPET timer. It should detect the case where it's non-working on at least one Acer system but not break others. Your system should boot and work normally with no change in dmesg. Let me know if it breaks something, thx. --------------040802030100070704070802 Content-Type: text/x-patch; name="hpet1.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="hpet1.diff" Index: sys/dev/acpica/acpi_hpet.c =================================================================== RCS file: /home/ncvs/src/sys/dev/acpica/acpi_hpet.c,v retrieving revision 1.5.2.4 diff -u -r1.5.2.4 acpi_hpet.c --- sys/dev/acpica/acpi_hpet.c 18 Jun 2007 00:29:55 -0000 1.5.2.4 +++ sys/dev/acpica/acpi_hpet.c 12 Jul 2007 21:20:27 -0000 @@ -144,7 +144,7 @@ { struct acpi_hpet_softc *sc; int rid; - uint32_t val; + uint32_t val, val2; uintmax_t freq; ACPI_FUNCTION_TRACE((char *)(uintptr_t) __func__); @@ -167,6 +167,9 @@ return (ENXIO); } + /* Be sure timer is enabled. */ + bus_write_4(sc->mem_res, HPET_OFFSET_ENABLE, 1); + /* Read basic statistics about the timer. */ val = bus_read_4(sc->mem_res, HPET_OFFSET_PERIOD); freq = (1000000000000000LL + val / 2) / val; @@ -179,12 +182,23 @@ ((val >> 13) & 1) ? " count_size" : ""); } - /* Be sure it is enabled. */ - bus_write_4(sc->mem_res, HPET_OFFSET_ENABLE, 1); - if (testenv("debug.acpi.hpet_test")) acpi_hpet_test(sc); + /* + * Don't attach if the timer never increments. Since the spec + * requires it to be at least 10 MHz, it has to change in 1 us. + */ + val = bus_read_4(sc->mem_res, HPET_OFFSET_VALUE); + DELAY(1); + val2 = bus_read_4(sc->mem_res, HPET_OFFSET_VALUE); + if (val == val2) { + device_printf(dev, "HPET never increments, disabling\n"); + bus_write_4(sc->mem_res, HPET_OFFSET_ENABLE, 0); + bus_free_resource(dev, SYS_RES_MEMORY, sc->mem_res); + return (ENXIO); + } + hpet_timecounter.tc_frequency = freq; hpet_timecounter.tc_priv = sc; tc_init(&hpet_timecounter); --------------040802030100070704070802-- From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 02:13:47 2007 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 10ABE16A403 for ; Fri, 13 Jul 2007 02:13:47 +0000 (UTC) (envelope-from rpaulo@fnop.net) Received: from core.fnop.net (mx.fnop.net [82.102.11.82]) by mx1.freebsd.org (Postfix) with ESMTP id C45AC13C442 for ; Fri, 13 Jul 2007 02:13:46 +0000 (UTC) (envelope-from rpaulo@fnop.net) Received: from core.fnop.net (mx.fnop.net [82.102.11.82]) by core.fnop.net (Postfix) with ESMTP id 8B29A690DC6; Fri, 13 Jul 2007 03:08:18 +0100 (WEST) Received: by core.fnop.net (Postfix, from userid 1015) id 57088690DDA; Fri, 13 Jul 2007 03:08:18 +0100 (WEST) X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on core.fnop.net X-Spam-Level: X-Spam-Status: No, score=-0.2 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,RCVD_IN_DSBL autolearn=no version=3.1.7 Received: from epsilon.local (87-196-53-163.net.novis.pt [87.196.53.163]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by core.fnop.net (Postfix) with ESMTP id D90A9690DC6; Fri, 13 Jul 2007 03:08:17 +0100 (WEST) Message-ID: <4696DFD3.1010808@fnop.net> Date: Fri, 13 Jul 2007 03:13:39 +0100 From: Rui Paulo User-Agent: Thunderbird 2.0.0.4 (X11/20070704) MIME-Version: 1.0 To: Nate Lawson References: <4696DB83.4000803@root.org> In-Reply-To: <4696DB83.4000803@root.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: current@FreeBSD.org Subject: Re: patch to catch non-working hpet X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2007 02:13:47 -0000 Nate Lawson wrote: > I need someone to test this code. You have to have an HPET timer. It > should detect the case where it's non-working on at least one Acer > system but not break others. Your system should boot and work normally > with no change in dmesg. Let me know if it breaks something, thx. Works fine. acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 2000 No changes in dmesg. Regards. -- Rui Paulo From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 02:32:50 2007 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EAF1C16A401 for ; Fri, 13 Jul 2007 02:32:50 +0000 (UTC) (envelope-from nate@root.org) Received: from root.org (root.org [67.118.192.226]) by mx1.freebsd.org (Postfix) with ESMTP id B714413C48D for ; Fri, 13 Jul 2007 02:32:50 +0000 (UTC) (envelope-from nate@root.org) Received: (qmail 82944 invoked from network); 13 Jul 2007 02:32:52 -0000 Received: from ppp-71-139-42-13.dsl.snfc21.pacbell.net (HELO ?10.0.5.18?) (nate-mail@71.139.42.13) by root.org with ESMTPA; 13 Jul 2007 02:32:52 -0000 Message-ID: <4696E448.8020807@root.org> Date: Thu, 12 Jul 2007 19:32:40 -0700 From: Nate Lawson User-Agent: Thunderbird 2.0.0.4 (X11/20070617) MIME-Version: 1.0 To: Rui Paulo References: <4696DB83.4000803@root.org> <4696DFD3.1010808@fnop.net> In-Reply-To: <4696DFD3.1010808@fnop.net> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: current@FreeBSD.org Subject: Re: patch to catch non-working hpet X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2007 02:32:51 -0000 Rui Paulo wrote: > Nate Lawson wrote: >> I need someone to test this code. You have to have an HPET timer. It >> should detect the case where it's non-working on at least one Acer >> system but not break others. Your system should boot and work normally >> with no change in dmesg. Let me know if it breaks something, thx. > > Works fine. > acpi_hpet0: iomem 0xfed00000-0xfed003ff on > acpi0 > Timecounter "HPET" frequency 14318180 Hz quality 2000 > > No changes in dmesg. Thanks. Now if it fixes silby's problem, I'll commit it. -Nate From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 00:54:57 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9CBE116A400 for ; Fri, 13 Jul 2007 00:54:57 +0000 (UTC) (envelope-from stevenschlansker@calmail.berkeley.edu) Received: from smtp-out1.berkeley.edu (smtp-out1.Berkeley.EDU [128.32.61.106]) by mx1.freebsd.org (Postfix) with ESMTP id 899B613C468 for ; Fri, 13 Jul 2007 00:54:57 +0000 (UTC) (envelope-from stevenschlansker@calmail.berkeley.edu) Received: from adsl-75-44-18-150.dsl.pltn13.sbcglobal.net ([75.44.18.150] helo=[192.168.42.3]) by fe2.calmail with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (auth plain:stevenschlansker@berkeley.edu) (envelope-from ) id 1I99CH-0005it-79 for freebsd-current@freebsd.org; Thu, 12 Jul 2007 17:39:49 -0700 Message-ID: <4696C9D2.9070108@calmail.berkeley.edu> Date: Thu, 12 Jul 2007 17:39:46 -0700 From: Steven Schlansker User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <4696B0DF.8030909@berkeley.edu> <20070713002611.GA86925@nowhere> In-Reply-To: <20070713002611.GA86925@nowhere> X-Enigmail-Version: 0.94.2.0 OpenPGP: id=40BFF7A7; url=subkeys.pgp.net Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 13 Jul 2007 02:34:49 +0000 Subject: Re: Removing an accidentally incorrect vdev from a ZFS pool X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2007 00:54:57 -0000 Craig Boston wrote: > On Thu, Jul 12, 2007 at 03:53:19PM -0700, Steven Schlansker wrote: >> I now need to remove this broken vdev from my array. I haven't added >> any data, so there shouldn't even be any data at all on it. However all >> the remove/delete options to zpool seem to exclusively work on mirrors >> and hot spares. I really need to get this vdev off the zfs - it's >> entirely useless. How can I do that? I've already taken out the >> accidental drive - I want to try to recover the old filesystem off of >> it. Lucky it wasn't too important, though it'd be nice to have. Now i >> have an array stuck permanently degraded. > > I don't think it's currently possible to remove a vdev from a pool > without destroying the pool and re-creating it. That being said, it may > be possible to salvage your situation. > > The first thing I would try would be > > zpool replace [pool] ad19 ad18 > > Once the resilver completes, your pool should magically get bigger, > though you may have to export/import the pool first (or reboot if you > can't unmount what's on it). > > If that fails, could you please post the output of 'zpool status' to the > list? > > Craig (Sorry about the duplicate Craig, meant to post that to the list.) Aha! Since I figured it was the wrong hard drive, I opened the case... and voila, my 400GB hard drive was actually installed and showing up incorrectly in dmesg. I replaced the pci interface, and now, a few resilvers and reboots later, everything is peachy. Thanks! Steven From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 03:11:22 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AAF7616A400 for ; Fri, 13 Jul 2007 03:11:22 +0000 (UTC) (envelope-from stevenschlansker@berkeley.edu) Received: from smtp-out1.berkeley.edu (smtp-out1.Berkeley.EDU [128.32.61.106]) by mx1.freebsd.org (Postfix) with ESMTP id 9853813C4B4 for ; Fri, 13 Jul 2007 03:11:22 +0000 (UTC) (envelope-from stevenschlansker@berkeley.edu) Received: from adsl-75-44-18-150.dsl.pltn13.sbcglobal.net ([75.44.18.150] helo=[192.168.42.10]) by fe3.calmail with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (auth plain:stevenschlansker@berkeley.edu) (envelope-from ) id 1I9BYw-0000LG-An for freebsd-current@freebsd.org; Thu, 12 Jul 2007 20:11:22 -0700 Message-ID: <4696ED57.3090507@berkeley.edu> Date: Thu, 12 Jul 2007 20:11:19 -0700 From: Steven Schlansker User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: freebsd-current@freebsd.org X-Enigmail-Version: 0.94.2.0 OpenPGP: id=40BFF7A7; url=subkeys.pgp.net Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: uma_zalloc_arg: zone "mbuf" with the following non-sleepable locks held: on today's amd64 kernel X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2007 03:11:22 -0000 'Fraid I'm not much of a kernel hacker, so advance apologies if this turns out just to be noise - but I figure since I'm running current I ought to report a few bugs. If it turns out that this sort of thing shouldn't be reported, just tell me ;) I compiled a new kernel at 11:30am, and I've been writing to zfs via nfs for a bit and these messages have been showing up: Jul 12 19:52:25 universe kernel: uma_zalloc_arg: zone "mbuf" with the following non-sleepable locks held: Jul 12 19:52:25 universe kernel: exclusive sleep mutex nfsd_mtx r = 0 (0xffffffff80aad120) locked @ /usr/src/sys/nfsserver/nfs_srvsock.c:660 Jul 12 19:52:25 universe kernel: KDB: stack backtrace: Jul 12 19:52:25 universe kernel: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a Jul 12 19:52:25 universe kernel: witness_warn() at witness_warn+0x248 Jul 12 19:52:25 universe kernel: uma_zalloc_arg() at uma_zalloc_arg+0x33a Jul 12 19:52:25 universe kernel: nfs_realign() at nfs_realign+0x63 Jul 12 19:52:25 universe kernel: nfsrv_rcv() at nfsrv_rcv+0x590 Jul 12 19:52:25 universe kernel: nfssvc() at nfssvc+0xb9f Jul 12 19:52:25 universe kernel: syscall() at syscall+0x1ce Jul 12 19:52:25 universe kernel: Xfast_syscall() at Xfast_syscall+0xab Jul 12 19:52:25 universe kernel: --- syscall (155, FreeBSD ELF64, nfssvc), rip = 0x8006891cc, rsp = 0x7fffffffea28, rbp = 0 --- Jul 12 19:52:25 universe kernel: uma_zalloc_arg: zone "mbuf_cluster" with the following non-sleepable locks held: Jul 12 19:52:25 universe kernel: exclusive sleep mutex nfsd_mtx r = 0 (0xffffffff80aad120) locked @ /usr/src/sys/nfsserver/nfs_srvsock.c:660 Jul 12 19:52:25 universe kernel: KDB: stack backtrace: Jul 12 19:52:25 universe kernel: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a Jul 12 19:52:25 universe kernel: witness_warn() at witness_warn+0x248 Jul 12 19:52:25 universe kernel: uma_zalloc_arg() at uma_zalloc_arg+0x33a Jul 12 19:52:25 universe kernel: nfs_realign() at nfs_realign+0x91 Jul 12 19:52:25 universe kernel: nfsrv_rcv() at nfsrv_rcv+0x590 Jul 12 19:52:25 universe kernel: nfssvc() at nfssvc+0xb9f Jul 12 19:52:25 universe kernel: syscall() at syscall+0x1ce Jul 12 19:52:25 universe kernel: Xfast_syscall() at Xfast_syscall+0xab Jul 12 19:52:25 universe kernel: --- syscall (155, FreeBSD ELF64, nfssvc), rip = 0x8006891cc, rsp = 0x7fffffffea28, rbp = 0 --- I'm running: FreeBSD universe.stevenschlansker.is-a-geek.org 7.0-CURRENT FreeBSD 7.0-CURRENT #1: Thu Jul 12 11:48:11 PDT 2007 root@universe.stevenschlansker.is-a-geek.org:/usr/obj/usr/src/sys/GENERIC amd64 Didn't do anything fancy - CVSup, buildworld buildkernel, install... Hope that helps someone track down a bug :) Steven Schlansker From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 05:30:11 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 48E5116A405 for ; Fri, 13 Jul 2007 05:30:11 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outM.internet-mail-service.net (outM.internet-mail-service.net [216.240.47.236]) by mx1.freebsd.org (Postfix) with ESMTP id 3563113C49D for ; Fri, 13 Jul 2007 05:30:11 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Thu, 12 Jul 2007 22:30:07 -0700 Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id 54226125ADB for ; Thu, 12 Jul 2007 22:30:07 -0700 (PDT) Message-ID: <46970DF7.3000803@elischer.org> Date: Thu, 12 Jul 2007 22:30:31 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) MIME-Version: 1.0 To: FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: crash in tty code in 6.1.. fixed since? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2007 05:30:11 -0000 Does this crash look familiar to anyone? It's in 6.1 unfortunatly.. #6 0xc069ca6a in calltrap () at ../../../i386/i386/exception.s:139 #7 0xc0587012 in ttymodem (tp=0xc6990800, flag=-1065963704) at ../../../kern/tty.c:1659 #8 0xc058b83e in ptcclose (dev=0x0, flags=7, fmt=8192, td=0xc6966d80) at linedisc.h:136 #9 0xc052bf77 in giant_close (dev=0xc7547c00, fflag=7, devtype=8192, td=0xc6966d80) at ../../../kern/kern_conf.c:266 #10 0xc051685f in devfs_close (ap=0xe706baa4) at ../../../fs/devfs/devfs_vnops.c:287 #11 0xc06c2a10 in VOP_CLOSE_APV (vop=0x0, a=0xc076af48) at vnode_if.c:426 #12 0xc05bf3ce in vn_close (vp=0xc764e550, flags=7, file_cred=0x0, td=0xc6966d80) at vnode_if.h:227 #13 0xc05c0212 in vn_closefile (fp=0xc7532510, td=0xc6966d80) at ../../../kern/vfs_vnops.c:852 #14 0xc0516887 in devfs_close_f (fp=0xc7532510, td=0xc6966d80) at ../../../fs/devfs/devfs_vnops.c:297 #15 0xc05361e8 in fdrop_locked (fp=0xc7532510, td=0xc6966d80) at file.h:289 #16 0xc0536135 in fdrop (fp=0xc7532510, td=0xc6966d80) at ../../../kern/kern_descrip.c:2122 #17 0xc05346d3 in closef (fp=0xc7532510, td=0xc6966d80) at ../../../kern/kern_descrip.c:1942 #18 0xc0533487 in fdfree (td=0xc6966d80) at ../../../kern/kern_descrip.c:1627 #19 0xc053cc88 in exit1 (td=0xc6966d80, rv=15) at ../../../kern/kern_exit.c:263 #20 0xc055b58b in sigexit (td=0xc6966d80, sig=15) at ../../../kern/kern_sig.c:2451 #21 0xc055b296 in postsig (sig=15) at ../../../kern/kern_sig.c:2326 #22 0xc0577fbe in ast (framep=0xe706bd38) at ../../../kern/subr_trap.c:266 #23 0xc069d3ad in doreti_ast () at ../../../i386/i386/exception.s:293 (kgdb) up #7 0xc0587012 in ttymodem (tp=0xc6990800, flag=-1065963704) at ../../../kern/tty.c:1659 1659 if (tp->t_session->s_leader) { Current language: auto; currently c (kgdb) list 1654 !ISSET(tp->t_cflag, CLOCAL)) { 1655 SET(tp->t_state, TS_ZOMBIE); 1656 CLR(tp->t_state, TS_CONNECTED); 1657 if (tp->t_session) { 1658 sx_slock(&proctree_lock); 1659 if (tp->t_session->s_leader) { 1660 struct proc *p; 1661 1662 p = tp->t_session->s_leader; 1663 PROC_LOCK(p); (kgdb) set print pretty (kgdb) p *tp $3 = { t_rawq = { c_cc = 0, [...] t_outcc = 119661, t_line = 0, t_dev = 0xc763fe00, t_mdev = 0x0, t_devunit = 0, t_state = 0, t_flags = 0, t_timeout = 300000, t_pgrp = 0x0, t_session = 0x0, t_sigio = 0x0, t_rsel = { si_thrlist = { tqe_next = 0x0, tqe_prev = 0x0 }, si_thread = 0x0, si_note = { [...] tp_session is NULL but it shouldn't have been able to have run that line (line 1659) if it had tested NULL 2 lines before.. this suggests a locking problem.. From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 05:40:00 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7C87416A401 for ; Fri, 13 Jul 2007 05:40:00 +0000 (UTC) (envelope-from eric@anholt.net) Received: from vonnegut.anholt.net (69-30-77-85.dq1sn.easystreet.com [69.30.77.85]) by mx1.freebsd.org (Postfix) with ESMTP id D380013C4BA for ; Fri, 13 Jul 2007 05:39:58 +0000 (UTC) (envelope-from eric@anholt.net) Received: from vonnegut.anholt.net (localhost [127.0.0.1]) by vonnegut.anholt.net (8.14.1/8.14.1) with ESMTP id l6CKuNNw061158; Thu, 12 Jul 2007 13:59:23 -0700 (PDT) (envelope-from eric@anholt.net) Received: (from anholt@localhost) by vonnegut.anholt.net (8.14.1/8.14.1/Submit) id l6CKtgMn060643; Thu, 12 Jul 2007 13:55:42 -0700 (PDT) (envelope-from eric@anholt.net) X-Authentication-Warning: vonnegut.anholt.net: anholt set sender to eric@anholt.net using -f From: Eric Anholt To: re@freebsd.org, current@freebsd.org Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-AXWcD71UA0EuCnCMobb0" Date: Thu, 12 Jul 2007 13:55:31 -0700 Message-Id: <1184273731.44469.16.camel@vonnegut> Mime-Version: 1.0 X-Mailer: Evolution 2.10.2 FreeBSD GNOME Team Port Cc: Subject: request for approval: G965 AGP support X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2007 05:40:00 -0000 --=-AXWcD71UA0EuCnCMobb0 Content-Type: multipart/mixed; boundary="=-5YELsow3Fpr9UE+T3E/E" --=-5YELsow3Fpr9UE+T3E/E Content-Type: text/plain Content-Transfer-Encoding: quoted-printable I think I've finally got my G965 AGP support ready to commit. I've tested on the GM965 and in a previous version the 915GM, and with kib@'s DRM fix things are looking good. Proposed commit message: Add support for G965/Q965/GM965/GME965/GME945 AGP. This adds a function to agp.c to set the aperture resource ID if it's not the usual AGP_APBASE. Previously, agp.c had been assuming AGP_APBASE, which resulted in incorrect agp_info, and contortions by agp_i810.c to work around it. Also, add functions to agp.c for default AGP_GET_APERTURE() and AGP_SET_APERTURE(), which return the aperture resource size and disallow aperture size changes. Moving to these for our AGP drivers will likely result in stability improvements. This should fix 855-class aperture size detection. Additionally, refuse to attach agp_i810 when some RAM is above 4GB and the GART can't reference memory that high. This should be very rare. The correct solution would be bus_dma conversion for agp, which is beyond the scope of this change. Other AGP drivers could likely use this change as well. G33/Q35/Q33 AGP support is also included, but disconnected by default due to lack of testing. PR: kern/109724 (855 aperture issue) Submitted by: FUJIMOTO Kou --=20 Eric Anholt anholt@FreeBSD.org eric@anholt.net eric.anholt@intel.com --=-5YELsow3Fpr9UE+T3E/E Content-Disposition: attachment; filename=agp-i965-6.diff Content-Type: text/x-patch; name=agp-i965-6.diff; charset=UTF-8 Content-Transfer-Encoding: base64 SW5kZXg6IGFncC5jDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09DQpSQ1MgZmlsZTogL2hvbWUvbmN2cy9zcmMvc3lzL3Bj aS9hZ3AuYyx2DQpyZXRyaWV2aW5nIHJldmlzaW9uIDEuNTUNCmRpZmYgLXUgLXIxLjU1IGFncC5j DQotLS0gYWdwLmMJMjIgT2N0IDIwMDYgMjE6MTg6NDggLTAwMDAJMS41NQ0KKysrIGFncC5jCTEy IEp1bCAyMDA3IDE4OjE1OjQ2IC0wMDAwDQpAQCAtMTkzLDE4ICsxOTMsMzYgQEANCiB9Ow0KICNk ZWZpbmUgYWdwX21heF9zaXplCShzaXplb2YoYWdwX21heCkgLyBzaXplb2YoYWdwX21heFswXSkp DQogDQorLyoqDQorICogU2V0cyB0aGUgUENJIHJlc291cmNlIHdoaWNoIHJlcHJlc2VudHMgdGhl IEFHUCBhcGVydHVyZS4NCisgKg0KKyAqIElmIG5vdCBjYWxsZWQsIHRoZSBkZWZhdWx0IEFHUCBh cGVydHVyZSBiYXNlIHJlc291cmNlIG9mIEFHUF9BUEJBU0Ugd2lsbA0KKyAqIGJlIHVzZWQuICBN dXN0IGJlIGNhbGxlZCBiZWZvcmUgYWdwX2dlbmVyaWNfYXR0YWNoKCkuDQorICovDQordm9pZA0K K2FncF9zZXRfYXBlcnR1cmVfcmVzb3VyY2UoZGV2aWNlX3QgZGV2LCBpbnQgcmlkKQ0KK3sNCisJ c3RydWN0IGFncF9zb2Z0YyAqc2MgPSBkZXZpY2VfZ2V0X3NvZnRjKGRldik7DQorDQorCXNjLT5h c19hcGVydHVyZV9yaWQgPSByaWQ7DQorfQ0KKw0KIGludA0KIGFncF9nZW5lcmljX2F0dGFjaChk ZXZpY2VfdCBkZXYpDQogew0KIAlzdHJ1Y3QgYWdwX3NvZnRjICpzYyA9IGRldmljZV9nZXRfc29m dGMoZGV2KTsNCi0JaW50IHJpZCwgaTsNCisJaW50IGk7DQogCXVfaW50IG1lbXNpemU7DQogDQog CS8qDQotCSAqIEZpbmQgYW5kIG1hcCB0aGUgYXBlcnR1cmUuDQorCSAqIEZpbmQgYW5kIG1hcCB0 aGUgYXBlcnR1cmUsIFJGX1NIQVJFQUJMRSBmb3IgRFJNIGJ1dCBub3QgUkZfQUNUSVZFDQorCSAq IGJlY2F1c2UgdGhlIGtlcm5lbCBkb2Vzbid0IG5lZWQgdG8gbWFwIGl0Lg0KIAkgKi8NCi0Jcmlk ID0gQUdQX0FQQkFTRTsNCi0Jc2MtPmFzX2FwZXJ0dXJlID0gYnVzX2FsbG9jX3Jlc291cmNlX2Fu eShkZXYsIFNZU19SRVNfTUVNT1JZLCAmcmlkLCAwKTsNCisJaWYgKHNjLT5hc19hcGVydHVyZV9y aWQgPT0gMCkNCisJCXNjLT5hc19hcGVydHVyZV9yaWQgPSBBR1BfQVBCQVNFOw0KKw0KKwlzYy0+ YXNfYXBlcnR1cmUgPSBidXNfYWxsb2NfcmVzb3VyY2VfYW55KGRldiwgU1lTX1JFU19NRU1PUlks DQorCSAgICAmc2MtPmFzX2FwZXJ0dXJlX3JpZCwgUkZfU0hBUkVBQkxFKTsNCiAJaWYgKCFzYy0+ YXNfYXBlcnR1cmUpDQogCQlyZXR1cm4gRU5PTUVNOw0KIA0KQEAgLTI0OSwxMiArMjY3LDQxIEBA DQogCXN0cnVjdCBhZ3Bfc29mdGMgKnNjID0gZGV2aWNlX2dldF9zb2Z0YyhkZXYpOw0KIA0KIAlk ZXN0cm95X2RldihzYy0+YXNfZGV2bm9kZSk7DQotCWJ1c19yZWxlYXNlX3Jlc291cmNlKGRldiwg U1lTX1JFU19NRU1PUlksIEFHUF9BUEJBU0UsIHNjLT5hc19hcGVydHVyZSk7DQorCWJ1c19yZWxl YXNlX3Jlc291cmNlKGRldiwgU1lTX1JFU19NRU1PUlksIHNjLT5hc19hcGVydHVyZV9yaWQsDQor CSAgICBzYy0+YXNfYXBlcnR1cmUpOw0KIAltdHhfZGVzdHJveSgmc2MtPmFzX2xvY2spOw0KIAlh Z3BfZmx1c2hfY2FjaGUoKTsNCiAJcmV0dXJuIDA7DQogfQ0KIA0KKy8qKg0KKyAqIERlZmF1bHQg QUdQIGFwZXJ0dXJlIHNpemUgZGV0ZWN0aW9uIHdoaWNoIHNpbXBseSByZXR1cm5zIHRoZSBzaXpl IG9mDQorICogdGhlIGFwZXJ0dXJlJ3MgUENJIHJlc291cmNlLg0KKyAqLw0KK2ludA0KK2FncF9n ZW5lcmljX2dldF9hcGVydHVyZShkZXZpY2VfdCBkZXYpDQorew0KKwlzdHJ1Y3QgYWdwX3NvZnRj ICpzYyA9IGRldmljZV9nZXRfc29mdGMoZGV2KTsNCisNCisJcmV0dXJuIHJtYW5fZ2V0X3NpemUo c2MtPmFzX2FwZXJ0dXJlKTsNCit9DQorDQorLyoqDQorICogRGVmYXVsdCBBR1AgYXBlcnR1cmUg c2l6ZSBzZXR0aW5nIGZ1bmN0aW9uLCB3aGljaCBzaW1wbHkgZG9lc24ndCBhbGxvdw0KKyAqIGNo YW5nZXMgdG8gcmVzb3VyY2Ugc2l6ZS4NCisgKi8NCitpbnQNCithZ3BfZ2VuZXJpY19zZXRfYXBl cnR1cmUoZGV2aWNlX3QgZGV2LCB1X2ludDMyX3QgYXBlcnR1cmUpDQorew0KKwl1X2ludDMyX3Qg Y3VycmVudF9hcGVydHVyZTsNCisNCisJY3VycmVudF9hcGVydHVyZSA9IEFHUF9HRVRfQVBFUlRV UkUoZGV2KTsNCisJaWYgKGN1cnJlbnRfYXBlcnR1cmUgIT0gYXBlcnR1cmUpDQorCQlyZXR1cm4g RUlOVkFMOw0KKwllbHNlDQorCQlyZXR1cm4gMDsNCit9DQorDQogLyoNCiAgKiBUaGlzIGRvZXMg dGhlIGVuYWJsZSBsb2dpYyBmb3IgdjMsIHdpdGggdGhlIHNhbWUgdG9wb2xvZ3kNCiAgKiByZXN0 cmljdGlvbnMgYXMgaW4gcGxhY2UgZm9yIHYyIC0tIG9uZSBidXMsIG9uZSBkZXZpY2Ugb24gdGhl IGJ1cy4NCkluZGV4OiBhZ3BfaTgxMC5jDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQpSQ1MgZmlsZTogL2hvbWUvbmN2 cy9zcmMvc3lzL3BjaS9hZ3BfaTgxMC5jLHYNCnJldHJpZXZpbmcgcmV2aXNpb24gMS4zOQ0KZGlm ZiAtdSAtcjEuMzkgYWdwX2k4MTAuYw0KLS0tIGFncF9pODEwLmMJMjcgU2VwIDIwMDYgMDY6Mzg6 NTQgLTAwMDAJMS4zOQ0KKysrIGFncF9pODEwLmMJMTIgSnVsIDIwMDcgMTg6Mjg6MjEgLTAwMDAN CkBAIC01OCwxOSArNTgsNDEgQEANCiANCiAjaW5jbHVkZSA8bWFjaGluZS9idXMuaD4NCiAjaW5j bHVkZSA8bWFjaGluZS9yZXNvdXJjZS5oPg0KKyNpbmNsdWRlIDxtYWNoaW5lL21kX3Zhci5oPg0K ICNpbmNsdWRlIDxzeXMvcm1hbi5oPg0KIA0KIE1BTExPQ19ERUNMQVJFKE1fQUdQKTsNCiANCi0j ZGVmaW5lIFJFQUQxKG9mZikJYnVzX3NwYWNlX3JlYWRfMShzYy0+YnN0LCBzYy0+YnNoLCBvZmYp DQotI2RlZmluZSBSRUFENChvZmYpCWJ1c19zcGFjZV9yZWFkXzQoc2MtPmJzdCwgc2MtPmJzaCwg b2ZmKQ0KLSNkZWZpbmUgV1JJVEU0KG9mZix2KQlidXNfc3BhY2Vfd3JpdGVfNChzYy0+YnN0LCBz Yy0+YnNoLCBvZmYsIHYpDQotI2RlZmluZSBXUklURUdUVChvZmYsdikJYnVzX3NwYWNlX3dyaXRl XzQoc2MtPmd0dF9ic3QsIHNjLT5ndHRfYnNoLCBvZmYsIHYpDQotDQotI2RlZmluZSBDSElQX0k4 MTAgMAkvKiBpODEwL2k4MTUgKi8NCi0jZGVmaW5lIENISVBfSTgzMCAxCS8qIDgzME0vODQ1RyAq Lw0KLSNkZWZpbmUgQ0hJUF9JODU1IDIJLyogODUyR00vODU1R00vODY1RyAqLw0KLSNkZWZpbmUg Q0hJUF9JOTE1IDMJLyogOTE1Ry85MTVHTSAqLw0KK2VudW0gew0KKwlDSElQX0k4MTAsCS8qIGk4 MTAvaTgxNSAqLw0KKwlDSElQX0k4MzAsCS8qIDgzME0vODQ1RyAqLw0KKwlDSElQX0k4NTUsCS8q IDg1MkdNLzg1NUdNLzg2NUcgKi8NCisJQ0hJUF9JOTE1LAkvKiA5MTVHLzkxNUdNICovDQorCUNI SVBfSTk2NSwJLyogRzk2NSAqLw0KKwlDSElQX0czMywJLyogRzMzL1EzMy9RMzUgKi8NCit9Ow0K Kw0KKy8qIFRoZSBpODEwIHRocm91Z2ggaTg1NSBoYXZlIHRoZSByZWdpc3RlcnMgYXQgQkFSIDEs IGFuZCB0aGUgR0FUVCBnZXRzDQorICogYWxsb2NhdGVkIGJ5IHVzLiAgVGhlIGk5MTUgaGFzIHJl Z2lzdGVycyBpbiBCQVIgMCBhbmQgdGhlIEdBVFQgaXMgYXQgdGhlDQorICogc3RhcnQgb2YgdGhl IHN0b2xlbiBtZW1vcnksIGFuZCBzaG91bGQgb25seSBiZSBhY2Nlc3NlZCBieSB0aGUgT1MgdGhy b3VnaA0KKyAqIEJBUiAzLiAgVGhlIEc5NjUgaGFzIHJlZ2lzdGVycyBhbmQgR0FUVCBpbiB0aGUg c2FtZSBCQVIgKDApIC0tIGZpcnN0IDUxMktCDQorICogaXMgcmVnaXN0ZXJzLCBzZWNvbmQgNTEy S0IgaXMgR0FUVC4NCisgKi8NCitzdGF0aWMgc3RydWN0IHJlc291cmNlX3NwZWMgYWdwX2k4MTBf cmVzX3NwZWNbXSA9IHsNCisJeyBTWVNfUkVTX01FTU9SWSwgQUdQX0k4MTBfTU1BRFIsIFJGX0FD VElWRSB8IFJGX1NIQVJFQUJMRSB9LA0KKwl7IC0xLCAwIH0NCit9Ow0KKw0KK3N0YXRpYyBzdHJ1 Y3QgcmVzb3VyY2Vfc3BlYyBhZ3BfaTkxNV9yZXNfc3BlY1tdID0gew0KKwl7IFNZU19SRVNfTUVN T1JZLCBBR1BfSTkxNV9NTUFEUiwgUkZfQUNUSVZFIHwgUkZfU0hBUkVBQkxFIH0sDQorCXsgU1lT X1JFU19NRU1PUlksIEFHUF9JOTE1X0dUVEFEUiwgUkZfQUNUSVZFIHwgUkZfU0hBUkVBQkxFIH0s DQorCXsgLTEsIDAgfQ0KK307DQorDQorc3RhdGljIHN0cnVjdCByZXNvdXJjZV9zcGVjIGFncF9p OTY1X3Jlc19zcGVjW10gPSB7DQorCXsgU1lTX1JFU19NRU1PUlksIEFHUF9JOTY1X0dUVE1NQURS LCBSRl9BQ1RJVkUgfCBSRl9TSEFSRUFCTEUgfSwNCisJeyAtMSwgMCB9DQorfTsNCiANCiBzdHJ1 Y3QgYWdwX2k4MTBfc29mdGMgew0KIAlzdHJ1Y3QgYWdwX3NvZnRjIGFncDsNCkBAIC04MSwxNyAr MTAzLDEwIEBADQogCXVfaW50MzJfdCBzdG9sZW47CQkvKiBudW1iZXIgb2YgaTgzMC84NDUgZ3R0 IGVudHJpZXMgZm9yIHN0b2xlbiBtZW1vcnkgKi8NCiAJZGV2aWNlX3QgYmRldjsJCQkvKiBicmlk Z2UgZGV2aWNlICovDQogDQotCXN0cnVjdCByZXNvdXJjZSAqcmVnczsJCS8qIG1lbW9yeSBtYXBw ZWQgR0MgcmVnaXN0ZXJzICovDQotCWJ1c19zcGFjZV90YWdfdCBic3Q7CQkvKiBidXNfc3BhY2Ug dGFnICovDQotCWJ1c19zcGFjZV9oYW5kbGVfdCBic2g7CQkvKiBidXNfc3BhY2UgaGFuZGxlICov DQotDQotCXN0cnVjdCByZXNvdXJjZSAqZ3R0OwkJLyogbWVtb3J5IG1hcHBlZCBHQVRUIGVudHJp ZXMgKi8NCi0JYnVzX3NwYWNlX3RhZ190IGd0dF9ic3Q7CS8qIGJ1c19zcGFjZSB0YWcgKi8NCi0J YnVzX3NwYWNlX2hhbmRsZV90IGd0dF9ic2g7CS8qIGJ1c19zcGFjZSBoYW5kbGUgKi8NCi0NCi0J c3RydWN0IHJlc291cmNlICpnbTsJCS8qIHVubWFwcGVkIChidXQgYWxsb2NhdGVkKSBhcGVydHVy ZSAqLw0KLQ0KIAl2b2lkICphcmdiX2N1cnNvcjsJCS8qIGNvbnRpZ21hbGxvYyBhcmVhIGZvciBB UkdCIGN1cnNvciAqLw0KKw0KKwlzdHJ1Y3QgcmVzb3VyY2Vfc3BlYyAqIHNjX3Jlc19zcGVjOw0K KwlzdHJ1Y3QgcmVzb3VyY2UgKnNjX3Jlc1syXTsNCiB9Ow0KIA0KIC8qIEZvciBhZGRpbmcgbmV3 IGRldmljZXMsIGRldmlkIGlzIHRoZSBpZCBvZiB0aGUgZ3JhcGhpY3MgY29udHJvbGxlcg0KQEAg LTEyNyw2ICsxNDIsMjggQEANCiAJICAgICJJbnRlbCA4Mjk0NUcgKDk0NUcgR01DSCkgU1ZHQSBj b250cm9sbGVyIn0sDQogCXsweDI3QTI4MDg2LCBDSElQX0k5MTUsIDB4MDAwMjAwMDAsDQogCSAg ICAiSW50ZWwgODI5NDVHTSAoOTQ1R00gR01DSCkgU1ZHQSBjb250cm9sbGVyIn0sDQorCXsweDI3 QTI4MDg2LCBDSElQX0k5MTUsIDB4MDAwMjAwMDAsDQorCSAgICAiSW50ZWwgOTQ1R01FIFNWR0Eg Y29udHJvbGxlciJ9LA0KKwl7MHgyOTcyODA4NiwgQ0hJUF9JOTY1LCAweDAwMDIwMDAwLA0KKwkg ICAgIkludGVsIDk0NkdaIFNWR0EgY29udHJvbGxlciJ9LA0KKwl7MHgyOTgyODA4NiwgQ0hJUF9J OTY1LCAweDAwMDIwMDAwLA0KKwkgICAgIkludGVsIEc5NjUgU1ZHQSBjb250cm9sbGVyIn0sDQor CXsweDI5OTI4MDg2LCBDSElQX0k5NjUsIDB4MDAwMjAwMDAsDQorCSAgICAiSW50ZWwgUTk2NSBT VkdBIGNvbnRyb2xsZXIifSwNCisJezB4MjlhMjgwODYsIENISVBfSTk2NSwgMHgwMDAyMDAwMCwN CisJICAgICJJbnRlbCBHOTY1IFNWR0EgY29udHJvbGxlciJ9LA0KKy8qDQorCXsweDI5YjI4MDg2 LCBDSElQX0czMywgMHgwMDAyMDAwMCwNCisJICAgICJJbnRlbCBRMzUgU1ZHQSBjb250cm9sbGVy In0sDQorCXsweDI5YzI4MDg2LCBDSElQX0czMywgMHgwMDAyMDAwMCwNCisJICAgICJJbnRlbCBH MzMgU1ZHQSBjb250cm9sbGVyIn0sDQorCXsweDI5ZDI4MDg2LCBDSElQX0czMywgMHgwMDAyMDAw MCwNCisJICAgICJJbnRlbCBRMzMgU1ZHQSBjb250cm9sbGVyIn0sDQorKi8NCisJezB4MmEwMjgw ODYsIENISVBfSTk2NSwgMHgwMDAyMDAwMCwNCisJICAgICJJbnRlbCBHTTk2NSBTVkdBIGNvbnRy b2xsZXIifSwNCisJezB4MmExMjgwODYsIENISVBfSTk2NSwgMHgwMDAyMDAwMCwNCisJICAgICJJ bnRlbCBHTUU5NjUgU1ZHQSBjb250cm9sbGVyIn0sDQogCXswLCAwLCAwLCBOVUxMfQ0KIH07DQog DQpAQCAtMTk0LDYgKzIzMSw4IEBADQogew0KIAlkZXZpY2VfdCBiZGV2Ow0KIAljb25zdCBzdHJ1 Y3QgYWdwX2k4MTBfbWF0Y2ggKm1hdGNoOw0KKwl1X2ludDhfdCBzbXJhbTsNCisJaW50IGdjYzEs IGRldmVuOw0KIA0KIAlpZiAocmVzb3VyY2VfZGlzYWJsZWQoImFncCIsIGRldmljZV9nZXRfdW5p dChkZXYpKSkNCiAJCXJldHVybiAoRU5YSU8pOw0KQEAgLTIxMSwyMCArMjUwLDE4IEBADQogCS8q DQogCSAqIGNoZWNraW5nIHdoZXRoZXIgaW50ZXJuYWwgZ3JhcGhpY3MgZGV2aWNlIGhhcyBiZWVu IGFjdGl2YXRlZC4NCiAJICovDQotCWlmIChtYXRjaC0+Y2hpcHR5cGUgPT0gQ0hJUF9JODEwKSB7 DQotCQl1X2ludDhfdCBzbXJhbTsNCi0NCisJc3dpdGNoIChtYXRjaC0+Y2hpcHR5cGUpIHsNCisJ Y2FzZSBDSElQX0k4MTA6DQogCQlzbXJhbSA9IHBjaV9yZWFkX2NvbmZpZyhiZGV2LCBBR1BfSTgx MF9TTVJBTSwgMSk7DQotCQlpZiAoKHNtcmFtICYgQUdQX0k4MTBfU01SQU1fR01TKQ0KLQkJICAg ID09IEFHUF9JODEwX1NNUkFNX0dNU19ESVNBQkxFRCkgew0KKwkJaWYgKChzbXJhbSAmIEFHUF9J ODEwX1NNUkFNX0dNUykgPT0NCisJCSAgICBBR1BfSTgxMF9TTVJBTV9HTVNfRElTQUJMRUQpIHsN CiAJCQlpZiAoYm9vdHZlcmJvc2UpDQogCQkJCXByaW50ZigiSTgxMDogZGlzYWJsZWQsIG5vdCBw cm9iaW5nXG4iKTsNCiAJCQlyZXR1cm4gRU5YSU87DQogCQl9DQotCX0gZWxzZSBpZiAobWF0Y2gt PmNoaXB0eXBlID09IENISVBfSTgzMCB8fA0KLQkgICAgbWF0Y2gtPmNoaXB0eXBlID09IENISVBf STg1NSkgew0KLQkJdW5zaWduZWQgaW50IGdjYzE7DQotDQorCQlicmVhazsNCisJY2FzZSBDSElQ X0k4MzA6DQorCWNhc2UgQ0hJUF9JODU1Og0KIAkJZ2NjMSA9IHBjaV9yZWFkX2NvbmZpZyhiZGV2 LCBBR1BfSTgzMF9HQ0MxLCAxKTsNCiAJCWlmICgoZ2NjMSAmIEFHUF9JODMwX0dDQzFfREVWMikg PT0NCiAJCSAgICBBR1BfSTgzMF9HQ0MxX0RFVjJfRElTQUJMRUQpIHsNCkBAIC0yMzIsMTYgKzI2 OSwxOCBAQA0KIAkJCQlwcmludGYoIkk4MzA6IGRpc2FibGVkLCBub3QgcHJvYmluZ1xuIik7DQog CQkJcmV0dXJuIEVOWElPOw0KIAkJfQ0KLQl9IGVsc2UgaWYgKG1hdGNoLT5jaGlwdHlwZSA9PSBD SElQX0k5MTUpIHsNCi0JCXVuc2lnbmVkIGludCBnY2MxOw0KLQ0KLQkJZ2NjMSA9IHBjaV9yZWFk X2NvbmZpZyhiZGV2LCBBR1BfSTkxNV9ERVZFTiwgNCk7DQotCQlpZiAoKGdjYzEgJiBBR1BfSTkx NV9ERVZFTl9EMkYwKSA9PQ0KKwkJYnJlYWs7DQorCWNhc2UgQ0hJUF9JOTE1Og0KKwljYXNlIENI SVBfSTk2NToNCisJY2FzZSBDSElQX0czMzoNCisJCWRldmVuID0gcGNpX3JlYWRfY29uZmlnKGJk ZXYsIEFHUF9JOTE1X0RFVkVOLCA0KTsNCisJCWlmICgoZGV2ZW4gJiBBR1BfSTkxNV9ERVZFTl9E MkYwKSA9PQ0KIAkJICAgIEFHUF9JOTE1X0RFVkVOX0QyRjBfRElTQUJMRUQpIHsNCiAJCQlpZiAo Ym9vdHZlcmJvc2UpDQogCQkJCXByaW50ZigiSTkxNTogZGlzYWJsZWQsIG5vdCBwcm9iaW5nXG4i KTsNCiAJCQlyZXR1cm4gRU5YSU87DQogCQl9DQorCQlicmVhazsNCiAJfQ0KIA0KIAlpZiAobWF0 Y2gtPmRldmlkID09IDB4MzU4MjgwODYpIHsNCkBAIC0yNzQsNzYgKzMxMyw5NSBAQA0KIAlyZXR1 cm4gQlVTX1BST0JFX0RFRkFVTFQ7DQogfQ0KIA0KK3N0YXRpYyB2b2lkDQorYWdwX2k4MTBfZHVt cF9yZWdzKGRldmljZV90IGRldikNCit7DQorCXN0cnVjdCBhZ3BfaTgxMF9zb2Z0YyAqc2MgPSBk ZXZpY2VfZ2V0X3NvZnRjKGRldik7DQorDQorCWRldmljZV9wcmludGYoZGV2LCAiQUdQX0k4MTBf UEdUQkxfQ1RMOiAlMDh4XG4iLA0KKwkgICAgYnVzX3JlYWRfNChzYy0+c2NfcmVzWzBdLCBBR1Bf STgxMF9QR1RCTF9DVEwpKTsNCisNCisJc3dpdGNoIChzYy0+Y2hpcHR5cGUpIHsNCisJY2FzZSBD SElQX0k4MTA6DQorCQlkZXZpY2VfcHJpbnRmKGRldiwgIkFHUF9JODEwX01JU0NDOiAweCUwNHhc biIsDQorCQkgICAgcGNpX3JlYWRfY29uZmlnKHNjLT5iZGV2LCBBR1BfSTgxMF9NSVNDQywgMikp Ow0KKwkJYnJlYWs7DQorCWNhc2UgQ0hJUF9JODMwOg0KKwkJZGV2aWNlX3ByaW50ZihkZXYsICJB R1BfSTgzMF9HQ0MxOiAweCUwMnhcbiIsDQorCQkgICAgcGNpX3JlYWRfY29uZmlnKHNjLT5iZGV2 LCBBR1BfSTgzMF9HQ0MxLCAxKSk7DQorCQlicmVhazsNCisJY2FzZSBDSElQX0k4NTU6DQorCQlk ZXZpY2VfcHJpbnRmKGRldiwgIkFHUF9JODU1X0dDQzE6IDB4JTAyeFxuIiwNCisJCSAgICBwY2lf cmVhZF9jb25maWcoc2MtPmJkZXYsIEFHUF9JODU1X0dDQzEsIDEpKTsNCisJCWJyZWFrOw0KKwlj YXNlIENISVBfSTkxNToNCisJY2FzZSBDSElQX0k5NjU6DQorCWNhc2UgQ0hJUF9HMzM6DQorCQlk ZXZpY2VfcHJpbnRmKGRldiwgIkFHUF9JODU1X0dDQzE6IDB4JTAyeFxuIiwNCisJCSAgICBwY2lf cmVhZF9jb25maWcoc2MtPmJkZXYsIEFHUF9JODU1X0dDQzEsIDEpKTsNCisJCWRldmljZV9wcmlu dGYoZGV2LCAiQUdQX0k5MTVfTVNBQzogMHglMDJ4XG4iLA0KKwkJICAgIHBjaV9yZWFkX2NvbmZp ZyhzYy0+YmRldiwgQUdQX0k5MTVfTVNBQywgMSkpOw0KKwkJYnJlYWs7DQorCX0NCisJZGV2aWNl X3ByaW50ZihkZXYsICJBcGVydHVyZSByZXNvdXJjZSBzaXplOiAlZCBieXRlc1xuIiwNCisJICAg IEFHUF9HRVRfQVBFUlRVUkUoZGV2KSk7DQorfQ0KKw0KIHN0YXRpYyBpbnQNCiBhZ3BfaTgxMF9h dHRhY2goZGV2aWNlX3QgZGV2KQ0KIHsNCiAJc3RydWN0IGFncF9pODEwX3NvZnRjICpzYyA9IGRl dmljZV9nZXRfc29mdGMoZGV2KTsNCiAJc3RydWN0IGFncF9nYXR0ICpnYXR0Ow0KIAljb25zdCBz dHJ1Y3QgYWdwX2k4MTBfbWF0Y2ggKm1hdGNoOw0KLQlpbnQgZXJyb3IsIHJpZDsNCisJaW50IGVy cm9yOw0KIA0KIAlzYy0+YmRldiA9IGFncF9pODEwX2ZpbmRfYnJpZGdlKGRldik7DQogCWlmICgh c2MtPmJkZXYpDQogCQlyZXR1cm4gRU5PRU5UOw0KIA0KKwltYXRjaCA9IGFncF9pODEwX21hdGNo KGRldik7DQorCXNjLT5jaGlwdHlwZSA9IG1hdGNoLT5jaGlwdHlwZTsNCisNCisJc3dpdGNoIChz Yy0+Y2hpcHR5cGUpIHsNCisJY2FzZSBDSElQX0k4MTA6DQorCWNhc2UgQ0hJUF9JODMwOg0KKwlj YXNlIENISVBfSTg1NToNCisJCXNjLT5zY19yZXNfc3BlYyA9IGFncF9pODEwX3Jlc19zcGVjOw0K KwkJYWdwX3NldF9hcGVydHVyZV9yZXNvdXJjZShkZXYsIEFHUF9BUEJBU0UpOw0KKwkJYnJlYWs7 DQorCWNhc2UgQ0hJUF9JOTE1Og0KKwljYXNlIENISVBfRzMzOg0KKwkJc2MtPnNjX3Jlc19zcGVj ID0gYWdwX2k5MTVfcmVzX3NwZWM7DQorCQlhZ3Bfc2V0X2FwZXJ0dXJlX3Jlc291cmNlKGRldiwg QUdQX0k5MTVfR01BRFIpOw0KKwkJYnJlYWs7DQorCWNhc2UgQ0hJUF9JOTY1Og0KKwkJc2MtPnNj X3Jlc19zcGVjID0gYWdwX2k5NjVfcmVzX3NwZWM7DQorCQlhZ3Bfc2V0X2FwZXJ0dXJlX3Jlc291 cmNlKGRldiwgQUdQX0k5MTVfR01BRFIpOw0KKwkJYnJlYWs7DQorCX0NCisNCiAJZXJyb3IgPSBh Z3BfZ2VuZXJpY19hdHRhY2goZGV2KTsNCiAJaWYgKGVycm9yKQ0KIAkJcmV0dXJuIGVycm9yOw0K IA0KLQltYXRjaCA9IGFncF9pODEwX21hdGNoKGRldik7DQotCXNjLT5jaGlwdHlwZSA9IG1hdGNo LT5jaGlwdHlwZTsNCi0NCi0JLyogU2FtZSBmb3IgaTgxMCBhbmQgaTgzMCAqLw0KLQlpZiAoc2Mt PmNoaXB0eXBlID09IENISVBfSTkxNSkNCi0JCXJpZCA9IEFHUF9JOTE1X01NQURSOw0KLQllbHNl DQotCQlyaWQgPSBBR1BfSTgxMF9NTUFEUjsNCisJaWYgKHNjLT5jaGlwdHlwZSAhPSBDSElQX0k5 NjUgJiYgc2MtPmNoaXB0eXBlICE9IENISVBfRzMzICYmDQorCSAgICBwdG9hKCh2bV9wYWRkcl90 KU1heG1lbSkgPiAweGZmZmZmZmZmdWwpDQorCXsNCisJCWRldmljZV9wcmludGYoZGV2LCAiYWdw X2k4MTAuYyBkb2VzIG5vdCBzdXBwb3J0IHBoeXNpY2FsICINCisJCSAgICAibWVtb3J5IGFib3Zl IDRHQi5cbiIpOw0KKwkJcmV0dXJuIEVOT0VOVDsNCisJfQ0KIA0KLQlzYy0+cmVncyA9IGJ1c19h bGxvY19yZXNvdXJjZV9hbnkoZGV2LCBTWVNfUkVTX01FTU9SWSwgJnJpZCwNCi0JCQkJCSAgUkZf QUNUSVZFKTsNCi0JaWYgKCFzYy0+cmVncykgew0KKwlpZiAoYnVzX2FsbG9jX3Jlc291cmNlcyhk ZXYsIHNjLT5zY19yZXNfc3BlYywgc2MtPnNjX3JlcykpIHsNCiAJCWFncF9nZW5lcmljX2RldGFj aChkZXYpOw0KIAkJcmV0dXJuIEVOT0RFVjsNCiAJfQ0KLQlzYy0+YnN0ID0gcm1hbl9nZXRfYnVz dGFnKHNjLT5yZWdzKTsNCi0Jc2MtPmJzaCA9IHJtYW5fZ2V0X2J1c2hhbmRsZShzYy0+cmVncyk7 DQotDQotCWlmIChzYy0+Y2hpcHR5cGUgPT0gQ0hJUF9JOTE1KSB7DQotCQlyaWQgPSBBR1BfSTkx NV9HVFRBRFI7DQotCQlzYy0+Z3R0ID0gYnVzX2FsbG9jX3Jlc291cmNlX2FueShkZXYsIFNZU19S RVNfTUVNT1JZLCAmcmlkLA0KLQkJCQkJCSBSRl9BQ1RJVkUpOw0KLQkJaWYgKCFzYy0+Z3R0KSB7 DQotCQkJYnVzX3JlbGVhc2VfcmVzb3VyY2UoZGV2LCBTWVNfUkVTX01FTU9SWSwNCi0JCQkJCSAg ICAgQUdQX0k5MTVfTU1BRFIsIHNjLT5yZWdzKTsNCi0JCQlhZ3BfZ2VuZXJpY19kZXRhY2goZGV2 KTsNCi0JCQlyZXR1cm4gRU5PREVWOw0KLQkJfQ0KLQkJc2MtPmd0dF9ic3QgPSBybWFuX2dldF9i dXN0YWcoc2MtPmd0dCk7DQotCQlzYy0+Z3R0X2JzaCA9IHJtYW5fZ2V0X2J1c2hhbmRsZShzYy0+ Z3R0KTsNCi0NCi0JCS8qIFdoaWxlIGFncF9nZW5lcmljX2F0dGFjaCBhbGxvY2F0ZXMgdGhlIEFH UF9BUEJBU0UgcmVzb3VyY2UNCi0JCSAqIHRvIHRyeSB0byByZXNlcnZlIHRoZSBhcGVydHVyZSwg b24gdGhlIDkxNSB0aGUgYXBlcnR1cmUNCi0JCSAqIGlzbid0IGluIFBDSVJfQkFSKDApLCBpdCdz IGluIFBDSVJfQkFSKDIpLCBzbyBpdCBhbGxvY2F0ZWQNCi0JCSAqIHRoZSByZWdpc3RlcnMgdGhh dCB3ZSBqdXN0IG1hcHBlZCBhbnl3YXkuICBTbywgYWxsb2NhdGUgdGhlDQotCQkgKiBhcGVydHVy ZSBoZXJlLCB3aGljaCBhbHNvIGdpdmVzIHVzIGVhc3kgYWNjZXNzIHRvIGl0IGZvciB0aGUNCi0J CSAqIGFncF9pODEwX2dldF9hcGVydHVyZSgpLg0KLQkJICovDQotCQlyaWQgPSBBR1BfSTkxNV9H TUFEUjsNCi0JCXNjLT5nbSA9IGJ1c19hbGxvY19yZXNvdXJjZV9hbnkoZGV2LCBTWVNfUkVTX01F TU9SWSwgJnJpZCwgMCk7DQotCQlpZiAoc2MtPmdtID09IE5VTEwpIHsNCi0JCQlidXNfcmVsZWFz ZV9yZXNvdXJjZShkZXYsIFNZU19SRVNfTUVNT1JZLA0KLQkJCQkJICAgICBBR1BfSTkxNV9NTUFE Uiwgc2MtPnJlZ3MpOw0KLQkJCWJ1c19yZWxlYXNlX3Jlc291cmNlKGRldiwgU1lTX1JFU19NRU1P UlksDQotCQkJCQkgICAgIEFHUF9JOTE1X0dUVEFEUiwgc2MtPnJlZ3MpOw0KLQkJCWFncF9nZW5l cmljX2RldGFjaChkZXYpOw0KLQkJCXJldHVybiBFTk9ERVY7DQotCQl9DQotCX0NCiANCiAJc2Mt PmluaXRpYWxfYXBlcnR1cmUgPSBBR1BfR0VUX0FQRVJUVVJFKGRldik7DQogDQogCWdhdHQgPSBt YWxsb2MoIHNpemVvZihzdHJ1Y3QgYWdwX2dhdHQpLCBNX0FHUCwgTV9OT1dBSVQpOw0KIAlpZiAo IWdhdHQpIHsNCisJCWJ1c19yZWxlYXNlX3Jlc291cmNlcyhkZXYsIHNjLT5zY19yZXNfc3BlYywg c2MtPnNjX3Jlcyk7DQogIAkJYWdwX2dlbmVyaWNfZGV0YWNoKGRldik7DQogIAkJcmV0dXJuIEVO T01FTTsNCiAJfQ0KQEAgLTM1Myw3ICs0MTEsOCBAQA0KIA0KIAlpZiAoIHNjLT5jaGlwdHlwZSA9 PSBDSElQX0k4MTAgKSB7DQogCQkvKiBTb21lIGk4MTBzIGhhdmUgb24tY2hpcCBtZW1vcnkgY2Fs bGVkIGRjYWNoZSAqLw0KLQkJaWYgKFJFQUQxKEFHUF9JODEwX0RSVCkgJiBBR1BfSTgxMF9EUlRf UE9QVUxBVEVEKQ0KKwkJaWYgKGJ1c19yZWFkXzEoc2MtPnNjX3Jlc1swXSwgQUdQX0k4MTBfRFJU KSAmDQorCQkgICAgQUdQX0k4MTBfRFJUX1BPUFVMQVRFRCkNCiAJCQlzYy0+ZGNhY2hlX3NpemUg PSA0ICogMTAyNCAqIDEwMjQ7DQogCQllbHNlDQogCQkJc2MtPmRjYWNoZV9zaXplID0gMDsNCkBA IC0zNjQsNiArNDIzLDggQEANCiAJCWlmICghZ2F0dC0+YWdfdmlydHVhbCkgew0KIAkJCWlmIChi b290dmVyYm9zZSkNCiAJCQkJZGV2aWNlX3ByaW50ZihkZXYsICJjb250aWd1b3VzIGFsbG9jYXRp b24gZmFpbGVkXG4iKTsNCisJCQlidXNfcmVsZWFzZV9yZXNvdXJjZXMoZGV2LCBzYy0+c2NfcmVz X3NwZWMsDQorCQkJICAgIHNjLT5zY19yZXMpOw0KIAkJCWZyZWUoZ2F0dCwgTV9BR1ApOw0KIAkJ CWFncF9nZW5lcmljX2RldGFjaChkZXYpOw0KIAkJCXJldHVybiBFTk9NRU07DQpAQCAtMzczLDcg KzQzNCw4IEBADQogCQlnYXR0LT5hZ19waHlzaWNhbCA9IHZ0b3BoeXMoKHZtX29mZnNldF90KSBn YXR0LT5hZ192aXJ0dWFsKTsNCiAJCWFncF9mbHVzaF9jYWNoZSgpOw0KIAkJLyogSW5zdGFsbCB0 aGUgR0FUVC4gKi8NCi0JCVdSSVRFNChBR1BfSTgxMF9QR1RCTF9DVEwsIGdhdHQtPmFnX3BoeXNp Y2FsIHwgMSk7DQorCQlidXNfd3JpdGVfNChzYy0+c2NfcmVzWzBdLCBBR1BfSTgxMF9QR1RCTF9D VEwsDQorCQkgICAgZ2F0dC0+YWdfcGh5c2ljYWwgfCAxKTsNCiAJfSBlbHNlIGlmICggc2MtPmNo aXB0eXBlID09IENISVBfSTgzMCApIHsNCiAJCS8qIFRoZSBpODMwIGF1dG9tYXRpY2FsbHkgaW5p dGlhbGl6ZXMgdGhlIDEyOGsgZ2F0dCBvbiBib290LiAqLw0KIAkJdW5zaWduZWQgaW50IGdjYzEs IHBndGJsY3RsOw0KQEAgLTM5Miw3MiArNDU0LDEyNiBAQA0KIAkJCWRlZmF1bHQ6DQogCQkJCXNj LT5zdG9sZW4gPSAwOw0KIAkJCQlkZXZpY2VfcHJpbnRmKGRldiwgInVua25vd24gbWVtb3J5IGNv bmZpZ3VyYXRpb24sIGRpc2FibGluZ1xuIik7DQorCQkJCWJ1c19yZWxlYXNlX3Jlc291cmNlcyhk ZXYsIHNjLT5zY19yZXNfc3BlYywNCisJCQkJICAgIHNjLT5zY19yZXMpOw0KKwkJCQlmcmVlKGdh dHQsIE1fQUdQKTsNCiAJCQkJYWdwX2dlbmVyaWNfZGV0YWNoKGRldik7DQogCQkJCXJldHVybiBF SU5WQUw7DQogCQl9DQotCQlpZiAoc2MtPnN0b2xlbiA+IDApDQotCQkJZGV2aWNlX3ByaW50Zihk ZXYsICJkZXRlY3RlZCAlZGsgc3RvbGVuIG1lbW9yeVxuIiwgc2MtPnN0b2xlbiAqIDQpOw0KLQkJ ZGV2aWNlX3ByaW50ZihkZXYsICJhcGVydHVyZSBzaXplIGlzICVkTVxuIiwgc2MtPmluaXRpYWxf YXBlcnR1cmUgLyAxMDI0IC8gMTAyNCk7DQorCQlpZiAoc2MtPnN0b2xlbiA+IDApIHsNCisJCQlk ZXZpY2VfcHJpbnRmKGRldiwgImRldGVjdGVkICVkayBzdG9sZW4gbWVtb3J5XG4iLA0KKwkJCSAg ICBzYy0+c3RvbGVuICogNCk7DQorCQl9DQorCQlkZXZpY2VfcHJpbnRmKGRldiwgImFwZXJ0dXJl IHNpemUgaXMgJWRNXG4iLA0KKwkJICAgIHNjLT5pbml0aWFsX2FwZXJ0dXJlIC8gMTAyNCAvIDEw MjQpOw0KIA0KIAkJLyogR0FUVCBhZGRyZXNzIGlzIGFscmVhZHkgaW4gdGhlcmUsIG1ha2Ugc3Vy ZSBpdCdzIGVuYWJsZWQgKi8NCi0JCXBndGJsY3RsID0gUkVBRDQoQUdQX0k4MTBfUEdUQkxfQ1RM KTsNCisJCXBndGJsY3RsID0gYnVzX3JlYWRfNChzYy0+c2NfcmVzWzBdLCBBR1BfSTgxMF9QR1RC TF9DVEwpOw0KIAkJcGd0YmxjdGwgfD0gMTsNCi0JCVdSSVRFNChBR1BfSTgxMF9QR1RCTF9DVEws IHBndGJsY3RsKTsNCisJCWJ1c193cml0ZV80KHNjLT5zY19yZXNbMF0sIEFHUF9JODEwX1BHVEJM X0NUTCwgcGd0YmxjdGwpOw0KIA0KIAkJZ2F0dC0+YWdfcGh5c2ljYWwgPSBwZ3RibGN0bCAmIH4x Ow0KLQl9IGVsc2UgaWYgKHNjLT5jaGlwdHlwZSA9PSBDSElQX0k4NTUgfHwgc2MtPmNoaXB0eXBl ID09IENISVBfSTkxNSkgewkvKiBDSElQX0k4NTUgKi8NCi0JCXVuc2lnbmVkIGludCBnY2MxLCBw Z3RibGN0bCwgc3RvbGVuOw0KKwl9IGVsc2UgaWYgKHNjLT5jaGlwdHlwZSA9PSBDSElQX0k4NTUg fHwgc2MtPmNoaXB0eXBlID09IENISVBfSTkxNSB8fA0KKwkgICAgc2MtPmNoaXB0eXBlID09IENI SVBfSTk2NSB8fCBzYy0+Y2hpcHR5cGUgPT0gQ0hJUF9HMzMpIHsNCisJCXVuc2lnbmVkIGludCBn Y2MxLCBwZ3RibGN0bCwgc3RvbGVuLCBndHRfc2l6ZTsNCiANCiAJCS8qIFN0b2xlbiBtZW1vcnkg aXMgc2V0IHVwIGF0IHRoZSBiZWdpbm5pbmcgb2YgdGhlIGFwZXJ0dXJlIGJ5DQotCQkgKiB0aGUg QklPUywgY29uc2lzdGluZyBvZiB0aGUgR0FUVCBmb2xsb3dlZCBieSA0a2IgZm9yIHRoZSBCSU9T DQotCQkgKiBkaXNwbGF5Lg0KKwkJICogdGhlIEJJT1MsIGNvbnNpc3Rpbmcgb2YgdGhlIEdBVFQg Zm9sbG93ZWQgYnkgNGtiIGZvciB0aGUNCisJCSAqIEJJT1MgZGlzcGxheS4NCiAJCSAqLw0KLQkJ aWYgKHNjLT5jaGlwdHlwZSA9PSBDSElQX0k4NTUpDQotCQkJc3RvbGVuID0gMTMyOw0KLQkJZWxz ZQ0KLQkJCXN0b2xlbiA9IDI2MDsNCi0NCi0JCWdjYzEgPSBwY2lfcmVhZF9jb25maWcoc2MtPmJk ZXYsIEFHUF9JODU1X0dDQzEsIDEpOw0KLQkJc3dpdGNoIChnY2MxICYgQUdQX0k4NTVfR0NDMV9H TVMpIHsNCi0JCQljYXNlIEFHUF9JODU1X0dDQzFfR01TX1NUT0xFTl8xTToNCi0JCQkJc2MtPnN0 b2xlbiA9ICgxMDI0IC0gc3RvbGVuKSAqIDEwMjQgLyA0MDk2Ow0KLQkJCQlicmVhazsNCi0JCQlj YXNlIEFHUF9JODU1X0dDQzFfR01TX1NUT0xFTl80TTogDQotCQkJCXNjLT5zdG9sZW4gPSAoNDA5 NiAtIHN0b2xlbikgKiAxMDI0IC8gNDA5NjsNCi0JCQkJYnJlYWs7DQotCQkJY2FzZSBBR1BfSTg1 NV9HQ0MxX0dNU19TVE9MRU5fOE06IA0KLQkJCQlzYy0+c3RvbGVuID0gKDgxOTIgLSBzdG9sZW4p ICogMTAyNCAvIDQwOTY7DQotCQkJCWJyZWFrOw0KLQkJCWNhc2UgQUdQX0k4NTVfR0NDMV9HTVNf U1RPTEVOXzE2TTogDQotCQkJCXNjLT5zdG9sZW4gPSAoMTYzODQgLSBzdG9sZW4pICogMTAyNCAv IDQwOTY7DQotCQkJCWJyZWFrOw0KLQkJCWNhc2UgQUdQX0k4NTVfR0NDMV9HTVNfU1RPTEVOXzMy TTogDQotCQkJCXNjLT5zdG9sZW4gPSAoMzI3NjggLSBzdG9sZW4pICogMTAyNCAvIDQwOTY7DQor CQlzd2l0Y2ggKHNjLT5jaGlwdHlwZSkgew0KKwkJY2FzZSBDSElQX0k4NTU6DQorCQkJZ3R0X3Np emUgPSAxMjg7DQorCQkJYnJlYWs7DQorCQljYXNlIENISVBfSTkxNToNCisJCQlndHRfc2l6ZSA9 IDI1NjsNCisJCQlicmVhazsNCisJCWNhc2UgQ0hJUF9JOTY1Og0KKwkJY2FzZSBDSElQX0czMzoN CisJCQlzd2l0Y2ggKGJ1c19yZWFkXzQoc2MtPnNjX3Jlc1swXSwgQUdQX0k4MTBfUEdUQkxfQ1RM KSAmDQorCQkJICAgIEFHUF9JODEwX1BHVEJMX1NJWkVfTUFTSykgew0KKwkJCWNhc2UgQUdQX0k4 MTBfUEdUQkxfU0laRV8xMjhLQjoNCisJCQkJZ3R0X3NpemUgPSAxMjg7DQogCQkJCWJyZWFrOw0K LQkJCWNhc2UgQUdQX0k5MTVfR0NDMV9HTVNfU1RPTEVOXzQ4TTogDQotCQkJCXNjLT5zdG9sZW4g PSAoNDkxNTIgLSBzdG9sZW4pICogMTAyNCAvIDQwOTY7DQorCQkJY2FzZSBBR1BfSTgxMF9QR1RC TF9TSVpFXzI1NktCOg0KKwkJCQlndHRfc2l6ZSA9IDI1NjsNCiAJCQkJYnJlYWs7DQotCQkJY2Fz ZSBBR1BfSTkxNV9HQ0MxX0dNU19TVE9MRU5fNjRNOiANCi0JCQkJc2MtPnN0b2xlbiA9ICg2NTUz NiAtIHN0b2xlbikgKiAxMDI0IC8gNDA5NjsNCisJCQljYXNlIEFHUF9JODEwX1BHVEJMX1NJWkVf NTEyS0I6DQorCQkJCWd0dF9zaXplID0gNTEyOw0KIAkJCQlicmVhazsNCiAJCQlkZWZhdWx0Og0K LQkJCQlzYy0+c3RvbGVuID0gMDsNCi0JCQkJZGV2aWNlX3ByaW50ZihkZXYsICJ1bmtub3duIG1l bW9yeSBjb25maWd1cmF0aW9uLCBkaXNhYmxpbmdcbiIpOw0KKwkJCQlkZXZpY2VfcHJpbnRmKGRl diwgIkJhZCBQR1RCTCBzaXplXG4iKTsNCisJCQkJYnVzX3JlbGVhc2VfcmVzb3VyY2VzKGRldiwg c2MtPnNjX3Jlc19zcGVjLA0KKwkJCQkgICAgc2MtPnNjX3Jlcyk7DQorCQkJCWZyZWUoZ2F0dCwg TV9BR1ApOw0KIAkJCQlhZ3BfZ2VuZXJpY19kZXRhY2goZGV2KTsNCiAJCQkJcmV0dXJuIEVJTlZB TDsNCisJCQl9DQorCQkJYnJlYWs7DQorCQlkZWZhdWx0Og0KKwkJCWRldmljZV9wcmludGYoZGV2 LCAiQmFkIGNoaXB0eXBlXG4iKTsNCisJCQlidXNfcmVsZWFzZV9yZXNvdXJjZXMoZGV2LCBzYy0+ c2NfcmVzX3NwZWMsDQorCQkJICAgIHNjLT5zY19yZXMpOw0KKwkJCWZyZWUoZ2F0dCwgTV9BR1Ap Ow0KKwkJCWFncF9nZW5lcmljX2RldGFjaChkZXYpOw0KKwkJCXJldHVybiBFSU5WQUw7DQorCQl9 DQorDQorCQkvKiBHQ0MxIGlzIGNhbGxlZCBNR0dDIG9uIGk5MTUrICovDQorCQlnY2MxID0gcGNp X3JlYWRfY29uZmlnKHNjLT5iZGV2LCBBR1BfSTg1NV9HQ0MxLCAxKTsNCisJCXN3aXRjaCAoZ2Nj MSAmIEFHUF9JODU1X0dDQzFfR01TKSB7DQorCQljYXNlIEFHUF9JODU1X0dDQzFfR01TX1NUT0xF Tl8xTToNCisJCQlzdG9sZW4gPSAxMDI0Ow0KKwkJCWJyZWFrOw0KKwkJY2FzZSBBR1BfSTg1NV9H Q0MxX0dNU19TVE9MRU5fNE06DQorCQkJc3RvbGVuID0gNDA5NjsNCisJCQlicmVhazsNCisJCWNh c2UgQUdQX0k4NTVfR0NDMV9HTVNfU1RPTEVOXzhNOg0KKwkJCXN0b2xlbiA9IDgxOTI7DQorCQkJ YnJlYWs7DQorCQljYXNlIEFHUF9JODU1X0dDQzFfR01TX1NUT0xFTl8xNk06DQorCQkJc3RvbGVu ID0gMTYzODQ7DQorCQkJYnJlYWs7DQorCQljYXNlIEFHUF9JODU1X0dDQzFfR01TX1NUT0xFTl8z Mk06DQorCQkJc3RvbGVuID0gMzI3Njg7DQorCQkJYnJlYWs7DQorCQljYXNlIEFHUF9JOTE1X0dD QzFfR01TX1NUT0xFTl80OE06DQorCQkJc3RvbGVuID0gNDkxNTI7DQorCQkJYnJlYWs7DQorCQlj YXNlIEFHUF9JOTE1X0dDQzFfR01TX1NUT0xFTl82NE06DQorCQkJc3RvbGVuID0gNjU1MzY7DQor CQkJYnJlYWs7DQorCQljYXNlIEFHUF9HMzNfR0NDMV9HTVNfU1RPTEVOXzEyOE06DQorCQkJc3Rv bGVuID0gMTI4ICogMTAyNDsNCisJCQlicmVhazsNCisJCWNhc2UgQUdQX0czM19HQ0MxX0dNU19T VE9MRU5fMjU2TToNCisJCQlzdG9sZW4gPSAyNTYgKiAxMDI0Ow0KKwkJCWJyZWFrOw0KKwkJZGVm YXVsdDoNCisJCQlkZXZpY2VfcHJpbnRmKGRldiwgInVua25vd24gbWVtb3J5IGNvbmZpZ3VyYXRp b24sICINCisJCQkgICAgImRpc2FibGluZ1xuIik7DQorCQkJYnVzX3JlbGVhc2VfcmVzb3VyY2Vz KGRldiwgc2MtPnNjX3Jlc19zcGVjLA0KKwkJCSAgICBzYy0+c2NfcmVzKTsNCisJCQlmcmVlKGdh dHQsIE1fQUdQKTsNCisJCQlhZ3BfZ2VuZXJpY19kZXRhY2goZGV2KTsNCisJCQlyZXR1cm4gRUlO VkFMOw0KIAkJfQ0KKwkJc2MtPnN0b2xlbiA9IChzdG9sZW4gLSBndHRfc2l6ZSAtIDQpICogMTAy NCAvIDQwOTY7DQogCQlpZiAoc2MtPnN0b2xlbiA+IDApDQogCQkJZGV2aWNlX3ByaW50ZihkZXYs ICJkZXRlY3RlZCAlZGsgc3RvbGVuIG1lbW9yeVxuIiwgc2MtPnN0b2xlbiAqIDQpOw0KIAkJZGV2 aWNlX3ByaW50ZihkZXYsICJhcGVydHVyZSBzaXplIGlzICVkTVxuIiwgc2MtPmluaXRpYWxfYXBl cnR1cmUgLyAxMDI0IC8gMTAyNCk7DQogDQogCQkvKiBHQVRUIGFkZHJlc3MgaXMgYWxyZWFkeSBp biB0aGVyZSwgbWFrZSBzdXJlIGl0J3MgZW5hYmxlZCAqLw0KLQkJcGd0YmxjdGwgPSBSRUFENChB R1BfSTgxMF9QR1RCTF9DVEwpOw0KKwkJcGd0YmxjdGwgPSBidXNfcmVhZF80KHNjLT5zY19yZXNb MF0sIEFHUF9JODEwX1BHVEJMX0NUTCk7DQogCQlwZ3RibGN0bCB8PSAxOw0KLQkJV1JJVEU0KEFH UF9JODEwX1BHVEJMX0NUTCwgcGd0YmxjdGwpOw0KKwkJYnVzX3dyaXRlXzQoc2MtPnNjX3Jlc1sw XSwgQUdQX0k4MTBfUEdUQkxfQ1RMLCBwZ3RibGN0bCk7DQogDQogCQlnYXR0LT5hZ19waHlzaWNh bCA9IHBndGJsY3RsICYgfjE7DQogCX0NCiANCisJaWYgKDApDQorCQlhZ3BfaTgxMF9kdW1wX3Jl Z3MoZGV2KTsNCisNCiAJcmV0dXJuIDA7DQogfQ0KIA0KQEAgLTQ3MywxMiArNTg5LDEyIEBADQog DQogCS8qIENsZWFyIHRoZSBHQVRUIGJhc2UuICovDQogCWlmICggc2MtPmNoaXB0eXBlID09IENI SVBfSTgxMCApIHsNCi0JCVdSSVRFNChBR1BfSTgxMF9QR1RCTF9DVEwsIDApOw0KKwkJYnVzX3dy aXRlXzQoc2MtPnNjX3Jlc1swXSwgQUdQX0k4MTBfUEdUQkxfQ1RMLCAwKTsNCiAJfSBlbHNlIHsN CiAJCXVuc2lnbmVkIGludCBwZ3RibGN0bDsNCi0JCXBndGJsY3RsID0gUkVBRDQoQUdQX0k4MTBf UEdUQkxfQ1RMKTsNCisJCXBndGJsY3RsID0gYnVzX3JlYWRfNChzYy0+c2NfcmVzWzBdLCBBR1Bf STgxMF9QR1RCTF9DVEwpOw0KIAkJcGd0YmxjdGwgJj0gfjE7DQotCQlXUklURTQoQUdQX0k4MTBf UEdUQkxfQ1RMLCBwZ3RibGN0bCk7DQorCQlidXNfd3JpdGVfNChzYy0+c2NfcmVzWzBdLCBBR1Bf STgxMF9QR1RCTF9DVEwsIHBndGJsY3RsKTsNCiAJfQ0KIA0KIAkvKiBQdXQgdGhlIGFwZXJ0dXJl IGJhY2sgdGhlIHdheSBpdCBzdGFydGVkLiAqLw0KQEAgLTQ4OSw2MSArNjA1LDI1IEBADQogCX0N CiAJZnJlZShzYy0+Z2F0dCwgTV9BR1ApOw0KIA0KLQlpZiAoc2MtPmNoaXB0eXBlID09IENISVBf STkxNSkgew0KLQkJYnVzX3JlbGVhc2VfcmVzb3VyY2UoZGV2LCBTWVNfUkVTX01FTU9SWSwgQUdQ X0k5MTVfR01BRFIsDQotCQkJCSAgICAgc2MtPmdtKTsNCi0JCWJ1c19yZWxlYXNlX3Jlc291cmNl KGRldiwgU1lTX1JFU19NRU1PUlksIEFHUF9JOTE1X0dUVEFEUiwNCi0JCQkJICAgICBzYy0+Z3R0 KTsNCi0JCWJ1c19yZWxlYXNlX3Jlc291cmNlKGRldiwgU1lTX1JFU19NRU1PUlksIEFHUF9JOTE1 X01NQURSLA0KLQkJCQkgICAgIHNjLT5yZWdzKTsNCi0JfSBlbHNlIHsNCi0JCWJ1c19yZWxlYXNl X3Jlc291cmNlKGRldiwgU1lTX1JFU19NRU1PUlksIEFHUF9JODEwX01NQURSLA0KLQkJCQkgICAg IHNjLT5yZWdzKTsNCi0JfQ0KLQ0KLQlyZXR1cm4gMDsNCi19DQotDQotc3RhdGljIHVfaW50MzJf dA0KLWFncF9pODEwX2dldF9hcGVydHVyZShkZXZpY2VfdCBkZXYpDQotew0KLQlzdHJ1Y3QgYWdw X2k4MTBfc29mdGMgKnNjID0gZGV2aWNlX2dldF9zb2Z0YyhkZXYpOw0KLQl1aW50MzJfdCB0ZW1w Ow0KLQl1X2ludDE2X3QgbWlzY2M7DQotDQotCXN3aXRjaCAoc2MtPmNoaXB0eXBlKSB7DQotCWNh c2UgQ0hJUF9JODEwOg0KLQkJbWlzY2MgPSBwY2lfcmVhZF9jb25maWcoc2MtPmJkZXYsIEFHUF9J ODEwX01JU0NDLCAyKTsNCi0JCWlmICgobWlzY2MgJiBBR1BfSTgxMF9NSVNDQ19XSU5TSVpFKSA9 PSBBR1BfSTgxMF9NSVNDQ19XSU5TSVpFXzMyKQ0KLQkJCXJldHVybiAzMiAqIDEwMjQgKiAxMDI0 Ow0KLQkJZWxzZQ0KLQkJCXJldHVybiA2NCAqIDEwMjQgKiAxMDI0Ow0KLQljYXNlIENISVBfSTgz MDoNCi0JCXRlbXAgPSBwY2lfcmVhZF9jb25maWcoc2MtPmJkZXYsIEFHUF9JODMwX0dDQzEsIDIp Ow0KLQkJaWYgKCh0ZW1wICYgQUdQX0k4MzBfR0NDMV9HTUFTSVpFKSA9PSBBR1BfSTgzMF9HQ0Mx X0dNQVNJWkVfNjQpDQotCQkJcmV0dXJuIDY0ICogMTAyNCAqIDEwMjQ7DQotCQllbHNlDQotCQkJ cmV0dXJuIDEyOCAqIDEwMjQgKiAxMDI0Ow0KLQljYXNlIENISVBfSTg1NToNCi0JCXJldHVybiAx MjggKiAxMDI0ICogMTAyNDsNCi0JY2FzZSBDSElQX0k5MTU6DQotCQkvKiBUaGUgZG9jdW1lbnRh dGlvbiBzdGF0ZXMgdGhhdCBBR1BfSTkxNV9NU0FDIHNob3VsZCBoYXZlIGJpdA0KLQkJICogMSBz ZXQgaWYgdGhlIGFwZXJ0dXJlIGlzIDEyOE1CIGluc3RlYWQgb2YgMjU2LiAgSG93ZXZlciwNCi0J CSAqIHRoYXQgYml0IGFwcGVhcnMgdG8gbm90IGdldCBzZXQsIHNvIHdlIGluc3RlYWQgdXNlIHRo ZQ0KLQkJICogYXBlcnR1cmUgcmVzb3VyY2Ugc2l6ZSwgd2hpY2ggc2hvdWxkIGFsd2F5cyBiZSBj b3JyZWN0Lg0KLQkJICovDQotCQlyZXR1cm4gcm1hbl9nZXRfc2l6ZShzYy0+Z20pOw0KLQl9DQor CWJ1c19yZWxlYXNlX3Jlc291cmNlcyhkZXYsIHNjLT5zY19yZXNfc3BlYywgc2MtPnNjX3Jlcyk7 DQogDQogCXJldHVybiAwOw0KIH0NCiANCisvKioNCisgKiBTZXRzIHRoZSBQQ0kgcmVzb3VyY2Ug c2l6ZSBvZiB0aGUgYXBlcnR1cmUgb24gaTgzMC1jbGFzcyBhbmQgYmVsb3cgY2hpcHNldHMsDQor ICogd2hpbGUgcmV0dXJuaW5nIGZhaWx1cmUgb24gbGF0ZXIgY2hpcHNldHMgd2hlbiBhbiBhY3R1 YWwgY2hhbmdlIGlzDQorICogcmVxdWVzdGVkLg0KKyAqDQorICogVGhpcyB3aG9sZSBmdW5jdGlv biBpcyBsaWtlbHkgYm9ndXMsIGFzIHRoZSBrZXJuZWwgd291bGQgcHJvYmFibHkgbmVlZCB0bw0K KyAqIHJlY29uZmlndXJlIHRoZSBwbGFjZW1lbnQgb2YgdGhlIEFHUCBhcGVydHVyZSBpZiBhIGxh cmdlciBzaXplIGlzIHJlcXVlc3RlZCwNCisgKiB3aGljaCBkb2Vzbid0IGhhcHBlbiBjdXJyZW50 bHkuDQorICovDQogc3RhdGljIGludA0KIGFncF9pODEwX3NldF9hcGVydHVyZShkZXZpY2VfdCBk ZXYsIHVfaW50MzJfdCBhcGVydHVyZSkNCiB7DQogCXN0cnVjdCBhZ3BfaTgxMF9zb2Z0YyAqc2Mg PSBkZXZpY2VfZ2V0X3NvZnRjKGRldik7DQogCXVfaW50MTZfdCBtaXNjYywgZ2NjMTsNCi0JdV9p bnQzMl90IHRlbXA7DQogDQogCXN3aXRjaCAoc2MtPmNoaXB0eXBlKSB7DQogCWNhc2UgQ0hJUF9J ODEwOg0KQEAgLTU4MCwzMiArNjYwLDU1IEBADQogCQlwY2lfd3JpdGVfY29uZmlnKHNjLT5iZGV2 LCBBR1BfSTgzMF9HQ0MxLCBnY2MxLCAyKTsNCiAJCWJyZWFrOw0KIAljYXNlIENISVBfSTg1NToN Ci0JCWlmIChhcGVydHVyZSAhPSAxMjggKiAxMDI0ICogMTAyNCkgew0KLQkJCWRldmljZV9wcmlu dGYoZGV2LCAiYmFkIGFwZXJ0dXJlIHNpemUgJWRcbiIsIGFwZXJ0dXJlKTsNCi0JCQlyZXR1cm4g RUlOVkFMOw0KLQkJfQ0KLQkJYnJlYWs7DQogCWNhc2UgQ0hJUF9JOTE1Og0KLQkJdGVtcCA9IHBj aV9yZWFkX2NvbmZpZyhkZXYsIEFHUF9JOTE1X01TQUMsIDEpOw0KLQkJdGVtcCAmPSB+QUdQX0k5 MTVfTVNBQ19HTUFTSVpFOw0KKwljYXNlIENISVBfSTk2NToNCisJY2FzZSBDSElQX0czMzoNCisJ CXJldHVybiBhZ3BfZ2VuZXJpY19zZXRfYXBlcnR1cmUoZGV2LCBhcGVydHVyZSk7DQorCX0NCiAN Ci0JCXN3aXRjaCAoYXBlcnR1cmUpIHsNCi0JCWNhc2UgMTI4ICogMTAyNCAqIDEwMjQ6DQotCQkJ dGVtcCB8PSBBR1BfSTkxNV9NU0FDX0dNQVNJWkVfMTI4Ow0KLQkJCWJyZWFrOw0KLQkJY2FzZSAy NTYgKiAxMDI0ICogMTAyNDoNCi0JCQl0ZW1wIHw9IEFHUF9JOTE1X01TQUNfR01BU0laRV8yNTY7 DQotCQkJYnJlYWs7DQotCQlkZWZhdWx0Og0KLQkJCWRldmljZV9wcmludGYoZGV2LCAiYmFkIGFw ZXJ0dXJlIHNpemUgJWRcbiIsIGFwZXJ0dXJlKTsNCi0JCQlyZXR1cm4gRUlOVkFMOw0KLQkJfQ0K KwlyZXR1cm4gMDsNCit9DQogDQotCQlwY2lfd3JpdGVfY29uZmlnKGRldiwgQUdQX0k5MTVfTVNB QywgdGVtcCwgMSk7DQotCQlicmVhazsNCisvKioNCisgKiBXcml0ZXMgYSBHVFQgZW50cnkgbWFw cGluZyB0aGUgcGFnZSBhdCB0aGUgZ2l2ZW4gb2Zmc2V0IGZyb20gdGhlIGJlZ2lubmluZw0KKyAq IG9mIHRoZSBhcGVydHVyZSB0byB0aGUgZ2l2ZW4gcGh5c2ljYWwgYWRkcmVzcy4NCisgKi8NCitz dGF0aWMgdm9pZA0KK2FncF9pODEwX3dyaXRlX2d0dF9lbnRyeShkZXZpY2VfdCBkZXYsIGludCBv ZmZzZXQsIHZtX29mZnNldF90IHBoeXNpY2FsLA0KKyAgICBpbnQgZW5hYmxlZCkNCit7DQorCXN0 cnVjdCBhZ3BfaTgxMF9zb2Z0YyAqc2MgPSBkZXZpY2VfZ2V0X3NvZnRjKGRldik7DQorCXVfaW50 MzJfdCBwdGU7DQorDQorCXB0ZSA9ICh1X2ludDMyX3QpcGh5c2ljYWwgfCAxOw0KKwlpZiAoc2Mt PmNoaXB0eXBlID09IENISVBfSTk2NSB8fCBzYy0+Y2hpcHR5cGUgPT0gQ0hJUF9HMzMpIHsNCisJ CXB0ZSB8PSAocGh5c2ljYWwgJiAweDAwMDAwMDBmMDAwMDAwMDB1bGwpID4+IDI4Ow0KKwl9IGVs c2Ugew0KKwkJLyogSWYgd2UgZG8gYWN0dWFsbHkgaGF2ZSBtZW1vcnkgYWJvdmUgNEdCIG9uIGFu IG9sZGVyIHN5c3RlbSwNCisJCSAqIGNyYXNoIGNsZWFubHkgcmF0aGVyIHRoYW4gc2NyaWJibGUg b24gc3lzdGVtIG1lbW9yeSwNCisJCSAqIHNvIHdlIGtub3cgd2UgbmVlZCB0byBmaXggaXQuDQor CQkgKi8NCisJCUtBU1NFUlQoKHB0ZSAmIDB4MDAwMDAwMGYwMDAwMDAwMHVsbCkgPT0gMCwNCisJ CSAgICAoIj40R0IgcGh5c2ljYWwgYWRkcmVzcyBpbiBhZ3AiKSk7DQogCX0NCiANCi0JcmV0dXJu IDA7DQorCXN3aXRjaCAoc2MtPmNoaXB0eXBlKSB7DQorCWNhc2UgQ0hJUF9JODEwOg0KKwljYXNl IENISVBfSTgzMDoNCisJY2FzZSBDSElQX0k4NTU6DQorCQlidXNfd3JpdGVfNChzYy0+c2NfcmVz WzBdLA0KKwkJICAgIEFHUF9JODEwX0dUVCArIChvZmZzZXQgPj4gQUdQX1BBR0VfU0hJRlQpICog NCwgcHRlKTsNCisJCWJyZWFrOw0KKwljYXNlIENISVBfSTkxNToNCisJY2FzZSBDSElQX0czMzoN CisJCWJ1c193cml0ZV80KHNjLT5zY19yZXNbMV0sDQorCQkgICAgKG9mZnNldCA+PiBBR1BfUEFH RV9TSElGVCkgKiA0LCBwdGUpOw0KKwkJYnJlYWs7DQorCWNhc2UgQ0hJUF9JOTY1Og0KKwkJYnVz X3dyaXRlXzQoc2MtPnNjX3Jlc1swXSwNCisJCSAgICAob2Zmc2V0ID4+IEFHUF9QQUdFX1NISUZU KSAqIDQgKyAoNTEyICogMTAyNCksIHB0ZSk7DQorCQlicmVhazsNCisJfQ0KIH0NCiANCiBzdGF0 aWMgaW50DQpAQCAtNjI1LDExICs3MjgsNyBAQA0KIAkJfQ0KIAl9DQogDQotCWlmIChzYy0+Y2hp cHR5cGUgPT0gQ0hJUF9JOTE1KSB7DQotCQlXUklURUdUVCgob2Zmc2V0ID4+IEFHUF9QQUdFX1NI SUZUKSAqIDQsIHBoeXNpY2FsIHwgMSk7DQotCX0gZWxzZSB7DQotCQlXUklURTQoQUdQX0k4MTBf R1RUICsgKG9mZnNldCA+PiBBR1BfUEFHRV9TSElGVCkgKiA0LCBwaHlzaWNhbCB8IDEpOw0KLQl9 DQorCWFncF9pODEwX3dyaXRlX2d0dF9lbnRyeShkZXYsIG9mZnNldCwgcGh5c2ljYWwsIDEpOw0K IA0KIAlyZXR1cm4gMDsNCiB9DQpAQCAtNjQ5LDEyICs3NDgsOCBAQA0KIAkJfQ0KIAl9DQogDQot CWlmIChzYy0+Y2hpcHR5cGUgPT0gQ0hJUF9JOTE1KSB7DQotCQlXUklURUdUVCgob2Zmc2V0ID4+ IEFHUF9QQUdFX1NISUZUKSAqIDQsIDApOw0KLQl9IGVsc2Ugew0KLQkJV1JJVEU0KEFHUF9JODEw X0dUVCArIChvZmZzZXQgPj4gQUdQX1BBR0VfU0hJRlQpICogNCwgMCk7DQotCX0NCi0JDQorCWFn cF9pODEwX3dyaXRlX2d0dF9lbnRyeShkZXYsIG9mZnNldCwgMCwgMCk7DQorDQogCXJldHVybiAw Ow0KIH0NCiANCkBAIC04MTIsMTYgKzkwNyw4IEBADQogCQl9DQogCQkvKiBUaGUgbWVtb3J5J3Mg YWxyZWFkeSB3aXJlZCBkb3duLCBqdXN0IHN0aWNrIGl0IGluIHRoZSBHVFQuICovDQogCQlmb3Ig KGkgPSAwOyBpIDwgbWVtLT5hbV9zaXplOyBpICs9IEFHUF9QQUdFX1NJWkUpIHsNCi0JCQl1X2lu dDMyX3QgcGh5c2ljYWwgPSBtZW0tPmFtX3BoeXNpY2FsICsgaTsNCi0NCi0JCQlpZiAoc2MtPmNo aXB0eXBlID09IENISVBfSTkxNSkgew0KLQkJCQlXUklURUdUVCgoKG9mZnNldCArIGkpID4+IEFH UF9QQUdFX1NISUZUKSAqIDQsDQotCQkJCSAgICBwaHlzaWNhbCB8IDEpOw0KLQkJCX0gZWxzZSB7 DQotCQkJCVdSSVRFNChBR1BfSTgxMF9HVFQgKw0KLQkJCQkgICAgKChvZmZzZXQgKyBpKSA+PiBB R1BfUEFHRV9TSElGVCkgKiA0LA0KLQkJCQkgICAgcGh5c2ljYWwgfCAxKTsNCi0JCQl9DQorCQkJ YWdwX2k4MTBfd3JpdGVfZ3R0X2VudHJ5KGRldiwgb2Zmc2V0ICsgaSwNCisJCQkgICAgbWVtLT5h bV9waHlzaWNhbCArIGksIDEpOw0KIAkJfQ0KIAkJYWdwX2ZsdXNoX2NhY2hlKCk7DQogCQltZW0t PmFtX29mZnNldCA9IG9mZnNldDsNCkBAIC04MzcsOCArOTI0LDggQEANCiAJCXJldHVybiBFSU5W QUw7DQogDQogCWZvciAoaSA9IDA7IGkgPCBtZW0tPmFtX3NpemU7IGkgKz0gQUdQX1BBR0VfU0la RSkgew0KLQkJV1JJVEU0KEFHUF9JODEwX0dUVCArIChvZmZzZXQgPj4gQUdQX1BBR0VfU0hJRlQp ICogNCwNCi0JCSAgICAgICBpIHwgMyk7DQorCQlidXNfd3JpdGVfNChzYy0+c2NfcmVzWzBdLA0K KwkJICAgIEFHUF9JODEwX0dUVCArIChpID4+IEFHUF9QQUdFX1NISUZUKSAqIDQsIGkgfCAzKTsN CiAJfQ0KIA0KIAlyZXR1cm4gMDsNCkBAIC04NTgsMTUgKzk0NSw4IEBADQogCQl9DQogDQogCQlm b3IgKGkgPSAwOyBpIDwgbWVtLT5hbV9zaXplOyBpICs9IEFHUF9QQUdFX1NJWkUpIHsNCi0JCQl2 bV9vZmZzZXRfdCBvZmZzZXQgPSBtZW0tPmFtX29mZnNldDsNCi0NCi0JCQlpZiAoc2MtPmNoaXB0 eXBlID09IENISVBfSTkxNSkgew0KLQkJCQlXUklURUdUVCgoKG9mZnNldCArIGkpID4+IEFHUF9Q QUdFX1NISUZUKSAqIDQsDQotCQkJCSAgICAwKTsNCi0JCQl9IGVsc2Ugew0KLQkJCQlXUklURTQo QUdQX0k4MTBfR1RUICsNCi0JCQkJICAgICgob2Zmc2V0ICsgaSkgPj4gQUdQX1BBR0VfU0hJRlQp ICogNCwgMCk7DQotCQkJfQ0KKwkJCWFncF9pODEwX3dyaXRlX2d0dF9lbnRyeShkZXYsIG1lbS0+ YW1fb2Zmc2V0ICsgaSwNCisJCQkgICAgMCwgMCk7DQogCQl9DQogCQlhZ3BfZmx1c2hfY2FjaGUo KTsNCiAJCW1lbS0+YW1faXNfYm91bmQgPSAwOw0KQEAgLTg4MCw4ICs5NjAsMTAgQEANCiAJaWYg KCBzYy0+Y2hpcHR5cGUgIT0gQ0hJUF9JODEwICkNCiAJCXJldHVybiBFSU5WQUw7DQogDQotCWZv ciAoaSA9IDA7IGkgPCBtZW0tPmFtX3NpemU7IGkgKz0gQUdQX1BBR0VfU0laRSkNCi0JCVdSSVRF NChBR1BfSTgxMF9HVFQgKyAoaSA+PiBBR1BfUEFHRV9TSElGVCkgKiA0LCAwKTsNCisJZm9yIChp ID0gMDsgaSA8IG1lbS0+YW1fc2l6ZTsgaSArPSBBR1BfUEFHRV9TSVpFKSB7DQorCQlidXNfd3Jp dGVfNChzYy0+c2NfcmVzWzBdLA0KKwkJICAgIEFHUF9JODEwX0dUVCArIChpID4+IEFHUF9QQUdF X1NISUZUKSAqIDQsIDApOw0KKwl9DQogDQogCXJldHVybiAwOw0KIH0NCkBAIC04OTQsNyArOTc2 LDcgQEANCiAJREVWTUVUSE9EKGRldmljZV9kZXRhY2gsCWFncF9pODEwX2RldGFjaCksDQogDQog CS8qIEFHUCBpbnRlcmZhY2UgKi8NCi0JREVWTUVUSE9EKGFncF9nZXRfYXBlcnR1cmUsCWFncF9p ODEwX2dldF9hcGVydHVyZSksDQorCURFVk1FVEhPRChhZ3BfZ2V0X2FwZXJ0dXJlLAlhZ3BfZ2Vu ZXJpY19nZXRfYXBlcnR1cmUpLA0KIAlERVZNRVRIT0QoYWdwX3NldF9hcGVydHVyZSwJYWdwX2k4 MTBfc2V0X2FwZXJ0dXJlKSwNCiAJREVWTUVUSE9EKGFncF9iaW5kX3BhZ2UsCWFncF9pODEwX2Jp bmRfcGFnZSksDQogCURFVk1FVEhPRChhZ3BfdW5iaW5kX3BhZ2UsCWFncF9pODEwX3VuYmluZF9w YWdlKSwNCkluZGV4OiBhZ3Bwcml2LmgNCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NClJDUyBmaWxlOiAvaG9tZS9uY3Zz L3NyYy9zeXMvcGNpL2FncHByaXYuaCx2DQpyZXRyaWV2aW5nIHJldmlzaW9uIDEuNQ0KZGlmZiAt dSAtcjEuNSBhZ3Bwcml2LmgNCi0tLSBhZ3Bwcml2LmgJMTYgSnVuIDIwMDQgMDk6NDc6MjAgLTAw MDAJMS41DQorKysgYWdwcHJpdi5oCTEyIEp1bCAyMDA3IDE3OjU1OjU2IC0wMDAwDQpAQCAtNjks NiArNjksNyBAQA0KICAqLw0KIHN0cnVjdCBhZ3Bfc29mdGMgew0KIAlzdHJ1Y3QgcmVzb3VyY2UJ ICAgICAgICAqYXNfYXBlcnR1cmU7CS8qIGxvY2F0aW9uIG9mIGFwZXJ0dXJlICovDQorCWludAkJ CWFzX2FwZXJ0dXJlX3JpZDsNCiAJdV9pbnQzMl90CQlhc19tYXhtZW07CS8qIGFsbG9jYXRpb24g dXBwZXIgYm91bmQgKi8NCiAJdV9pbnQzMl90CQlhc19hbGxvY2F0ZWQ7CS8qIGFtb3VudCBhbGxv Y2F0ZWQgKi8NCiAJZW51bSBhZ3BfYWNxdWlyZV9zdGF0ZQlhc19zdGF0ZTsNCkBAIC04OCw5ICs4 OSwxMyBAQA0KIHZvaWQJCQlhZ3BfZmx1c2hfY2FjaGUodm9pZCk7DQogdV9pbnQ4X3QJCWFncF9m aW5kX2NhcHMoZGV2aWNlX3QgZGV2KTsNCiBzdHJ1Y3QgYWdwX2dhdHQJICAgICAgICphZ3BfYWxs b2NfZ2F0dChkZXZpY2VfdCBkZXYpOw0KK3ZvaWQJCQlhZ3Bfc2V0X2FwZXJ0dXJlX3Jlc291cmNl KGRldmljZV90IGRldiwgaW50IHJpZCk7DQogdm9pZAkJICAgICAgICBhZ3BfZnJlZV9nYXR0KHN0 cnVjdCBhZ3BfZ2F0dCAqZ2F0dCk7DQogaW50CQkJYWdwX2dlbmVyaWNfYXR0YWNoKGRldmljZV90 IGRldik7DQogaW50CQkJYWdwX2dlbmVyaWNfZGV0YWNoKGRldmljZV90IGRldik7DQoraW50CQkJ YWdwX2dlbmVyaWNfZ2V0X2FwZXJ0dXJlKGRldmljZV90IGRldik7DQoraW50CQkJYWdwX2dlbmVy aWNfc2V0X2FwZXJ0dXJlKGRldmljZV90IGRldiwNCisJCQkJCQkgdV9pbnQzMl90IGFwZXJ0dXJl KTsNCiBpbnQJCQlhZ3BfZ2VuZXJpY19lbmFibGUoZGV2aWNlX3QgZGV2LCB1X2ludDMyX3QgbW9k ZSk7DQogc3RydWN0IGFncF9tZW1vcnkgICAgICAqYWdwX2dlbmVyaWNfYWxsb2NfbWVtb3J5KGRl dmljZV90IGRldiwgaW50IHR5cGUsDQogCQkJCQkJIHZtX3NpemVfdCBzaXplKTsNCkluZGV4OiBh Z3ByZWcuaA0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PQ0KUkNTIGZpbGU6IC9ob21lL25jdnMvc3JjL3N5cy9wY2kvYWdw cmVnLmgsdg0KcmV0cmlldmluZyByZXZpc2lvbiAxLjE4DQpkaWZmIC11IC1yMS4xOCBhZ3ByZWcu aA0KLS0tIGFncHJlZy5oCTUgSmFuIDIwMDcgMjI6NTU6MTkgLTAwMDAJMS4xOA0KKysrIGFncHJl Zy5oCTkgSnVsIDIwMDcgMTY6NTc6NTEgLTAwMDANCkBAIC0xODAsMTEgKzE4MCwxOSBAQA0KICAq IE1lbW9yeSBtYXBwZWQgcmVnaXN0ZXIgb2Zmc2V0cyBmb3IgaTgxMCBjaGlwc2V0Lg0KICAqLw0K ICNkZWZpbmUgQUdQX0k4MTBfUEdUQkxfQ1RMCTB4MjAyMA0KKy8qKg0KKyAqIFRoaXMgZmllbGQg ZGV0ZXJtaW5lcyB0aGUgYWN0dWFsIHNpemUgb2YgdGhlIGdsb2JhbCBHVFQgb24gdGhlIDk2NQ0K KyAqIGFuZCBHMzMNCisgKi8NCisjZGVmaW5lIEFHUF9JODEwX1BHVEJMX1NJWkVfTUFTSwkweDAw MDAwMDBlDQorI2RlZmluZSBBR1BfSTgxMF9QR1RCTF9TSVpFXzUxMktCCSgwIDw8IDEpDQorI2Rl ZmluZSBBR1BfSTgxMF9QR1RCTF9TSVpFXzI1NktCCSgxIDw8IDEpDQorI2RlZmluZSBBR1BfSTgx MF9QR1RCTF9TSVpFXzEyOEtCCSgyIDw8IDEpDQogI2RlZmluZSBBR1BfSTgxMF9EUlQJCTB4MzAw MA0KICNkZWZpbmUgQUdQX0k4MTBfRFJUX1VOUE9QVUxBVEVEIDB4MDANCiAjZGVmaW5lIEFHUF9J ODEwX0RSVF9QT1BVTEFURUQJMHgwMQ0KICNkZWZpbmUgQUdQX0k4MTBfR1RUCQkweDEwMDAwDQot IA0KKw0KIC8qDQogICogQ29uZmlnIHJlZ2lzdGVycyBmb3IgaTgzME1HIGRldmljZSAwDQogICov DQpAQCAtMTkyLDcgKzIwMCw3IEBADQogI2RlZmluZSBBR1BfSTgzMF9HQ0MxX0RFVjIJCTB4MDgN CiAjZGVmaW5lIEFHUF9JODMwX0dDQzFfREVWMl9FTkFCTEVECTB4MDANCiAjZGVmaW5lIEFHUF9J ODMwX0dDQzFfREVWMl9ESVNBQkxFRAkweDA4DQotI2RlZmluZSBBR1BfSTgzMF9HQ0MxX0dNUwkJ MHg3MA0KKyNkZWZpbmUgQUdQX0k4MzBfR0NDMV9HTVMJCTB4ZjAgLyogVG9wIGJpdCByZXNlcnZl ZCBwcmUtRzMzICovDQogI2RlZmluZSBBR1BfSTgzMF9HQ0MxX0dNU19TVE9MRU5fNTEyCTB4MjAN CiAjZGVmaW5lIEFHUF9JODMwX0dDQzFfR01TX1NUT0xFTl8xMDI0CTB4MzANCiAjZGVmaW5lIEFH UF9JODMwX0dDQzFfR01TX1NUT0xFTl84MTkyCTB4NDANCkBAIC0yNDQsNiArMjUyLDIxIEBADQog I2RlZmluZSBBR1BfSTkxNV9NU0FDX0dNQVNJWkVfMjU2CTB4MDANCiANCiAvKg0KKyAqIEc5NjUg cmVnaXN0ZXJzDQorICovDQorI2RlZmluZSBBR1BfSTk2NV9HVFRNTUFEUgkJMHgxMA0KKyNkZWZp bmUgQUdQX0k5NjVfTVNBQwkJCTB4NjINCisjZGVmaW5lIEFHUF9JOTY1X01TQUNfR01BU0laRV8x MjgJMHgwMA0KKyNkZWZpbmUgQUdQX0k5NjVfTVNBQ19HTUFTSVpFXzI1NgkweDAyDQorI2RlZmlu ZSBBR1BfSTk2NV9NU0FDX0dNQVNJWkVfNTEyCTB4MDYNCisNCisvKg0KKyAqIEczMyByZWdpc3Rl cnMNCisgKi8NCisjZGVmaW5lIEFHUF9HMzNfR0NDMV9HTVNfU1RPTEVOXzEyOE0JMHg4MA0KKyNk ZWZpbmUgQUdQX0czM19HQ0MxX0dNU19TVE9MRU5fMjU2TQkweDkwDQorDQorLyoNCiAgKiBOVklE SUEgbkZvcmNlL25Gb3JjZTIgcmVnaXN0ZXJzDQogICovDQogI2RlZmluZQlBR1BfTlZJRElBXzBf QVBCQVNFCQkweDEwDQo= --=-5YELsow3Fpr9UE+T3E/E-- --=-AXWcD71UA0EuCnCMobb0 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQBGlpU7HUdvYGzw6vcRAmScAJ9XE16Dp6YZMvoQqDi+EN/WMpuT1wCfbz0S O/A4lvsK+ALpDkacjIY7vIQ= =6K8w -----END PGP SIGNATURE----- --=-AXWcD71UA0EuCnCMobb0-- From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 05:45:07 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B786416A401; Fri, 13 Jul 2007 05:45:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [62.111.66.27]) by mx1.freebsd.org (Postfix) with ESMTP id 6E9B213C478; Fri, 13 Jul 2007 05:45:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from localhost (amavis.str.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id EA3D641C5AD; Fri, 13 Jul 2007 07:45:05 +0200 (CEST) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([62.111.66.27]) by localhost (amavis.str.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id BtMuXvm94yHG; Fri, 13 Jul 2007 07:45:05 +0200 (CEST) Received: by mail.cksoft.de (Postfix, from userid 66) id 7B31741C5AC; Fri, 13 Jul 2007 07:45:05 +0200 (CEST) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id BFF21444885; Fri, 13 Jul 2007 05:41:04 +0000 (UTC) Date: Fri, 13 Jul 2007 05:41:04 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: "George V. Neville-Neil" In-Reply-To: Message-ID: <20070713053534.D31116@maildrop.int.zabbadoz.net> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Peter Blok , FreeBSD current mailing list , net@freebsd.org Subject: Re: FAST_IPSEC is now IPSEC, please be advised... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2007 05:45:07 -0000 On Thu, 12 Jul 2007, gnn@freebsd.org wrote: Morning, > At Wed, 11 Jul 2007 13:49:37 +0200, > Peter Blok wrote: >> >> Hi George, >> >> Is somebody looking at ipsec-tools? As far as I can see it requires a >> lot of kame definitions, although not used most of the times. I have >> tried to make sense of this, but it wasn't easy. > > I am not right now, if you have interest and or patches I (we) would > love to see them. I have a preliminary hackish patch. The problem is that I have other patches in there as well. I'll have to disunite them. I was hoping that ipsec-tools would release earlier so that the gcc4 compile issues would have been solved already only leaving us with the directory changes for the #inlcude files... /bz -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT Software is harder than hardware so better get it right the first time. From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 05:51:48 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 702A416A400; Fri, 13 Jul 2007 05:51:48 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe08.swip.net [212.247.154.225]) by mx1.freebsd.org (Postfix) with ESMTP id 4501413C494; Fri, 13 Jul 2007 05:51:47 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] Received: from [194.248.135.20] (account mc467741@c2i.net HELO laptop.lan) by mailfe08.swip.net (CommuniGate Pro SMTP 5.1.10) with ESMTPA id 543103494; Fri, 13 Jul 2007 07:51:45 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Fri, 13 Jul 2007 07:51:48 +0200 User-Agent: KMail/1.9.5 References: <46970DF7.3000803@elischer.org> In-Reply-To: <46970DF7.3000803@elischer.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200707130751.48815.hselasky@c2i.net> Cc: Julian Elischer , FreeBSD Current Subject: Re: crash in tty code in 6.1.. fixed since? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2007 05:51:48 -0000 On Friday 13 July 2007 07:30, Julian Elischer wrote: > Does this crash look familiar to anyone? > It's in 6.1 unfortunatly.. > Is this a USB modem ? --HPS From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 05:51:48 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 702A416A400; Fri, 13 Jul 2007 05:51:48 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe08.swip.net [212.247.154.225]) by mx1.freebsd.org (Postfix) with ESMTP id 4501413C494; Fri, 13 Jul 2007 05:51:47 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] Received: from [194.248.135.20] (account mc467741@c2i.net HELO laptop.lan) by mailfe08.swip.net (CommuniGate Pro SMTP 5.1.10) with ESMTPA id 543103494; Fri, 13 Jul 2007 07:51:45 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Fri, 13 Jul 2007 07:51:48 +0200 User-Agent: KMail/1.9.5 References: <46970DF7.3000803@elischer.org> In-Reply-To: <46970DF7.3000803@elischer.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200707130751.48815.hselasky@c2i.net> Cc: Julian Elischer , FreeBSD Current Subject: Re: crash in tty code in 6.1.. fixed since? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2007 05:51:48 -0000 On Friday 13 July 2007 07:30, Julian Elischer wrote: > Does this crash look familiar to anyone? > It's in 6.1 unfortunatly.. > Is this a USB modem ? --HPS From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 05:58:16 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id ACD4816A402 for ; Fri, 13 Jul 2007 05:58:16 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outR.internet-mail-service.net (outR.internet-mail-service.net [216.240.47.241]) by mx1.freebsd.org (Postfix) with ESMTP id 973DA13C4B3 for ; Fri, 13 Jul 2007 05:58:16 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Thu, 12 Jul 2007 22:58:16 -0700 Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id D1453125ADD; Thu, 12 Jul 2007 22:58:15 -0700 (PDT) Message-ID: <4697148F.8020304@elischer.org> Date: Thu, 12 Jul 2007 22:58:39 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) MIME-Version: 1.0 To: Hans Petter Selasky References: <46970DF7.3000803@elischer.org> <200707130751.48815.hselasky@c2i.net> In-Reply-To: <200707130751.48815.hselasky@c2i.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, FreeBSD Current Subject: Re: crash in tty code in 6.1.. fixed since? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2007 05:58:16 -0000 Hans Petter Selasky wrote: > On Friday 13 July 2007 07:30, Julian Elischer wrote: >> Does this crash look familiar to anyone? >> It's in 6.1 unfortunatly.. >> > > Is this a USB modem ? no it's a pty > > --HPS > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 05:58:16 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AD32816A403 for ; Fri, 13 Jul 2007 05:58:16 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outQ.internet-mail-service.net (outQ.internet-mail-service.net [216.240.47.240]) by mx1.freebsd.org (Postfix) with ESMTP id 9445413C481 for ; Fri, 13 Jul 2007 05:58:16 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Thu, 12 Jul 2007 22:58:16 -0700 Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id D1453125ADD; Thu, 12 Jul 2007 22:58:15 -0700 (PDT) Message-ID: <4697148F.8020304@elischer.org> Date: Thu, 12 Jul 2007 22:58:39 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) MIME-Version: 1.0 To: Hans Petter Selasky References: <46970DF7.3000803@elischer.org> <200707130751.48815.hselasky@c2i.net> In-Reply-To: <200707130751.48815.hselasky@c2i.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, FreeBSD Current Subject: Re: crash in tty code in 6.1.. fixed since? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2007 05:58:16 -0000 Hans Petter Selasky wrote: > On Friday 13 July 2007 07:30, Julian Elischer wrote: >> Does this crash look familiar to anyone? >> It's in 6.1 unfortunatly.. >> > > Is this a USB modem ? no it's a pty > > --HPS > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 06:47:57 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4156616A401 for ; Fri, 13 Jul 2007 06:47:57 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe12.swip.net [212.247.155.97]) by mx1.freebsd.org (Postfix) with ESMTP id A596113C4B9 for ; Fri, 13 Jul 2007 06:47:56 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] Received: from [194.248.135.20] (account mc467741@c2i.net HELO laptop.lan) by mailfe12.swip.net (CommuniGate Pro SMTP 5.1.10) with ESMTPA id 373814781; Fri, 13 Jul 2007 08:47:54 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Fri, 13 Jul 2007 08:47:57 +0200 User-Agent: KMail/1.9.5 References: <46970DF7.3000803@elischer.org> <200707130751.48815.hselasky@c2i.net> <4697148F.8020304@elischer.org> In-Reply-To: <4697148F.8020304@elischer.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200707130847.57829.hselasky@c2i.net> Cc: Julian Elischer , FreeBSD Current Subject: Re: crash in tty code in 6.1.. fixed since? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2007 06:47:57 -0000 On Friday 13 July 2007 07:58, Julian Elischer wrote: > Hans Petter Selasky wrote: > > On Friday 13 July 2007 07:30, Julian Elischer wrote: > >> Does this crash look familiar to anyone? > >> It's in 6.1 unfortunatly.. > > > > Is this a USB modem ? > > no it's a pty Maybe you should add a "mtx_assert(&Giant, MA_OWNED);" there to check if the caller is really holding Giant! --HPS From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 07:22:44 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A927F16A40F for ; Fri, 13 Jul 2007 07:22:44 +0000 (UTC) (envelope-from michiel@boland.org) Received: from neerbosch.nijmegen.internl.net (neerbosch.nijmegen.internl.net [217.149.193.38]) by mx1.freebsd.org (Postfix) with ESMTP id 306B613C4A8 for ; Fri, 13 Jul 2007 07:22:44 +0000 (UTC) (envelope-from michiel@boland.org) Received: from neerbosch.nijmegen.internl.net by neerbosch.nijmegen.internl.net via neerbosch.nijmegen.internl.net [217.149.193.38] with ESMTP for id l6D7MgXv002836 (8.13.4/1.4); Fri, 13 Jul 2007 09:22:42 +0200 (MEST) Received: from localhost by neerbosch.nijmegen.internl.net via mboland@localhost with ESMTP for id l6D7Mg9r002832 (8.13.4/2.02); Fri, 13 Jul 2007 09:22:42 +0200 (MEST) X-Authentication-Warning: neerbosch.nijmegen.internl.net: mboland owned process doing -bs Date: Fri, 13 Jul 2007 09:22:42 +0200 (MEST) From: Michiel Boland To: freebsd-current@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: immediate reboot with ipnat/ipmon on amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2007 07:22:44 -0000 Hi. I wanted to try something out with nat. So I tried this with ipnat. But my -CURRENT amd64 box instantly reboots if I type # ipnat -l # ipmon -a No crash dump, nothing. Just immediate reboot. FWIW - ipfilter was built into the kernel (i.e. not a module) Anyone else seeing this? From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 07:35:49 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 591E216A400 for ; Fri, 13 Jul 2007 07:35:49 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.170]) by mx1.freebsd.org (Postfix) with ESMTP id D442F13C4B6 for ; Fri, 13 Jul 2007 07:35:48 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by ug-out-1314.google.com with SMTP id o4so573539uge for ; Fri, 13 Jul 2007 00:35:47 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:reply-to:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding:sender; b=L41/dWTaGkdQM+x7Ecly60yvWfpvRH3bc/eQu5x1bAyxGxhlGpR6j7fw0tz+lRhekJrq36L3phmZfjlBvkUrddPZLKGk7PL+9DcPYZsOM3hpLyvc+Ll5fa/E9eCFu6FncL+Ko7h7Zuzi8qOijcr1rqehBWl3mRPxDdes+rERvvc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:reply-to:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding:sender; b=KStdWmxH/bvTKZClORAe1gh3IWzrThp5IPdVFoD9+WO+zeIQHjVBUriMWZfbXOupskLyRC6AYi0rsRA3yhsCQiB6SCaccAIFhHMUnLbV6AURnFRqOol2IL308LwMQdUgWhLzbk1DJy4gUK24l+WhUge9cKgJb3yeOs9mPwWcOCM= Received: by 10.67.93.7 with SMTP id v7mr1825727ugl.1184312147675; Fri, 13 Jul 2007 00:35:47 -0700 (PDT) Received: from ?172.31.5.25? ( [89.97.252.178]) by mx.google.com with ESMTP id 35sm6599914nfu.2007.07.13.00.35.47 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 13 Jul 2007 00:35:47 -0700 (PDT) Message-ID: <46972B28.1010409@FreeBSD.org> Date: Fri, 13 Jul 2007 09:35:04 +0200 From: Attilio Rao User-Agent: Thunderbird 1.5 (X11/20060526) MIME-Version: 1.0 To: Julian Elischer References: <46970DF7.3000803@elischer.org> In-Reply-To: <46970DF7.3000803@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: Attilio Rao Cc: FreeBSD Current Subject: Re: crash in tty code in 6.1.. fixed since? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: attilio@FreeBSD.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2007 07:35:49 -0000 Julian Elischer wrote: > Does this crash look familiar to anyone? > It's in 6.1 unfortunatly.. > > #6 0xc069ca6a in calltrap () at ../../../i386/i386/exception.s:139 > #7 0xc0587012 in ttymodem (tp=0xc6990800, flag=-1065963704) > at ../../../kern/tty.c:1659 > #8 0xc058b83e in ptcclose (dev=0x0, flags=7, fmt=8192, td=0xc6966d80) > at linedisc.h:136 > #9 0xc052bf77 in giant_close (dev=0xc7547c00, fflag=7, devtype=8192, > td=0xc6966d80) at ../../../kern/kern_conf.c:266 > #10 0xc051685f in devfs_close (ap=0xe706baa4) > at ../../../fs/devfs/devfs_vnops.c:287 > #11 0xc06c2a10 in VOP_CLOSE_APV (vop=0x0, a=0xc076af48) at vnode_if.c:426 > #12 0xc05bf3ce in vn_close (vp=0xc764e550, flags=7, file_cred=0x0, > td=0xc6966d80) at vnode_if.h:227 > #13 0xc05c0212 in vn_closefile (fp=0xc7532510, td=0xc6966d80) > at ../../../kern/vfs_vnops.c:852 > #14 0xc0516887 in devfs_close_f (fp=0xc7532510, td=0xc6966d80) > at ../../../fs/devfs/devfs_vnops.c:297 > #15 0xc05361e8 in fdrop_locked (fp=0xc7532510, td=0xc6966d80) at file.h:289 > #16 0xc0536135 in fdrop (fp=0xc7532510, td=0xc6966d80) > at ../../../kern/kern_descrip.c:2122 > #17 0xc05346d3 in closef (fp=0xc7532510, td=0xc6966d80) > at ../../../kern/kern_descrip.c:1942 > #18 0xc0533487 in fdfree (td=0xc6966d80) at > ../../../kern/kern_descrip.c:1627 > #19 0xc053cc88 in exit1 (td=0xc6966d80, rv=15) at > ../../../kern/kern_exit.c:263 > #20 0xc055b58b in sigexit (td=0xc6966d80, sig=15) > at ../../../kern/kern_sig.c:2451 > #21 0xc055b296 in postsig (sig=15) at ../../../kern/kern_sig.c:2326 > #22 0xc0577fbe in ast (framep=0xe706bd38) at ../../../kern/subr_trap.c:266 > #23 0xc069d3ad in doreti_ast () at ../../../i386/i386/exception.s:293 > > (kgdb) up > #7 0xc0587012 in ttymodem (tp=0xc6990800, flag=-1065963704) > at ../../../kern/tty.c:1659 > 1659 if (tp->t_session->s_leader) { > Current language: auto; currently c > (kgdb) list > 1654 !ISSET(tp->t_cflag, CLOCAL)) { > 1655 SET(tp->t_state, TS_ZOMBIE); > 1656 CLR(tp->t_state, TS_CONNECTED); > 1657 if (tp->t_session) { > 1658 sx_slock(&proctree_lock); > 1659 if (tp->t_session->s_leader) { > 1660 struct proc *p; > 1661 > 1662 p = > tp->t_session->s_leader; > 1663 PROC_LOCK(p); > > (kgdb) set print pretty > (kgdb) p *tp > $3 = { > t_rawq = { > c_cc = 0, > [...] > > t_outcc = 119661, t_line = 0, t_dev = 0xc763fe00, t_mdev = 0x0, > t_devunit = 0, t_state = 0, t_flags = 0, t_timeout = 300000, t_pgrp > = 0x0, t_session = 0x0, t_sigio = 0x0, t_rsel = { > si_thrlist = { > tqe_next = 0x0, tqe_prev = 0x0 > }, si_thread = 0x0, si_note = { > [...] > > > tp_session is NULL but it shouldn't have been able to have run that line > (line 1659) if it had tested NULL 2 lines before.. > this suggests a locking problem.. I think it has been fixed some months ago IIRC. The problem here, should be that if sx_slock() let thread sleep, Giant is released before to sleep and tp->t_session can be accessed in racy way. Another nice side-effect about having tty Giant :) Attilio PS: I think I alredy documented these kinds of bugs in my locking documentation in perforce. From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 07:47:58 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 064B016A401 for ; Fri, 13 Jul 2007 07:47:58 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe12.swip.net [212.247.155.97]) by mx1.freebsd.org (Postfix) with ESMTP id 9470613C4BA for ; Fri, 13 Jul 2007 07:47:57 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] Received: from [194.248.135.20] (account mc467741@c2i.net HELO laptop.lan) by mailfe12.swip.net (CommuniGate Pro SMTP 5.1.10) with ESMTPA id 373814781; Fri, 13 Jul 2007 08:47:54 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Fri, 13 Jul 2007 08:47:57 +0200 User-Agent: KMail/1.9.5 References: <46970DF7.3000803@elischer.org> <200707130751.48815.hselasky@c2i.net> <4697148F.8020304@elischer.org> In-Reply-To: <4697148F.8020304@elischer.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200707130847.57829.hselasky@c2i.net> Cc: Julian Elischer , FreeBSD Current Subject: Re: crash in tty code in 6.1.. fixed since? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2007 07:47:58 -0000 On Friday 13 July 2007 07:58, Julian Elischer wrote: > Hans Petter Selasky wrote: > > On Friday 13 July 2007 07:30, Julian Elischer wrote: > >> Does this crash look familiar to anyone? > >> It's in 6.1 unfortunatly.. > > > > Is this a USB modem ? > > no it's a pty Maybe you should add a "mtx_assert(&Giant, MA_OWNED);" there to check if the caller is really holding Giant! --HPS From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 08:07:45 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1EC2B16A401 for ; Fri, 13 Jul 2007 08:07:45 +0000 (UTC) (envelope-from ubm@u-boot-man.de) Received: from mail.upper.net (mail.upper.net [62.75.224.33]) by mx1.freebsd.org (Postfix) with ESMTP id B3AC013C428 for ; Fri, 13 Jul 2007 08:07:44 +0000 (UTC) (envelope-from ubm@u-boot-man.de) Received: from ubm.mine.nu (p57AE01F2.dip0.t-ipconnect.de [87.174.1.242]) (authenticated bits=0) by mail.upper.net (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l6D87dgZ028718 for ; Fri, 13 Jul 2007 10:07:40 +0200 Date: Fri, 13 Jul 2007 10:14:06 +0200 From: Marc "UBM" Bocklet To: freebsd-current@freebsd.org Message-Id: <20070713101406.00409c43.ubm@u-boot-man.de> In-Reply-To: References: X-Mailer: Sylpheed 2.4.0 (GTK+ 2.10.12; i386-portbld-freebsd6.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: immediate reboot with ipnat/ipmon on amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2007 08:07:45 -0000 On Fri, 13 Jul 2007 09:22:42 +0200 (MEST) Michiel Boland wrote: > Hi. I wanted to try something out with nat. So I tried this with > ipnat. But my -CURRENT amd64 box instantly reboots if I type > > # ipnat -l > # ipmon -a > > No crash dump, nothing. Just immediate reboot. > > FWIW - ipfilter was built into the kernel (i.e. not a module) > > Anyone else seeing this? I'm not seeing this with ipfilter as a module on i386: root@ubm:/usr/home/sheep# ipnat -l List of active MAP/Redirect filters: List of active sessions: root@ubm:/usr/home/sheep# ipmon -a ^C root@ubm:/usr/home/sheep# uname -a FreeBSD blah.blah 7.0-CURRENT FreeBSD 7.0-CURRENT #0: Mon Jul 9 17:06:47 CEST 2007 Bye Marc -- "And what rough beast, its hour come round at last, Slouches towards Bethlehem to be born?" W.B. Yeats, The Second Coming From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 08:19:35 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4299E16A401 for ; Fri, 13 Jul 2007 08:19:35 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [210.51.165.229]) by mx1.freebsd.org (Postfix) with ESMTP id EABF613C481 for ; Fri, 13 Jul 2007 08:19:34 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from localhost (tarsier.geekcn.org [210.51.165.229]) by tarsier.geekcn.org (Postfix) with ESMTP id 24080EB48F3; Fri, 13 Jul 2007 16:19:34 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([210.51.165.229]) by localhost (mail.geekcn.org [210.51.165.229]) (amavisd-new, port 10024) with ESMTP id CRPyip1YF-+o; Fri, 13 Jul 2007 16:19:29 +0800 (CST) Received: from LI-Xins-MacBook.local (sina152-194.staff.sina.com.cn [61.135.152.194]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTP id 65C3DEB680A; Fri, 13 Jul 2007 16:19:29 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:cc:subject:references:in-reply-to: x-enigmail-version:openpgp:content-type; b=ZA2bIu24gJpdEVeNlWRKPA8qo7TCckr5PuhRF+jYBv+mDCk7Q9aMGZQRTYxaC6tvz 5V4DuMQI4zZhRMlKm/ZLA== Message-ID: <46973584.9020404@delphij.net> Date: Fri, 13 Jul 2007 16:19:16 +0800 From: LI Xin Organization: The FreeBSD Project User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) MIME-Version: 1.0 To: Michiel Boland References: In-Reply-To: X-Enigmail-Version: 0.95.2 OpenPGP: url=http://www.delphij.net/delphij.asc Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enigB303AACD41139BAE40737805" Cc: freebsd-current@freebsd.org Subject: Re: immediate reboot with ipnat/ipmon on amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2007 08:19:35 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB303AACD41139BAE40737805 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Michiel Boland wrote: > Hi. I wanted to try something out with nat. So I tried this with ipnat.= > But my -CURRENT amd64 box instantly reboots if I type >=20 > # ipnat -l > # ipmon -a >=20 > No crash dump, nothing. Just immediate reboot. Do you have access to system console to confirm that it does not panic and just rebooted? Looks like a panic I think... Cheers, --=20 Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! --------------enigB303AACD41139BAE40737805 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.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGlzWEOfuToMruuMARCjR7AJ4vKxYSr8vD4lza+PfxR7FT3YzJ9ACcDgYm z2ZhF6W41PuNKMhd/34l40I= =P9+3 -----END PGP SIGNATURE----- --------------enigB303AACD41139BAE40737805-- From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 08:22:02 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F420A16A401; Fri, 13 Jul 2007 08:22:01 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe01.swip.net [212.247.154.1]) by mx1.freebsd.org (Postfix) with ESMTP id D14B213C441; Fri, 13 Jul 2007 08:22:00 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] Received: from [194.248.135.20] (account mc467741@c2i.net HELO laptop.lan) by mailfe01.swip.net (CommuniGate Pro SMTP 5.1.10) with ESMTPA id 525531068; Fri, 13 Jul 2007 10:21:59 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org, attilio@freebsd.org Date: Fri, 13 Jul 2007 10:21:59 +0200 User-Agent: KMail/1.9.5 References: <46970DF7.3000803@elischer.org> <46972B28.1010409@FreeBSD.org> In-Reply-To: <46972B28.1010409@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200707131021.59966.hselasky@c2i.net> Cc: Julian Elischer , FreeBSD Current Subject: Re: crash in tty code in 6.1.. fixed since? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2007 08:22:02 -0000 On Friday 13 July 2007 09:35, Attilio Rao wrote: > Julian Elischer wrote: > > Does this crash look familiar to anyone? > > It's in 6.1 unfortunatly.. > > > > #6 0xc069ca6a in calltrap () at ../../../i386/i386/exception.s:139 > > #7 0xc0587012 in ttymodem (tp=0xc6990800, flag=-1065963704) > > at ../../../kern/tty.c:1659 > > #8 0xc058b83e in ptcclose (dev=0x0, flags=7, fmt=8192, td=0xc6966d80) > > at linedisc.h:136 > > #9 0xc052bf77 in giant_close (dev=0xc7547c00, fflag=7, devtype=8192, > > td=0xc6966d80) at ../../../kern/kern_conf.c:266 > > #10 0xc051685f in devfs_close (ap=0xe706baa4) > > at ../../../fs/devfs/devfs_vnops.c:287 > > #11 0xc06c2a10 in VOP_CLOSE_APV (vop=0x0, a=0xc076af48) at vnode_if.c:426 > > #12 0xc05bf3ce in vn_close (vp=0xc764e550, flags=7, file_cred=0x0, > > td=0xc6966d80) at vnode_if.h:227 > > #13 0xc05c0212 in vn_closefile (fp=0xc7532510, td=0xc6966d80) > > at ../../../kern/vfs_vnops.c:852 > > #14 0xc0516887 in devfs_close_f (fp=0xc7532510, td=0xc6966d80) > > at ../../../fs/devfs/devfs_vnops.c:297 > > #15 0xc05361e8 in fdrop_locked (fp=0xc7532510, td=0xc6966d80) at > > file.h:289 #16 0xc0536135 in fdrop (fp=0xc7532510, td=0xc6966d80) > > at ../../../kern/kern_descrip.c:2122 > > #17 0xc05346d3 in closef (fp=0xc7532510, td=0xc6966d80) > > at ../../../kern/kern_descrip.c:1942 > > #18 0xc0533487 in fdfree (td=0xc6966d80) at > > ../../../kern/kern_descrip.c:1627 > > #19 0xc053cc88 in exit1 (td=0xc6966d80, rv=15) at > > ../../../kern/kern_exit.c:263 > > #20 0xc055b58b in sigexit (td=0xc6966d80, sig=15) > > at ../../../kern/kern_sig.c:2451 > > #21 0xc055b296 in postsig (sig=15) at ../../../kern/kern_sig.c:2326 > > #22 0xc0577fbe in ast (framep=0xe706bd38) at > > ../../../kern/subr_trap.c:266 #23 0xc069d3ad in doreti_ast () at > > ../../../i386/i386/exception.s:293 > > > > (kgdb) up > > #7 0xc0587012 in ttymodem (tp=0xc6990800, flag=-1065963704) > > at ../../../kern/tty.c:1659 > > 1659 if (tp->t_session->s_leader) { > > Current language: auto; currently c > > (kgdb) list > > 1654 !ISSET(tp->t_cflag, CLOCAL)) { > > 1655 SET(tp->t_state, TS_ZOMBIE); > > 1656 CLR(tp->t_state, TS_CONNECTED); > > 1657 if (tp->t_session) { > > 1658 sx_slock(&proctree_lock); > > 1659 if (tp->t_session->s_leader) { > > 1660 struct proc *p; > > 1661 > > 1662 p = > > tp->t_session->s_leader; > > 1663 PROC_LOCK(p); > > > > (kgdb) set print pretty > > (kgdb) p *tp > > $3 = { > > t_rawq = { > > c_cc = 0, > > [...] > > > > t_outcc = 119661, t_line = 0, t_dev = 0xc763fe00, t_mdev = 0x0, > > t_devunit = 0, t_state = 0, t_flags = 0, t_timeout = 300000, t_pgrp > > = 0x0, t_session = 0x0, t_sigio = 0x0, t_rsel = { > > si_thrlist = { > > tqe_next = 0x0, tqe_prev = 0x0 > > }, si_thread = 0x0, si_note = { > > [...] > > > > > > tp_session is NULL but it shouldn't have been able to have run that line > > (line 1659) if it had tested NULL 2 lines before.. > > this suggests a locking problem.. > > I think it has been fixed some months ago IIRC. > The problem here, should be that if sx_slock() let thread sleep, Giant > is released before to sleep and tp->t_session can be accessed in racy way. > Another nice side-effect about having tty Giant :) > If TTY was not Giant locked, you would have had an error there if another mutex was locked, and the problem would have been solved years ago :-) Maybe related: Regarding the keyboard system which is also Giant locked, we should add assert Giant statements, because I see several callers doing calls into the keyboard system without holding Giant! --HPS From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 08:22:02 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F420A16A401; Fri, 13 Jul 2007 08:22:01 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe01.swip.net [212.247.154.1]) by mx1.freebsd.org (Postfix) with ESMTP id D14B213C441; Fri, 13 Jul 2007 08:22:00 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] Received: from [194.248.135.20] (account mc467741@c2i.net HELO laptop.lan) by mailfe01.swip.net (CommuniGate Pro SMTP 5.1.10) with ESMTPA id 525531068; Fri, 13 Jul 2007 10:21:59 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org, attilio@freebsd.org Date: Fri, 13 Jul 2007 10:21:59 +0200 User-Agent: KMail/1.9.5 References: <46970DF7.3000803@elischer.org> <46972B28.1010409@FreeBSD.org> In-Reply-To: <46972B28.1010409@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200707131021.59966.hselasky@c2i.net> Cc: Julian Elischer , FreeBSD Current Subject: Re: crash in tty code in 6.1.. fixed since? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2007 08:22:02 -0000 On Friday 13 July 2007 09:35, Attilio Rao wrote: > Julian Elischer wrote: > > Does this crash look familiar to anyone? > > It's in 6.1 unfortunatly.. > > > > #6 0xc069ca6a in calltrap () at ../../../i386/i386/exception.s:139 > > #7 0xc0587012 in ttymodem (tp=0xc6990800, flag=-1065963704) > > at ../../../kern/tty.c:1659 > > #8 0xc058b83e in ptcclose (dev=0x0, flags=7, fmt=8192, td=0xc6966d80) > > at linedisc.h:136 > > #9 0xc052bf77 in giant_close (dev=0xc7547c00, fflag=7, devtype=8192, > > td=0xc6966d80) at ../../../kern/kern_conf.c:266 > > #10 0xc051685f in devfs_close (ap=0xe706baa4) > > at ../../../fs/devfs/devfs_vnops.c:287 > > #11 0xc06c2a10 in VOP_CLOSE_APV (vop=0x0, a=0xc076af48) at vnode_if.c:426 > > #12 0xc05bf3ce in vn_close (vp=0xc764e550, flags=7, file_cred=0x0, > > td=0xc6966d80) at vnode_if.h:227 > > #13 0xc05c0212 in vn_closefile (fp=0xc7532510, td=0xc6966d80) > > at ../../../kern/vfs_vnops.c:852 > > #14 0xc0516887 in devfs_close_f (fp=0xc7532510, td=0xc6966d80) > > at ../../../fs/devfs/devfs_vnops.c:297 > > #15 0xc05361e8 in fdrop_locked (fp=0xc7532510, td=0xc6966d80) at > > file.h:289 #16 0xc0536135 in fdrop (fp=0xc7532510, td=0xc6966d80) > > at ../../../kern/kern_descrip.c:2122 > > #17 0xc05346d3 in closef (fp=0xc7532510, td=0xc6966d80) > > at ../../../kern/kern_descrip.c:1942 > > #18 0xc0533487 in fdfree (td=0xc6966d80) at > > ../../../kern/kern_descrip.c:1627 > > #19 0xc053cc88 in exit1 (td=0xc6966d80, rv=15) at > > ../../../kern/kern_exit.c:263 > > #20 0xc055b58b in sigexit (td=0xc6966d80, sig=15) > > at ../../../kern/kern_sig.c:2451 > > #21 0xc055b296 in postsig (sig=15) at ../../../kern/kern_sig.c:2326 > > #22 0xc0577fbe in ast (framep=0xe706bd38) at > > ../../../kern/subr_trap.c:266 #23 0xc069d3ad in doreti_ast () at > > ../../../i386/i386/exception.s:293 > > > > (kgdb) up > > #7 0xc0587012 in ttymodem (tp=0xc6990800, flag=-1065963704) > > at ../../../kern/tty.c:1659 > > 1659 if (tp->t_session->s_leader) { > > Current language: auto; currently c > > (kgdb) list > > 1654 !ISSET(tp->t_cflag, CLOCAL)) { > > 1655 SET(tp->t_state, TS_ZOMBIE); > > 1656 CLR(tp->t_state, TS_CONNECTED); > > 1657 if (tp->t_session) { > > 1658 sx_slock(&proctree_lock); > > 1659 if (tp->t_session->s_leader) { > > 1660 struct proc *p; > > 1661 > > 1662 p = > > tp->t_session->s_leader; > > 1663 PROC_LOCK(p); > > > > (kgdb) set print pretty > > (kgdb) p *tp > > $3 = { > > t_rawq = { > > c_cc = 0, > > [...] > > > > t_outcc = 119661, t_line = 0, t_dev = 0xc763fe00, t_mdev = 0x0, > > t_devunit = 0, t_state = 0, t_flags = 0, t_timeout = 300000, t_pgrp > > = 0x0, t_session = 0x0, t_sigio = 0x0, t_rsel = { > > si_thrlist = { > > tqe_next = 0x0, tqe_prev = 0x0 > > }, si_thread = 0x0, si_note = { > > [...] > > > > > > tp_session is NULL but it shouldn't have been able to have run that line > > (line 1659) if it had tested NULL 2 lines before.. > > this suggests a locking problem.. > > I think it has been fixed some months ago IIRC. > The problem here, should be that if sx_slock() let thread sleep, Giant > is released before to sleep and tp->t_session can be accessed in racy way. > Another nice side-effect about having tty Giant :) > If TTY was not Giant locked, you would have had an error there if another mutex was locked, and the problem would have been solved years ago :-) Maybe related: Regarding the keyboard system which is also Giant locked, we should add assert Giant statements, because I see several callers doing calls into the keyboard system without holding Giant! --HPS From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 08:26:26 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AA5FB16A400 for ; Fri, 13 Jul 2007 08:26:26 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.173]) by mx1.freebsd.org (Postfix) with ESMTP id 327F913C4BC for ; Fri, 13 Jul 2007 08:26:25 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by ug-out-1314.google.com with SMTP id o4so581820uge for ; Fri, 13 Jul 2007 01:26:25 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:reply-to:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding:sender; b=ISTHR4QiALyH6dagtN5igaCoQs13FJjUEr5tqlHdtj4Njm2+7W5p0l+uiaz5aJ0COVIx/kcKuo141zHzlBLldxLyK3D/mbVyXW5+5s3zVwkRVAg3FaNXx3eib76/QBfa0GHx870s2UaGsQLDq35fdtotbczBG4M8brDxrd9vQP8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:reply-to:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding:sender; b=Nv8dLkuGmKN2hhZz3PAbWRETZZs8eAZlggh/8lqgSj1nTSR2XDXMu9P5XqNHAJPC7Pw8xBQvSyYaeRoq6qgD77LXJgwBjkQqo+A/gSDdDD/QNIqwj4jAOK6srVdp6k01H9ux6/SigoT6/LAVhExJcCrLoT6OQjJGtogYz0wtBHs= Received: by 10.82.162.14 with SMTP id k14mr1606292bue.1184315184949; Fri, 13 Jul 2007 01:26:24 -0700 (PDT) Received: from ?172.31.5.25? ( [89.97.252.178]) by mx.google.com with ESMTP id d26sm11291889nfh.2007.07.13.01.26.24 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 13 Jul 2007 01:26:24 -0700 (PDT) Message-ID: <46973708.2040401@FreeBSD.org> Date: Fri, 13 Jul 2007 10:25:44 +0200 From: Attilio Rao User-Agent: Thunderbird 1.5 (X11/20060526) MIME-Version: 1.0 To: Hans Petter Selasky References: <46970DF7.3000803@elischer.org> <46972B28.1010409@FreeBSD.org> <200707131021.59966.hselasky@c2i.net> In-Reply-To: <200707131021.59966.hselasky@c2i.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: Attilio Rao Cc: freebsd-current@freebsd.org, Julian Elischer , FreeBSD Current Subject: Re: crash in tty code in 6.1.. fixed since? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: attilio@FreeBSD.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2007 08:26:26 -0000 Hans Petter Selasky wrote: > > If TTY was not Giant locked, you would have had an error there if another > mutex was locked, and the problem would have been solved years ago :-) Not sure what you mean, but the first evidence is that you would have explicitly drop/pickup the mutex so that you would have handled the race not trasparently as Giant does. Moreover, it seems that tty should be partially locked with a sleeping primitive (sx probabilly). Attilio From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 08:26:26 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B505E16A402 for ; Fri, 13 Jul 2007 08:26:26 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.172]) by mx1.freebsd.org (Postfix) with ESMTP id 3B07913C4BE for ; Fri, 13 Jul 2007 08:26:25 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by ug-out-1314.google.com with SMTP id o4so581819uge for ; Fri, 13 Jul 2007 01:26:25 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:reply-to:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding:sender; b=ISTHR4QiALyH6dagtN5igaCoQs13FJjUEr5tqlHdtj4Njm2+7W5p0l+uiaz5aJ0COVIx/kcKuo141zHzlBLldxLyK3D/mbVyXW5+5s3zVwkRVAg3FaNXx3eib76/QBfa0GHx870s2UaGsQLDq35fdtotbczBG4M8brDxrd9vQP8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:reply-to:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding:sender; b=Nv8dLkuGmKN2hhZz3PAbWRETZZs8eAZlggh/8lqgSj1nTSR2XDXMu9P5XqNHAJPC7Pw8xBQvSyYaeRoq6qgD77LXJgwBjkQqo+A/gSDdDD/QNIqwj4jAOK6srVdp6k01H9ux6/SigoT6/LAVhExJcCrLoT6OQjJGtogYz0wtBHs= Received: by 10.82.162.14 with SMTP id k14mr1606292bue.1184315184949; Fri, 13 Jul 2007 01:26:24 -0700 (PDT) Received: from ?172.31.5.25? ( [89.97.252.178]) by mx.google.com with ESMTP id d26sm11291889nfh.2007.07.13.01.26.24 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 13 Jul 2007 01:26:24 -0700 (PDT) Message-ID: <46973708.2040401@FreeBSD.org> Date: Fri, 13 Jul 2007 10:25:44 +0200 From: Attilio Rao User-Agent: Thunderbird 1.5 (X11/20060526) MIME-Version: 1.0 To: Hans Petter Selasky References: <46970DF7.3000803@elischer.org> <46972B28.1010409@FreeBSD.org> <200707131021.59966.hselasky@c2i.net> In-Reply-To: <200707131021.59966.hselasky@c2i.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: Attilio Rao Cc: freebsd-current@freebsd.org, Julian Elischer , FreeBSD Current Subject: Re: crash in tty code in 6.1.. fixed since? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: attilio@FreeBSD.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2007 08:26:26 -0000 Hans Petter Selasky wrote: > > If TTY was not Giant locked, you would have had an error there if another > mutex was locked, and the problem would have been solved years ago :-) Not sure what you mean, but the first evidence is that you would have explicitly drop/pickup the mutex so that you would have handled the race not trasparently as Giant does. Moreover, it seems that tty should be partially locked with a sleeping primitive (sx probabilly). Attilio From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 08:27:23 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 57B2616A40D; Fri, 13 Jul 2007 08:27:23 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from relay02.kiev.sovam.com (relay02.kiev.sovam.com [62.64.120.197]) by mx1.freebsd.org (Postfix) with ESMTP id DD79313C51B; Fri, 13 Jul 2007 08:27:22 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from [89.162.146.170] (helo=skuns.kiev.zoral.com.ua) by relay02.kiev.sovam.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1I9GUe-000Dch-4H; Fri, 13 Jul 2007 11:27:19 +0300 Received: from deviant.kiev.zoral.com.ua (root@[10.1.1.148]) by skuns.kiev.zoral.com.ua (8.14.1/8.14.1) with ESMTP id l6D8R6qA020407 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Jul 2007 11:27:06 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.1/8.14.1) with ESMTP id l6D8R6GB045262; Fri, 13 Jul 2007 11:27:06 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.1/8.14.1/Submit) id l6D8R5Pt045261; Fri, 13 Jul 2007 11:27:05 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 13 Jul 2007 11:27:05 +0300 From: Kostik Belousov To: Attilio Rao Message-ID: <20070713082705.GI2200@deviant.kiev.zoral.com.ua> References: <46970DF7.3000803@elischer.org> <46972B28.1010409@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="FyU5fTJCTr/6Eq8v" Content-Disposition: inline In-Reply-To: <46972B28.1010409@FreeBSD.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.90.3, clamav-milter version 0.90.3 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.2.1 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on skuns.kiev.zoral.com.ua X-Scanner-Signature: fd47f7ed058f8bb752f6c36e497d0305 X-DrWeb-checked: yes X-SpamTest-Envelope-From: kostikbel@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Header: Not Detected X-SpamTest-Info: Profiles 1217 [July 12 2007] X-SpamTest-Info: helo_type=3 X-SpamTest-Method: none X-SpamTest-Rate: 0 X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0255], KAS30/Release Cc: Julian Elischer , FreeBSD Current Subject: Re: crash in tty code in 6.1.. fixed since? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2007 08:27:23 -0000 --FyU5fTJCTr/6Eq8v Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jul 13, 2007 at 09:35:04AM +0200, Attilio Rao wrote: > Julian Elischer wrote: > >Does this crash look familiar to anyone? > >It's in 6.1 unfortunatly.. > > > >#6 0xc069ca6a in calltrap () at ../../../i386/i386/exception.s:139 > >#7 0xc0587012 in ttymodem (tp=3D0xc6990800, flag=3D-1065963704) > > at ../../../kern/tty.c:1659 > >#8 0xc058b83e in ptcclose (dev=3D0x0, flags=3D7, fmt=3D8192, td=3D0xc69= 66d80) > > at linedisc.h:136 > >#9 0xc052bf77 in giant_close (dev=3D0xc7547c00, fflag=3D7, devtype=3D81= 92, =20 > >td=3D0xc6966d80) at ../../../kern/kern_conf.c:266 > >#10 0xc051685f in devfs_close (ap=3D0xe706baa4) > > at ../../../fs/devfs/devfs_vnops.c:287 > >#11 0xc06c2a10 in VOP_CLOSE_APV (vop=3D0x0, a=3D0xc076af48) at vnode_if.= c:426 > >#12 0xc05bf3ce in vn_close (vp=3D0xc764e550, flags=3D7, file_cred=3D0x0,= =20 > >td=3D0xc6966d80) at vnode_if.h:227 > >#13 0xc05c0212 in vn_closefile (fp=3D0xc7532510, td=3D0xc6966d80) > > at ../../../kern/vfs_vnops.c:852 > >#14 0xc0516887 in devfs_close_f (fp=3D0xc7532510, td=3D0xc6966d80) > > at ../../../fs/devfs/devfs_vnops.c:297 > >#15 0xc05361e8 in fdrop_locked (fp=3D0xc7532510, td=3D0xc6966d80) at fil= e.h:289 > >#16 0xc0536135 in fdrop (fp=3D0xc7532510, td=3D0xc6966d80) > > at ../../../kern/kern_descrip.c:2122 > >#17 0xc05346d3 in closef (fp=3D0xc7532510, td=3D0xc6966d80) > > at ../../../kern/kern_descrip.c:1942 > >#18 0xc0533487 in fdfree (td=3D0xc6966d80) at=20 > >../../../kern/kern_descrip.c:1627 > >#19 0xc053cc88 in exit1 (td=3D0xc6966d80, rv=3D15) at=20 > >../../../kern/kern_exit.c:263 > >#20 0xc055b58b in sigexit (td=3D0xc6966d80, sig=3D15) > > at ../../../kern/kern_sig.c:2451 > >#21 0xc055b296 in postsig (sig=3D15) at ../../../kern/kern_sig.c:2326 > >#22 0xc0577fbe in ast (framep=3D0xe706bd38) at ../../../kern/subr_trap.c= :266 > >#23 0xc069d3ad in doreti_ast () at ../../../i386/i386/exception.s:293 > > > >(kgdb) up > >#7 0xc0587012 in ttymodem (tp=3D0xc6990800, flag=3D-1065963704) > > at ../../../kern/tty.c:1659 > >1659 if (tp->t_session->s_leader) { > >Current language: auto; currently c > >(kgdb) list > >1654 !ISSET(tp->t_cflag, CLOCAL)) { > >1655 SET(tp->t_state, TS_ZOMBIE); > >1656 CLR(tp->t_state, TS_CONNECTED); > >1657 if (tp->t_session) { > >1658 sx_slock(&proctree_lock); > >1659 if (tp->t_session->s_leader) { > >1660 struct proc *p; > >1661 > >1662 p =3D=20 > >tp->t_session->s_leader; > >1663 PROC_LOCK(p); > > > >(kgdb) set print pretty > >(kgdb) p *tp > >$3 =3D { > > t_rawq =3D { > > c_cc =3D 0, > >[...] > > > > t_outcc =3D 119661, t_line =3D 0, t_dev =3D 0xc763fe00, t_mdev =3D 0= x0,=20 > > t_devunit =3D 0, t_state =3D 0, t_flags =3D 0, t_timeout =3D 300000,= t_pgrp=20 > >=3D 0x0, t_session =3D 0x0, t_sigio =3D 0x0, t_rsel =3D { > > si_thrlist =3D { > > tqe_next =3D 0x0, tqe_prev =3D 0x0 > > }, si_thread =3D 0x0, si_note =3D { > > [...] > > > > > >tp_session is NULL but it shouldn't have been able to have run that line= =20 > >(line 1659) if it had tested NULL 2 lines before.. > >this suggests a locking problem.. >=20 > I think it has been fixed some months ago IIRC. > The problem here, should be that if sx_slock() let thread sleep, Giant=20 > is released before to sleep and tp->t_session can be accessed in racy way. > Another nice side-effect about having tty Giant :) Yes, it seems that rev. 1.267 fixed it and was MFCed as rev. 1.228.2.6. There was a lot of commits around this one, it may be safer to update to RELENG_6. --FyU5fTJCTr/6Eq8v Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGlzdYC3+MBN1Mb4gRAsEsAKDRz9V2Yvp1DZe6ZVOBaYma+JQPhwCfTHeo xm7KhWy0n9MUgT3MTF7kWCk= =Oc6E -----END PGP SIGNATURE----- --FyU5fTJCTr/6Eq8v-- From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 08:38:52 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E858D16A420; Fri, 13 Jul 2007 08:38:52 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [210.51.165.229]) by mx1.freebsd.org (Postfix) with ESMTP id 53DAF13C4CB; Fri, 13 Jul 2007 08:38:52 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from localhost (tarsier.geekcn.org [210.51.165.229]) by tarsier.geekcn.org (Postfix) with ESMTP id F3187EB682C; Fri, 13 Jul 2007 16:38:49 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([210.51.165.229]) by localhost (mail.geekcn.org [210.51.165.229]) (amavisd-new, port 10024) with ESMTP id UIIntQBE6-Js; Fri, 13 Jul 2007 16:38:46 +0800 (CST) Received: from LI-Xins-MacBook.local (sina152-194.staff.sina.com.cn [61.135.152.194]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTP id A12AEEB6828; Fri, 13 Jul 2007 16:38:45 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:cc:subject:references:in-reply-to: x-enigmail-version:openpgp:content-type; b=IcSv7QNTBTZx1zp3ED5TyWH2O/RLDq72+hC5GKMT6aGJI5B8+v7HoSsDlYa6c9I34 6iWJVQKLBTbdED50eD96Q== Message-ID: <46973A08.3030607@delphij.net> Date: Fri, 13 Jul 2007 16:38:32 +0800 From: LI Xin Organization: The FreeBSD Project User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) MIME-Version: 1.0 To: Hans Petter Selasky References: <46970DF7.3000803@elischer.org> <46972B28.1010409@FreeBSD.org> <200707131021.59966.hselasky@c2i.net> In-Reply-To: <200707131021.59966.hselasky@c2i.net> X-Enigmail-Version: 0.95.2 OpenPGP: url=http://www.delphij.net/delphij.asc Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig75C34CAA7CA5F87B9A746A65" Cc: attilio@freebsd.org, freebsd-current@freebsd.org, Julian Elischer , FreeBSD Current Subject: Re: crash in tty code in 6.1.. fixed since? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2007 08:38:53 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig75C34CAA7CA5F87B9A746A65 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hans Petter Selasky wrote: [...] > Maybe related: >=20 > Regarding the keyboard system which is also Giant locked, we should add= assert=20 > Giant statements, because I see several callers doing calls into the ke= yboard=20 > system without holding Giant! I think that is a good idea. By adding these assertions our user community would be able to catch more under-exercised codepath under their workload. Do you already have some patch to add these assertions? Cheers, --=20 Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! --------------enig75C34CAA7CA5F87B9A746A65 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.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGlzoJOfuToMruuMARChHzAJ9y3wYKAZETR2Hg2sOvdHtDmp+oKgCfcRHf dYUS72s+nsfvw14rEcpYQCQ= =R4AN -----END PGP SIGNATURE----- --------------enig75C34CAA7CA5F87B9A746A65-- From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 08:38:52 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E858D16A420; Fri, 13 Jul 2007 08:38:52 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [210.51.165.229]) by mx1.freebsd.org (Postfix) with ESMTP id 53DAF13C4CB; Fri, 13 Jul 2007 08:38:52 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from localhost (tarsier.geekcn.org [210.51.165.229]) by tarsier.geekcn.org (Postfix) with ESMTP id F3187EB682C; Fri, 13 Jul 2007 16:38:49 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([210.51.165.229]) by localhost (mail.geekcn.org [210.51.165.229]) (amavisd-new, port 10024) with ESMTP id UIIntQBE6-Js; Fri, 13 Jul 2007 16:38:46 +0800 (CST) Received: from LI-Xins-MacBook.local (sina152-194.staff.sina.com.cn [61.135.152.194]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTP id A12AEEB6828; Fri, 13 Jul 2007 16:38:45 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:cc:subject:references:in-reply-to: x-enigmail-version:openpgp:content-type; b=IcSv7QNTBTZx1zp3ED5TyWH2O/RLDq72+hC5GKMT6aGJI5B8+v7HoSsDlYa6c9I34 6iWJVQKLBTbdED50eD96Q== Message-ID: <46973A08.3030607@delphij.net> Date: Fri, 13 Jul 2007 16:38:32 +0800 From: LI Xin Organization: The FreeBSD Project User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) MIME-Version: 1.0 To: Hans Petter Selasky References: <46970DF7.3000803@elischer.org> <46972B28.1010409@FreeBSD.org> <200707131021.59966.hselasky@c2i.net> In-Reply-To: <200707131021.59966.hselasky@c2i.net> X-Enigmail-Version: 0.95.2 OpenPGP: url=http://www.delphij.net/delphij.asc Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig75C34CAA7CA5F87B9A746A65" Cc: attilio@freebsd.org, freebsd-current@freebsd.org, Julian Elischer , FreeBSD Current Subject: Re: crash in tty code in 6.1.. fixed since? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2007 08:38:53 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig75C34CAA7CA5F87B9A746A65 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hans Petter Selasky wrote: [...] > Maybe related: >=20 > Regarding the keyboard system which is also Giant locked, we should add= assert=20 > Giant statements, because I see several callers doing calls into the ke= yboard=20 > system without holding Giant! I think that is a good idea. By adding these assertions our user community would be able to catch more under-exercised codepath under their workload. Do you already have some patch to add these assertions? Cheers, --=20 Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! --------------enig75C34CAA7CA5F87B9A746A65 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.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGlzoJOfuToMruuMARChHzAJ9y3wYKAZETR2Hg2sOvdHtDmp+oKgCfcRHf dYUS72s+nsfvw14rEcpYQCQ= =R4AN -----END PGP SIGNATURE----- --------------enig75C34CAA7CA5F87B9A746A65-- From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 08:54:16 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DD6DB16A403 for ; Fri, 13 Jul 2007 08:54:16 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from heff.fud.org.nz (203-109-251-39.static.bliink.ihug.co.nz [203.109.251.39]) by mx1.freebsd.org (Postfix) with ESMTP id 8447E13C491 for ; Fri, 13 Jul 2007 08:54:16 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: by heff.fud.org.nz (Postfix, from userid 1001) id CFF0D1CC5D; Fri, 13 Jul 2007 20:54:14 +1200 (NZST) Date: Fri, 13 Jul 2007 20:54:14 +1200 From: Andrew Thompson To: d@delphij.net Message-ID: <20070713085414.GC11395@heff.fud.org.nz> References: <46970DF7.3000803@elischer.org> <46972B28.1010409@FreeBSD.org> <200707131021.59966.hselasky@c2i.net> <46973A08.3030607@delphij.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46973A08.3030607@delphij.net> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: attilio@freebsd.org, freebsd-current@freebsd.org, Julian Elischer , Hans Petter Selasky Subject: Re: crash in tty code in 6.1.. fixed since? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2007 08:54:16 -0000 On Fri, Jul 13, 2007 at 04:38:32PM +0800, LI Xin wrote: > Hans Petter Selasky wrote: > [...] > > Maybe related: > > > > Regarding the keyboard system which is also Giant locked, we should add assert > > Giant statements, because I see several callers doing calls into the keyboard > > system without holding Giant! > > I think that is a good idea. By adding these assertions our user > community would be able to catch more under-exercised codepath under > their workload. Well hopefully the developer adding the assertions would attempt to find them all first rather than 'fishing' for a panic. :) From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 08:55:11 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1D93316A407; Fri, 13 Jul 2007 08:55:11 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe07.swip.net [212.247.154.193]) by mx1.freebsd.org (Postfix) with ESMTP id 4D98E13C4B3; Fri, 13 Jul 2007 08:55:09 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] Received: from [194.248.135.20] (account mc467741@c2i.net HELO laptop.lan) by mailfe07.swip.net (CommuniGate Pro SMTP 5.1.10) with ESMTPA id 546198060; Fri, 13 Jul 2007 10:55:08 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org, attilio@freebsd.org Date: Fri, 13 Jul 2007 10:55:12 +0200 User-Agent: KMail/1.9.5 References: <46970DF7.3000803@elischer.org> <200707131021.59966.hselasky@c2i.net> <46973708.2040401@FreeBSD.org> In-Reply-To: <46973708.2040401@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200707131055.12084.hselasky@c2i.net> Cc: Julian Elischer , FreeBSD Current Subject: Re: crash in tty code in 6.1.. fixed since? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2007 08:55:11 -0000 On Friday 13 July 2007 10:25, Attilio Rao wrote: > Hans Petter Selasky wrote: > > If TTY was not Giant locked, you would have had an error there if another > > mutex was locked, and the problem would have been solved years ago :-) > > Not sure what you mean, but the first evidence is that you would have > explicitly drop/pickup the mutex so that you would have handled the race > not trasparently as Giant does. > Moreover, it seems that tty should be partially locked with a sleeping > primitive (sx probabilly). > If you lock a mutex first and then a sx-lock, you should get a warning, right? --HPS From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 08:55:11 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1D93316A407; Fri, 13 Jul 2007 08:55:11 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe07.swip.net [212.247.154.193]) by mx1.freebsd.org (Postfix) with ESMTP id 4D98E13C4B3; Fri, 13 Jul 2007 08:55:09 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] Received: from [194.248.135.20] (account mc467741@c2i.net HELO laptop.lan) by mailfe07.swip.net (CommuniGate Pro SMTP 5.1.10) with ESMTPA id 546198060; Fri, 13 Jul 2007 10:55:08 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org, attilio@freebsd.org Date: Fri, 13 Jul 2007 10:55:12 +0200 User-Agent: KMail/1.9.5 References: <46970DF7.3000803@elischer.org> <200707131021.59966.hselasky@c2i.net> <46973708.2040401@FreeBSD.org> In-Reply-To: <46973708.2040401@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200707131055.12084.hselasky@c2i.net> Cc: Julian Elischer , FreeBSD Current Subject: Re: crash in tty code in 6.1.. fixed since? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2007 08:55:11 -0000 On Friday 13 July 2007 10:25, Attilio Rao wrote: > Hans Petter Selasky wrote: > > If TTY was not Giant locked, you would have had an error there if another > > mutex was locked, and the problem would have been solved years ago :-) > > Not sure what you mean, but the first evidence is that you would have > explicitly drop/pickup the mutex so that you would have handled the race > not trasparently as Giant does. > Moreover, it seems that tty should be partially locked with a sleeping > primitive (sx probabilly). > If you lock a mutex first and then a sx-lock, you should get a warning, right? --HPS From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 08:58:47 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B257816A402; Fri, 13 Jul 2007 08:58:47 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe01.swip.net [212.247.154.1]) by mx1.freebsd.org (Postfix) with ESMTP id EB49D13C481; Fri, 13 Jul 2007 08:58:46 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] Received: from [194.248.135.20] (account mc467741@c2i.net HELO laptop.lan) by mailfe01.swip.net (CommuniGate Pro SMTP 5.1.10) with ESMTPA id 525561390; Fri, 13 Jul 2007 10:58:45 +0200 From: Hans Petter Selasky To: d@delphij.net Date: Fri, 13 Jul 2007 10:58:48 +0200 User-Agent: KMail/1.9.5 References: <46970DF7.3000803@elischer.org> <200707131021.59966.hselasky@c2i.net> <46973A08.3030607@delphij.net> In-Reply-To: <46973A08.3030607@delphij.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200707131058.48999.hselasky@c2i.net> Cc: attilio@freebsd.org, freebsd-current@freebsd.org, Julian Elischer , FreeBSD Current Subject: Re: crash in tty code in 6.1.. fixed since? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2007 08:58:47 -0000 On Friday 13 July 2007 10:38, LI Xin wrote: > Hans Petter Selasky wrote: > [...] > > > Maybe related: > > > > Regarding the keyboard system which is also Giant locked, we should add > > assert Giant statements, because I see several callers doing calls into > > the keyboard system without holding Giant! > > I think that is a good idea. By adding these assertions our user > community would be able to catch more under-exercised codepath under > their workload. > > Do you already have some patch to add these assertions? No. But I have added several assertions to my "ukbd.c", mainly in the callbacks. From time to time they trigger, and then I just return, because there is no other choice. That means, if you try to lock Giant, you will most likely get a locking order reversal. The worst example is the mechanism when you print something and scroll lock led is enabled. Then printf will call the ukbd driver to clear the scroll lock led! Yikes. Ouuch. "ukbd.c" must out of Giant! http://www.turbocat.net/~hselasky/isdn4bsd/sources/src/sys/dev/usb/ukbd.c --HPS From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 08:58:47 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B257816A402; Fri, 13 Jul 2007 08:58:47 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe01.swip.net [212.247.154.1]) by mx1.freebsd.org (Postfix) with ESMTP id EB49D13C481; Fri, 13 Jul 2007 08:58:46 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] Received: from [194.248.135.20] (account mc467741@c2i.net HELO laptop.lan) by mailfe01.swip.net (CommuniGate Pro SMTP 5.1.10) with ESMTPA id 525561390; Fri, 13 Jul 2007 10:58:45 +0200 From: Hans Petter Selasky To: d@delphij.net Date: Fri, 13 Jul 2007 10:58:48 +0200 User-Agent: KMail/1.9.5 References: <46970DF7.3000803@elischer.org> <200707131021.59966.hselasky@c2i.net> <46973A08.3030607@delphij.net> In-Reply-To: <46973A08.3030607@delphij.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200707131058.48999.hselasky@c2i.net> Cc: attilio@freebsd.org, freebsd-current@freebsd.org, Julian Elischer , FreeBSD Current Subject: Re: crash in tty code in 6.1.. fixed since? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2007 08:58:47 -0000 On Friday 13 July 2007 10:38, LI Xin wrote: > Hans Petter Selasky wrote: > [...] > > > Maybe related: > > > > Regarding the keyboard system which is also Giant locked, we should add > > assert Giant statements, because I see several callers doing calls into > > the keyboard system without holding Giant! > > I think that is a good idea. By adding these assertions our user > community would be able to catch more under-exercised codepath under > their workload. > > Do you already have some patch to add these assertions? No. But I have added several assertions to my "ukbd.c", mainly in the callbacks. From time to time they trigger, and then I just return, because there is no other choice. That means, if you try to lock Giant, you will most likely get a locking order reversal. The worst example is the mechanism when you print something and scroll lock led is enabled. Then printf will call the ukbd driver to clear the scroll lock led! Yikes. Ouuch. "ukbd.c" must out of Giant! http://www.turbocat.net/~hselasky/isdn4bsd/sources/src/sys/dev/usb/ukbd.c --HPS From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 08:59:24 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 76A0416A400 for ; Fri, 13 Jul 2007 08:59:24 +0000 (UTC) (envelope-from llwang@infor.ck.tp.edu.tw) Received: from infor.ck.tp.edu.tw (infor.ck.tp.edu.tw [203.64.26.200]) by mx1.freebsd.org (Postfix) with ESMTP id 497CC13C4C5 for ; Fri, 13 Jul 2007 08:59:24 +0000 (UTC) (envelope-from llwang@infor.ck.tp.edu.tw) Received: by infor.ck.tp.edu.tw (Postfix, from userid 1001) id B8981170EC; Fri, 13 Jul 2007 16:43:25 +0800 (TST) Date: Fri, 13 Jul 2007 16:43:25 +0800 From: "Li-Lun Wang (Leland Wang)" To: freebsd-current@freebsd.org Message-ID: <20070713084325.GA47351@Athena.infor.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-action=pgp-signed Content-Disposition: inline User-Agent: Mutt/1.5.15 (2007-04-06) Subject: threadlock and msk watchdog timeout X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2007 08:59:24 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, After making world a couple of days ago, my msk(4) became very unstable. Under moderate network load, the interface hung and I received kernel: msk0: watchdog timeout (missed Tx interrupts) -- recovering at least once every several minutes and kernel: msk0: Rx FIFO overrun! occasionally. It was so annoying that I took the trouble of binary searching the kernel version to find the one destabilized my msk(4). The outcome of the search turned out te be strange. Instead of finding a date after which msk(4) became so very unstable, it *seemed* that the older the kernel version the stabler msk(4) I got, and the newer the kernel version the easier and more often msk(4) hung. I managed to pin down that with the kernel as of 2007.06.04.12.00.00, it seemed not to give me any msk watchdog timeout at all, and that with the kernel as of 2007.06.05.12.00.00, msk(4) began to hang and the watchdog began to timeout once in a while. There may be a latter commit that made my msk(4) even more unstable, but I am not sure about this part as it is not easy to measure the level of "unstableness" of the network. It seems that the most significant commit between 2007.06.04.12.00.00 and 2007.06.05.12.00.00 was threadlock by jeff@. I don't know why or how it would affect msk(4), though. I was using SCHED_SMP on a C2D, but switched back to SCHED_ULE when I did the search. I discovered a couple other funny phenomena during the search that may also suggest this be related to threadlock. One is that msk(4) seemed to hang less frequently when the system was busy building world or kernel. The other thing is that I seemed to be able to help unhang the interface by switching the input focus in X Window by move my mouse cursor to another window. My result might not be accurate, though, as I only rebuilt the kernel, not the whole world, when I did the search. - -- llwang -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.3 (FreeBSD) iD8DBQFGlzseCQM7t5B2mhARAiKNAJ9wwCRBFGQOo5Vy2pzTrldHwHh3zwCfXw/u NZ66KfvJ0HR1A2sc/HffwxI= =fi7k -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 09:01:24 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2232416A400 for ; Fri, 13 Jul 2007 09:01:24 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.169]) by mx1.freebsd.org (Postfix) with ESMTP id A4B3B13C441 for ; Fri, 13 Jul 2007 09:01:23 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by ug-out-1314.google.com with SMTP id o4so587645uge for ; Fri, 13 Jul 2007 02:01:22 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:reply-to:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding:sender; b=nINwMILCNEQkvVYYQlDRxHaEnCMLHC5F6X5UthGcExndP611GjdKGHCNFvN4mE3yE8rrzMHVh/rkamT0a48q8kKjUCv0TRT7sDbndJePDpAyHnfNebPdysasygXeHyWwaQe0wKiho7NBbWfKyjd3CYClNkRtM+d19pUO1vVoJys= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:reply-to:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding:sender; b=Ie+JYPTDH+2Q3APe6yTcWba0XXBkzpJ0HkRFolvDzV0c5wE3XnvxU558t0Y+vYKWFf0/Ht9Y7mEXhH28I6I9ALW8DVD44zlEyNqdqd3IQIqSWSoXmJ8grb0trSSgBR/TAVtyCIowQpd0iz8zJyt8LskVRo3ejLO1lZQkW2FEETo= Received: by 10.67.97.18 with SMTP id z18mr1870448ugl.1184317282445; Fri, 13 Jul 2007 02:01:22 -0700 (PDT) Received: from ?172.31.5.25? ( [89.97.252.178]) by mx.google.com with ESMTP id h7sm6296199nfh.2007.07.13.02.01.21 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 13 Jul 2007 02:01:22 -0700 (PDT) Message-ID: <46973F39.2050508@FreeBSD.org> Date: Fri, 13 Jul 2007 11:00:41 +0200 From: Attilio Rao User-Agent: Thunderbird 1.5 (X11/20060526) MIME-Version: 1.0 To: Hans Petter Selasky References: <46970DF7.3000803@elischer.org> <200707131021.59966.hselasky@c2i.net> <46973708.2040401@FreeBSD.org> <200707131055.12084.hselasky@c2i.net> In-Reply-To: <200707131055.12084.hselasky@c2i.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: Attilio Rao Cc: freebsd-current@freebsd.org, Julian Elischer , FreeBSD Current Subject: Re: crash in tty code in 6.1.. fixed since? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: attilio@FreeBSD.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2007 09:01:24 -0000 Hans Petter Selasky wrote: > On Friday 13 July 2007 10:25, Attilio Rao wrote: >> Hans Petter Selasky wrote: >>> If TTY was not Giant locked, you would have had an error there if another >>> mutex was locked, and the problem would have been solved years ago :-) >> Not sure what you mean, but the first evidence is that you would have >> explicitly drop/pickup the mutex so that you would have handled the race >> not trasparently as Giant does. >> Moreover, it seems that tty should be partially locked with a sleeping >> primitive (sx probabilly). >> > > If you lock a mutex first and then a sx-lock, you should get a warning, right? No, a panic. What I mean is that if you had a mutex here instead than Giant what would have probabilly happened is having code like this: mtx_lock(&tty_mtx); ... if (tp->t_session) { mtx_unlock(&tty_mtx); sx_slock(&proctree_lock); mtx_lock(&tty_mtx); if (tp->t_session && tp->t_session->s_leader) { struct proc *p; What changes really here is that you explicitly check again the state of t_session ptr since it can be changed while dropping/pickingup again the tty_mtx. Since you used a mutex differently from Giant you know you have to do that. With Giant the problem is that the dropping/pickingup happens implicitly in our primitives so you can just make (easy) mistakes like these. Attilio From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 09:01:24 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2375116A401 for ; Fri, 13 Jul 2007 09:01:24 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.168]) by mx1.freebsd.org (Postfix) with ESMTP id A61B313C442 for ; Fri, 13 Jul 2007 09:01:23 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by ug-out-1314.google.com with SMTP id o4so587644uge for ; Fri, 13 Jul 2007 02:01:22 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:reply-to:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding:sender; b=nINwMILCNEQkvVYYQlDRxHaEnCMLHC5F6X5UthGcExndP611GjdKGHCNFvN4mE3yE8rrzMHVh/rkamT0a48q8kKjUCv0TRT7sDbndJePDpAyHnfNebPdysasygXeHyWwaQe0wKiho7NBbWfKyjd3CYClNkRtM+d19pUO1vVoJys= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:reply-to:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding:sender; b=Ie+JYPTDH+2Q3APe6yTcWba0XXBkzpJ0HkRFolvDzV0c5wE3XnvxU558t0Y+vYKWFf0/Ht9Y7mEXhH28I6I9ALW8DVD44zlEyNqdqd3IQIqSWSoXmJ8grb0trSSgBR/TAVtyCIowQpd0iz8zJyt8LskVRo3ejLO1lZQkW2FEETo= Received: by 10.67.97.18 with SMTP id z18mr1870448ugl.1184317282445; Fri, 13 Jul 2007 02:01:22 -0700 (PDT) Received: from ?172.31.5.25? ( [89.97.252.178]) by mx.google.com with ESMTP id h7sm6296199nfh.2007.07.13.02.01.21 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 13 Jul 2007 02:01:22 -0700 (PDT) Message-ID: <46973F39.2050508@FreeBSD.org> Date: Fri, 13 Jul 2007 11:00:41 +0200 From: Attilio Rao User-Agent: Thunderbird 1.5 (X11/20060526) MIME-Version: 1.0 To: Hans Petter Selasky References: <46970DF7.3000803@elischer.org> <200707131021.59966.hselasky@c2i.net> <46973708.2040401@FreeBSD.org> <200707131055.12084.hselasky@c2i.net> In-Reply-To: <200707131055.12084.hselasky@c2i.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: Attilio Rao Cc: freebsd-current@freebsd.org, Julian Elischer , FreeBSD Current Subject: Re: crash in tty code in 6.1.. fixed since? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: attilio@FreeBSD.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2007 09:01:24 -0000 Hans Petter Selasky wrote: > On Friday 13 July 2007 10:25, Attilio Rao wrote: >> Hans Petter Selasky wrote: >>> If TTY was not Giant locked, you would have had an error there if another >>> mutex was locked, and the problem would have been solved years ago :-) >> Not sure what you mean, but the first evidence is that you would have >> explicitly drop/pickup the mutex so that you would have handled the race >> not trasparently as Giant does. >> Moreover, it seems that tty should be partially locked with a sleeping >> primitive (sx probabilly). >> > > If you lock a mutex first and then a sx-lock, you should get a warning, right? No, a panic. What I mean is that if you had a mutex here instead than Giant what would have probabilly happened is having code like this: mtx_lock(&tty_mtx); ... if (tp->t_session) { mtx_unlock(&tty_mtx); sx_slock(&proctree_lock); mtx_lock(&tty_mtx); if (tp->t_session && tp->t_session->s_leader) { struct proc *p; What changes really here is that you explicitly check again the state of t_session ptr since it can be changed while dropping/pickingup again the tty_mtx. Since you used a mutex differently from Giant you know you have to do that. With Giant the problem is that the dropping/pickingup happens implicitly in our primitives so you can just make (easy) mistakes like these. Attilio From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 10:08:38 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BD38B16A404 for ; Fri, 13 Jul 2007 10:08:38 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.234]) by mx1.freebsd.org (Postfix) with ESMTP id CAF0B13C441 for ; Fri, 13 Jul 2007 10:08:37 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by nz-out-0506.google.com with SMTP id l8so365066nzf for ; Fri, 13 Jul 2007 03:08:37 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:received:received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=eta7gQXQkAqn5Cl8IFjPsF1cBxMeMlxnskMp/2YCJAHNETC5u6Hn4kmmdmU0+qQlxWevuKvps2gmXEi9rbbAmPt3tXbStcSoIgwbAi+GYiIMbiguM34cRoL++uKUTJct+akitkyo4Nz+01ISdHGaYWjyyCYfRc+2Y1b9sjUDJ4w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=SO+YcEw/LPaMbqN7XHjM17JsR5Ozhvr1cHx6fYZMhfmNDYBglMLyLCpgsjKVIGPgITMkxmijewjmKpddZVqQWaMcStn8A/1TZuzu/0UWJTlEku0P3Mm+A0AUGXtr4/bRTVA43CNXAJXob3sLMNt/cNBIXQwuT578GIt+R8SH/XI= Received: by 10.115.95.1 with SMTP id x1mr1486520wal.1184321316512; Fri, 13 Jul 2007 03:08:36 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTP id j6sm36199926wah.2007.07.13.03.08.34 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 13 Jul 2007 03:08:35 -0700 (PDT) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id l6DA8Uw2019931 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Jul 2007 19:08:30 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id l6DA8TuH019930; Fri, 13 Jul 2007 19:08:29 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Fri, 13 Jul 2007 19:08:29 +0900 From: Pyun YongHyeon To: "Li-Lun Wang (Leland Wang)" Message-ID: <20070713100829.GC17801@cdnetworks.co.kr> References: <20070713084325.GA47351@Athena.infor.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070713084325.GA47351@Athena.infor.org> User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@freebsd.org Subject: Re: threadlock and msk watchdog timeout X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2007 10:08:38 -0000 On Fri, Jul 13, 2007 at 04:43:25PM +0800, Li-Lun Wang (Leland Wang) wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > After making world a couple of days ago, my msk(4) became very > unstable. Under moderate network load, the interface hung and I > received > > kernel: msk0: watchdog timeout (missed Tx interrupts) -- recovering > > at least once every several minutes and > > kernel: msk0: Rx FIFO overrun! > > occasionally. > > It was so annoying that I took the trouble of binary searching the > kernel version to find the one destabilized my msk(4). > > The outcome of the search turned out te be strange. Instead of > finding a date after which msk(4) became so very unstable, it *seemed* > that the older the kernel version the stabler msk(4) I got, and the > newer the kernel version the easier and more often msk(4) hung. > > I managed to pin down that with the kernel as of 2007.06.04.12.00.00, > it seemed not to give me any msk watchdog timeout at all, and that > with the kernel as of 2007.06.05.12.00.00, msk(4) began to hang and > the watchdog began to timeout once in a while. There may be a latter > commit that made my msk(4) even more unstable, but I am not sure about > this part as it is not easy to measure the level of "unstableness" of > the network. > > It seems that the most significant commit between 2007.06.04.12.00.00 > and 2007.06.05.12.00.00 was threadlock by jeff@. I don't know why or > how it would affect msk(4), though. I was using SCHED_SMP on a C2D, > but switched back to SCHED_ULE when I did the search. > > I discovered a couple other funny phenomena during the search that may > also suggest this be related to threadlock. One is that msk(4) seemed > to hang less frequently when the system was busy building world or > kernel. The other thing is that I seemed to be able to help unhang > the interface by switching the input focus in X Window by move my > mouse cursor to another window. > > My result might not be accurate, though, as I only rebuilt the kernel, > not the whole world, when I did the search. > Does msk(4) use shared interrupt? Show me the output of "vmstat -i". -- Regards, Pyun YongHyeon From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 07:49:33 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C10C416A402; Fri, 13 Jul 2007 07:49:33 +0000 (UTC) (envelope-from vanhu@zeninc.net) Received: from smtp.zeninc.net (reverse-25.fdn.fr [80.67.176.25]) by mx1.freebsd.org (Postfix) with ESMTP id 7DFD213C442; Fri, 13 Jul 2007 07:49:33 +0000 (UTC) (envelope-from vanhu@zeninc.net) Received: by smtp.zeninc.net (smtpd, from userid 1000) id 9810A3F1F; Fri, 13 Jul 2007 09:26:57 +0200 (CEST) Date: Fri, 13 Jul 2007 09:26:57 +0200 From: VANHULLEBUS Yvan To: "Bjoern A. Zeeb" Message-ID: <20070713072657.GA13945@zen.inc> References: <20070713053534.D31116@maildrop.int.zabbadoz.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070713053534.D31116@maildrop.int.zabbadoz.net> User-Agent: All mail clients suck. This one just sucks less. X-Mailman-Approved-At: Fri, 13 Jul 2007 11:25:08 +0000 Cc: "George V. Neville-Neil" , Peter Blok , FreeBSD current mailing list , net@freebsd.org Subject: Re: FAST_IPSEC is now IPSEC, please be advised... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2007 07:49:33 -0000 On Fri, Jul 13, 2007 at 05:41:04AM +0000, Bjoern A. Zeeb wrote: > On Thu, 12 Jul 2007, gnn@freebsd.org wrote: > >At Wed, 11 Jul 2007 13:49:37 +0200, > >Peter Blok wrote: Hi all. [KAME's IPSec removal and ipsec-tools] > I have a preliminary hackish patch. The problem is that I have other > patches in there as well. I'll have to disunite them. > > I was hoping that ipsec-tools would release earlier so that the gcc4 > compile issues would have been solved already only leaving us with the > directory changes for the #inlcude files... Ipsec-tools 0.7.0 Release (which includes gcc4 fixes) should have been released this week. We did NOT release it until now for various reasons, including the fact that I hoped we could fix this include problem for 0.7.0 release. But if it is quite simple to fix for -HEAD, which now only have netipsec/ipsec.h, it is harder to solve cleanly for older versions, which have both netinet6/ipsec.h and netipsec/ipsec.h, and on which I just don't know how to guess which one we should use. I think I'll commit today a patch to detect the case where we only have netipsec/ipsec.h (so it will compile again on -HEAD), and we'll keep the netinet6/ipsec.h Vs netipsec/ipsec.h problem as an open issue until someone gives me a clean way to decide which one we should use when we found both. Yvan. -- NETASQ http://www.netasq.com From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 11:51:11 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5A6B616A401 for ; Fri, 13 Jul 2007 11:51:11 +0000 (UTC) (envelope-from ianf@clue.co.za) Received: from munchkin.clue.co.za (munchkin.clue.co.za [66.219.59.160]) by mx1.freebsd.org (Postfix) with ESMTP id 27F1A13C441 for ; Fri, 13 Jul 2007 11:51:11 +0000 (UTC) (envelope-from ianf@clue.co.za) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=20070313; d=clue.co.za; h=Received:Received:Received:To:Subject:From:X-Attribution:Date:Message-Id; b=OpPIf2qxEVkaHzYnpEVz+dABxVbtAVIzNkmoInlTkqH1CU3sJZ/wG6giyL9+YVM/aoEtD//2eD8nr+sOQCDatkHJBqgTf/Xo4VMJnmizTpPHBfnZkkNJHISCZCh1gFg0I3aFLSkdQp71iHWaub3VSLshau7vjd1UFE3cjYgiz2VwcM8mVrfFofzIhyQS0w33LGdwzmbNsfXuFJhIZQfoMddVitexTXxHG1azT40aSMnw8mkidFGkzNflxJJ+lQie; Received: from uucp by munchkin.clue.co.za with local (Exim 4.66) (envelope-from ) id 1I9Jfy-0003JO-It for current@freebsd.org; Fri, 13 Jul 2007 11:51:10 +0000 Received: from ianf.clue.co.za ([10.0.0.6] helo=clue.co.za) by urchin.clue.co.za with esmtpa (Exim 4.66) (envelope-from ) id 1I9Jey-0001Jq-Pl for current@freebsd.org; Fri, 13 Jul 2007 11:50:08 +0000 Received: from localhost ([127.0.0.1] helo=clue.co.za) by clue.co.za with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I9Jey-0000ht-0L for current@freebsd.org; Fri, 13 Jul 2007 13:50:08 +0200 To: current@freebsd.org From: Ian FREISLICH X-Attribution: BOFH Date: Fri, 13 Jul 2007 13:50:07 +0200 Message-Id: Cc: Subject: Wireless (bg)scan and ARP X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2007 11:51:11 -0000 Hi Recently (over the past month or so) I've been having issues with my wirless NIC. I'm using wpa_supplicant and DHCP. Something happens either at the time the lease is renewed, or the NIC does a background scan or association is lost for a short while that breaks the ARP table. The interface remains up, reassociates, keeps its IP address and the ARP table has entries for hosts on the local network. However, until I delete all the entries in the ARP table, it cannot communicate with hosts that it has ARP entries for. Sometimes it take hours to occur, other times it can happen a few times in a 5 minute interval. ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) ath0: mem 0x98100000-0x9810ffff irq 17 at device 0.0 on pci3 ath0: [ITHREAD] ath0: using obsoleted if_watchdog interface ath0: Ethernet address: 00:17:f2:50:66:16 ath0: mac 10.3 phy 6.1 radio 10.2 hw.ath.hal.swba_backoff: 0 hw.ath.hal.sw_brt: 10 hw.ath.hal.dma_brt: 2 hw.ath.hal.version: 0.9.20.3 hw.ath.txbuf: 200 hw.ath.rxbuf: 40 hw.ath.regdomain: 0 hw.ath.countrycode: 0 hw.ath.xchanmode: 1 hw.ath.outdoor: 1 hw.ath.calibrate: 30 dev.ath.0.%desc: Atheros 5424/2424 dev.ath.0.%driver: ath dev.ath.0.%location: slot=0 function=0 handle=\_SB_.PCI0.RP02.PXS2 dev.ath.0.%pnpinfo: vendor=0x168c device=0x001c subvendor=0x106b subdevice=0x008 6 class=0x020000 dev.ath.0.%parent: pci3 dev.ath.0.smoothing_rate: 95 dev.ath.0.sample_rate: 10 dev.ath.0.countrycode: 0 dev.ath.0.regdomain: 106 dev.ath.0.slottime: 9 dev.ath.0.acktimeout: 48 dev.ath.0.ctstimeout: 48 dev.ath.0.softled: 0 dev.ath.0.ledpin: 0 dev.ath.0.ledon: 0 dev.ath.0.ledidle: 2700 dev.ath.0.txantenna: 0 dev.ath.0.rxantenna: 1 dev.ath.0.diversity: 1 dev.ath.0.txintrperiod: 5 dev.ath.0.diag: 0 dev.ath.0.tpscale: 0 dev.ath.0.tpc: 0 dev.ath.0.tpack: 63 dev.ath.0.tpcts: 63 dev.ath.0.fftxqmin: 2 dev.ath.0.fftxqmax: 50 dev.ath.0.monpass: 24 dev.ath.0.wake: 0 ath0: flags=8843 metric 0 mtu 1500 ether 00:17:f2:50:66:16 inet 10.0.0.6 netmask 0xffffff00 broadcast 10.0.0.255 media: IEEE 802.11 Wireless Ethernet autoselect (OFDM/48Mbps) status: associated ssid cluelan channel 13 (2472 Mhz 11g) bssid 00:30:4f:55:f8:c6 authmode WPA privacy ON deftxkey UNDEF TKIP 2:128-bit txpowmax 35 bmiss 7 scanvalid 60 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi11g 14 roam:rate11g 5 protmode CTS burst roaming MANUAL bintval 100 -- Ian Freislich From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 12:37:05 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AAD1E16A410 for ; Fri, 13 Jul 2007 12:37:05 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [83.98.131.211]) by mx1.freebsd.org (Postfix) with ESMTP id 6A5C913C478 for ; Fri, 13 Jul 2007 12:37:05 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id 151BF1CCE9; Fri, 13 Jul 2007 14:35:52 +0200 (CEST) Date: Fri, 13 Jul 2007 14:35:52 +0200 From: Ed Schouten To: VANHULLEBUS Yvan Message-ID: <20070713123552.GW55449@hoeg.nl> References: <20070713053534.D31116@maildrop.int.zabbadoz.net> <20070713072657.GA13945@zen.inc> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="O2izrSG9ltmUPm45" Content-Disposition: inline In-Reply-To: <20070713072657.GA13945@zen.inc> User-Agent: Mutt/1.5.16 (2007-06-09) Cc: "Bjoern A. Zeeb" , net@freebsd.org, Peter Blok , FreeBSD current mailing list , "George V. Neville-Neil" Subject: Re: FAST_IPSEC is now IPSEC, please be advised... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2007 12:37:05 -0000 --O2izrSG9ltmUPm45 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * VANHULLEBUS Yvan wrote: > But if it is quite simple to fix for -HEAD, which now only have > netipsec/ipsec.h, it is harder to solve cleanly for older versions, > which have both netinet6/ipsec.h and netipsec/ipsec.h, and on which I > just don't know how to guess which one we should use. You could use the __FreeBSD_version definition to detect what version of FreeBSD people are using. I guess it has been bumped after the IPSEC import. --=20 Ed Schouten WWW: http://g-rave.nl/ --O2izrSG9ltmUPm45 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGl3Gn52SDGA2eCwURAkLqAJ0e9ktUkyYLFc9SUFBNeYMT9MYW+ACeN66v T8KqKR+0xvw/Qxog1M6DPLc= =BM3I -----END PGP SIGNATURE----- --O2izrSG9ltmUPm45-- From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 12:49:19 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2C4BE16A408 for ; Fri, 13 Jul 2007 12:49:19 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.freebsd.org (Postfix) with ESMTP id 99A1013C4C2 for ; Fri, 13 Jul 2007 12:49:18 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.8/8.13.8) with ESMTP id l6DCnB4c003447; Fri, 13 Jul 2007 08:49:15 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-current@freebsd.org Date: Fri, 13 Jul 2007 08:36:56 -0400 User-Agent: KMail/1.9.6 References: <20070520174124.GA14987@Athena.infor.org> <20070521040808.GD36838@cdnetworks.co.kr> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200707130836.58062.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Fri, 13 Jul 2007 08:49:15 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.3/3656/Fri Jul 13 07:24:51 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: pyunyh@gmail.com, "Li-Lun \"Leland\" Wang" Subject: Re: msk watchdog timeout X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2007 12:49:19 -0000 On Monday 21 May 2007 12:45:39 am Li-Lun "Leland" Wang wrote: > On 5/20/07, Pyun YongHyeon wrote: > > On Sun, May 20, 2007 at 09:39:54PM -0500, Li-Lun Leland Wang wrote: > > > On 5/20/07, Pyun YongHyeon wrote: > > > >On Mon, May 21, 2007 at 01:41:24AM +0800, Li-Lun Wang (Leland Wang) wrote: > > > > > I just installed 7.0-current as of May 3 on my new computer that comes > > > > > with an on-board Marvell Yukon Gigabit Ethernet. Every now and then > > > > > if the network throughput comes near several hundred kbytes, I get the > > > > > msk0 watchdog timeout messages: > > > > > > > > > > kernel: msk0: watchdog timeout > > > > > msk0: watchdog timeout (missed Tx interrupts) -- recovering > > > > > > > > > > Although it says recovering, the interface never comes back alive. > > > > > > > >The above message indicates the driver sent all pending transmission > > > >requests but the driver didn't receive corresponding Tx completion > > > >interrupts. Not recovering from the watchdog timeout means there are > > > >another issues on the driver. However as disabling MSI fixed the > > > >issue, I guess it's not fault of msk(4) and it comes from bad/broken > > > >MSI implementation of your system. I guess it's time to add your > > > >chipset to a PCI quirk table in order to blacklist it. > > > > > > I do reckon that MSI doesn't work on earlier Intel chipsets. Mine is > > > P965 (on a gigabyte GA-965P-DS3 rev 1.3), which I suppose is recent > > > enough to support MSI, isn't it? Or could there be other problems > > > > Using latest chipsets does not necessarily guarantee working MSI. > > I see. I think we should maybe add P965 to the PCI quirk list for > broken MSI, then? Possibly. > > > possible? > > > > > > > Yes. But I couldn't find possible issue on msk(4) yet. > > Maybe I was not clear enough. Could there be something else that > causes MSI to not working correctly other than the chipset? I was > just wondering why I didn't see too many broken MSI reports if most > Intel chipsets are broken. If it's not the driver it would be the chipset. We already don't use MSI on systems that don't support either PCI-X or PCI-express, so that implicitly blacklists most older Intel chipsets. Do you have any other devices in your system that support MSI? pciconf -lc output would be useful to look at. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 12:49:20 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A09EE16A406 for ; Fri, 13 Jul 2007 12:49:20 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.freebsd.org (Postfix) with ESMTP id 4E3C813C4EB for ; Fri, 13 Jul 2007 12:49:20 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.8/8.13.8) with ESMTP id l6DCnB4b003447; Fri, 13 Jul 2007 08:49:14 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-current@freebsd.org Date: Fri, 13 Jul 2007 08:31:43 -0400 User-Agent: KMail/1.9.6 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200707130831.44748.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Fri, 13 Jul 2007 08:49:14 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.3/3656/Fri Jul 13 07:24:51 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Ivan Voras Subject: Re: Quick hardware survey - disk INT13 "EDD" services? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2007 12:49:20 -0000 On Saturday 19 May 2007 11:39:53 am Ivan Voras wrote: > Hi! > > Does anyone have a machine that doesn't support EDD / packet interface / > "Extended INT13" interface on its hard drive(s) and is capable of > running 7-CURRENT? (486 and early Pentium class machines?) Specifically, you'd have to have a BIOS with a copyright date older than 1995. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 12:49:25 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C201D16A4FE for ; Fri, 13 Jul 2007 12:49:25 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.freebsd.org (Postfix) with ESMTP id 68AA013C491 for ; Fri, 13 Jul 2007 12:49:25 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.8/8.13.8) with ESMTP id l6DCnB4d003447; Fri, 13 Jul 2007 08:49:17 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-current@freebsd.org Date: Fri, 13 Jul 2007 08:47:59 -0400 User-Agent: KMail/1.9.6 References: <2a41acea0705211617p17f74964oabdc88564376ada3@mail.gmail.com> In-Reply-To: <2a41acea0705211617p17f74964oabdc88564376ada3@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200707130848.01101.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Fri, 13 Jul 2007 08:49:18 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.3/3656/Fri Jul 13 07:24:51 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Ian FREISLICH , Jack Vogel Subject: Re: em0 hijacking traffic to port 623 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2007 12:49:25 -0000 On Monday 21 May 2007 07:17:07 pm Jack Vogel wrote: > On 5/21/07, Sten Spans wrote: > > On Mon, 21 May 2007, Ian FREISLICH wrote: > > > > > Hi > > > > > > We've noticed an issue on our firewalls where the first em device > > > in the system hijacks inbound port 623 tcp and udp. The OS never > > > sees this traffic. Interestingly, em1 and em2 do not appear to be > > > afflicted by this problem. Some reading I've done points to a > > > similar conclusion: > > > > > > http://blogs.sun.com/shepler/entry/port_623_or_the_mount > > > > > > I've looked at the bios, but I can't find any settings that remotely > > > hint IPMI or RMCP+ or serial-over-lan. > > > > > > Does anyone know how I can stop the card or system from stealing > > > port 623 in hardware or must I just stop using em0 (and/or Intel NICS)? > > > > Does "ifconfig em0 promisc" help ? > > That fixed firmware related vanishing ipv6 packets on fxp and em. > > Is this happening even with the latest CURRENT driver, there is code in > it now that is supposed to stop the firmware from doing that, at least > that was the theory :) We still see this at work. We use this workaround in /etc/sysctl.conf: net.inet.ip.portrange.lowlast=665 It seems that the em0 interface always snoops 623 looking for RCMP packets for IPMI (or ASF). -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 13:17:33 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 88CBA16A403 for ; Fri, 13 Jul 2007 13:17:33 +0000 (UTC) (envelope-from ianf@clue.co.za) Received: from munchkin.clue.co.za (munchkin.clue.co.za [66.219.59.160]) by mx1.freebsd.org (Postfix) with ESMTP id 5522F13C467 for ; Fri, 13 Jul 2007 13:17:33 +0000 (UTC) (envelope-from ianf@clue.co.za) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=20070313; d=clue.co.za; h=Received:Received:Received:To:From:Subject:In-Reply-To:X-Attribution:Date:Message-Id; b=Je1NkQ0ebLJZgOOArUOH0iyfAYRYrARFxaUlcqKm9SIZRyGmEWeDlPlDCr9AmnAEWK5r9qnUpwabjbvUDP3fDKwgM59r/4nriNj7aYPEtHQrNKS6VZSEGsNeSgPBHdsc4kT5iIp5+QBo736STqW8T8zjs/eS4LlVhOCr38uVSi3YqRbFh04P/aUYYBuWadcQYA7LUY/rY9jMWBtNqVl5hghHvp42L+M2VWZSYBjpUTyHKhnChSMtAJf7Tk7Vzfwj; Received: from uucp by munchkin.clue.co.za with local (Exim 4.66) (envelope-from ) id 1I9L1Y-0001QC-Bk; Fri, 13 Jul 2007 13:17:32 +0000 Received: from ianf.clue.co.za ([10.0.0.6] helo=clue.co.za) by urchin.clue.co.za with esmtpa (Exim 4.66) (envelope-from ) id 1I9Kzv-00023y-3V; Fri, 13 Jul 2007 13:15:51 +0000 Received: from localhost ([127.0.0.1] helo=clue.co.za) by clue.co.za with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I9Kzu-0001lV-HJ; Fri, 13 Jul 2007 15:15:50 +0200 To: freebsd-current@freebsd.org, Jack Vogel From: Ian FREISLICH In-Reply-To: Message from John Baldwin of "Fri, 13 Jul 2007 08:47:59 -0400." <200707130848.01101.jhb@freebsd.org> X-Attribution: BOFH Date: Fri, 13 Jul 2007 15:15:50 +0200 Message-Id: Cc: Subject: Re: em0 hijacking traffic to port 623 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2007 13:17:33 -0000 John Baldwin wrote: > On Monday 21 May 2007 07:17:07 pm Jack Vogel wrote: > > On 5/21/07, Sten Spans wrote: > > > On Mon, 21 May 2007, Ian FREISLICH wrote: > > > > > > > Hi > > > > > > > > We've noticed an issue on our firewalls where the first em device > > > > in the system hijacks inbound port 623 tcp and udp. The OS never > > > > sees this traffic. Interestingly, em1 and em2 do not appear to be > > > > afflicted by this problem. Some reading I've done points to a > > > > similar conclusion: > > > > > > > > http://blogs.sun.com/shepler/entry/port_623_or_the_mount > > > > > > > > I've looked at the bios, but I can't find any settings that remotely > > > > hint IPMI or RMCP+ or serial-over-lan. > > > > > > > > Does anyone know how I can stop the card or system from stealing > > > > port 623 in hardware or must I just stop using em0 (and/or Intel NICS)? > > > > > > Does "ifconfig em0 promisc" help ? > > > That fixed firmware related vanishing ipv6 packets on fxp and em. > > > > Is this happening even with the latest CURRENT driver, there is code in > > it now that is supposed to stop the firmware from doing that, at least > > that was the theory :) > > We still see this at work. We use this workaround in /etc/sysctl.conf: > > net.inet.ip.portrange.lowlast=665 > > It seems that the em0 interface always snoops 623 looking for RCMP > packets for IPMI (or ASF). =================================================================== RCS file: /home/ncvs/src/sys/dev/em/e1000_82540.c,v retrieving revision 1.3 diff -u -d -r1.3 e1000_82540.c --- e1000_82540.c 16 May 2007 00:14:23 -0000 1.3 +++ e1000_82540.c 25 May 2007 13:40:19 -0000 @@ -316,6 +316,7 @@ /* Disable HW ARPs on ASF enabled adapters */ manc = E1000_READ_REG(hw, E1000_MANC); manc &= ~E1000_MANC_ARP_EN; + manc &= ~(E1000_MANC_RMCP_EN | E1000_MANC_0298_EN); E1000_WRITE_REG(hw, E1000_MANC, manc); E1000_WRITE_REG(hw, E1000_IMC, 0xffffffff); Fixes it for me. But, of course, I'm not interested in ASF on my gateway hosts. I didn't look further into the initalization of the chip. The datasheet I downloaded suggests that you can filter these packets on IP address as well and I suspect the option is turned on with some default in the EEPROM register that equates to 0.0.0.0/0. Ian -- Ian Freislich From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 13:19:35 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C623416A400 for ; Fri, 13 Jul 2007 13:19:35 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.freebsd.org (Postfix) with ESMTP id 774DA13C47E for ; Fri, 13 Jul 2007 13:19:35 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.8/8.13.8) with ESMTP id l6DDJVmF003637; Fri, 13 Jul 2007 09:19:33 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-current@freebsd.org Date: Fri, 13 Jul 2007 09:13:13 -0400 User-Agent: KMail/1.9.6 References: <20070531101415.A56583@gta.com> In-Reply-To: <20070531101415.A56583@gta.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200707130913.14514.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Fri, 13 Jul 2007 09:19:33 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.3/3656/Fri Jul 13 07:24:51 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Larry Baird Subject: Re: Multiple IRQs for PCI interrupt X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2007 13:19:35 -0000 On Thursday 31 May 2007 10:14:15 am Larry Baird wrote: > Can anybody shed any light on the following panic : > Multiple IRQs for PCI interrupt 0.31.INTA: 18 and 16 > > Looking at the code this comes from mptable_pci_route_interrupt_handler() > in i386/i386/mptable.c. This message comes when I try to put 7.0 on > a box that was running 6.2. Comparing 6.2 and 7.0, it looks like I > might have the same problem if I turned on INVARIANTS in 6.2. > > For now I have ifdefed out this check, but I would really like to > understand the issue. Your BIOS is telling the OS that a PCI interrupt is hooked up to two different places. You really should be using ACPI. Barring that you can use explicit hints for the pci0.31.INTA IRQ or attempt to get your BIOS manufacturer to fix their BIOS. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 13:19:36 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EBCD616A401; Fri, 13 Jul 2007 13:19:36 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.freebsd.org (Postfix) with ESMTP id 71FB913C4A6; Fri, 13 Jul 2007 13:19:36 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.8/8.13.8) with ESMTP id l6DDJVmE003637; Fri, 13 Jul 2007 09:19:31 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-current@freebsd.org Date: Fri, 13 Jul 2007 09:07:35 -0400 User-Agent: KMail/1.9.6 References: <4659DAD1.9040609@elischer.org> <20070527.235832.-267226920.imp@bsdimp.com> In-Reply-To: <20070527.235832.-267226920.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200707130907.37295.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Fri, 13 Jul 2007 09:19:31 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.3/3656/Fri Jul 13 07:24:51 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: julian@elischer.org, "M. Warner Losh" , current@freebsd.org Subject: Re: fun fun fun. no networking X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2007 13:19:37 -0000 On Monday 28 May 2007 01:58:32 am M. Warner Losh wrote: > In message: <4659DAD1.9040609@elischer.org> > Julian Elischer writes: > : I finally rebooted my old laptop on a -current from about 3 weeks ago. > : (I did the rebuild then but the machine has been off since) > : and ta-da! no network card.. it is a Dell inspiron 7500 with > : a pccard 'ed' device card.. > : > : Was there anything broken 3 weeks ago WRT old ed driver cards? > : or pccd? > : > : It come up saying "unknown card type".. Which is odd > : as it always used to knwo what to do. > : > : This machine has a local CVS mirror on it so > : even though it's offline, I'm rebuilding from 2 months ago.. > : (I couldn't just reboot to the old system as there is really only just > : room for one kernel directory on the root partition.) > : > : More info when it comes back online > > I think, but am not sure, this is related to some changes John made to > acpi resource allocation. I get weird port allocations due to some > questionable assumptions on his part... I've not had time to look > into this in detail, but I see it on all cardbus cards that allocate > I/O ports. All of the ones that only do memory work great. You can try this perhaps: --- //depot/vendor/freebsd/src/sys/dev/acpica/acpi.c 2007/05/08 14:37:51 +++ //depot/user/jhb/acpipci/dev/acpica/acpi.c 2007/05/08 22:28:25 @@ -1030,17 +1030,18 @@ } /* - * If this is an allocation of a specific range, see if we can satisfy - * the request from our system resource regions. If we can't, pass the - * request up to the parent. + * Try to pass the request up to our parent first. If that + * doesn't work, then see if we can satisfy the request via a + * suballocation from our system resource regions. */ - if (start + count - 1 == end && rm != NULL) + res = BUS_ALLOC_RESOURCE(device_get_parent(bus), child, type, rid, + start, end, count, flags); + if (res == NULL && rm != NULL) { res = rman_reserve_resource(rm, start, end, count, flags & ~RF_ACTIVE, child); - if (res == NULL) { - res = BUS_ALLOC_RESOURCE(device_get_parent(bus), child, type, rid, - start, end, count, flags); - } else { + if (res == NULL) + goto out; + rman_set_rid(res, *rid); /* If requested, activate the resource using the parent's method. */ -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 13:19:36 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EBCD616A401; Fri, 13 Jul 2007 13:19:36 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.freebsd.org (Postfix) with ESMTP id 71FB913C4A6; Fri, 13 Jul 2007 13:19:36 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.8/8.13.8) with ESMTP id l6DDJVmE003637; Fri, 13 Jul 2007 09:19:31 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-current@freebsd.org Date: Fri, 13 Jul 2007 09:07:35 -0400 User-Agent: KMail/1.9.6 References: <4659DAD1.9040609@elischer.org> <20070527.235832.-267226920.imp@bsdimp.com> In-Reply-To: <20070527.235832.-267226920.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200707130907.37295.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Fri, 13 Jul 2007 09:19:31 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.3/3656/Fri Jul 13 07:24:51 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: julian@elischer.org, "M. Warner Losh" , current@freebsd.org Subject: Re: fun fun fun. no networking X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2007 13:19:37 -0000 On Monday 28 May 2007 01:58:32 am M. Warner Losh wrote: > In message: <4659DAD1.9040609@elischer.org> > Julian Elischer writes: > : I finally rebooted my old laptop on a -current from about 3 weeks ago. > : (I did the rebuild then but the machine has been off since) > : and ta-da! no network card.. it is a Dell inspiron 7500 with > : a pccard 'ed' device card.. > : > : Was there anything broken 3 weeks ago WRT old ed driver cards? > : or pccd? > : > : It come up saying "unknown card type".. Which is odd > : as it always used to knwo what to do. > : > : This machine has a local CVS mirror on it so > : even though it's offline, I'm rebuilding from 2 months ago.. > : (I couldn't just reboot to the old system as there is really only just > : room for one kernel directory on the root partition.) > : > : More info when it comes back online > > I think, but am not sure, this is related to some changes John made to > acpi resource allocation. I get weird port allocations due to some > questionable assumptions on his part... I've not had time to look > into this in detail, but I see it on all cardbus cards that allocate > I/O ports. All of the ones that only do memory work great. You can try this perhaps: --- //depot/vendor/freebsd/src/sys/dev/acpica/acpi.c 2007/05/08 14:37:51 +++ //depot/user/jhb/acpipci/dev/acpica/acpi.c 2007/05/08 22:28:25 @@ -1030,17 +1030,18 @@ } /* - * If this is an allocation of a specific range, see if we can satisfy - * the request from our system resource regions. If we can't, pass the - * request up to the parent. + * Try to pass the request up to our parent first. If that + * doesn't work, then see if we can satisfy the request via a + * suballocation from our system resource regions. */ - if (start + count - 1 == end && rm != NULL) + res = BUS_ALLOC_RESOURCE(device_get_parent(bus), child, type, rid, + start, end, count, flags); + if (res == NULL && rm != NULL) { res = rman_reserve_resource(rm, start, end, count, flags & ~RF_ACTIVE, child); - if (res == NULL) { - res = BUS_ALLOC_RESOURCE(device_get_parent(bus), child, type, rid, - start, end, count, flags); - } else { + if (res == NULL) + goto out; + rman_set_rid(res, *rid); /* If requested, activate the resource using the parent's method. */ -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 13:41:35 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 06C9D16A400; Fri, 13 Jul 2007 13:41:35 +0000 (UTC) (envelope-from pj@smo.de) Received: from ilk.de (mx-out12.ilk.de [194.121.104.12]) by mx1.freebsd.org (Postfix) with ESMTP id 6FC7913C48D; Fri, 13 Jul 2007 13:41:32 +0000 (UTC) (envelope-from pj@smo.de) Received: from bologna.intern.smo.de (pool52.ka.ilk.net [212.86.194.52]) by ilk.de (8.13.4/8.13.4/ilk-relay) with ESMTP id l6DDCvEq017493; Fri, 13 Jul 2007 15:12:57 +0200 Received: from [192.168.153.208] (herdubreid.intern.smo.de [192.168.153.208]) by bologna.intern.smo.de (8.13.4+Sun/8.13.4) with ESMTP id l6DDA73L004479; Fri, 13 Jul 2007 15:10:08 +0200 (CEST) Message-ID: <46977AE1.9060004@smo.de> Date: Fri, 13 Jul 2007 15:15:13 +0200 From: Philipp Ost User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.13) Gecko/20070525 X-Accept-Language: de, en-us, en MIME-Version: 1.0 To: John Baldwin References: <200707130831.44748.jhb@freebsd.org> In-Reply-To: <200707130831.44748.jhb@freebsd.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Ivan Voras Subject: Re: Quick hardware survey - disk INT13 "EDD" services? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2007 13:41:35 -0000 John Baldwin wrote: > On Saturday 19 May 2007 11:39:53 am Ivan Voras wrote: > >>Hi! >> >>Does anyone have a machine that doesn't support EDD / packet interface / >>"Extended INT13" interface on its hard drive(s) and is capable of >>running 7-CURRENT? (486 and early Pentium class machines?) > > > Specifically, you'd have to have a BIOS with a copyright date older than 1995. > I have an IBM Personal Computer 330-450DX2 which currently has NetBSD 2.0.2 installed. I don't know the exact copyright date of the BIOS, but I can power the machine up again if needed ;-) The hard drives are Western Digital Caviar 2600 (1.5GiB), but I also have two Western Digital Caviar 1365 (365MiB) it those are better suited for the task... I had problems installing FreeBSD on this machine back in 2005 (can't rememeber if it was low memory (32MiB) or "stupid" hard disk layout), but I can try it again as I have a little more experience now :-) For which purposes do you need the machine? HTH, Philipp -- www.familie-ost.info/~pj From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 13:42:54 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8DDFC16A400 for ; Fri, 13 Jul 2007 13:42:54 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by mx1.freebsd.org (Postfix) with ESMTP id 1D7F713C4B8 for ; Fri, 13 Jul 2007 13:42:54 +0000 (UTC) (envelope-from max@love2party.net) Received: from [88.66.26.241] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu8) with ESMTP (Nemesis), id 0ML31I-1I9LQ43hdm-00048s; Fri, 13 Jul 2007 15:42:53 +0200 From: Max Laier Organization: FreeBSD To: freebsd-current@freebsd.org Date: Fri, 13 Jul 2007 15:44:36 +0200 User-Agent: KMail/1.9.7 X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGdu+2]; R]*pL,U>^H?)gW@49@wdJ`H<%}*_BD U_or=\mOZf764&nYj=JYbR1PW0ud>|!~, , CPC.1-D$FG@0h3#'5"k{V]a~. X-Provags-ID: V01U2FsdGVkX1+k4q8d2Xpv3B1w7IoPgmEiFYukiD/LvLUfMnt gqcin1UU8TTHu6i+xTTvk6+uoMK2SzHuypT4Pbd2gB6IzzVu3q 7HIiwdCHeW1y8rdtwQBMhd94rqWNXxtbZGy3pE1MFk= Subject: Can't build RELENG_6 from HEAD? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2007 13:42:54 -0000 --nextPart4609864.QkBsLSmD5P Content-Type: multipart/mixed; boundary="Boundary-01=_IH4lG8nxnilEwY7" Content-Transfer-Encoding: 7bit Content-Disposition: inline --Boundary-01=_IH4lG8nxnilEwY7 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi, is it me or can't RELENG_6 be built from HEAD anymore? =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --Boundary-01=_IH4lG8nxnilEwY7 Content-Type: text/plain; charset="us-ascii"; name="as-build" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="as-build" Script started on Fri Jul 13 15:42:06 2007 15:42 [/usr/src/gnu/usr.bin/binutils/as]amd64> make cc -O2 -fno-strict-aliasing -pipe -march=opteron -DBFD_DEFAULT_TARGET_SIZE=64 -I. -I/usr/src/gnu/usr.bin/binutils/as -I/usr/src/gnu/usr.bin/binutils/as/../libbfd -I/usr/obj/usr/src/gnu/usr.bin/binutils/as/../libbfd -I/usr/src/gnu/usr.bin/binutils/as/../../../../contrib/binutils/include -DDEFAULT_ARCH=\"x86_64\" -DTARGET_CPU=\"x86_64\" -DTARGET_CANONICAL=\"x86_64-obrien-freebsd\" -DTARGET_ALIAS=\"x86_64-obrien-freebsd\" -DVERSION=\""2.15 [FreeBSD] 2004-05-23"\" -D_GNU_SOURCE -I/usr/src/gnu/usr.bin/binutils/as/../../../../contrib/binutils/gas -I/usr/src/gnu/usr.bin/binutils/as/../../../../contrib/binutils/gas/config -I/usr/src/gnu/usr.bin/binutils/as/../../../../contrib/binutils -I/usr/src/gnu/usr.bin/binutils/as -I/usr/src/gnu/usr.bin/binutils/as/amd64-freebsd -Wsystem-headers -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/gnu/usr.bin/binutils/as/../../../../contrib/binutils/gas/app.c In file included from /usr/src/gnu/usr.bin/binutils/as/amd64-freebsd/targ-cpu.h:3, from /usr/src/gnu/usr.bin/binutils/as/../../../../contrib/binutils/gas/config/obj-elf.h:42, from /usr/src/gnu/usr.bin/binutils/as/obj-format.h:3, from /usr/src/gnu/usr.bin/binutils/as/../../../../contrib/binutils/gas/config/te-freebsd.h:30, from /usr/src/gnu/usr.bin/binutils/as/targ-env.h:3, from /usr/src/gnu/usr.bin/binutils/as/../../../../contrib/binutils/gas/as.h:626, from /usr/src/gnu/usr.bin/binutils/as/../../../../contrib/binutils/gas/app.c:30: /usr/src/gnu/usr.bin/binutils/as/../../../../contrib/binutils/gas/config/tc-i386.h:451: error: array type has incomplete element type *** Error code 1 Stop in /usr/src/gnu/usr.bin/binutils/as. Script done on Fri Jul 13 15:42:11 2007 --Boundary-01=_IH4lG8nxnilEwY7-- --nextPart4609864.QkBsLSmD5P Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQBGl4HNXyyEoT62BG0RAnh2AJwIAlbgn9toBdxQtiL3vhYERxNEigCdFRJT 0fmqC8KAeJyBTv2RVion5B8= =TiSR -----END PGP SIGNATURE----- --nextPart4609864.QkBsLSmD5P-- From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 13:51:30 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 508CC16A409 for ; Fri, 13 Jul 2007 13:51:30 +0000 (UTC) (envelope-from lulf@stud.ntnu.no) Received: from merke.itea.ntnu.no (merke.itea.ntnu.no [129.241.7.61]) by mx1.freebsd.org (Postfix) with ESMTP id 882FC13C491 for ; Fri, 13 Jul 2007 13:51:29 +0000 (UTC) (envelope-from lulf@stud.ntnu.no) Received: from localhost (localhost [127.0.0.1]) by merke.itea.ntnu.no (Postfix) with ESMTP id 86EF113CE69 for ; Fri, 13 Jul 2007 15:51:28 +0200 (CEST) Received: from twoflower.idi.ntnu.no (twoflower.idi.ntnu.no [129.241.104.169]) by merke.itea.ntnu.no (Postfix) with ESMTP for ; Fri, 13 Jul 2007 15:51:27 +0200 (CEST) Received: by twoflower.idi.ntnu.no (Postfix, from userid 1002) id 4B33E1710C; Fri, 13 Jul 2007 15:51:27 +0200 (CEST) Date: Fri, 13 Jul 2007 15:51:27 +0200 From: Ulf Lilleengen To: freebsd-current@freebsd.org Message-ID: <20070713135127.GA86715@twoflower.idi.ntnu.no> Mail-Followup-To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="tThc/1wpZn/ma/RB" Content-Disposition: inline User-Agent: Mutt/1.5.15 (2007-04-06) X-Content-Scanned: with sophos and spamassassin at mailgw.ntnu.no. Subject: Promise SATA300 TX4 problems in CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2007 13:51:30 -0000 --tThc/1wpZn/ma/RB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, I just bought a Promise SATA-300 TX4 card for my computer. I use a SCSI drive on an adaptect controller for the system disk. I started encountering problems when trying to copy data from the filesystem on one of the ATA disks connected to the Promise card. I get these messages: ad10: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=37814559 ad10: FAILURE - device detached subdisk10: detached ad10: detached g_vfs_done():ad10s3a[WRITE(offset=114688, length=16384)]error = 6 g_vfs_done():ad10s3a[READ(offset=23412736, length=131072)]error = 6 g_vfs_done():ad10s3a[READ(offset=23412736, length=65536)]error = 6 g_vfs_done():ad10s3a[READ(offset=23478272, length=131072)]error = 6 Then if I try to use the system (dhclient in this case), it panics with: panic: vinvalbuf: dirty bufs However, I tried installing 6.2 to see if the issue remains there as well. And it didn't. I works excellent in 6.2. However, I'd like to run CURRENT on this machine. I've attached relevant part of messages, and a core dump can be found at http://twoflower.idi.ntnu.no/crash Is this perhaps a bug in the ata-subsystem? -- Ulf Lilleengen --tThc/1wpZn/ma/RB Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=msgs Jul 13 13:21:02 ridcully syslogd: kernel boot file is /boot/kernel/kernel Jul 13 13:21:02 ridcully kernel: Copyright (c) 1992-2007 The FreeBSD Project. Jul 13 13:21:02 ridcully kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 Jul 13 13:21:02 ridcully kernel: The Regents of the University of California. All rights reserved. Jul 13 13:21:02 ridcully kernel: FreeBSD is a registered trademark of The FreeBSD Foundation. Jul 13 13:21:02 ridcully kernel: FreeBSD 7.0-CURRENT #0: Sat Jul 7 19:38:03 CEST 2007 Jul 13 13:21:02 ridcully kernel: root@dhcppc4:/usr/obj/usr/src/sys/GENERIC Jul 13 13:21:02 ridcully kernel: WARNING: WITNESS option enabled, expect reduced performance. Jul 13 13:21:02 ridcully kernel: Timecounter "i8254" frequency 1193182 Hz quality 0 Jul 13 13:21:02 ridcully kernel: CPU: Intel Pentium III (698.14-MHz 686-class CPU) Jul 13 13:21:02 ridcully kernel: Origin = "GenuineIntel" Id = 0x683 Stepping = 3 Jul 13 13:21:02 ridcully kernel: Features=0x387fbff Jul 13 13:21:02 ridcully kernel: real memory = 1073676288 (1023 MB) Jul 13 13:21:02 ridcully kernel: avail memory = 1037074432 (989 MB) Jul 13 13:21:02 ridcully kernel: ACPI APIC Table: Jul 13 13:21:02 ridcully kernel: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs Jul 13 13:21:02 ridcully kernel: cpu0 (BSP): APIC ID: 0 Jul 13 13:21:02 ridcully kernel: cpu1 (AP): APIC ID: 1 Jul 13 13:21:02 ridcully kernel: ioapic0 irqs 0-23 on motherboard Jul 13 13:21:02 ridcully kernel: kbd1 at kbdmux0 Jul 13 13:21:02 ridcully kernel: ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) Jul 13 13:21:02 ridcully kernel: acpi0: on motherboard Jul 13 13:21:02 ridcully kernel: acpi0: [ITHREAD] Jul 13 13:21:02 ridcully kernel: acpi0: Power Button (fixed) Jul 13 13:21:02 ridcully kernel: acpi0: reservation of 0, a0000 (3) failed Jul 13 13:21:02 ridcully kernel: acpi0: reservation of 100000, 3fef0000 (3) failed Jul 13 13:21:02 ridcully kernel: Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000 Jul 13 13:21:02 ridcully kernel: acpi_timer0: <24-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0 Jul 13 13:21:02 ridcully kernel: cpu0: on acpi0 Jul 13 13:21:02 ridcully kernel: cpu1: on acpi0 Jul 13 13:21:02 ridcully kernel: acpi_button0: on acpi0 Jul 13 13:21:02 ridcully kernel: pcib0: port 0xcf8-0xcff,0x4000-0x4041,0x5000-0x500f on acpi0 Jul 13 13:21:02 ridcully kernel: pci0: on pcib0 Jul 13 13:21:02 ridcully kernel: agp0: on hostb0 Jul 13 13:21:02 ridcully kernel: pcib1: at device 1.0 on pci0 Jul 13 13:21:02 ridcully kernel: pci1: on pcib1 Jul 13 13:21:02 ridcully kernel: vgapci0: port 0xc000-0xc0ff mem 0xdc000000-0xdcffffff,0xde000000-0xde000fff at device 0.0 on pci1 Jul 13 13:21:02 ridcully kernel: isab0: at device 7.0 on pci0 Jul 13 13:21:02 ridcully kernel: isa0: on isab0 Jul 13 13:21:02 ridcully kernel: atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xf000-0xf00f at device 7.1 on pci0 Jul 13 13:21:02 ridcully kernel: ata0: on atapci0 Jul 13 13:21:02 ridcully kernel: ata0: [ITHREAD] Jul 13 13:21:02 ridcully kernel: ata1: on atapci0 Jul 13 13:21:02 ridcully kernel: ata1: [ITHREAD] Jul 13 13:21:02 ridcully kernel: uhci0: port 0xd000-0xd01f irq 19 at device 7.2 on pci0 Jul 13 13:21:02 ridcully kernel: uhci0: [GIANT-LOCKED] Jul 13 13:21:02 ridcully kernel: uhci0: [ITHREAD] Jul 13 13:21:02 ridcully kernel: usb0: on uhci0 Jul 13 13:21:02 ridcully kernel: usb0: USB revision 1.0 Jul 13 13:21:02 ridcully kernel: uhub0: on usb0 Jul 13 13:21:02 ridcully kernel: uhub0: 2 ports with 2 removable, self powered Jul 13 13:21:02 ridcully kernel: pci0: at device 7.3 (no driver attached) Jul 13 13:21:02 ridcully kernel: xl0: <3Com 3c905C-TX Fast Etherlink XL> port 0xd400-0xd47f mem 0xe4021000-0xe402107f irq 17 at device 9.0 on pci0 Jul 13 13:21:02 ridcully kernel: miibus0: on xl0 Jul 13 13:21:02 ridcully kernel: xlphy0: <3c905C 10/100 internal PHY> PHY 24 on miibus0 Jul 13 13:21:02 ridcully kernel: xlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto Jul 13 13:21:02 ridcully kernel: xl0: Ethernet address: 00:01:02:ab:b9:b0 Jul 13 13:21:02 ridcully kernel: xl0: [ITHREAD] Jul 13 13:21:02 ridcully kernel: xl1: <3Com 3c905C-TX Fast Etherlink XL> port 0xd800-0xd87f mem 0xe4020000-0xe402007f irq 18 at device 10.0 on pci0 Jul 13 13:21:02 ridcully kernel: miibus1: on xl1 Jul 13 13:21:02 ridcully kernel: xlphy1: <3c905C 10/100 internal PHY> PHY 24 on miibus1 Jul 13 13:21:02 ridcully kernel: xlphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto Jul 13 13:21:02 ridcully kernel: xl1: Ethernet address: 00:01:02:ab:b9:44 Jul 13 13:21:02 ridcully kernel: xl1: [ITHREAD] Jul 13 13:21:02 ridcully kernel: atapci1: port 0xdc00-0xdc7f,0xe000-0xe0ff mem 0xe4023000-0xe4023fff,0xe4000000-0xe401ffff irq 19 at device 11.0 on pci0 Jul 13 13:21:02 ridcully kernel: atapci1: [ITHREAD] Jul 13 13:21:02 ridcully kernel: atapci1: [ITHREAD] Jul 13 13:21:02 ridcully kernel: ata2: on atapci1 Jul 13 13:21:02 ridcully kernel: ata2: [ITHREAD] Jul 13 13:21:02 ridcully kernel: ata3: on atapci1 Jul 13 13:21:02 ridcully kernel: ata3: [ITHREAD] Jul 13 13:21:02 ridcully kernel: ata4: on atapci1 Jul 13 13:21:02 ridcully kernel: ata4: [ITHREAD] Jul 13 13:21:02 ridcully kernel: ata5: on atapci1 Jul 13 13:21:02 ridcully kernel: ata5: [ITHREAD] Jul 13 13:21:02 ridcully kernel: ahc0: port 0xe400-0xe4ff mem 0xe4022000-0xe4022fff irq 16 at device 12.0 on pci0 Jul 13 13:21:02 ridcully kernel: ahc0: [ITHREAD] Jul 13 13:21:02 ridcully kernel: aic7895C: Ultra Wide Channel A, SCSI Id=7, 32/253 SCBs Jul 13 13:21:02 ridcully kernel: ahc1: port 0xe800-0xe8ff mem 0xe4024000-0xe4024fff irq 16 at device 12.1 on pci0 Jul 13 13:21:02 ridcully kernel: ahc1: [ITHREAD] Jul 13 13:21:02 ridcully kernel: aic7895C: Ultra Wide Channel B, SCSI Id=7, 32/253 SCBs Jul 13 13:21:02 ridcully kernel: acpi_tz0: on acpi0 Jul 13 13:21:02 ridcully kernel: fdc0: port 0x3f2-0x3f5,0x3f7 irq 6 drq 2 on acpi0 Jul 13 13:21:02 ridcully kernel: fdc0: [FILTER] Jul 13 13:21:02 ridcully kernel: sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 Jul 13 13:21:02 ridcully kernel: sio0: type 16550A Jul 13 13:21:02 ridcully kernel: sio0: [FILTER] Jul 13 13:21:02 ridcully kernel: sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 Jul 13 13:21:02 ridcully kernel: sio1: type 16550A Jul 13 13:21:02 ridcully kernel: sio1: [FILTER] Jul 13 13:21:02 ridcully kernel: pmtimer0 on isa0 Jul 13 13:21:02 ridcully kernel: orm0: at iomem 0xc0000-0xc7fff,0xc8000-0xc87ff,0xc9000-0xc97ff,0xca000-0xcefff,0xcf000-0xd57ff pnpid ORM0000 on isa0 Jul 13 13:21:02 ridcully kernel: atkbdc0: at port 0x60,0x64 on isa0 Jul 13 13:21:02 ridcully kernel: atkbd0: irq 1 on atkbdc0 Jul 13 13:21:02 ridcully kernel: kbd0 at atkbd0 Jul 13 13:21:02 ridcully kernel: atkbd0: [GIANT-LOCKED] Jul 13 13:21:02 ridcully kernel: atkbd0: [ITHREAD] Jul 13 13:21:02 ridcully kernel: ppc0: at port 0x378-0x37f irq 7 on isa0 Jul 13 13:21:02 ridcully kernel: ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode Jul 13 13:21:02 ridcully kernel: ppbus0: on ppc0 Jul 13 13:21:02 ridcully kernel: plip0: on ppbus0 Jul 13 13:21:02 ridcully kernel: lpt0: on ppbus0 Jul 13 13:21:02 ridcully kernel: lpt0: Interrupt-driven port Jul 13 13:21:02 ridcully kernel: ppi0: on ppbus0 Jul 13 13:21:02 ridcully kernel: ppc0: [GIANT-LOCKED] Jul 13 13:21:02 ridcully kernel: ppc0: [ITHREAD] Jul 13 13:21:02 ridcully kernel: sc0: at flags 0x100 on isa0 Jul 13 13:21:02 ridcully kernel: sc0: VGA <16 virtual consoles, flags=0x300> Jul 13 13:21:02 ridcully kernel: vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Jul 13 13:21:02 ridcully kernel: Timecounters tick every 1.000 msec Jul 13 13:21:02 ridcully kernel: acd0: DVDR at ata0-slave UDMA33 Jul 13 13:21:02 ridcully kernel: ad6: 152627MB at ata3-master SATA150 Jul 13 13:21:02 ridcully kernel: ad10: 238475MB at ata5-master SATA300 Jul 13 13:21:02 ridcully kernel: Waiting 5 seconds for SCSI devices to settle Jul 13 13:21:02 ridcully kernel: da0 at ahc0 bus 0 target 1 lun 0 Jul 13 13:21:02 ridcully kernel: da0: Fixed Direct Access SCSI-4 device Jul 13 13:21:02 ridcully kernel: da0: 40.000MB/s transfers (20.000MHz, offset 8, 16bit) Jul 13 13:21:02 ridcully kernel: da0: Command Queueing Enabled Jul 13 13:21:02 ridcully kernel: da0: 8715MB (17850264 512 byte sectors: 255H 63S/T 1111C) Jul 13 13:21:02 ridcully kernel: SMP: AP CPU #1 Launched! Jul 13 13:21:02 ridcully kernel: WARNING: WITNESS option enabled, expect reduced performance. Jul 13 13:21:02 ridcully kernel: Trying to mount root from ufs:/dev/da0s1a Jul 13 13:21:02 ridcully root: /etc/rc: WARNING: Dump directory does not exist. Savecore not run. Jul 13 13:21:08 ridcully login: ROOT LOGIN (root) ON ttyv0 Jul 13 13:21:34 ridcully kernel: WARNING: R/W mount of /mnt denied. Filesystem is not clean - run fsck Jul 13 13:24:06 ridcully kernel: ad10: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=37814559 Jul 13 13:24:42 ridcully kernel: ad10: FAILURE - device detached Jul 13 13:24:42 ridcully kernel: subdisk10: detached Jul 13 13:24:42 ridcully kernel: ad10: detached Jul 13 13:24:42 ridcully kernel: g_vfs_done():ad10s3a[WRITE(offset=114688, length=16384)]error = 6 Jul 13 13:24:42 ridcully kernel: g_vfs_done():ad10s3a[READ(offset=23412736, length=131072)]error = 6 Jul 13 13:24:42 ridcully kernel: g_vfs_done():ad10s3a[READ(offset=23412736, length=65536)]error = 6 Jul 13 13:24:42 ridcully kernel: g_vfs_done():ad10s3a[READ(offset=23478272, length=131072)]error = 6 --tThc/1wpZn/ma/RB-- From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 14:44:03 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 78BD916A402 for ; Fri, 13 Jul 2007 14:44:03 +0000 (UTC) (envelope-from gelsemap@superhero.nl) Received: from superman.superhero.nl (superhero.nl [82.95.198.17]) by mx1.freebsd.org (Postfix) with ESMTP id DC3FC13C48E for ; Fri, 13 Jul 2007 14:44:02 +0000 (UTC) (envelope-from gelsemap@superhero.nl) Received: (qmail 94149 invoked by uid 80); 13 Jul 2007 14:44:05 -0000 Received: from 195.50.100.20 (SquirrelMail authenticated user gelsemap) by www.superhero.nl with HTTP; Fri, 13 Jul 2007 16:44:05 +0200 (CEST) Message-ID: <42845.195.50.100.20.1184337845.squirrel@www.superhero.nl> In-Reply-To: <20070713135127.GA86715@twoflower.idi.ntnu.no> References: <20070713135127.GA86715@twoflower.idi.ntnu.no> Date: Fri, 13 Jul 2007 16:44:05 +0200 (CEST) From: "Gelsema, P \(Patrick\)" To: freebsd-current@freebsd.org User-Agent: SquirrelMail/1.4.8 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: Re: Promise SATA300 TX4 problems in CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2007 14:44:03 -0000 On Fri, July 13, 2007 15:51, Ulf Lilleengen wrote: > Hi, > > I just bought a Promise SATA-300 TX4 card for my computer. I use a SCSI > drive on > an adaptect controller for the system disk. I started encountering > problems when > trying to copy data from the filesystem on one of the ATA disks connected > to the > Promise card. I get these messages: > > ad10: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=37814559 > ad10: FAILURE - device detached > subdisk10: detached > ad10: detached > g_vfs_done():ad10s3a[WRITE(offset=114688, length=16384)]error = 6 > g_vfs_done():ad10s3a[READ(offset=23412736, length=131072)]error = 6 > g_vfs_done():ad10s3a[READ(offset=23412736, length=65536)]error = 6 > g_vfs_done():ad10s3a[READ(offset=23478272, length=131072)]error = 6 I saw the same error on aic7902 (Adaptec 39320D). After running buildworld with the latest sources. In my case i couldnt mount root anymore, even if I typed it in manually. I've also got mangled entries messages. I am running AMD64 version. I am currently testing different setups of harddisks, cables and make worlds to determine the culprit. See http://lists.freebsd.org/pipermail/freebsd-current/2007-July/074910.html for more details. Rgds, Patrick > > Then if I try to use the system (dhclient in this case), it panics with: > panic: vinvalbuf: dirty bufs > > However, I tried installing 6.2 to see if the issue remains there as well. > And > it didn't. I works excellent in 6.2. However, I'd like to run CURRENT on > this > machine. I've attached relevant part of messages, and a core dump can be > found > at http://twoflower.idi.ntnu.no/crash > > Is this perhaps a bug in the ata-subsystem? > -- > Ulf Lilleengen > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 14:48:12 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id ED31D16A402 for ; Fri, 13 Jul 2007 14:48:12 +0000 (UTC) (envelope-from ivoras@fer.hr) Received: from ls405.t-com.hr (ls405.t-com.hr [195.29.150.135]) by mx1.freebsd.org (Postfix) with ESMTP id 7584E13C428 for ; Fri, 13 Jul 2007 14:48:12 +0000 (UTC) (envelope-from ivoras@fer.hr) Received: from ls248.t-com.hr (ls248.t-com.hr [195.29.150.237]) by ls405.t-com.hr (Postfix) with ESMTP id 0FF4A145167; Fri, 13 Jul 2007 16:48:11 +0200 (CEST) Received: from ls248.t-com.hr (localhost.localdomain [127.0.0.1]) by ls248.t-com.hr (Qmlai) with ESMTP id 0CAAAD5004A; Fri, 13 Jul 2007 16:48:11 +0200 (CEST) Received: from ls248.t-com.hr (localhost.localdomain [127.0.0.1]) by ls248.t-com.hr (Qmlai) with ESMTP id EBA87D50047; Fri, 13 Jul 2007 16:48:10 +0200 (CEST) X-Envelope-Sender-Info: g5URFa92gX9K/Rg9VFA/rDP8X/bJh/Qeg7AE4sWgrjI6StkSH1j7CT0zJW9WjWDV X-Envelope-Sender: ivoras@fer.hr Received: from [10.0.0.100] (78-1-120-27.adsl.net.t-com.hr [78.1.120.27]) by ls248.t-com.hr (Qmali) with ESMTP id 829255E01B0; Fri, 13 Jul 2007 16:48:10 +0200 (CEST) Message-ID: <469790A4.3060803@fer.hr> Date: Fri, 13 Jul 2007 16:48:04 +0200 From: Ivan Voras User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Philipp Ost References: <200707130831.44748.jhb@freebsd.org> <46977AE1.9060004@smo.de> In-Reply-To: <46977AE1.9060004@smo.de> X-Enigmail-Version: 0.94.3.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigB3DD9AA008D4164CE4DE5E85" Cc: freebsd-current@freebsd.org Subject: Re: Quick hardware survey - disk INT13 "EDD" services? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2007 14:48:13 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB3DD9AA008D4164CE4DE5E85 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Philipp Ost wrote: > John Baldwin wrote: >> On Saturday 19 May 2007 11:39:53 am Ivan Voras wrote: >> >>> Hi! >>> >>> Does anyone have a machine that doesn't support EDD / packet >>> interface / "Extended INT13" interface on its hard drive(s) and is >>> capable of running 7-CURRENT? (486 and early Pentium class machines?)= > I have an IBM Personal Computer 330-450DX2 which currently has NetBSD > 2.0.2 installed. I don't know the exact copyright date of the BIOS, but= > I can power the machine up again if needed ;-) > The hard drives are Western Digital Caviar 2600 (1.5GiB), but I also > have two Western Digital Caviar 1365 (365MiB) it those are better suite= d > for the task... > For which purposes do you need the machine? I started this thread way back when I hoped I may have the time to add support for GPT booting myself, with the purpose of trying to simplify the loader and discard the support for old non-EDD BIOS-es. Won't happen now, but thanks for the report - maybe someone else can use the information. --------------enigB3DD9AA008D4164CE4DE5E85 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.2.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGl5CpldnAQVacBcgRAjLKAKCmPaUTz9YD/PQTfBRB2vNJcFahZwCfSMwE K6l2Rsai6CfCVUWuXnbEGxs= =JHnZ -----END PGP SIGNATURE----- --------------enigB3DD9AA008D4164CE4DE5E85-- From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 14:53:59 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2948916A407 for ; Fri, 13 Jul 2007 14:53:59 +0000 (UTC) (envelope-from llwang@llwang.org) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.232]) by mx1.freebsd.org (Postfix) with ESMTP id E67B013C428 for ; Fri, 13 Jul 2007 14:53:58 +0000 (UTC) (envelope-from llwang@llwang.org) Received: by wr-out-0506.google.com with SMTP id i23so348321wra for ; Fri, 13 Jul 2007 07:53:58 -0700 (PDT) Received: by 10.78.21.7 with SMTP id 7mr491531huu.1184336820512; Fri, 13 Jul 2007 07:27:00 -0700 (PDT) Received: by 10.78.121.3 with HTTP; Fri, 13 Jul 2007 07:27:00 -0700 (PDT) Message-ID: Date: Fri, 13 Jul 2007 09:27:00 -0500 From: "Li-Lun \"Leland\" Wang" Sender: llwang@llwang.org To: pyunyh@gmail.com In-Reply-To: <20070713100829.GC17801@cdnetworks.co.kr> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070713084325.GA47351@Athena.infor.org> <20070713100829.GC17801@cdnetworks.co.kr> X-Google-Sender-Auth: e6e294faa11b3ca8 Cc: freebsd-current@freebsd.org Subject: Re: threadlock and msk watchdog timeout X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2007 14:53:59 -0000 On 7/13/07, Pyun YongHyeon wrote: > Does msk(4) use shared interrupt? > Show me the output of "vmstat -i". Here is the output of vmstat -i. interrupt total rate irq1: atkbd0 677 1 irq16: mskc0 uhci0 9423 15 irq18: ehci0 uhci+ 9444 15 irq19: atapci0++ 14362 22 irq22: pcm0 15 0 cpu0: timer 1251072 1995 cpu1: timer 1251206 1995 Total 2536199 4044 One thing I forgot to mention is that I've already disabled MSI on this system. Regards, -- llwang From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 14:54:39 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 20A4216A400 for ; Fri, 13 Jul 2007 14:54:39 +0000 (UTC) (envelope-from llwang@llwang.org) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.169]) by mx1.freebsd.org (Postfix) with ESMTP id 9E04B13C4A8 for ; Fri, 13 Jul 2007 14:54:38 +0000 (UTC) (envelope-from llwang@llwang.org) Received: by ug-out-1314.google.com with SMTP id o4so651726uge for ; Fri, 13 Jul 2007 07:54:37 -0700 (PDT) Received: by 10.78.201.10 with SMTP id y10mr494991huf.1184336995314; Fri, 13 Jul 2007 07:29:55 -0700 (PDT) Received: by 10.78.121.3 with HTTP; Fri, 13 Jul 2007 07:29:55 -0700 (PDT) Message-ID: Date: Fri, 13 Jul 2007 09:29:55 -0500 From: "Li-Lun \"Leland\" Wang" Sender: llwang@llwang.org To: "John Baldwin" In-Reply-To: <200707130836.58062.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070520174124.GA14987@Athena.infor.org> <20070521040808.GD36838@cdnetworks.co.kr> <200707130836.58062.jhb@freebsd.org> X-Google-Sender-Auth: 183da2d2658d3eb1 Cc: pyunyh@gmail.com, freebsd-current@freebsd.org Subject: Re: msk watchdog timeout X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2007 14:54:39 -0000 On 7/13/07, John Baldwin wrote: > On Monday 21 May 2007 12:45:39 am Li-Lun "Leland" Wang wrote: > > On 5/20/07, Pyun YongHyeon wrote: > > > On Sun, May 20, 2007 at 09:39:54PM -0500, Li-Lun Leland Wang wrote: > > > > On 5/20/07, Pyun YongHyeon wrote: > > > > >On Mon, May 21, 2007 at 01:41:24AM +0800, Li-Lun Wang (Leland Wang) > wrote: > > > > > > I just installed 7.0-current as of May 3 on my new computer that > comes > > > > > > with an on-board Marvell Yukon Gigabit Ethernet. Every now and > then > > > > > > if the network throughput comes near several hundred kbytes, I get > the > > > > > > msk0 watchdog timeout messages: > > > > > > > > > > > > kernel: msk0: watchdog timeout > > > > > > msk0: watchdog timeout (missed Tx interrupts) -- recovering > > > > > > > > > > > > Although it says recovering, the interface never comes back alive. > > > > > > > > > >The above message indicates the driver sent all pending transmission > > > > >requests but the driver didn't receive corresponding Tx completion > > > > >interrupts. Not recovering from the watchdog timeout means there are > > > > >another issues on the driver. However as disabling MSI fixed the > > > > >issue, I guess it's not fault of msk(4) and it comes from bad/broken > > > > >MSI implementation of your system. I guess it's time to add your > > > > >chipset to a PCI quirk table in order to blacklist it. > > > > > > > > I do reckon that MSI doesn't work on earlier Intel chipsets. Mine is > > > > P965 (on a gigabyte GA-965P-DS3 rev 1.3), which I suppose is recent > > > > enough to support MSI, isn't it? Or could there be other problems > > > > > > Using latest chipsets does not necessarily guarantee working MSI. > > > > I see. I think we should maybe add P965 to the PCI quirk list for > > broken MSI, then? > > Possibly. > > > > > possible? > > > > > > > > > > Yes. But I couldn't find possible issue on msk(4) yet. > > > > Maybe I was not clear enough. Could there be something else that > > causes MSI to not working correctly other than the chipset? I was > > just wondering why I didn't see too many broken MSI reports if most > > Intel chipsets are broken. > > If it's not the driver it would be the chipset. We already don't use MSI on > systems that don't support either PCI-X or PCI-express, so that implicitly > blacklists most older Intel chipsets. Do you have any other devices in your > system that support MSI? pciconf -lc output would be useful to look at. Here is the output of pciconf -lc: hostb0@pci0:0:0: class=0x060000 card=0x50001458 chip=0x29a08086 rev=0x02 hdr=0x00 cap 09[e0] = vendor (length 9) Intel cap 0 version 1 pcib1@pci0:1:0: class=0x060400 card=0x50001458 chip=0x29a18086 rev=0x02 hdr=0x01 cap 0d[88] = PCI Bridge card=0x50001458 cap 01[80] = powerspec 3 supports D0 D3 current D0 cap 05[90] = MSI supports 1 message cap 10[a0] = PCI-Express 1 root port none0@pci0:3:0: class=0x078000 card=0x29a41458 chip=0x29a48086 rev=0x02 hdr=0x00 cap 01[50] = powerspec 3 supports D0 D3 current D0 cap 05[8c] = MSI supports 1 message, 64 bit uhci0@pci0:26:0: class=0x0c0300 card=0x50041458 chip=0x28348086 rev=0x02 hdr=0x00 uhci1@pci0:26:1: class=0x0c0300 card=0x50041458 chip=0x28358086 rev=0x02 hdr=0x00 ehci0@pci0:26:7: class=0x0c0320 card=0x50061458 chip=0x283a8086 rev=0x02 hdr=0x00 cap 01[50] = powerspec 2 supports D0 D3 current D0 pcm0@pci0:27:0: class=0x040300 card=0xa0021458 chip=0x284b8086 rev=0x02 hdr=0x00 cap 01[50] = powerspec 2 supports D0 D3 current D0 cap 05[60] = MSI supports 1 message, 64 bit cap 10[70] = PCI-Express 1 type 0 pcib2@pci0:28:0: class=0x060400 card=0x50011458 chip=0x283f8086 rev=0x02 hdr=0x01 cap 10[40] = PCI-Express 1 root port cap 05[80] = MSI supports 1 message cap 0d[90] = PCI Bridge card=0x50011458 cap 01[a0] = powerspec 2 supports D0 D3 current D0 pcib3@pci0:28:3: class=0x060400 card=0x50011458 chip=0x28458086 rev=0x02 hdr=0x01 cap 10[40] = PCI-Express 1 root port cap 05[80] = MSI supports 1 message cap 0d[90] = PCI Bridge card=0x50011458 cap 01[a0] = powerspec 2 supports D0 D3 current D0 pcib4@pci0:28:4: class=0x060400 card=0x50011458 chip=0x28478086 rev=0x02 hdr=0x01 cap 10[40] = PCI-Express 1 root port cap 05[80] = MSI supports 1 message cap 0d[90] = PCI Bridge card=0x50011458 cap 01[a0] = powerspec 2 supports D0 D3 current D0 uhci2@pci0:29:0: class=0x0c0300 card=0x50041458 chip=0x28308086 rev=0x02 hdr=0x00 uhci3@pci0:29:1: class=0x0c0300 card=0x50041458 chip=0x28318086 rev=0x02 hdr=0x00 uhci4@pci0:29:2: class=0x0c0300 card=0x50041458 chip=0x28328086 rev=0x02 hdr=0x00 ehci1@pci0:29:7: class=0x0c0320 card=0x50061458 chip=0x28368086 rev=0x02 hdr=0x00 cap 01[50] = powerspec 2 supports D0 D3 current D0 pcib5@pci0:30:0: class=0x060401 card=0x50001458 chip=0x244e8086 rev=0xf2 hdr=0x01 cap 0d[50] = PCI Bridge card=0x50001458 isab0@pci0:31:0: class=0x060100 card=0x50011458 chip=0x28108086 rev=0x02 hdr=0x00 cap 09[e0] = vendor (length 12) Intel cap 1 version 0 features: SATA RAID-5, 4 PCI-e x1 slots, SATA RAID-0/1/10 atapci1@pci0:31:2: class=0x010601 card=0xb0051458 chip=0x28248086 rev=0x02 hdr=0x00 cap 05[80] = MSI supports 16 messages cap 01[70] = powerspec 3 supports D0 D3 current D0 cap 12[a8] = unknown ichsmb0@pci0:31:3: class=0x0c0500 card=0x50011458 chip=0x283e8086 rev=0x02 hdr=0x00 vgapci0@pci1:0:0: class=0x030000 card=0x34451458 chip=0x042110de rev=0xa1 hdr=0x00 cap 01[60] = powerspec 2 supports D0 D3 current D0 cap 05[68] = MSI supports 1 message, 64 bit cap 10[78] = PCI-Express 1 endpoint atapci0@pci3:0:0: class=0x010185 card=0xb0001458 chip=0x2363197b rev=0x02 hdr=0x00 cap 01[68] = powerspec 2 supports D0 D3 current D0 cap 10[50] = PCI-Express 1 legacy endpoint IRQ 0 mskc0@pci4:0:0: class=0x020000 card=0xe0001458 chip=0x436211ab rev=0x22 hdr=0x00 cap 01[48] = powerspec 2 supports D0 D1 D2 D3 current D0 cap 03[50] = VPD cap 05[5c] = MSI supports 2 messages, 64 bit cap 10[e0] = PCI-Express 1 legacy endpoint Thanks. -- llwang From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 15:00:44 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 83CE716A409 for ; Fri, 13 Jul 2007 15:00:44 +0000 (UTC) (envelope-from fullermd@over-yonder.net) Received: from optimus.centralmiss.com (ns.centralmiss.com [206.156.254.79]) by mx1.freebsd.org (Postfix) with ESMTP id 5B79B13C442 for ; Fri, 13 Jul 2007 15:00:44 +0000 (UTC) (envelope-from fullermd@over-yonder.net) Received: from draco.over-yonder.net (adsl-072-148-013-213.sip.jan.bellsouth.net [72.148.13.213]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by optimus.centralmiss.com (Postfix) with ESMTP id C69FB28BD8 for ; Fri, 13 Jul 2007 10:00:43 -0500 (CDT) Received: by draco.over-yonder.net (Postfix, from userid 100) id 5101261C42; Fri, 13 Jul 2007 10:00:43 -0500 (CDT) Date: Fri, 13 Jul 2007 10:00:43 -0500 From: "Matthew D. Fuller" To: freebsd-current@freebsd.org Message-ID: <20070713150043.GA64470@over-yonder.net> References: <20070713135127.GA86715@twoflower.idi.ntnu.no> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070713135127.GA86715@twoflower.idi.ntnu.no> X-Editor: vi X-OS: FreeBSD User-Agent: Mutt/1.5.16-fullermd.4 (2007-06-09) Subject: Re: Promise SATA300 TX4 problems in CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2007 15:00:44 -0000 On Fri, Jul 13, 2007 at 03:51:27PM +0200 I heard the voice of Ulf Lilleengen, and lo! it spake thus: > > I started encountering problems when trying to copy data from the > filesystem on one of the ATA disks connected to the Promise card. I > get these messages: > > ad10: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=37814559 [...] > However, I tried installing 6.2 to see if the issue remains there as > well. And it didn't. I works excellent in 6.2. This may be related to a problem I've had with -CURRENT on a box with a TX2200 for a while. See . It failed with a couple-weeks-ago -CURRENT, and also with a -CURRENT back in early March, but runs 6.2 like nobody's business (or I wouldn't be typing this mail on it ;) -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 15:23:25 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5CBFA16A405 for ; Fri, 13 Jul 2007 15:23:25 +0000 (UTC) (envelope-from h.schmalzbauer@omnisec.de) Received: from host.omnisec.de (host.omnisec.de [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id D109F13C494 for ; Fri, 13 Jul 2007 15:23:24 +0000 (UTC) (envelope-from h.schmalzbauer@omnisec.de) Received: from tek.flintsbach.schmalzbauer.de (tek.flintsbach.schmalzbauer.de [172.21.2.3]) by host.omnisec.de (8.13.8/8.13.8) with ESMTP id l6DFIk5K026346 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Jul 2007 17:18:51 +0200 (CEST) (envelope-from h.schmalzbauer@omnisec.de) Received: from titan.flintsbach.schmalzbauer.de (titan.flintsbach.schmalzbauer.de [IPv6:fec0::1:0:0:1:1]) by tek.flintsbach.schmalzbauer.de (8.13.8/8.13.8) with ESMTP id l6DFNIiT051098; Fri, 13 Jul 2007 17:23:18 +0200 (CEST) (envelope-from h.schmalzbauer@omnisec.de) Received: by titan.flintsbach.schmalzbauer.de (8.14.1/8.14.1/Submit) id l6DFIkek001295; Fri, 13 Jul 2007 17:18:46 +0200 (CEST) (envelope-from h.schmalzbauer@omnisec.de) From: Harald Schmalzbauer Organization: OmniSEC To: freebsd-current@freebsd.org, "rhurlin@gwdg.de >> \"Hurling, Rainer\"" Date: Fri, 13 Jul 2007 17:18:45 +0200 User-Agent: KMail/1.9.6 References: <468345F2.1060209@freebsd.org> <200707112331.19068.h.schmalzbauer@omnisec.de> <4695EC5D.4020504@nw-fva.de> In-Reply-To: <4695EC5D.4020504@nw-fva.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200707131718.45968.h.schmalzbauer@omnisec.de> Cc: Subject: Re: Nvidia-driver and current lead system reboot with no error message X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2007 15:23:25 -0000 Am Donnerstag, 12. Juli 2007 schrieb Rainer Hurling: > Hello Harry, [*SNIP*] > This error in src/nvidia_pci.c originates by testing the version of > 7.0-CURRENT: > > -------------- > #if __FreeBSD_version >=3D 700031 > status =3D bus_setup_intr(dev, sc->irq, flags, NULL, nvidia_intr, sc, > &sc->irq_ih); > #else > status =3D bus_setup_intr(dev, sc->irq, flags, nvidia_intr, sc, > &sc->irq_ih); > #endif > -------------- > > Do you use newest CURRENT? With my FreeBSD version from yesterday the Yes, it was a fresh -current and I had seen this too. Just increasing 70003= 1=20 to 800031 has helped :) At first I hadn't looked into src/nvidia_pci.c because my C skills ar far=20 beyond trying to fix drivers... But it lasts for that kind of try and=20 error :) Best regards, =2DHarry =2D-=20 OmniSEC - UNIX und Windows Netzwerke - Sicher Harald Schmalzbauer =46lintsbacher Str. 3 80686 M=FCnchen +49 (0) 89 18947781 +49 (0) 160 93860101 USt-IdNr.: DE253184753 From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 16:10:13 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.ORG Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8C43616A403 for ; Fri, 13 Jul 2007 16:10:13 +0000 (UTC) (envelope-from hugo@barafranca.com) Received: from mail.barafranca.com (mail.barafranca.com [67.19.101.164]) by mx1.freebsd.org (Postfix) with ESMTP id 46DBD13C481 for ; Fri, 13 Jul 2007 16:10:13 +0000 (UTC) (envelope-from hugo@barafranca.com) Received: from localhost (localhost [127.0.0.1]) by mail.barafranca.com (Postfix) with ESMTP id 0DDB9C3DD0 for ; Fri, 13 Jul 2007 16:47:44 +0000 (UTC) Received: from mail.barafranca.com ([67.19.101.164]) by localhost (mail.barafranca.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 50924-01 for ; Fri, 13 Jul 2007 16:47:01 +0000 (UTC) Received: from nexus.bsdlan.org (a213-22-26-49.cpe.netcabo.pt [213.22.26.49]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.barafranca.com (Postfix) with ESMTP id 505E9C4720 for ; Fri, 13 Jul 2007 16:46:59 +0000 (UTC) Message-ID: <4697A3BB.90607@barafranca.com> Date: Fri, 13 Jul 2007 17:09:31 +0100 From: Hugo Silva User-Agent: Thunderbird 2.0.0.0 (X11/20070609) MIME-Version: 1.0 To: freebsd-current@FreeBSD.ORG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at barafranca.com X-Spam-Status: No, score=0 tagged_above=-1 required=4 tests=[none] X-Spam-Score: 0 X-Spam-Level: Cc: Subject: Spurious RSTs, syncache, and pf weirdness X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2007 16:10:13 -0000 Hi list, I've been following the discussions about spurious rsts and syncache problems, however today I came across something new. This test server is running a low volume load balancer (haproxy) with 7.0. FreeBSD 7.0-CURRENT FreeBSD 7.0-CURRENT #0: Thu Jul 12 23:08:18 UTC 2007 I'm getting enormous amounts of syncache/spurious rsts errors: TCP: [189.174.49.42]:1092 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1096 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1094 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1097 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1099 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1098 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1100 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1101 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1102 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1103 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1104 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1105 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1107 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1106 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1108 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1109 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1110 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1113 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1112 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1114 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1115 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1116 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1117 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1118 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1120 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1119 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1121 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1122 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1123 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1124 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1125 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1127 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1126 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1129 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1130 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1131 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1132 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1133 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1135 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1137 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1136 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1138 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1139 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1141 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1140 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1143 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1145 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1146 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1149 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1148 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1151 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1150 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1153 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1155 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1154 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1157 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1156 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1158 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1160 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1161 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1162 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1163 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1164 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1165 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1166 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1167 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1169 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1168 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1170 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1171 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1172 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1173 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1174 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1176 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1175 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1177 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1178 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1179 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1180 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1182 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1184 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1183 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1187 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1186 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1188 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1192 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1189 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1191 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1190 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1193 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1194 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1197 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1196 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1198 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1199 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1201 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1202 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1203 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1205 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1204 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1206 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1208 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1210 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1211 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1212 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1213 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1214 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1215 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1217 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1216 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1218 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1219 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1221 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1220 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1223 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1225 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1224 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1226 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1227 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1228 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1229 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1231 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1232 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1233 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1234 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1235 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1239 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1241 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1240 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1243 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1242 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1245 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1244 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1246 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1247 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1248 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1251 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1252 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1253 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1254 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1256 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1255 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1257 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1258 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1259 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1261 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1260 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint (root@deserteagle/ttyp1) root:/usr/local/etc# uname -sr FreeBSD 7.0-CURRENT (root@deserteagle/ttyp1) root:/usr/local/etc# uname -srv FreeBSD 7.0-CURRENT FreeBSD 7.0-CURRENT #0: Thu Jul 12 23:08:18 UTC 2007 root@mailspam.barafranca.com:/usr/obj/usr/src/sys/DESERTEAGLE (root@deserteagle/ttyp1) root:/usr/local/etc# dmesg TCP: [189.174.49.42]:4842 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:4851 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:4850 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:4849 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:4848 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:4861 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:4860 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:4859 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:4858 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:4857 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:4855 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:4854 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:4853 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:4852 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:4863 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:4862 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:4866 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:4865 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:4868 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:4869 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:4872 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:4870 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:4874 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:4875 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:4873 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:4876 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:4877 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:4878 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:4879 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:4880 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:4881 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [86.137.72.197]:55368 to [SERVER_IP]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected TCP: [86.137.72.197]:55368 to [SERVER_IP]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected TCP: [86.137.72.197]:55368 to [SERVER_IP]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected TCP: [86.137.72.197]:55369 to [SERVER_IP]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected TCP: [86.137.72.197]:55369 to [SERVER_IP]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected TCP: [86.137.72.197]:55369 to [SERVER_IP]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected TCP: [189.174.49.42]:4882 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:4883 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [200.101.114.236]:50786 to [SERVER_IP]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected TCP: [189.174.49.42]:4884 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:4886 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:4885 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:4888 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [88.249.5.47]:10126 to [SERVER_IP]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected TCP: [88.249.5.47]:10129 to [SERVER_IP]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected TCP: [189.174.49.42]:4890 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:4889 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:4891 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:4892 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:4894 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:4895 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:4896 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:4897 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:4900 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:4898 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:4899 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:4901 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:4902 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:4903 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:4904 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:4905 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:4910 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:4911 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:4907 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:4912 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:4913 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:4914 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:4915 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:4916 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:4920 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:4921 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:4927 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:4928 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:4929 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:4932 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:4933 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [85.113.252.100]:3010 to [SERVER_IP]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected TCP: [189.174.49.42]:4934 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:4935 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:4936 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:4937 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:4938 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:4940 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:4941 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:4939 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:4942 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:4943 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:4944 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:4946 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:4945 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [88.249.5.47]:10451 to [SERVER_IP]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected TCP: [88.249.5.47]:10451 to [SERVER_IP]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected TCP: [88.249.5.47]:10452 to [SERVER_IP]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected TCP: [189.174.49.42]:4948 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:4947 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:4949 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:4954 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:4955 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:4956 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:4958 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:4957 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:4960 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:4959 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:4962 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:4961 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:4963 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:4964 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:4965 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:4968 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:4969 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:4966 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:4972 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:4970 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:4971 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:4976 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:4974 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:4975 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:4980 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:4979 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:4982 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:4983 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:4984 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:4985 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:4986 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:4987 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:4988 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:4989 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:4990 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:4991 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:4992 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:4993 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:4996 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:4997 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:4994 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:4995 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:4998 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1026 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:5000 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1030 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1031 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1033 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1032 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1034 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1037 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1039 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1041 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1040 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1042 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1043 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1045 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1046 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1051 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1050 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1052 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1047 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1054 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1057 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1056 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1059 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1058 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1060 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1061 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1063 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1062 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1064 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1065 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1067 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1066 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [80.74.160.18]:36950 to [SERVER_IP]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected TCP: [80.74.160.18]:36950 to [SERVER_IP]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected TCP: [80.74.160.18]:36950 to [SERVER_IP]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected TCP: [189.174.49.42]:1069 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1068 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1070 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1072 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1073 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1074 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1077 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1076 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1081 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1080 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1083 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1082 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1079 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1078 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1085 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1084 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1086 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1089 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1088 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1091 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1093 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1092 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1096 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1094 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1097 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1099 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1098 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1100 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1101 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1102 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1103 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1104 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1105 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1107 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1106 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1108 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1109 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1110 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [83.249.50.6]:61527 to [SERVER_IP]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected TCP: [83.249.50.6]:61527 to [SERVER_IP]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected TCP: [83.249.50.6]:63029 to [SERVER_IP]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected TCP: [189.174.49.42]:1113 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1112 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1114 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1115 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1116 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1117 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1118 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1120 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1119 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1121 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1122 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1123 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1124 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1125 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1127 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1126 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1129 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1130 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1131 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [83.54.146.138]:1666 to [SERVER_IP]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected TCP: [83.54.146.138]:1666 to [SERVER_IP]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected TCP: [83.54.146.138]:1666 to [SERVER_IP]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected TCP: [83.54.146.138]:1666 to [SERVER_IP]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected TCP: [83.54.146.138]:1666 to [SERVER_IP]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected TCP: [83.54.146.138]:1666 to [SERVER_IP]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected TCP: [189.174.49.42]:1132 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [83.54.146.138]:1666 to [SERVER_IP]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected TCP: [189.174.49.42]:1133 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1135 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1137 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1136 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1138 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1139 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [193.77.54.179]:3091 to [SERVER_IP]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected TCP: [193.77.54.179]:3091 to [SERVER_IP]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected TCP: [193.77.54.179]:3091 to [SERVER_IP]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected TCP: [193.77.54.179]:3091 to [SERVER_IP]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected TCP: [189.174.49.42]:1141 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1140 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1143 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1145 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1146 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1149 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1148 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1151 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1150 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1153 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1155 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1154 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1157 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1156 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1158 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1160 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1161 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1162 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1163 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1164 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1165 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1166 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1167 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1169 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1168 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1170 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1171 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1172 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1173 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1174 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1176 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1175 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1177 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1178 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1179 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1180 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1182 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1184 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1183 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1187 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1186 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1188 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1192 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1189 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1191 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1190 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1193 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1194 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1197 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1196 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1198 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1199 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1201 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1202 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [81.214.207.221]:4121 to [SERVER_IP]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected TCP: [81.214.207.221]:4121 to [SERVER_IP]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected TCP: [81.214.207.221]:4121 to [SERVER_IP]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected TCP: [189.174.49.42]:1203 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1205 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1204 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [193.77.54.179]:3184 to [SERVER_IP]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected TCP: [193.77.54.179]:3184 to [SERVER_IP]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected TCP: [193.77.54.179]:3184 to [SERVER_IP]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected TCP: [189.174.49.42]:1206 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1208 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1210 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1211 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1212 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1213 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1214 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1215 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1217 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1216 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1218 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1219 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1221 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1220 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1223 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1225 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1224 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1226 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1227 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1228 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1229 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1231 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1232 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1233 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1234 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1235 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1239 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1241 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1240 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1243 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1242 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1245 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1244 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1246 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1247 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1248 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1251 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1252 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1253 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1254 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1256 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1255 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1257 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1258 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1259 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [193.77.54.179]:3259 to [SERVER_IP]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected TCP: [193.77.54.179]:3259 to [SERVER_IP]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected TCP: [193.77.54.179]:3259 to [SERVER_IP]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected TCP: [193.77.54.179]:3259 to [SERVER_IP]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected TCP: [193.77.54.179]:3259 to [SERVER_IP]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected TCP: [193.77.54.179]:3259 to [SERVER_IP]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected TCP: [193.77.54.179]:3259 to [SERVER_IP]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected TCP: [193.77.54.179]:3259 to [SERVER_IP]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected TCP: [193.77.54.179]:3259 to [SERVER_IP]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected TCP: [189.174.49.42]:1261 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1260 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1263 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1262 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [86.106.13.35]:4733 to [SERVER_IP]:80 tcpflags 0x11; syncache_expand: SEQ 655051299 != IRS+1 655050586, segment rejected TCP: [189.174.49.42]:1265 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1264 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1266 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1267 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [193.77.54.179]:3293 to [SERVER_IP]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected TCP: [193.77.54.179]:3293 to [SERVER_IP]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected TCP: [193.77.54.179]:3293 to [SERVER_IP]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected TCP: [193.77.54.179]:3293 to [SERVER_IP]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected TCP: [193.77.54.179]:3293 to [SERVER_IP]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected TCP: [193.77.54.179]:3293 to [SERVER_IP]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected TCP: [193.77.54.179]:3293 to [SERVER_IP]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected TCP: [193.77.54.179]:3293 to [SERVER_IP]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected TCP: [193.77.54.179]:3293 to [SERVER_IP]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected TCP: [193.77.54.179]:3293 to [SERVER_IP]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected TCP: [193.77.54.179]:3293 to [SERVER_IP]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected TCP: [193.77.54.179]:3293 to [SERVER_IP]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected TCP: [193.77.54.179]:3293 to [SERVER_IP]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected TCP: [193.77.54.179]:3293 to [SERVER_IP]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected TCP: [193.77.54.179]:3293 to [SERVER_IP]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected TCP: [193.77.54.179]:3293 to [SERVER_IP]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected TCP: [189.174.49.42]:1269 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint TCP: [189.174.49.42]:1268 to [SERVER_IP]:80 tcpflags 0x14; tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint But these have been talked about on the lists before. What's new for me is the following bits of the firewall (pf) logs: tcpdump: WARNING: pflog0: no IPv4 address assigned tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on pflog0, link-type PFLOG (OpenBSD pflog file), capture size 96 bytes 000000 rule 0/0(match): block unkn(99) on em0: SERVER_IP.52582 > 70.87.97.148.80: [|tcp] 29. 232416 rule 0/0(match): block unkn(99) on em0: SERVER_IP.53798 > 70.87.97.148.80: [|tcp] 6. 169692 rule 0/0(match): block in/out on em0: 189.174.49.42.1090 > SERVER_IP.80: [|tcp] 23. 727713 rule 0/0(match): block unkn(99) on em0: SERVER_IP.54494 > 70.87.97.148.80: [|tcp] 4. 868905 rule 0/0(match): block unkn(99) on em0: SERVER_IP.52582 > 70.87.97.148.80: [|tcp] 10. 466335 rule 0/0(match): block in/out on em0: 86.83.219.100.52937 > SERVER_IP.80: tcp 8 [bad hdr length 12 - too short, < 20] 003244 rule 0/0(match): block in/out on em0: 86.83.219.100.52937 > SERVER_IP.80: tcp 8 [bad hdr length 12 - too short, < 20] 356903 rule 0/0(match): block in/out on em0: 86.83.219.100.52938 > SERVER_IP.80: tcp 804 [bad hdr length 12 - too short, < 20] 017480 rule 0/0(match): block in/out on em0: 86.83.219.100.52937 > SERVER_IP.80: tcp 8 [bad hdr length 12 - too short, < 20] 365816 rule 0/0(match): block in/out on em0: SERVER_IP.80 > 86.83.219.100.52937: [|tcp] 417682 rule 0/0(match): block in/out on em0: 86.83.219.100.52937 > SERVER_IP.80: tcp 8 [bad hdr length 12 - too short, < 20] 103435 rule 0/0(match): block in/out on em0: 86.83.219.100.52938 > SERVER_IP.80: tcp 804 [bad hdr length 12 - too short, < 20] 054869 rule 0/0(match): block in/out on em0: SERVER_IP.80 > 86.83.219.100.52937: tcp 440 [bad hdr length 12 - too short, < 20] 951978 rule 0/0(match): block in/out on em0: SERVER_IP.80 > 86.83.219.100.52937: tcp 440 [bad hdr length 12 - too short, < 20] 447951 rule 0/0(match): block in/out on em0: 86.83.219.100.52937 > SERVER_IP.80: tcp 8 [bad hdr length 12 - too short, < 20] 330415 rule 0/0(match): block in/out on em0: 86.83.219.100.52938 > SERVER_IP.80: tcp 544 [bad hdr length 12 - too short, < 20] 925605 rule 0/0(match): block in/out on em0: SERVER_IP.80 > 86.83.219.100.52937: tcp 440 [bad hdr length 12 - too short, < 20] 879470 rule 0/0(match): block in/out on em0: 86.83.219.100.52938 > SERVER_IP.80: tcp 544 [bad hdr length 12 - too short, < 20] 989978 rule 0/0(match): block in/out on em0: 86.83.219.100.52937 > SERVER_IP.80: tcp 4 [bad hdr length 16 - too short, < 20] 812219 rule 0/0(match): block in/out on em0: 86.83.219.100.52938 > SERVER_IP.80: tcp 804 [bad hdr length 12 - too short, < 20] 526273 rule 0/0(match): block in/out on em0: SERVER_IP.80 > 86.83.219.100.52937: tcp 436 [bad hdr length 16 - too short, < 20] 2. 599942 rule 0/0(match): block in/out on em0: SERVER_IP.80 > 86.83.219.100.52937: tcp 436 [bad hdr length 16 - too short, < 20] 086065 rule 0/0(match): block in/out on em0: SERVER_IP.80 > 86.83.219.100.52937: tcp 4 [bad hdr length 16 - too short, < 20] 000028 rule 0/0(match): block in/out on em0: SERVER_IP.80 > 86.83.219.100.52937: tcp 4 [bad hdr length 16 - too short, < 20] 384983 rule 0/0(match): block in/out on em0: 86.83.219.100.52938 > SERVER_IP.80: tcp 804 [bad hdr length 12 - too short, < 20] 1. 822808 rule 0/0(match): block in/out on em0: 86.83.219.100.52937 > SERVER_IP.80: tcp 4 [bad hdr length 16 - too short, < 20] 2. 706014 rule 0/0(match): block in/out on em0: SERVER_IP.80 > 86.83.219.100.52937: tcp 436 [bad hdr length 16 - too short, < 20] 2. 680363 rule 0/0(match): block in/out on em0: 86.83.219.100.52938 > SERVER_IP.80: tcp 800 [bad hdr length 16 - too short, < 20] 1. 302568 rule 0/0(match): block unkn(99) on em0: SERVER_IP.53798 > 70.87.97.148.80: tcp 16 [bad hdr length 16 - too short, < 20] 2. 285843 rule 0/0(match): block in/out on em0: 189.174.49.42.1111 > SERVER_IP.80: tcp 4 [bad hdr length 16 - too short, < 20] 3. 507719 rule 0/0(match): block in/out on em0: 86.83.219.100.52937 > SERVER_IP.80: [|tcp] 023314 rule 0/0(match): block in/out on em0: SERVER_IP.80 > 86.83.219.100.52937: tcp 436 [bad hdr length 16 - too short, < 20] 7. 258828 rule 0/0(match): block in/out on em0: 86.83.219.100.52938 > SERVER_IP.80: [|tcp] 12. 140786 rule 0/0(match): block in/out on em0: SERVER_IP.80 > 86.83.219.100.52937: [|tcp] 4. 680908 rule 0/0(match): block unkn(99) on em0: SERVER_IP.54494 > 70.87.97.148.80: [|tcp] 4. 868902 rule 0/0(match): block unkn(99) on em0: SERVER_IP.52582 > 70.87.97.148.80: [|tcp] 29. 049419 rule 0/0(match): block in/out on em0: SERVER_IP.80 > 86.83.219.100.52937: [|tcp] 183006 rule 0/0(match): block unkn(99) on em0: SERVER_IP.53798 > 70.87.97.148.80: [|tcp] 29. 897395 rule 0/0(match): block unkn(99) on em0: SERVER_IP.54494 > 70.87.97.148.80: [|tcp] 8. 518833 rule 0/0(match): block in/out on em0: SERVER_IP.80 > 86.83.219.100.52937: [|tcp] 8. 305595 rule 0/0(match): block in/out on em0: 86.83.219.100.53088 > SERVER_IP.80: [|tcp] 13. 416273 rule 0/0(match): block in/out on em0: 86.83.219.100.53088 > SERVER_IP.80: [|tcp] 3. 860625 rule 0/0(match): block unkn(99) on em0: SERVER_IP.53798 > 70.87.97.148.80: [|tcp] 12. 545885 rule 0/0(match): block in/out on em0: 189.174.49.42.1147 > SERVER_IP.80: [|tcp] 470857 rule 0/0(match): block in/out on em0: SERVER_IP.80 > 86.83.219.100.52937: [|tcp] 3. 536973 rule 0/0(match): block in/out on em0: 189.174.49.42.1152 > SERVER_IP.80: [|tcp] 13. 343683 rule 0/0(match): block unkn(99) on em0: SERVER_IP.54494 > 70.87.97.148.80: [|tcp] 21. 718571 rule 0/0(match): block in/out on em0: SERVER_IP.80 > 86.83.219.100.52937: [|tcp] 42. 280158 rule 0/0(match): block unkn(99) on em0: SERVER_IP.54494 > 70.87.97.148.80: [|tcp] Notice the unkn(99) and the bad hdr length errors. on 6.2, this problem doesn't exist. Is this something new or is it related to the spurious rsts & syncache errors ? Best regards, Hugo From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 16:17:11 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 14DA116A401 for ; Fri, 13 Jul 2007 16:17:11 +0000 (UTC) (envelope-from almarrie@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.248]) by mx1.freebsd.org (Postfix) with ESMTP id 7154113C441 for ; Fri, 13 Jul 2007 16:17:10 +0000 (UTC) (envelope-from almarrie@gmail.com) Received: by an-out-0708.google.com with SMTP id c14so132249anc for ; Fri, 13 Jul 2007 09:17:09 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Vh4QiCMSHNhELZNFu0AIqY99dXhkYiwG67pH0EZ4Movy7TN35+EubH/kAS0xauDVWJghuJCueZQaKw+4qqM7ZzRDCym4su7Xao/GM2hO+7OWbnXSn/cLAIVTHCiizViTKNpARU25O9mDMcFpqwQbus1quDsSoo90plKoWyp5x1k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=bT51Ip3q7yEYzOziqhvPlDwrUH/2s7Ie3gmAsc16ImPuckWsQAvrPGru8WCsMn5oOrsxCRKYdfyz2XvulPrv9vQzn06RPbpqLBdXBpLVFbEaZlJIA0XmN+qjvZCa3iinBt64qMkIi0C4jzm0W0uneLT7E2KFC1lK38wxzrnSsbs= Received: by 10.100.10.20 with SMTP id 20mr1000439anj.1184343428840; Fri, 13 Jul 2007 09:17:08 -0700 (PDT) Received: by 10.100.9.14 with HTTP; Fri, 13 Jul 2007 09:17:08 -0700 (PDT) Message-ID: <499c70c0707130917q41979bc9y5ab69d6fb6454cc0@mail.gmail.com> Date: Fri, 13 Jul 2007 19:17:08 +0300 From: "Abdullah Ibn Hamad Al-Marri" To: "Hugo Silva" In-Reply-To: <4697A3BB.90607@barafranca.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4697A3BB.90607@barafranca.com> Cc: freebsd-current@freebsd.org Subject: Re: Spurious RSTs, syncache, and pf weirdness X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2007 16:17:11 -0000 On 7/13/07, Hugo Silva wrote: > Hi list, > > I've been following the discussions about spurious rsts and syncache > problems, however today I came across something new. > > This test server is running a low volume load balancer (haproxy) with 7.0. > > > FreeBSD 7.0-CURRENT FreeBSD 7.0-CURRENT #0: Thu Jul 12 23:08:18 UTC 2007 > > > I'm getting enormous amounts of syncache/spurious rsts errors: > > TCP: [189.174.49.42]:1092 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1096 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1094 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1097 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1099 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1098 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1100 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1101 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1102 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1103 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1104 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1105 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1107 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1106 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1108 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1109 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1110 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1113 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1112 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1114 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1115 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1116 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1117 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1118 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1120 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1119 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1121 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1122 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1123 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1124 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1125 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1127 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1126 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1129 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1130 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1131 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1132 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1133 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1135 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1137 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1136 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1138 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1139 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1141 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1140 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1143 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1145 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1146 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1149 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1148 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1151 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1150 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1153 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1155 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1154 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1157 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1156 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1158 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1160 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1161 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1162 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1163 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1164 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1165 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1166 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1167 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1169 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1168 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1170 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1171 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1172 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1173 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1174 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1176 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1175 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1177 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1178 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1179 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1180 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1182 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1184 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1183 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1187 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1186 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1188 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1192 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1189 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1191 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1190 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1193 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1194 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1197 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1196 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1198 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1199 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1201 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1202 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1203 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1205 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1204 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1206 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1208 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1210 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1211 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1212 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1213 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1214 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1215 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1217 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1216 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1218 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1219 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1221 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1220 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1223 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1225 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1224 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1226 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1227 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1228 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1229 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1231 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1232 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1233 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1234 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1235 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1239 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1241 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1240 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1243 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1242 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1245 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1244 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1246 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1247 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1248 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1251 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1252 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1253 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1254 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1256 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1255 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1257 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1258 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1259 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1261 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1260 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > (root@deserteagle/ttyp1) root:/usr/local/etc# uname -sr > FreeBSD 7.0-CURRENT > (root@deserteagle/ttyp1) root:/usr/local/etc# uname -srv > FreeBSD 7.0-CURRENT FreeBSD 7.0-CURRENT #0: Thu Jul 12 23:08:18 UTC > 2007 root@mailspam.barafranca.com:/usr/obj/usr/src/sys/DESERTEAGLE > (root@deserteagle/ttyp1) root:/usr/local/etc# dmesg > TCP: [189.174.49.42]:4842 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:4851 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:4850 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:4849 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:4848 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:4861 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:4860 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:4859 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:4858 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:4857 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:4855 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:4854 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:4853 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:4852 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:4863 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:4862 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:4866 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:4865 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:4868 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:4869 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:4872 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:4870 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:4874 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:4875 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:4873 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:4876 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:4877 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:4878 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:4879 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:4880 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:4881 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [86.137.72.197]:55368 to [SERVER_IP]:80 tcpflags 0x4; > tcp_input: Listen socket: Spurious RST, segment rejected > TCP: [86.137.72.197]:55368 to [SERVER_IP]:80 tcpflags 0x4; > tcp_input: Listen socket: Spurious RST, segment rejected > TCP: [86.137.72.197]:55368 to [SERVER_IP]:80 tcpflags 0x4; > tcp_input: Listen socket: Spurious RST, segment rejected > TCP: [86.137.72.197]:55369 to [SERVER_IP]:80 tcpflags 0x4; > tcp_input: Listen socket: Spurious RST, segment rejected > TCP: [86.137.72.197]:55369 to [SERVER_IP]:80 tcpflags 0x4; > tcp_input: Listen socket: Spurious RST, segment rejected > TCP: [86.137.72.197]:55369 to [SERVER_IP]:80 tcpflags 0x4; > tcp_input: Listen socket: Spurious RST, segment rejected > TCP: [189.174.49.42]:4882 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:4883 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [200.101.114.236]:50786 to [SERVER_IP]:80 tcpflags 0x4; > tcp_input: Listen socket: Spurious RST, segment rejected > TCP: [189.174.49.42]:4884 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:4886 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:4885 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:4888 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [88.249.5.47]:10126 to [SERVER_IP]:80 tcpflags 0x4; tcp_input: > Listen socket: Spurious RST, segment rejected > TCP: [88.249.5.47]:10129 to [SERVER_IP]:80 tcpflags 0x4; tcp_input: > Listen socket: Spurious RST, segment rejected > TCP: [189.174.49.42]:4890 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:4889 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:4891 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:4892 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:4894 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:4895 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:4896 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:4897 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:4900 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:4898 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:4899 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:4901 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:4902 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:4903 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:4904 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:4905 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:4910 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:4911 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:4907 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:4912 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:4913 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:4914 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:4915 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:4916 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:4920 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:4921 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:4927 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:4928 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:4929 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:4932 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:4933 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [85.113.252.100]:3010 to [SERVER_IP]:80 tcpflags 0x4; > tcp_input: Listen socket: Spurious RST, segment rejected > TCP: [189.174.49.42]:4934 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:4935 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:4936 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:4937 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:4938 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:4940 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:4941 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:4939 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:4942 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:4943 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:4944 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:4946 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:4945 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [88.249.5.47]:10451 to [SERVER_IP]:80 tcpflags 0x4; tcp_input: > Listen socket: Spurious RST, segment rejected > TCP: [88.249.5.47]:10451 to [SERVER_IP]:80 tcpflags 0x4; tcp_input: > Listen socket: Spurious RST, segment rejected > TCP: [88.249.5.47]:10452 to [SERVER_IP]:80 tcpflags 0x4; tcp_input: > Listen socket: Spurious RST, segment rejected > TCP: [189.174.49.42]:4948 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:4947 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:4949 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:4954 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:4955 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:4956 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:4958 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:4957 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:4960 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:4959 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:4962 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:4961 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:4963 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:4964 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:4965 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:4968 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:4969 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:4966 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:4972 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:4970 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:4971 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:4976 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:4974 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:4975 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:4980 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:4979 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:4982 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:4983 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:4984 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:4985 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:4986 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:4987 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:4988 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:4989 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:4990 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:4991 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:4992 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:4993 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:4996 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:4997 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:4994 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:4995 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:4998 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1026 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:5000 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1030 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1031 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1033 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1032 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1034 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1037 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1039 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1041 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1040 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1042 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1043 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1045 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1046 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1051 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1050 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1052 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1047 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1054 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1057 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1056 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1059 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1058 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1060 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1061 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1063 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1062 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1064 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1065 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1067 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1066 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [80.74.160.18]:36950 to [SERVER_IP]:80 tcpflags 0x4; > tcp_input: Listen socket: Spurious RST, segment rejected > TCP: [80.74.160.18]:36950 to [SERVER_IP]:80 tcpflags 0x4; > tcp_input: Listen socket: Spurious RST, segment rejected > TCP: [80.74.160.18]:36950 to [SERVER_IP]:80 tcpflags 0x4; > tcp_input: Listen socket: Spurious RST, segment rejected > TCP: [189.174.49.42]:1069 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1068 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1070 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1072 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1073 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1074 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1077 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1076 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1081 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1080 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1083 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1082 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1079 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1078 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1085 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1084 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1086 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1089 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1088 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1091 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1093 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1092 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1096 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1094 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1097 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1099 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1098 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1100 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1101 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1102 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1103 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1104 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1105 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1107 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1106 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1108 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1109 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1110 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [83.249.50.6]:61527 to [SERVER_IP]:80 tcpflags 0x4; tcp_input: > Listen socket: Spurious RST, segment rejected > TCP: [83.249.50.6]:61527 to [SERVER_IP]:80 tcpflags 0x4; tcp_input: > Listen socket: Spurious RST, segment rejected > TCP: [83.249.50.6]:63029 to [SERVER_IP]:80 tcpflags 0x4; tcp_input: > Listen socket: Spurious RST, segment rejected > TCP: [189.174.49.42]:1113 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1112 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1114 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1115 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1116 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1117 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1118 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1120 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1119 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1121 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1122 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1123 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1124 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1125 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1127 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1126 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1129 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1130 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1131 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [83.54.146.138]:1666 to [SERVER_IP]:80 tcpflags 0x4; > tcp_input: Listen socket: Spurious RST, segment rejected > TCP: [83.54.146.138]:1666 to [SERVER_IP]:80 tcpflags 0x4; > tcp_input: Listen socket: Spurious RST, segment rejected > TCP: [83.54.146.138]:1666 to [SERVER_IP]:80 tcpflags 0x4; > tcp_input: Listen socket: Spurious RST, segment rejected > TCP: [83.54.146.138]:1666 to [SERVER_IP]:80 tcpflags 0x4; > tcp_input: Listen socket: Spurious RST, segment rejected > TCP: [83.54.146.138]:1666 to [SERVER_IP]:80 tcpflags 0x4; > tcp_input: Listen socket: Spurious RST, segment rejected > TCP: [83.54.146.138]:1666 to [SERVER_IP]:80 tcpflags 0x4; > tcp_input: Listen socket: Spurious RST, segment rejected > TCP: [189.174.49.42]:1132 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [83.54.146.138]:1666 to [SERVER_IP]:80 tcpflags 0x4; > tcp_input: Listen socket: Spurious RST, segment rejected > TCP: [189.174.49.42]:1133 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1135 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1137 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1136 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1138 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1139 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [193.77.54.179]:3091 to [SERVER_IP]:80 tcpflags 0x4; > tcp_input: Listen socket: Spurious RST, segment rejected > TCP: [193.77.54.179]:3091 to [SERVER_IP]:80 tcpflags 0x4; > tcp_input: Listen socket: Spurious RST, segment rejected > TCP: [193.77.54.179]:3091 to [SERVER_IP]:80 tcpflags 0x4; > tcp_input: Listen socket: Spurious RST, segment rejected > TCP: [193.77.54.179]:3091 to [SERVER_IP]:80 tcpflags 0x4; > tcp_input: Listen socket: Spurious RST, segment rejected > TCP: [189.174.49.42]:1141 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1140 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1143 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1145 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1146 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1149 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1148 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1151 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1150 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1153 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1155 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1154 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1157 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1156 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1158 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1160 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1161 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1162 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1163 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1164 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1165 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1166 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1167 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1169 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1168 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1170 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1171 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1172 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1173 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1174 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1176 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1175 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1177 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1178 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1179 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1180 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1182 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1184 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1183 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1187 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1186 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1188 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1192 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1189 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1191 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1190 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1193 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1194 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1197 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1196 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1198 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1199 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1201 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1202 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [81.214.207.221]:4121 to [SERVER_IP]:80 tcpflags 0x4; > tcp_input: Listen socket: Spurious RST, segment rejected > TCP: [81.214.207.221]:4121 to [SERVER_IP]:80 tcpflags 0x4; > tcp_input: Listen socket: Spurious RST, segment rejected > TCP: [81.214.207.221]:4121 to [SERVER_IP]:80 tcpflags 0x4; > tcp_input: Listen socket: Spurious RST, segment rejected > TCP: [189.174.49.42]:1203 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1205 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1204 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [193.77.54.179]:3184 to [SERVER_IP]:80 tcpflags 0x4; > tcp_input: Listen socket: Spurious RST, segment rejected > TCP: [193.77.54.179]:3184 to [SERVER_IP]:80 tcpflags 0x4; > tcp_input: Listen socket: Spurious RST, segment rejected > TCP: [193.77.54.179]:3184 to [SERVER_IP]:80 tcpflags 0x4; > tcp_input: Listen socket: Spurious RST, segment rejected > TCP: [189.174.49.42]:1206 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1208 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1210 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1211 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1212 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1213 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1214 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1215 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1217 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1216 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1218 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1219 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1221 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1220 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1223 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1225 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1224 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1226 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1227 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1228 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1229 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1231 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1232 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1233 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1234 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1235 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1239 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1241 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1240 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1243 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1242 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1245 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1244 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1246 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1247 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1248 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1251 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1252 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1253 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1254 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1256 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1255 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1257 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1258 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1259 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [193.77.54.179]:3259 to [SERVER_IP]:80 tcpflags 0x4; > tcp_input: Listen socket: Spurious RST, segment rejected > TCP: [193.77.54.179]:3259 to [SERVER_IP]:80 tcpflags 0x4; > tcp_input: Listen socket: Spurious RST, segment rejected > TCP: [193.77.54.179]:3259 to [SERVER_IP]:80 tcpflags 0x4; > tcp_input: Listen socket: Spurious RST, segment rejected > TCP: [193.77.54.179]:3259 to [SERVER_IP]:80 tcpflags 0x4; > tcp_input: Listen socket: Spurious RST, segment rejected > TCP: [193.77.54.179]:3259 to [SERVER_IP]:80 tcpflags 0x4; > tcp_input: Listen socket: Spurious RST, segment rejected > TCP: [193.77.54.179]:3259 to [SERVER_IP]:80 tcpflags 0x4; > tcp_input: Listen socket: Spurious RST, segment rejected > TCP: [193.77.54.179]:3259 to [SERVER_IP]:80 tcpflags 0x4; > tcp_input: Listen socket: Spurious RST, segment rejected > TCP: [193.77.54.179]:3259 to [SERVER_IP]:80 tcpflags 0x4; > tcp_input: Listen socket: Spurious RST, segment rejected > TCP: [193.77.54.179]:3259 to [SERVER_IP]:80 tcpflags 0x4; > tcp_input: Listen socket: Spurious RST, segment rejected > TCP: [189.174.49.42]:1261 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1260 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1263 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1262 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [86.106.13.35]:4733 to [SERVER_IP]:80 tcpflags 0x11; > syncache_expand: SEQ 655051299 != IRS+1 655050586, segment rejected > TCP: [189.174.49.42]:1265 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1264 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1266 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1267 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [193.77.54.179]:3293 to [SERVER_IP]:80 tcpflags 0x4; > tcp_input: Listen socket: Spurious RST, segment rejected > TCP: [193.77.54.179]:3293 to [SERVER_IP]:80 tcpflags 0x4; > tcp_input: Listen socket: Spurious RST, segment rejected > TCP: [193.77.54.179]:3293 to [SERVER_IP]:80 tcpflags 0x4; > tcp_input: Listen socket: Spurious RST, segment rejected > TCP: [193.77.54.179]:3293 to [SERVER_IP]:80 tcpflags 0x4; > tcp_input: Listen socket: Spurious RST, segment rejected > TCP: [193.77.54.179]:3293 to [SERVER_IP]:80 tcpflags 0x4; > tcp_input: Listen socket: Spurious RST, segment rejected > TCP: [193.77.54.179]:3293 to [SERVER_IP]:80 tcpflags 0x4; > tcp_input: Listen socket: Spurious RST, segment rejected > TCP: [193.77.54.179]:3293 to [SERVER_IP]:80 tcpflags 0x4; > tcp_input: Listen socket: Spurious RST, segment rejected > TCP: [193.77.54.179]:3293 to [SERVER_IP]:80 tcpflags 0x4; > tcp_input: Listen socket: Spurious RST, segment rejected > TCP: [193.77.54.179]:3293 to [SERVER_IP]:80 tcpflags 0x4; > tcp_input: Listen socket: Spurious RST, segment rejected > TCP: [193.77.54.179]:3293 to [SERVER_IP]:80 tcpflags 0x4; > tcp_input: Listen socket: Spurious RST, segment rejected > TCP: [193.77.54.179]:3293 to [SERVER_IP]:80 tcpflags 0x4; > tcp_input: Listen socket: Spurious RST, segment rejected > TCP: [193.77.54.179]:3293 to [SERVER_IP]:80 tcpflags 0x4; > tcp_input: Listen socket: Spurious RST, segment rejected > TCP: [193.77.54.179]:3293 to [SERVER_IP]:80 tcpflags 0x4; > tcp_input: Listen socket: Spurious RST, segment rejected > TCP: [193.77.54.179]:3293 to [SERVER_IP]:80 tcpflags 0x4; > tcp_input: Listen socket: Spurious RST, segment rejected > TCP: [193.77.54.179]:3293 to [SERVER_IP]:80 tcpflags 0x4; > tcp_input: Listen socket: Spurious RST, segment rejected > TCP: [193.77.54.179]:3293 to [SERVER_IP]:80 tcpflags 0x4; > tcp_input: Listen socket: Spurious RST, segment rejected > TCP: [189.174.49.42]:1269 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > TCP: [189.174.49.42]:1268 to [SERVER_IP]:80 tcpflags 0x14; > tcp_input: Listen socket: Our SYN|ACK was rejected, connection attempt > aborted by remote endpoint > > > > > > But these have been talked about on the lists before. > > What's new for me is the following bits of the firewall (pf) logs: > > > tcpdump: WARNING: pflog0: no IPv4 address assigned > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode > listening on pflog0, link-type PFLOG (OpenBSD pflog file), capture size > 96 bytes > 000000 rule 0/0(match): block unkn(99) on em0: SERVER_IP.52582 > > 70.87.97.148.80: [|tcp] > 29. 232416 rule 0/0(match): block unkn(99) on em0: SERVER_IP.53798 > > 70.87.97.148.80: [|tcp] > > Notice the unkn(99) and the bad hdr length errors. on 6.2, this problem > doesn't exist. Is this something new or is it related to the spurious > rsts & syncache errors ? > > > Best regards, > > Hugo It's known bug, they are trying to fix it before FreeBSD 7.0-RELEASE. -- Regards, -Abdullah Ibn Hamad Al-Marri Arab Portal http://www.WeArab.Net/ From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 16:21:53 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D33E816A402 for ; Fri, 13 Jul 2007 16:21:53 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.178]) by mx1.freebsd.org (Postfix) with ESMTP id AD45A13C4CA for ; Fri, 13 Jul 2007 16:21:53 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: by wa-out-1112.google.com with SMTP id j37so659653waf for ; Fri, 13 Jul 2007 09:21:53 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=aZwQfzDksRBn4m3FxnfY96NLTHv3pq6/Jjl5VffUc8k3z8TT4obbb4YlNtE6BP9YBGWBEMRRGnaI7GGg09WWsil1jJoUR2lYIEbCXhBBXPKCuD9KIktOQcwqFB9qnuQTVNfqvKIRKti0QLPN2eUVDlqML60oRZrPPcmA88bLnmY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=X76C0l3tKVX40fg5gLgBNVnsNRtcENNp+7svlp5/hY4HaF4WJ0rAdNd/GnhcZLMJCNhBVJqORvpDhue6bWZKa0TTUMHpx5pjUsKTMH5ETfDebUVxwKVF97rKFLURwDT+vG7dmqcbEBGYLLTDyBxUl3zlP0sKtQ30POCIgYmpK4E= Received: by 10.114.146.1 with SMTP id t1mr1797907wad.1184343713308; Fri, 13 Jul 2007 09:21:53 -0700 (PDT) Received: by 10.114.103.14 with HTTP; Fri, 13 Jul 2007 09:21:53 -0700 (PDT) Message-ID: <2a41acea0707130921x38d35d3br62842ef118c93261@mail.gmail.com> Date: Fri, 13 Jul 2007 09:21:53 -0700 From: "Jack Vogel" To: "Ian FREISLICH" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200707130848.01101.jhb@freebsd.org> Cc: freebsd-current@freebsd.org Subject: Re: em0 hijacking traffic to port 623 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2007 16:21:53 -0000 On 7/13/07, Ian FREISLICH wrote: > John Baldwin wrote: > > On Monday 21 May 2007 07:17:07 pm Jack Vogel wrote: > > > On 5/21/07, Sten Spans wrote: > > > > On Mon, 21 May 2007, Ian FREISLICH wrote: > > > > > > > > > Hi > > > > > > > > > > We've noticed an issue on our firewalls where the first em device > > > > > in the system hijacks inbound port 623 tcp and udp. The OS never > > > > > sees this traffic. Interestingly, em1 and em2 do not appear to be > > > > > afflicted by this problem. Some reading I've done points to a > > > > > similar conclusion: > > > > > > > > > > http://blogs.sun.com/shepler/entry/port_623_or_the_mount > > > > > > > > > > I've looked at the bios, but I can't find any settings that remotely > > > > > hint IPMI or RMCP+ or serial-over-lan. > > > > > > > > > > Does anyone know how I can stop the card or system from stealing > > > > > port 623 in hardware or must I just stop using em0 (and/or Intel NICS)? > > > > > > > > Does "ifconfig em0 promisc" help ? > > > > That fixed firmware related vanishing ipv6 packets on fxp and em. > > > > > > Is this happening even with the latest CURRENT driver, there is code in > > > it now that is supposed to stop the firmware from doing that, at least > > > that was the theory :) > > > > We still see this at work. We use this workaround in /etc/sysctl.conf: > > > > net.inet.ip.portrange.lowlast=665 > > > > It seems that the em0 interface always snoops 623 looking for RCMP > > packets for IPMI (or ASF). > > =================================================================== > RCS file: /home/ncvs/src/sys/dev/em/e1000_82540.c,v > retrieving revision 1.3 > diff -u -d -r1.3 e1000_82540.c > --- e1000_82540.c 16 May 2007 00:14:23 -0000 1.3 > +++ e1000_82540.c 25 May 2007 13:40:19 -0000 > @@ -316,6 +316,7 @@ > /* Disable HW ARPs on ASF enabled adapters */ > manc = E1000_READ_REG(hw, E1000_MANC); > manc &= ~E1000_MANC_ARP_EN; > + manc &= ~(E1000_MANC_RMCP_EN | E1000_MANC_0298_EN); > E1000_WRITE_REG(hw, E1000_MANC, manc); > > E1000_WRITE_REG(hw, E1000_IMC, 0xffffffff); > > Fixes it for me. But, of course, I'm not interested in ASF on my > gateway hosts. > > I didn't look further into the initalization of the chip. The > datasheet I downloaded suggests that you can filter these packets > on IP address as well and I suspect the option is turned on with > some default in the EEPROM register that equates to 0.0.0.0/0. Hardcoding this change into shared code is not the right place to do it, however I'll take a look at that and figure out a more appropriate approach. Jack From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 16:27:45 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EC3C716A406; Fri, 13 Jul 2007 16:27:45 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (nagual.pp.ru [194.87.13.69]) by mx1.freebsd.org (Postfix) with ESMTP id 4704113C4C2; Fri, 13 Jul 2007 16:27:45 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.14.1/8.14.1) with ESMTP id l6DGRhg0016540; Fri, 13 Jul 2007 20:27:43 +0400 (MSD) (envelope-from ache@nagual.pp.ru) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nagual.pp.ru; s=default; t=1184344063; bh=OR0cSVkSmfSKcCSMdifUDuYelylZJDOBZzoHoBx JgkM=; l=1458; h=Received:Date:From:To:Subject:Message-ID: Mail-Followup-To:References:MIME-Version:Content-Type: Content-Disposition:In-Reply-To:User-Agent; b=EKrxemhQu6rhAn02iNsh nMc8vNJzHy71di1ArltjXpxsJwLApJr9U88Er9lKsj6HXcKo6hEKvvD2Voih7WsaIol ZlduhH0VBpSLjp3YS4AxfiNLnvMt19Cj2YNj/znbOfpl4ggnaOlBV6XjCP92sCUleJu +2le7L8ts8wbM+6fI= Received: (from ache@localhost) by nagual.pp.ru (8.14.1/8.14.1/Submit) id l6DGRhtr016539; Fri, 13 Jul 2007 20:27:43 +0400 (MSD) (envelope-from ache) Date: Fri, 13 Jul 2007 20:27:42 +0400 From: Andrey Chernov To: "Sean C. Farley" , Robert Watson , freebsd-current , Michal Mertl Message-ID: <20070713162742.GA16260@nagual.pp.ru> Mail-Followup-To: Andrey Chernov , "Sean C. Farley" , Robert Watson , freebsd-current , Michal Mertl References: <20070704215154.O77978@thor.farley.org> <20070705115816.GA50506@nagual.pp.ru> <20070705105922.F98700@thor.farley.org> <20070707130859.GA96605@nagual.pp.ru> <20070707131359.GB96605@nagual.pp.ru> <20070707133102.C14065@thor.farley.org> <20070707191835.GA4368@nagual.pp.ru> <20070707205410.B14065@thor.farley.org> <20070708020940.GA80166@nagual.pp.ru> <20070708171727.GA90490@nagual.pp.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070708171727.GA90490@nagual.pp.ru> User-Agent: Mutt/1.5.16 (2007-06-09) Cc: Subject: Re: Environment handling broken in /bin/sh with changes to {get,set,put}env() X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2007 16:27:46 -0000 On Sun, Jul 08, 2007 at 09:17:27PM +0400, Andrey Chernov wrote: > Hmm. I just think a bit more and feel worry about that place in the merge > code: > > *equals = '\0'; > if (setenv(*env, equals + 1, 1) == -1) > return (-1); > *equals = '='; > because it modifies memory which may be treated like const one. > > Consider following scenario: getenv() is not thread-safe, but may be [snip] I found another breakage case not covered by your last getenv() fix. Take this simple program: -- a.c ------------------------------------------------------------------- #include extern char **environ; main () { static char *nenv[2]; nenv[0] = "PATH=/bin"; nenv[1] = NULL; /* environ = nenv; unsetenv("PATH"); or somethig like which touch '=' char in nenv[0] */ nenv[0][4] = '\0'; } -- a.c ------------------------------------------------------------------- Look at assembler code first: cc -S a.c cat a.s .file "a.c" .local nenv.1948 .comm nenv.1948,8,4 .section .rodata .LC0: .string "PATH=/bin" .text [skipped] As you may see, compiler puts "PATH=/bin" to the program's .rodata section which is placed to read only memory. If later you'll modify this single "PATH=/bin" (comes from "nenv" now) by *equals = '\0'; ... *equals = '='; core dump happens, which simulated in my simple a.c example by nenv[0][4] = '\0'; Just run it and got code dump. -- http://ache.pp.ru/ From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 16:39:06 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AC63F16A400 for ; Fri, 13 Jul 2007 16:39:06 +0000 (UTC) (envelope-from h.schmalzbauer@omnisec.de) Received: from host.omnisec.de (host.omnisec.de [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id 2DFD113C4B3 for ; Fri, 13 Jul 2007 16:39:05 +0000 (UTC) (envelope-from h.schmalzbauer@omnisec.de) Received: from tek.flintsbach.schmalzbauer.de (tek.flintsbach.schmalzbauer.de [172.21.2.3]) by host.omnisec.de (8.13.8/8.13.8) with ESMTP id l6DGYRAa027170 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 13 Jul 2007 18:34:32 +0200 (CEST) (envelope-from h.schmalzbauer@omnisec.de) Received: from titan.flintsbach.schmalzbauer.de (titan.flintsbach.schmalzbauer.de [IPv6:fec0::1:0:0:1:1]) by tek.flintsbach.schmalzbauer.de (8.13.8/8.13.8) with ESMTP id l6DGcxtP051601 for ; Fri, 13 Jul 2007 18:38:59 +0200 (CEST) (envelope-from h.schmalzbauer@omnisec.de) Received: by titan.flintsbach.schmalzbauer.de (8.14.1/8.14.1/Submit) id l6DGYRUY001525 for freebsd-current@freebsd.org; Fri, 13 Jul 2007 18:34:27 +0200 (CEST) (envelope-from h.schmalzbauer@omnisec.de) From: Harald Schmalzbauer Organization: OmniSEC To: freebsd-current@freebsd.org Date: Fri, 13 Jul 2007 18:34:26 +0200 User-Agent: KMail/1.9.6 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200707131834.27131.h.schmalzbauer@omnisec.de> Subject: kqemu crash (page fault) with -current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2007 16:39:06 -0000 Hello, today I tried qemu for the first time and I love it. Now I'd need some speed and tried kqemu, but it immediately reboots my machine. Here is what I could transcribe: Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 faulkt virtual address = 0x82 fault code = supervisor read, page not present instruction pointer = 0x20:0xc0670545 stack pointer = 0x28:0xe71e5a3c frame pointer = 0x28:0xe71e5a50 code segment = bas 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 1461 (qemu) [thread pid 1461 tid 100088] Stopped at _vm_map_lock+0x10: cmpb $0,0x81(%ebx) db> bt Tracing pid 1461 tid 100088 td 0xc4995800 _vm_map_lock(1,c070cbb4,7ac,c07344c4,c0714b73,...) at _vm_map_lock+0x10 vm_map_wire(1,285f6000,285f7000,1,116,...) at vm_map_wire+0x33 kqemu_lock_user_page(e71e5af4,285f6000,f01d2000,285f6000,0,...) at kqemu_lock_user_page+0x38 mon_user_map() at mon_user_map+0xe7 Any help appreciated. Thanks in advance, -Harry From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 16:46:06 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EEAAF16A400 for ; Fri, 13 Jul 2007 16:46:06 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from ns.trinitel.com (186.161.36.72.static.reverse.layeredtech.com [72.36.161.186]) by mx1.freebsd.org (Postfix) with ESMTP id C363613C4C4 for ; Fri, 13 Jul 2007 16:46:06 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from proton.local (209-163-168-124.static.twtelecom.net [209.163.168.124]) (authenticated bits=0) by ns.trinitel.com (8.14.1/8.14.1) with ESMTP id l6DGk5Eq030017; Fri, 13 Jul 2007 11:46:05 -0500 (CDT) (envelope-from anderson@freebsd.org) Message-ID: <4697AC4C.7080901@freebsd.org> Date: Fri, 13 Jul 2007 11:46:04 -0500 From: Eric Anderson User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) MIME-Version: 1.0 To: Harald Schmalzbauer References: <200707131834.27131.h.schmalzbauer@omnisec.de> In-Reply-To: <200707131834.27131.h.schmalzbauer@omnisec.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on ns.trinitel.com Cc: freebsd-current@freebsd.org Subject: Re: kqemu crash (page fault) with -current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2007 16:46:07 -0000 Harald Schmalzbauer wrote: > Hello, > > today I tried qemu for the first time and I love it. > Now I'd need some speed and tried kqemu, but it immediately reboots my > machine. > Here is what I could transcribe: > > Fatal trap 12: page fault while in kernel mode > cpuid = 1; apic id = 01 > faulkt virtual address = 0x82 > fault code = supervisor read, page not present > instruction pointer = 0x20:0xc0670545 > stack pointer = 0x28:0xe71e5a3c > frame pointer = 0x28:0xe71e5a50 > code segment = bas 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 1461 (qemu) > [thread pid 1461 tid 100088] > Stopped at _vm_map_lock+0x10: cmpb $0,0x81(%ebx) > db> bt > Tracing pid 1461 tid 100088 td 0xc4995800 > _vm_map_lock(1,c070cbb4,7ac,c07344c4,c0714b73,...) at _vm_map_lock+0x10 > vm_map_wire(1,285f6000,285f7000,1,116,...) at vm_map_wire+0x33 > kqemu_lock_user_page(e71e5af4,285f6000,f01d2000,285f6000,0,...) at > kqemu_lock_user_page+0x38 > mon_user_map() at mon_user_map+0xe7 > > Any help appreciated. See the other thread in emulation@. Basically, you need to recompile kqemu-kmod with -DKSE. Eric From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 16:52:17 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 63E6216A41A for ; Fri, 13 Jul 2007 16:52:17 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.freebsd.org (Postfix) with ESMTP id EB39413C481 for ; Fri, 13 Jul 2007 16:52:16 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.8/8.13.8) with ESMTP id l6DGqDG5005050; Fri, 13 Jul 2007 12:52:14 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: "Li-Lun \"Leland\" Wang" Date: Fri, 13 Jul 2007 11:49:30 -0400 User-Agent: KMail/1.9.6 References: <20070520174124.GA14987@Athena.infor.org> <200707130836.58062.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200707131149.30956.jhb@freebsd.org> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Fri, 13 Jul 2007 12:52:14 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.3/3658/Fri Jul 13 11:27:31 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: pyunyh@gmail.com, freebsd-current@freebsd.org Subject: Re: msk watchdog timeout X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2007 16:52:17 -0000 On Friday 13 July 2007 10:29:55 am Li-Lun "Leland" Wang wrote: > On 7/13/07, John Baldwin wrote: > > On Monday 21 May 2007 12:45:39 am Li-Lun "Leland" Wang wrote: > > > On 5/20/07, Pyun YongHyeon wrote: > > > > On Sun, May 20, 2007 at 09:39:54PM -0500, Li-Lun Leland Wang wrote: > > > > > On 5/20/07, Pyun YongHyeon wrote: > > > > > >On Mon, May 21, 2007 at 01:41:24AM +0800, Li-Lun Wang (Leland Wang) > > wrote: > > > > > > > I just installed 7.0-current as of May 3 on my new computer that > > comes > > > > > > > with an on-board Marvell Yukon Gigabit Ethernet. Every now and > > then > > > > > > > if the network throughput comes near several hundred kbytes, I get > > the > > > > > > > msk0 watchdog timeout messages: > > > > > > > > > > > > > > kernel: msk0: watchdog timeout > > > > > > > msk0: watchdog timeout (missed Tx interrupts) -- recovering > > > > > > > > > > > > > > Although it says recovering, the interface never comes back alive. > > > > > > > > > > > >The above message indicates the driver sent all pending transmission > > > > > >requests but the driver didn't receive corresponding Tx completion > > > > > >interrupts. Not recovering from the watchdog timeout means there are > > > > > >another issues on the driver. However as disabling MSI fixed the > > > > > >issue, I guess it's not fault of msk(4) and it comes from bad/broken > > > > > >MSI implementation of your system. I guess it's time to add your > > > > > >chipset to a PCI quirk table in order to blacklist it. > > > > > > > > > > I do reckon that MSI doesn't work on earlier Intel chipsets. Mine is > > > > > P965 (on a gigabyte GA-965P-DS3 rev 1.3), which I suppose is recent > > > > > enough to support MSI, isn't it? Or could there be other problems > > > > > > > > Using latest chipsets does not necessarily guarantee working MSI. > > > > > > I see. I think we should maybe add P965 to the PCI quirk list for > > > broken MSI, then? > > > > Possibly. > > > > > > > possible? > > > > > > > > > > > > > Yes. But I couldn't find possible issue on msk(4) yet. > > > > > > Maybe I was not clear enough. Could there be something else that > > > causes MSI to not working correctly other than the chipset? I was > > > just wondering why I didn't see too many broken MSI reports if most > > > Intel chipsets are broken. > > > > If it's not the driver it would be the chipset. We already don't use MSI on > > systems that don't support either PCI-X or PCI-express, so that implicitly > > blacklists most older Intel chipsets. Do you have any other devices in your > > system that support MSI? pciconf -lc output would be useful to look at. > > Here is the output of pciconf -lc: > > pcm0@pci0:27:0: class=0x040300 card=0xa0021458 chip=0x284b8086 rev=0x02 hdr=0x00 > cap 01[50] = powerspec 2 supports D0 D3 current D0 > cap 05[60] = MSI supports 1 message, 64 bit > cap 10[70] = PCI-Express 1 type 0 Perhaps try the experimental pcm MSI support to see if it works. If it does then you know MSI works ok. Oh, and if MSI were broken, you wouldn't get any interrupts on the adapter at all, if you are only getting timeouts under load but the adapter works fine with lower amounts of traffic, then it is probably an issue in the msk(4) driver and not the MSI support in the chipset. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 17:02:36 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A85C816A402 for ; Fri, 13 Jul 2007 17:02:36 +0000 (UTC) (envelope-from kensmith@cse.Buffalo.EDU) Received: from opus.cse.buffalo.edu (opus.cse.Buffalo.EDU [128.205.32.4]) by mx1.freebsd.org (Postfix) with ESMTP id 6E64813C4BA for ; Fri, 13 Jul 2007 17:02:36 +0000 (UTC) (envelope-from kensmith@cse.Buffalo.EDU) Received: from [127.0.0.1] (localhost.cse.buffalo.edu [127.0.0.1]) by opus.cse.buffalo.edu (8.13.8/8.12.4) with ESMTP id l6DGOKjY096137; Fri, 13 Jul 2007 12:24:20 -0400 (EDT) From: Ken Smith To: Michiel Boland In-Reply-To: References: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-6UTze/FLILkZlILRwD1k" Organization: U. Buffalo CSE Department Date: Fri, 13 Jul 2007 12:24:20 -0400 Message-Id: <1184343860.95218.64.camel@opus.cse.buffalo.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.10.2 FreeBSD GNOME Team Port Cc: freebsd-current@freebsd.org Subject: Re: upgrade 6-STABLE to -CURRENT on sparc64 renders box unusable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2007 17:02:36 -0000 --=-6UTze/FLILkZlILRwD1k Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2007-07-10 at 22:41 +0200, Michiel Boland wrote: > Well, in fact I did manage to debug this further. :) >=20 > The problem is that on sparc64 and -CURRENT, every executable segfaults i= n >=20 > _rtld > init_rtld > relocate_objects > reloc_non_plt > mmap > __getosreldate >=20 > It appears that __getosreldate was added five days ago, which may explain= =20 > why the breakage on sparc64 hasn't been reported yet. (I am ccing peter@=20 > since he committed this.) >=20 > If I apply the following patch, then rebuild libc, things are more or les= s=20 > ok again. Of course this patch is very suboptimal, I am just trying to=20 > point out where the problem is.=20 Thanks for your work on this, it helped quite a bit. The problem is also affecting the PowerPC architecture. A fix that Alexander Kabaev worked out for sparc64 just got committed as V1.15 of libexec/rtld-elf/sparc64/reloc.c; we're still looking at PowerPC. --=20 Ken Smith - From there to here, from here to | kensmith@cse.buffalo.edu there, funny things are everywhere. | - Theodore Geisel | --=-6UTze/FLILkZlILRwD1k Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQBGl6c0/G14VSmup/YRAhyCAKCDNHTDCgc6OaIXciv42L89i2e0igCfQ5EG hA/4v2LEx6Zca6HdqTLI3s0= =tOb1 -----END PGP SIGNATURE----- --=-6UTze/FLILkZlILRwD1k-- From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 17:48:24 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 06B5316A404 for ; Fri, 13 Jul 2007 17:48:24 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by mx1.freebsd.org (Postfix) with ESMTP id 7BADC13C481 for ; Fri, 13 Jul 2007 17:48:21 +0000 (UTC) (envelope-from max@love2party.net) Received: from [88.66.26.241] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu7) with ESMTP (Nemesis), id 0ML2xA-1I9PFb3V3Y-0003f6; Fri, 13 Jul 2007 19:48:20 +0200 From: Max Laier Organization: FreeBSD To: freebsd-current@freebsd.org Date: Fri, 13 Jul 2007 19:50:02 +0200 User-Agent: KMail/1.9.7 References: <4697A3BB.90607@barafranca.com> <499c70c0707130917q41979bc9y5ab69d6fb6454cc0@mail.gmail.com> In-Reply-To: <499c70c0707130917q41979bc9y5ab69d6fb6454cc0@mail.gmail.com> X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGdu+2]; R]*pL,U>^H?)gW@49@wdJ`H<=?utf-8?q?=25=7D*=5FBD=0A=09U=5For=3D=5CmOZf764=26nYj=3DJYbR1PW0ud?=>|!~,,CPC.1-D$FG@0h3#'5"k{V]a~.<=?utf-8?q?mZ=7D44=23Se=7Em=0A=09Fe=7E=5C=5DX5B=5D=5Fxj?=(ykz9QKMw_l0C2AQ]}Ym8)fU MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3737676.pFfa2h7ix8"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200707131950.12304.max@love2party.net> X-Provags-ID: V01U2FsdGVkX18WWWKL4KfyFbYGQdwkVQ4DqzjRdOOBGZedhC6 jCNbtQJP4AlOf72IrFw+zaDXGadJxrtZVFIg54knzG5gtCbu1J BpL7olumMTFVTvpW4QAwhtL1WlGdO82zVr1avNvjFM= Cc: Hugo Silva , Abdullah Ibn Hamad Al-Marri Subject: Re: Spurious RSTs, syncache, and pf weirdness X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2007 17:48:24 -0000 --nextPart3737676.pFfa2h7ix8 Content-Type: multipart/mixed; boundary="Boundary-01=_Ot7lGQXxVc5kRWZ" Content-Transfer-Encoding: 7bit Content-Disposition: inline --Boundary-01=_Ot7lGQXxVc5kRWZ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Friday 13 July 2007, Abdullah Ibn Hamad Al-Marri wrote: > On 7/13/07, Hugo Silva wrote: > > But these have been talked about on the lists before. > > > > What's new for me is the following bits of the firewall (pf) logs: > > > > tcpdump: WARNING: pflog0: no IPv4 address assigned > > tcpdump: verbose output suppressed, use -v or -vv for full protocol > > decode listening on pflog0, link-type PFLOG (OpenBSD pflog file), > > capture size 96 bytes > > 000000 rule 0/0(match): block unkn(99) on em0: SERVER_IP.52582 > > > 70.87.97.148.80: [|tcp] > > 29. 232416 rule 0/0(match): block unkn(99) on em0: SERVER_IP.53798 > > > 70.87.97.148.80: [|tcp] > > > > > Notice the unkn(99) and the bad hdr length errors. on 6.2, this > > problem doesn't exist. Is this something new or is it related to the > > spurious rsts & syncache errors ? > > > > > > Best regards, > > > > Hugo > > It's known bug, they are trying to fix it before FreeBSD 7.0-RELEASE. No it's not. It's a known feature. The attached patch fixes it. This=20 needs to go through tcpdump.org, but I haven't had time to take care of=20 it, yet. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --Boundary-01=_Ot7lGQXxVc5kRWZ Content-Type: text/x-diff; charset="utf-8"; name="pf.41.tcpdump_local.diff" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="pf.41.tcpdump_local.diff" Index: contrib/libpcap/gencode.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/store/mlaier/fcvs/src/contrib/libpcap/gencode.c,v retrieving revision 1.16 diff -u -r1.16 gencode.c =2D-- contrib/libpcap/gencode.c 4 Sep 2006 19:54:21 -0000 1.16 +++ contrib/libpcap/gencode.c 30 Jun 2007 17:01:13 -0000 @@ -75,7 +75,14 @@ #include "ppp.h" #include "sll.h" #include "arcnet.h" +#ifdef HAVE_NET_PFVAR_H +#include +#include +#include +#include +#else #include "pf.h" +#endif #ifndef offsetof #define offsetof(s, e) ((size_t)&((s *)0)->e) #endif Index: contrib/libpcap/grammar.y =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/store/mlaier/fcvs/src/contrib/libpcap/grammar.y,v retrieving revision 1.11 diff -u -r1.11 grammar.y =2D-- contrib/libpcap/grammar.y 4 Sep 2006 19:54:21 -0000 1.11 +++ contrib/libpcap/grammar.y 30 Jun 2007 17:02:55 -0000 @@ -53,7 +53,13 @@ #include "pcap-int.h" =20 #include "gencode.h" +#ifdef HAVE_NET_PFVAR_H +#include +#include +#include +#else #include "pf.h" +#endif #include =20 #ifdef HAVE_OS_PROTO_H Index: contrib/tcpdump/print-pflog.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/store/mlaier/fcvs/src/contrib/tcpdump/print-pflog.c,v retrieving revision 1.1.1.3 diff -u -r1.1.1.3 print-pflog.c =2D-- contrib/tcpdump/print-pflog.c 4 Sep 2006 20:04:14 -0000 1.1.1.3 +++ contrib/tcpdump/print-pflog.c 30 Jun 2007 17:03:26 -0000 @@ -28,6 +28,16 @@ #include "config.h" #endif =20 +#ifdef HAVE_NET_PFVAR_H +#include +#include +#include +#include +#include +#else +#include "pf.h" +#endif + #include =20 #include @@ -35,7 +45,6 @@ =20 #include "interface.h" #include "addrtoname.h" =2D#include "pf.h" =20 static struct tok pf_reasons[] =3D { { 0, "0(match)" }, Index: lib/libpcap/config.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/store/mlaier/fcvs/src/lib/libpcap/config.h,v retrieving revision 1.5 diff -u -r1.5 config.h =2D-- lib/libpcap/config.h 29 May 2005 18:12:46 -0000 1.5 +++ lib/libpcap/config.h 30 Jun 2007 17:05:20 -0000 @@ -45,6 +45,9 @@ /* Define to 1 if you have the header file. */ #define HAVE_MEMORY_H 1 =20 +/* Define to 1 if you have the header file. */ +#define HAVE_NET_PFVAR_H 1 + /* Define to 1 if you have the header file. */ /* #undef HAVE_NETINET_ETHER_H */ =20 Index: usr.sbin/tcpdump/tcpdump/config.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/store/mlaier/fcvs/src/usr.sbin/tcpdump/tcpdump/config.h,v retrieving revision 1.7 diff -u -r1.7 config.h =2D-- usr.sbin/tcpdump/tcpdump/config.h 11 Jul 2005 04:14:42 -0000 1.7 +++ usr.sbin/tcpdump/tcpdump/config.h 30 Jun 2007 17:06:34 -0000 @@ -193,6 +193,9 @@ /* Define to 1 if you have the header file. */ /* #undef HAVE_NETDNET_DNETDB_H */ =20 +/* Define to 1 if you have the header file. */ +#define HAVE_NET_PFVAR_H 1 + /* Define to 1 if you have the header file. */ /* #undef HAVE_NETINET_ETHER_H */ =20 --Boundary-01=_Ot7lGQXxVc5kRWZ-- --nextPart3737676.pFfa2h7ix8 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQBGl7tUXyyEoT62BG0RAmSnAJ9SHK5KUZsxgBYT2iF5vT6iJ2bfcACfZ+W+ zq1C6q7+Mgy5TFBwq8PjDqM= =abpn -----END PGP SIGNATURE----- --nextPart3737676.pFfa2h7ix8-- From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 18:12:18 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C56B216A402 for ; Fri, 13 Jul 2007 18:12:18 +0000 (UTC) (envelope-from r.c.ladan@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.173]) by mx1.freebsd.org (Postfix) with ESMTP id 4CA3713C467 for ; Fri, 13 Jul 2007 18:12:18 +0000 (UTC) (envelope-from r.c.ladan@gmail.com) Received: by ug-out-1314.google.com with SMTP id o4so693789uge for ; Fri, 13 Jul 2007 11:12:17 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:subject:x-enigmail-version:content-type; b=d/u3UHbvDEFQPOWTM64bpY2q8FXdae2TNi5djwRT7y2uYuAnOvd5AZu2PU/r/bVhmc2mipMae6PMkB3MdyFBkKpnl9uG5VGl0MqyGV6YJENI5fFIUEN3H4XmtW1uNs8eFUMjDPCVxNVSRF+maokbgjrFFPk0XDvhzIBhHQ9Lq1s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:subject:x-enigmail-version:content-type; b=V0crcc2xrwWT1bHSLGlc7fP5Al2VSIV3GcnU5UFja3Wspegfy7yJq3N8yivZAk0xVEqAdwIEQK8S8JzvHgLzxvwn/eEEJW0IuZiZjzdtVhn4uEYrljhTtX7lZKB+yLOfctXWF8kQ3xlrqAQYHHB5YND/VaRLOP+u5zWYSZ9mN6A= Received: by 10.67.121.15 with SMTP id y15mr2157378ugm.1184348810523; Fri, 13 Jul 2007 10:46:50 -0700 (PDT) Received: from 195-241-221-201.dsl.ip.tiscali.nl ( [195.241.221.201]) by mx.google.com with ESMTP id d24sm13072902nfh.2007.07.13.10.46.49 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 13 Jul 2007 10:46:49 -0700 (PDT) Message-ID: <4697BA83.8040704@gmail.com> Date: Fri, 13 Jul 2007 19:46:43 +0200 From: Rene Ladan User-Agent: Thunderbird 2.0.0.4 (X11/20070616) MIME-Version: 1.0 To: current@freebsd.org, Pav Lucistnik X-Enigmail-Version: 0.95.1 Content-Type: multipart/mixed; boundary="------------090709070607070102030406" Cc: Subject: net/boinc-client pograms only run half the time with SCHED_ULE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2007 18:12:18 -0000 This is a multi-part message in MIME format. --------------090709070607070102030406 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi, I noticed that when using SCHED_ULE on my 2007-07-11 i386 CURRENT box (SMP), the projects run with net/boinc-client only run for half the time. On my T5600 (2-core) top shows something like: load avarages : about 2 (as expected) einstein@home : about 50% on core i seti@home : about 50% on core 1-i The values in the TIME column also indicate that the projects run only half the time. My complete kernel configration is attached. I've switched back to SCHED_4BSD for now, as that scheduler works ok. Regards, Rene -- GPG fingerprint = E738 5471 D185 7013 0EE0 4FC8 3C1D 6F83 12E1 84F6 (subkeys.pgp.net) "It won't fit on the line." -- me, 2001 --------------090709070607070102030406 Content-Type: text/plain; name="RENE.current" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="RENE.current" # # GENERIC -- Generic kernel configuration file for FreeBSD/i386 # # For more information on this file, please read the handbook section on # Kernel Configuration Files: # # http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-config.html # # The handbook is also available locally in /usr/share/doc/handbook # if you've installed the doc distribution, otherwise always see the # FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the # latest information. # # An exhaustive list of options and more detailed explanations of the # device lines is also present in the ../../conf/NOTES and NOTES files. # If you are in doubt as to the purpose or necessity of a line, check first # in NOTES. # machine i386 cpu I686_CPU ident RENE # To statically compile in device wiring instead of /boot/device.hints #hints "GENERIC.hints" # Default places to look for devices. makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols # Debugging for use in -current options KDB # Enable kernel debugger support. options DDB # Support DDB. options KDB_TRACE options GDB # Support remote GDB. options INVARIANTS # Enable calls of extra sanity checking options INVARIANT_SUPPORT # Extra sanity checks of internal structures, required by INVARIANTS options WITNESS # Enable checks to detect deadlocks and cycles options WITNESS_SKIPSPIN # Don't run witness on spinlocks for speed #options SCHED_ULE # ULE scheduler only runs BOINC 1/2 time ? --> current! options SCHED_4BSD # works with BOINC as expected options PREEMPTION # Enable kernel thread preemption options INET # InterNETworking options INET6 # IPv6 communications protocols options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists options UFS_DIRHASH # Improve performance on big directories options MD_ROOT # MD is a potential root device options CD9660 # ISO 9660 Filesystem options COMPAT_43TTY # Compatible with BSD 4.3 [KEEP THIS!] options COMPAT_FREEBSD5 # Compatible with FreeBSD5 options COMPAT_FREEBSD6 # Compatible with FreeBSD6 options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI options KTRACE # ktrace(1) support options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options KBD_INSTALL_CDEV # install a CDEV entry in /dev options AHC_REG_PRETTY_PRINT # Print register bitfields in debug # output. Adds ~128k to driver. options AHD_REG_PRETTY_PRINT # Print register bitfields in debug # output. Adds ~215k to driver. options ADAPTIVE_GIANT # Giant mutex is adaptive. options SMP # Dual core T5600 device apic # I/O APIC options STOP_NMI # stop CPUs with NMI instead of IPI # Bus support. device eisa device pci # ATA and ATAPI devices device ata # as module ? device atadisk # ATA disk drives # as module ? options ATA_STATIC_ID # Static device numbering # SCSI peripherals device scbus # SCSI bus (required for SCSI) device da # Direct Access (disks) device cd # CD device pass # Passthrough device (direct SCSI access) # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc # AT keyboard controller device atkbd # AT keyboard device psm # PS/2 mouse device vga # VGA video card driver device splash # Splash screen and screen saver support # syscons is the default console driver, resembling an SCO console device sc device agp # support several AGP chipsets, required for drm # drm/radeon not supported yet for RV515 (Radeon Mobility X1450) :( device drm device radeondrm # Add suspend/resume support for the i8254. device pmtimer # Pseudo devices. device loop # Network loopback device ether # Ethernet support device pty # Pseudo-ttys (telnet etc) # The `bpf' device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! # Note that 'bpf' is required for DHCP. device bpf # Berkeley packet filter # USB support device uhci # UHCI PCI->USB interface device ohci # OHCI PCI->USB interface device ehci # EHCI PCI->USB interface (USB 2.0) device usb # USB Bus (required) #added options VESA options DEVICE_POLLING device wlan device wlan_wep device wlan_amrr device wlan_scan_sta device wlan_scan_ap --------------090709070607070102030406-- From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 18:21:23 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 00A6116A404 for ; Fri, 13 Jul 2007 18:21:23 +0000 (UTC) (envelope-from lydianconcepts@gmail.com) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.239]) by mx1.freebsd.org (Postfix) with ESMTP id B42F313C4B5 for ; Fri, 13 Jul 2007 18:21:22 +0000 (UTC) (envelope-from lydianconcepts@gmail.com) Received: by nz-out-0506.google.com with SMTP id l8so469735nzf for ; Fri, 13 Jul 2007 11:21:22 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Z4s5Ux+jtSVPs+ZFSq0bodmTwtV4axFrwE0OlSYcwo+oblUfPwbFG87MSy9+cQt22rSuzISaqLQQMhbrWxbYay0VI3aIcNfIYvCu4chTV+pMQ+EKLXKBeo3uBkBFQnsLGuF9Jwci3r/930f65Nw7KLyQQp4kv6sWQqMfoWONASg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=sMHJbkX5srzgzKiFDzvVsWmNLQTKN+Zflf3dYoABojyhWEzlR9sRBBSs2qtlbBqndhJcr1dWw8CkfBj4lVzjQq+PbGyVw9lrPfI/bbaVkfd3YDtbcD1WfEVgX699ZzdISX40AVPgnrWOkHqVX9Z1KJhAGeJ2hS33gy4JOpeJs8w= Received: by 10.114.153.18 with SMTP id a18mr1874747wae.1184350881781; Fri, 13 Jul 2007 11:21:21 -0700 (PDT) Received: by 10.114.125.14 with HTTP; Fri, 13 Jul 2007 11:21:21 -0700 (PDT) Message-ID: <7579f7fb0707131121s2725d0a7o34dc81cd2c6cf9f@mail.gmail.com> Date: Fri, 13 Jul 2007 11:21:21 -0700 From: "Matthew Jacob" To: "Max Laier" In-Reply-To: <200707131544.46012.max@love2party.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200707131544.46012.max@love2party.net> Cc: freebsd-current@freebsd.org Subject: Re: Can't build RELENG_6 from HEAD? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2007 18:21:23 -0000 gcc 4.X will barf all over RELENG_6 code. Better start thinking about a jailed build. On 7/13/07, Max Laier wrote: > Hi, > > is it me or can't RELENG_6 be built from HEAD anymore? > > -- > /"\ Best regards, | mlaier@freebsd.org > \ / Max Laier | ICQ #67774661 > X http://pf4freebsd.love2party.net/ | mlaier@EFnet > / \ ASCII Ribbon Campaign | Against HTML Mail and News > > Script started on Fri Jul 13 15:42:06 2007 > 15:42 [/usr/src/gnu/usr.bin/binutils/as]amd64> make > cc -O2 -fno-strict-aliasing -pipe -march=opteron -DBFD_DEFAULT_TARGET_SIZE=64 -I. -I/usr/src/gnu/usr.bin/binutils/as -I/usr/src/gnu/usr.bin/binutils/as/../libbfd -I/usr/obj/usr/src/gnu/usr.bin/binutils/as/../libbfd -I/usr/src/gnu/usr.bin/binutils/as/../../../../contrib/binutils/include -DDEFAULT_ARCH=\"x86_64\" -DTARGET_CPU=\"x86_64\" -DTARGET_CANONICAL=\"x86_64-obrien-freebsd\" -DTARGET_ALIAS=\"x86_64-obrien-freebsd\" -DVERSION=\""2.15 [FreeBSD] 2004-05-23"\" -D_GNU_SOURCE -I/usr/src/gnu/usr.bin/binutils/as/../../../../contrib/binutils/gas -I/usr/src/gnu/usr.bin/binutils/as/../../../../contrib/binutils/gas/config -I/usr/src/gnu/usr.bin/binutils/as/../../../../contrib/binutils -I/usr/src/gnu/usr.bin/binutils/as -I/usr/src/gnu/usr.bin/binutils/as/amd64-freebsd -Wsystem-headers -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/gnu/usr.bin/binutils/as/../../../../contrib/binutils/gas/app.c > In file included from /usr/src/gnu/usr.bin/binutils/as/amd64-freebsd/targ-cpu.h:3, > from /usr/src/gnu/usr.bin/binutils/as/../../../../contrib/binutils/gas/config/obj-elf.h:42, > from /usr/src/gnu/usr.bin/binutils/as/obj-format.h:3, > from /usr/src/gnu/usr.bin/binutils/as/../../../../contrib/binutils/gas/config/te-freebsd.h:30, > from /usr/src/gnu/usr.bin/binutils/as/targ-env.h:3, > from /usr/src/gnu/usr.bin/binutils/as/../../../../contrib/binutils/gas/as.h:626, > from /usr/src/gnu/usr.bin/binutils/as/../../../../contrib/binutils/gas/app.c:30: > /usr/src/gnu/usr.bin/binutils/as/../../../../contrib/binutils/gas/config/tc-i386.h:451: error: array type has incomplete element type > *** Error code 1 > > Stop in /usr/src/gnu/usr.bin/binutils/as. > > Script done on Fri Jul 13 15:42:11 2007 > > > From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 18:43:00 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BF53216A404 for ; Fri, 13 Jul 2007 18:43:00 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outM.internet-mail-service.net (outM.internet-mail-service.net [216.240.47.236]) by mx1.freebsd.org (Postfix) with ESMTP id A2C9D13C4AA for ; Fri, 13 Jul 2007 18:43:00 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Fri, 13 Jul 2007 11:43:00 -0700 Received: from julian-mac.elischer.org (nat.ironport.com [63.251.108.100]) by idiom.com (Postfix) with ESMTP id E273F125AEB; Fri, 13 Jul 2007 11:42:59 -0700 (PDT) Message-ID: <4697C7C4.3070500@elischer.org> Date: Fri, 13 Jul 2007 11:43:16 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) MIME-Version: 1.0 To: Kostik Belousov References: <46970DF7.3000803@elischer.org> <46972B28.1010409@FreeBSD.org> <20070713082705.GI2200@deviant.kiev.zoral.com.ua> In-Reply-To: <20070713082705.GI2200@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Attilio Rao , FreeBSD Current Subject: Re: crash in tty code in 6.1.. fixed since? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2007 18:43:00 -0000 >>> tp_session is NULL but it shouldn't have been able to have run that line >>> (line 1659) if it had tested NULL 2 lines before.. >>> this suggests a locking problem.. >> I think it has been fixed some months ago IIRC. >> The problem here, should be that if sx_slock() let thread sleep, Giant >> is released before to sleep and tp->t_session can be accessed in racy way. >> Another nice side-effect about having tty Giant :) > > Yes, it seems that rev. 1.267 fixed it and was MFCed as rev. 1.228.2.6. > There was a lot of commits around this one, it may be safer to update to > RELENG_6. That's not an option on a product. 6.1 has passed all sorts of QA benchmarks etc. and while we will upgrade, it will probably happen next year. From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 18:52:57 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 85E9116A400 for ; Fri, 13 Jul 2007 18:52:57 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outU.internet-mail-service.net (outU.internet-mail-service.net [216.240.47.244]) by mx1.freebsd.org (Postfix) with ESMTP id 723BD13C481 for ; Fri, 13 Jul 2007 18:52:57 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Fri, 13 Jul 2007 11:52:56 -0700 Received: from julian-mac.elischer.org (nat.ironport.com [63.251.108.100]) by idiom.com (Postfix) with ESMTP id 7650D125A27; Fri, 13 Jul 2007 11:52:56 -0700 (PDT) Message-ID: <4697CA1A.9060700@elischer.org> Date: Fri, 13 Jul 2007 11:53:14 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) MIME-Version: 1.0 To: John Baldwin References: <4659DAD1.9040609@elischer.org> <20070527.235832.-267226920.imp@bsdimp.com> <200707130907.37295.jhb@freebsd.org> In-Reply-To: <200707130907.37295.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, current@freebsd.org, "M. Warner Losh" Subject: Re: fun fun fun. no networking X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2007 18:52:57 -0000 John Baldwin wrote: > You can try this perhaps: thanks, but it came to life again a few days later.. (I guess something else changed..) > > --- //depot/vendor/freebsd/src/sys/dev/acpica/acpi.c 2007/05/08 14:37:51 > +++ //depot/user/jhb/acpipci/dev/acpica/acpi.c 2007/05/08 22:28:25 > @@ -1030,17 +1030,18 @@ > } > > /* > - * If this is an allocation of a specific range, see if we can satisfy > - * the request from our system resource regions. If we can't, pass the > - * request up to the parent. > + * Try to pass the request up to our parent first. If that > + * doesn't work, then see if we can satisfy the request via a > + * suballocation from our system resource regions. > */ > - if (start + count - 1 == end && rm != NULL) > + res = BUS_ALLOC_RESOURCE(device_get_parent(bus), child, type, rid, > + start, end, count, flags); > + if (res == NULL && rm != NULL) { > res = rman_reserve_resource(rm, start, end, count, flags & ~RF_ACTIVE, > child); > - if (res == NULL) { > - res = BUS_ALLOC_RESOURCE(device_get_parent(bus), child, type, rid, > - start, end, count, flags); > - } else { > + if (res == NULL) > + goto out; > + > rman_set_rid(res, *rid); > > /* If requested, activate the resource using the parent's method. */ > From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 18:52:57 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8C1CA16A401 for ; Fri, 13 Jul 2007 18:52:57 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outT.internet-mail-service.net (outT.internet-mail-service.net [216.240.47.243]) by mx1.freebsd.org (Postfix) with ESMTP id 77CB213C48E for ; Fri, 13 Jul 2007 18:52:57 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Fri, 13 Jul 2007 11:52:56 -0700 Received: from julian-mac.elischer.org (nat.ironport.com [63.251.108.100]) by idiom.com (Postfix) with ESMTP id 7650D125A27; Fri, 13 Jul 2007 11:52:56 -0700 (PDT) Message-ID: <4697CA1A.9060700@elischer.org> Date: Fri, 13 Jul 2007 11:53:14 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) MIME-Version: 1.0 To: John Baldwin References: <4659DAD1.9040609@elischer.org> <20070527.235832.-267226920.imp@bsdimp.com> <200707130907.37295.jhb@freebsd.org> In-Reply-To: <200707130907.37295.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, current@freebsd.org, "M. Warner Losh" Subject: Re: fun fun fun. no networking X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2007 18:52:57 -0000 John Baldwin wrote: > You can try this perhaps: thanks, but it came to life again a few days later.. (I guess something else changed..) > > --- //depot/vendor/freebsd/src/sys/dev/acpica/acpi.c 2007/05/08 14:37:51 > +++ //depot/user/jhb/acpipci/dev/acpica/acpi.c 2007/05/08 22:28:25 > @@ -1030,17 +1030,18 @@ > } > > /* > - * If this is an allocation of a specific range, see if we can satisfy > - * the request from our system resource regions. If we can't, pass the > - * request up to the parent. > + * Try to pass the request up to our parent first. If that > + * doesn't work, then see if we can satisfy the request via a > + * suballocation from our system resource regions. > */ > - if (start + count - 1 == end && rm != NULL) > + res = BUS_ALLOC_RESOURCE(device_get_parent(bus), child, type, rid, > + start, end, count, flags); > + if (res == NULL && rm != NULL) { > res = rman_reserve_resource(rm, start, end, count, flags & ~RF_ACTIVE, > child); > - if (res == NULL) { > - res = BUS_ALLOC_RESOURCE(device_get_parent(bus), child, type, rid, > - start, end, count, flags); > - } else { > + if (res == NULL) > + goto out; > + > rman_set_rid(res, *rid); > > /* If requested, activate the resource using the parent's method. */ > From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 19:06:02 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 073F416A400 for ; Fri, 13 Jul 2007 19:06:02 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.186]) by mx1.freebsd.org (Postfix) with ESMTP id 8EF5013C4A8 for ; Fri, 13 Jul 2007 19:06:01 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by fk-out-0910.google.com with SMTP id b27so30171fka for ; Fri, 13 Jul 2007 12:06:00 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:reply-to:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding:sender; b=iC8XzKEz4cK+C3BnlI656SgdC0qRBQFRKuEfaiu1W8oVsBnMkyS3sFVMzZkKei5uIYXM7/rQN2gq2CsPYZLVwSWIobgUIzsKtHYbGUHiQi1vwH9gJ54Lvt3naEi5OjtcdiPY0MXd+VcpNVPUl+Tq6jCNinJpYxKGsgnWbsbWQ8g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:reply-to:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding:sender; b=HBZg/p9BW+KN2RWFC0/GW6S4XQzKCnPNiNPlAwP558rd1KWjm/KdgcxDszzmA6VcPx89hx8PUqTx+8qpW9HMrwsntXnSbOF3yb7TQE/ELvs2tYL6eQAIbTSJ8or5MIgwgl9t5+CBfyICDMCDBi+oQRdDUIFMvZXzatGhGoR9rvc= Received: by 10.82.100.1 with SMTP id x1mr2399813bub.1184353559821; Fri, 13 Jul 2007 12:05:59 -0700 (PDT) Received: from ?151.75.219.248? ( [151.75.219.248]) by mx.google.com with ESMTP id 31sm13348885nfu.2007.07.13.12.05.59 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 13 Jul 2007 12:05:59 -0700 (PDT) Message-ID: <4697CCEB.9080707@FreeBSD.org> Date: Fri, 13 Jul 2007 21:05:15 +0200 From: Attilio Rao User-Agent: Thunderbird 1.5 (X11/20060526) MIME-Version: 1.0 To: Harald Schmalzbauer References: <200707131834.27131.h.schmalzbauer@omnisec.de> In-Reply-To: <200707131834.27131.h.schmalzbauer@omnisec.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: Attilio Rao Cc: freebsd-current@freebsd.org Subject: Re: kqemu crash (page fault) with -current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: attilio@FreeBSD.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2007 19:06:02 -0000 Harald Schmalzbauer wrote: > Hello, > > today I tried qemu for the first time and I love it. > Now I'd need some speed and tried kqemu, but it immediately reboots my > machine. > Here is what I could transcribe: Could you please try this patch and see if it helps?: http://people.freebsd.org/~attilio/kqemu.diff Thanks, Attilio From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 19:18:33 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E269A16A408; Fri, 13 Jul 2007 19:18:33 +0000 (UTC) (envelope-from volker@vwsoft.com) Received: from frontmail.ipactive.de (frontmail.maindns.de [85.214.95.103]) by mx1.freebsd.org (Postfix) with ESMTP id 0168113C4B2; Fri, 13 Jul 2007 19:18:27 +0000 (UTC) (envelope-from volker@vwsoft.com) Received: from mail.vtec.ipme.de (Q7cca.q.ppp-pool.de [89.53.124.202]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by frontmail.ipactive.de (Postfix) with ESMTP id D4B7B12883F; Fri, 13 Jul 2007 21:18:21 +0200 (CEST) Received: from cesar.sz.vwsoft.com (unknown [192.168.18.3]) by mail.vtec.ipme.de (Postfix) with ESMTP id 162D83F43D; Fri, 13 Jul 2007 21:17:50 +0200 (CEST) Message-ID: <4697CFF2.5020001@vwsoft.com> Date: Fri, 13 Jul 2007 21:18:10 +0200 From: Volker User-Agent: Thunderbird 2.0.0.4 (X11/20070615) MIME-Version: 1.0 To: John Baldwin References: <200707130831.44748.jhb@freebsd.org> In-Reply-To: <200707130831.44748.jhb@freebsd.org> X-Enigmail-Version: 0.95.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-VWSoft-MailScanner: Found to be clean X-MailScanner-From: volker@vwsoft.com X-ipactive-MailScanner-Information: Please contact the ISP for more information X-ipactive-MailScanner: Found to be clean X-ipactive-MailScanner-From: volker@vwsoft.com Cc: freebsd-current@freebsd.org, Ivan Voras Subject: Re: Re: Quick hardware survey - disk INT13 "EDD" services? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2007 19:18:34 -0000 On 12/23/-58 20:59, John Baldwin wrote: > On Saturday 19 May 2007 11:39:53 am Ivan Voras wrote: >> Hi! >> >> Does anyone have a machine that doesn't support EDD / packet interface / >> "Extended INT13" interface on its hard drive(s) and is capable of >> running 7-CURRENT? (486 and early Pentium class machines?) > > Specifically, you'd have to have a BIOS with a copyright date older than 1995. > I don't know anything about EDD or 'packet interface' but I do have a Epox MVP-3C or MVP-3G board (socket 7, BIOS dated 1999) and a CPU K6-2 anything laying around. I think the board will fit your needs (quite a bit unsure). I'm somewhat limited on IDE devices (just a 4 or 8g is laying around, scsi is not a problem). Unfortunately rebuilding world + kernel on a machine like that takes ~18 hours but I'm able to set this up. What do you want to test? Do you need remote (ssh/openvpn) access to it? Interested in that machine? Volker From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 19:35:49 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AD2B516A402 for ; Fri, 13 Jul 2007 19:35:49 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) Received: from mail.ambrisko.com (mail.ambrisko.com [64.174.51.43]) by mx1.freebsd.org (Postfix) with ESMTP id 84F6113C428 for ; Fri, 13 Jul 2007 19:35:49 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) Received: from server2.ambrisko.com (HELO www.ambrisko.com) ([192.168.1.2]) by ironport2.ambrisko.com with ESMTP; 13 Jul 2007 12:02:25 -0700 Received: from ambrisko.com (localhost [127.0.0.1]) by www.ambrisko.com (8.13.1/8.12.11) with ESMTP id l6DJ7Fbj090310; Fri, 13 Jul 2007 12:07:15 -0700 (PDT) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.13.1/8.13.1/Submit) id l6DJ7Fu1090309; Fri, 13 Jul 2007 12:07:15 -0700 (PDT) (envelope-from ambrisko) From: Doug Ambrisko Message-Id: <200707131907.l6DJ7Fu1090309@ambrisko.com> In-Reply-To: <7579f7fb0707131121s2725d0a7o34dc81cd2c6cf9f@mail.gmail.com> To: Matthew Jacob Date: Fri, 13 Jul 2007 12:07:15 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL94b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Cc: Max Laier , freebsd-current@freebsd.org Subject: Re: Can't build RELENG_6 from HEAD? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2007 19:35:49 -0000 Matthew Jacob writes: | gcc 4.X will barf all over RELENG_6 code. Better start thinking about | a jailed build. And if you do script something like: #!/bin/sh UNAME_s="FreeBSD" UNAME_m="i386" UNAME_p="i386" ROOT=$HOME/stable_$UNAME_p REVISION=`cd ${ROOT}/sys/conf && grep REVISION= newvers.sh | cut -f2 -d'"'` BRANCH=`cd ${ROOT}/sys/conf && grep BRANCH= newvers.sh | head -n1 | cut -f2 -d'"'` UNAME_r=$REVISION-$BRANCH UNAME_v="$UNAME_s $UNAME_r #0: Thu May 4 07:54:55 PDT 2006 root@a21p:/data/home/ambrisko/current/usr/src/sys/$UNAME_p/compile/THINK" OSVERSION=`awk '/\#define.*__FreeBSD_version/ { print $3 }' < ${ROOT}/sys/sys/param.h` export UNAME_s UNAME_r UNAME_v UNAME_m UNAME_p OSVERSION ROOT if [ -r $ROOT/dev/zero ] then echo dev already mounted else sudo mount -t devfs dev $ROOT/dev fi sudo ln -sf ld-elf.so.1 $ROOT/libexec/ld-elf32.so.1 sudo sh -c '( echo "libpthread.so.2 libthr.so.2" ;\ echo "libpthread.so libthr.so") > ${ROOT}/etc/libmap.conf' sudo cp ${ROOT}/etc/libmap.conf ${ROOT}/etc/libmap32.conf sudo chroot $ROOT You can then build i386 on amd64 or i386 on i386. Ports will build and pkg_add works :-) Inside uname -a will report 6.X for i386. I think it would be nice to put some of this into the src/Makefile so you can do "make chroot" and it would set this up and throw you into a chroot/jail/vimage. At work we extended it to 4.X. This way we can build everything on a FreeBSD amd64 machine for 6.X i386, 6.X amd64 or 4.X i386 code. The 4.X is important to link with 3rd party code. It simplifies our build machines and I can build our stuff on a amd64 -current box. Doug A. From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 19:39:48 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 271D416A403 for ; Fri, 13 Jul 2007 19:39:48 +0000 (UTC) (envelope-from scf@FreeBSD.org) Received: from mail.farley.org (farley.org [67.64.95.201]) by mx1.freebsd.org (Postfix) with ESMTP id DCDB413C481 for ; Fri, 13 Jul 2007 19:39:47 +0000 (UTC) (envelope-from scf@FreeBSD.org) Received: from thor.farley.org (thor.farley.org [192.168.1.5]) by mail.farley.org (8.14.1/8.14.1) with ESMTP id l6DJfcd9053388; Fri, 13 Jul 2007 14:41:38 -0500 (CDT) (envelope-from scf@FreeBSD.org) Date: Fri, 13 Jul 2007 14:39:30 -0500 (CDT) From: "Sean C. Farley" To: Andrey Chernov In-Reply-To: <20070713162742.GA16260@nagual.pp.ru> Message-ID: <20070713142545.K26096@thor.farley.org> References: <20070704215154.O77978@thor.farley.org> <20070705115816.GA50506@nagual.pp.ru> <20070705105922.F98700@thor.farley.org> <20070707130859.GA96605@nagual.pp.ru> <20070707131359.GB96605@nagual.pp.ru> <20070707133102.C14065@thor.farley.org> <20070707191835.GA4368@nagual.pp.ru> <20070707205410.B14065@thor.farley.org> <20070708020940.GA80166@nagual.pp.ru> <20070708171727.GA90490@nagual.pp.ru> <20070713162742.GA16260@nagual.pp.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.1 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on mail.farley.org Cc: freebsd-current Subject: Re: Environment handling broken in /bin/sh with changes to {get,set,put}env() X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2007 19:39:48 -0000 On Fri, 13 Jul 2007, Andrey Chernov wrote: > On Sun, Jul 08, 2007 at 09:17:27PM +0400, Andrey Chernov wrote: *snip* > [snip] > > I found another breakage case not covered by your last getenv() fix. > Take this simple program: > > -- a.c --------------------------------------------------------------- > #include > extern char **environ; > > main () { > > static char *nenv[2]; > > nenv[0] = "PATH=/bin"; > nenv[1] = NULL; > > /* > environ = nenv; > unsetenv("PATH"); or somethig like > which touch '=' char in nenv[0] > */ > > nenv[0][4] = '\0'; > > } > -- a.c --------------------------------------------------------------- *snip* > As you may see, compiler puts "PATH=/bin" to the program's .rodata > section which is placed to read only memory. > > If later you'll modify this single "PATH=/bin" (comes from "nenv" now) > by > *equals = '\0'; > ... > *equals = '='; > core dump happens, which simulated in my simple a.c example by > nenv[0][4] = '\0'; > > Just run it and got code dump. FreeBSD 6 will also dump if the length of the value was less than or equal to "/bin" since it reuses this string. This will core dump: nenv[0] = "PATH=/bin"; nenv[1] = NULL; environ = nenv; setenv("PATH", "/bin", 1); Sean -- scf@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 20:00:23 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 73FC516A404 for ; Fri, 13 Jul 2007 20:00:23 +0000 (UTC) (envelope-from h.schmalzbauer@omnisec.de) Received: from host.omnisec.de (host.omnisec.de [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id E776713C4B2 for ; Fri, 13 Jul 2007 20:00:22 +0000 (UTC) (envelope-from h.schmalzbauer@omnisec.de) Received: from tek.flintsbach.schmalzbauer.de (tek.flintsbach.schmalzbauer.de [172.21.2.3]) by host.omnisec.de (8.13.8/8.13.8) with ESMTP id l6DJtihv029230 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Jul 2007 21:55:49 +0200 (CEST) (envelope-from h.schmalzbauer@omnisec.de) Received: from titan.flintsbach.schmalzbauer.de (titan.flintsbach.schmalzbauer.de [IPv6:fec0::1:0:0:1:1]) by tek.flintsbach.schmalzbauer.de (8.13.8/8.13.8) with ESMTP id l6DK0GFI053027; Fri, 13 Jul 2007 22:00:16 +0200 (CEST) (envelope-from h.schmalzbauer@omnisec.de) Received: by titan.flintsbach.schmalzbauer.de (8.14.1/8.14.1/Submit) id l6DJthsq001279; Fri, 13 Jul 2007 21:55:43 +0200 (CEST) (envelope-from h.schmalzbauer@omnisec.de) From: Harald Schmalzbauer Organization: OmniSEC To: attilio@freebsd.org Date: Fri, 13 Jul 2007 21:55:43 +0200 User-Agent: KMail/1.9.6 References: <200707131834.27131.h.schmalzbauer@omnisec.de> <4697CCEB.9080707@FreeBSD.org> In-Reply-To: <4697CCEB.9080707@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200707132155.43783.h.schmalzbauer@omnisec.de> Cc: freebsd-current@freebsd.org Subject: Re: kqemu crash (page fault) with -current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2007 20:00:23 -0000 Am Freitag, 13. Juli 2007 schrieb Attilio Rao: > Harald Schmalzbauer wrote: > > Hello, > > > > today I tried qemu for the first time and I love it. > > Now I'd need some speed and tried kqemu, but it immediately reboots my > > machine. > > Here is what I could transcribe: > > Could you please try this patch and see if it helps?: > http://people.freebsd.org/~attilio/kqemu.diff I applied it, rebuilt my kernel and kqemu, but machine crashes immedately=20 after running qemu (without disabled kqemu). Should I also rebuild qemu itself? I don't think it's needed. But CFLAGS+=3D -DKSE helped! I could install various OS, only when I enable -kernel-kqemu most installer= =20 quit with page fault. Thanks, =2DHarry > Thanks, > Attilio =2D-=20 OmniSEC - UNIX und Windows Netzwerke - Sicher Harald Schmalzbauer =46lintsbacher Str. 3 80686 M=FCnchen +49 (0) 89 18947781 +49 (0) 160 93860101 USt-IdNr.: DE253184753 From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 20:15:41 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 154AB16A401; Fri, 13 Jul 2007 20:15:41 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.freebsd.org (Postfix) with ESMTP id 94F4713C481; Fri, 13 Jul 2007 20:15:40 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.8/8.13.8) with ESMTP id l6DKFb4P006368; Fri, 13 Jul 2007 16:15:38 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-current@freebsd.org Date: Fri, 13 Jul 2007 15:28:50 -0400 User-Agent: KMail/1.9.6 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200707131528.51396.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Fri, 13 Jul 2007 16:15:38 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.3/3663/Fri Jul 13 15:16:34 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: scottl@freebsd.org, Matt Reimer Subject: Re: arcmsr crash X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2007 20:15:41 -0000 On Tuesday 05 June 2007 05:22:38 pm Matt Reimer wrote: > Once a week or so we're seeing a panic with a -current kernel built > just before the gcc 4.2 import (maybe three weeks ago). The box has a > Supermicro X7DBE/X7DBE+ motherboard with two Xeon 5160s, 16G RAM, and > an Areca 1220 controller with eight 500G disks connected. > > Does this indicate that the arcmsr driver is at fault: > > Tracing command irq16: arcmsr0 pid 26 tid 100018 td 0xffffff040fc5b000 > cpustop_handler() at cpustop_handler+0x35 > ipi_nmi_handler() at ipi_nmi_handler+0x2e > trap() at trap+0x365 > nmi_calltrap() at nmi_calltrap+0x8 > --- trap 0x13, rip = 0xffffffff8041ab11, rsp = 0xffffffffab59eff0, rbp > = 0xffffffffac0a37d0 --- > siocnclose() at siocnclose+0x21 > sio_cnputc() at sio_cnputc+0x89 > cnputc() at cnputc+0x6a > putchar() at putchar+0x5f > kvprintf() at kvprintf+0xd45 > printf() at printf+0xe1 > panic() at panic+0x145 > xpt_done() at xpt_done+0x14a > arcmsr_interrupt() at arcmsr_interrupt+0x2df > ithread_loop() at ithread_loop+0x108 > fork_exit() at fork_exit+0xaa > fork_trampoline() at fork_trampoline+0xe > --- trap 0, rip = 0, rsp = 0xffffffffac0a3d30, rbp = 0 --- Looks like it has panic'd here: switch (done_ccb->ccb_h.path->periph->type) { case CAM_PERIPH_BIO: mtx_lock(&cam_bioq_lock); TAILQ_INSERT_TAIL(&cam_bioq, &done_ccb->ccb_h, sim_links.tqe); done_ccb->ccb_h.pinfo.index = CAM_DONEQ_INDEX; mtx_unlock(&cam_bioq_lock); swi_sched(cambio_ih, 0); break; default: panic("unknown periph type %d", done_ccb->ccb_h.path->periph->type); } which should seem to indicate that, yes, it is a driver bug. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 20:15:42 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 75F5D16A401; Fri, 13 Jul 2007 20:15:42 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.freebsd.org (Postfix) with ESMTP id EC12213C48E; Fri, 13 Jul 2007 20:15:41 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.8/8.13.8) with ESMTP id l6DKFb4Q006368; Fri, 13 Jul 2007 16:15:40 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-current@freebsd.org Date: Fri, 13 Jul 2007 15:46:15 -0400 User-Agent: KMail/1.9.6 References: <20070614161632.GA3385@kobe.laptop> <20070617163227.GA1318@kobe.laptop> <20070622124154.GA2780@kobe.laptop> In-Reply-To: <20070622124154.GA2780@kobe.laptop> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200707131546.16361.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Fri, 13 Jul 2007 16:15:40 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.3/3663/Fri Jul 13 15:16:34 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Attilio Rao , Giorgos Keramidas , current@freebsd.org Subject: Re: hard-lock with CPU spinning X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2007 20:15:42 -0000 On Friday 22 June 2007 08:41:54 am Giorgos Keramidas wrote: > On 2007-06-17 19:32, Giorgos Keramidas wrote: > >On 2007-06-14 20:02, Giorgos Keramidas wrote: > >>On 2007-06-14 18:36, Attilio Rao wrote: > >>>2007/6/14, Giorgos Keramidas : > >>>> If I leave my laptop idle for a long period of time, it tends to lock up > >>>> with the CPU fan spinning fast (presumambly because some part of the > >>>> kernel tries to acquire a lock and spins constantly for it). > >>>> > >>>> Unfortunately, this happens when X11 is running and I can't break into > >>>> DDB to snoop around. > > > > Hi Attilio, > > > > thanks for the eagerness to help, but I was too quick in assuming this > > was a hard-lock. The kernel hasn't deadlocked, but the laptop is almost > > unresponsive because the X server eats up an enormous amount of CPU. > > > > I left an xterm window running: > > > > > cd /home/keramida > > > ( while true ; do \ > > uptime ; ps xaur | head -20 ; \ > > sleep 5 ; echo ; \ > > done ) 2>&1 | tee logfile > > > > and when hte CPU fan started spinning fast, I managed to shutdown > > normally by pressing the laptop's power-off button and waiting long > > enough for the X process to die. > > > > The ~/logfile file contains near its end entries like: > > > > % 6:43PM up 2:05, 1 user, load averages: 0.76, 0.39, 0.24 > > % USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND > > % root 1234 97.8 4.2 285648 21428 v1 R 4:41PM 3:22.41 X :0 -dpi 96 (Xorg) > > % root 12 97.1 0.0 0 8 ?? RL 4:37PM 112:19.80 [idle: cpu0] > > % root 11 2.2 0.0 0 8 ?? RL 4:37PM 110:16.80 [idle: cpu1] > > Finally, more progress :) > > This seems to kick in only when I use: > > % xset +dpms > % xset s on > % xset b 100 800 20 > > By disabling DPMS with '-dpms' there is no CPU-eating behavior > even after leaving my laptop on for hours. > > So this seems to be a bug in the +dpms part of X11 :-) I'll have to try that. My laptop has a similar issue except it seems to be cpufreq related (if I disable powerd I don't see the behavior). I don't use xset, but I probably have dpms enabled in KDE. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 20:15:42 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 75F5D16A401; Fri, 13 Jul 2007 20:15:42 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.freebsd.org (Postfix) with ESMTP id EC12213C48E; Fri, 13 Jul 2007 20:15:41 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.8/8.13.8) with ESMTP id l6DKFb4Q006368; Fri, 13 Jul 2007 16:15:40 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-current@freebsd.org Date: Fri, 13 Jul 2007 15:46:15 -0400 User-Agent: KMail/1.9.6 References: <20070614161632.GA3385@kobe.laptop> <20070617163227.GA1318@kobe.laptop> <20070622124154.GA2780@kobe.laptop> In-Reply-To: <20070622124154.GA2780@kobe.laptop> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200707131546.16361.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Fri, 13 Jul 2007 16:15:40 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.3/3663/Fri Jul 13 15:16:34 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Attilio Rao , Giorgos Keramidas , current@freebsd.org Subject: Re: hard-lock with CPU spinning X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2007 20:15:42 -0000 On Friday 22 June 2007 08:41:54 am Giorgos Keramidas wrote: > On 2007-06-17 19:32, Giorgos Keramidas wrote: > >On 2007-06-14 20:02, Giorgos Keramidas wrote: > >>On 2007-06-14 18:36, Attilio Rao wrote: > >>>2007/6/14, Giorgos Keramidas : > >>>> If I leave my laptop idle for a long period of time, it tends to lock up > >>>> with the CPU fan spinning fast (presumambly because some part of the > >>>> kernel tries to acquire a lock and spins constantly for it). > >>>> > >>>> Unfortunately, this happens when X11 is running and I can't break into > >>>> DDB to snoop around. > > > > Hi Attilio, > > > > thanks for the eagerness to help, but I was too quick in assuming this > > was a hard-lock. The kernel hasn't deadlocked, but the laptop is almost > > unresponsive because the X server eats up an enormous amount of CPU. > > > > I left an xterm window running: > > > > > cd /home/keramida > > > ( while true ; do \ > > uptime ; ps xaur | head -20 ; \ > > sleep 5 ; echo ; \ > > done ) 2>&1 | tee logfile > > > > and when hte CPU fan started spinning fast, I managed to shutdown > > normally by pressing the laptop's power-off button and waiting long > > enough for the X process to die. > > > > The ~/logfile file contains near its end entries like: > > > > % 6:43PM up 2:05, 1 user, load averages: 0.76, 0.39, 0.24 > > % USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND > > % root 1234 97.8 4.2 285648 21428 v1 R 4:41PM 3:22.41 X :0 -dpi 96 (Xorg) > > % root 12 97.1 0.0 0 8 ?? RL 4:37PM 112:19.80 [idle: cpu0] > > % root 11 2.2 0.0 0 8 ?? RL 4:37PM 110:16.80 [idle: cpu1] > > Finally, more progress :) > > This seems to kick in only when I use: > > % xset +dpms > % xset s on > % xset b 100 800 20 > > By disabling DPMS with '-dpms' there is no CPU-eating behavior > even after leaving my laptop on for hours. > > So this seems to be a bug in the +dpms part of X11 :-) I'll have to try that. My laptop has a similar issue except it seems to be cpufreq related (if I disable powerd I don't see the behavior). I don't use xset, but I probably have dpms enabled in KDE. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 20:19:30 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id ABB6316A403; Fri, 13 Jul 2007 20:19:30 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 47FCF13C4A5; Fri, 13 Jul 2007 20:19:30 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from scott-longs-computer.local (phobos.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.8/8.13.8) with ESMTP id l6DKJQH4016907; Fri, 13 Jul 2007 14:19:27 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <4697DE41.7090100@samsco.org> Date: Fri, 13 Jul 2007 14:19:13 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.4) Gecko/20070509 SeaMonkey/1.1.2 MIME-Version: 1.0 To: John Baldwin References: <200707131528.51396.jhb@freebsd.org> In-Reply-To: <200707131528.51396.jhb@freebsd.org> X-Enigmail-Version: 0.95.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (pooker.samsco.org [168.103.85.57]); Fri, 13 Jul 2007 14:19:27 -0600 (MDT) X-Spam-Status: No, score=-1.4 required=5.5 tests=ALL_TRUSTED autolearn=failed version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: freebsd-current@freebsd.org, Matt Reimer Subject: Re: arcmsr crash X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2007 20:19:30 -0000 John Baldwin wrote: > On Tuesday 05 June 2007 05:22:38 pm Matt Reimer wrote: >> Once a week or so we're seeing a panic with a -current kernel built >> just before the gcc 4.2 import (maybe three weeks ago). The box has a >> Supermicro X7DBE/X7DBE+ motherboard with two Xeon 5160s, 16G RAM, and >> an Areca 1220 controller with eight 500G disks connected. >> >> Does this indicate that the arcmsr driver is at fault: >> >> Tracing command irq16: arcmsr0 pid 26 tid 100018 td 0xffffff040fc5b000 >> cpustop_handler() at cpustop_handler+0x35 >> ipi_nmi_handler() at ipi_nmi_handler+0x2e >> trap() at trap+0x365 >> nmi_calltrap() at nmi_calltrap+0x8 >> --- trap 0x13, rip = 0xffffffff8041ab11, rsp = 0xffffffffab59eff0, rbp >> = 0xffffffffac0a37d0 --- >> siocnclose() at siocnclose+0x21 >> sio_cnputc() at sio_cnputc+0x89 >> cnputc() at cnputc+0x6a >> putchar() at putchar+0x5f >> kvprintf() at kvprintf+0xd45 >> printf() at printf+0xe1 >> panic() at panic+0x145 >> xpt_done() at xpt_done+0x14a >> arcmsr_interrupt() at arcmsr_interrupt+0x2df >> ithread_loop() at ithread_loop+0x108 >> fork_exit() at fork_exit+0xaa >> fork_trampoline() at fork_trampoline+0xe >> --- trap 0, rip = 0, rsp = 0xffffffffac0a3d30, rbp = 0 --- > > Looks like it has panic'd here: > > switch (done_ccb->ccb_h.path->periph->type) { > case CAM_PERIPH_BIO: > mtx_lock(&cam_bioq_lock); > TAILQ_INSERT_TAIL(&cam_bioq, &done_ccb->ccb_h, > sim_links.tqe); > done_ccb->ccb_h.pinfo.index = CAM_DONEQ_INDEX; > mtx_unlock(&cam_bioq_lock); > swi_sched(cambio_ih, 0); > break; > default: > panic("unknown periph type %d", > done_ccb->ccb_h.path->periph->type); > } > > which should seem to indicate that, yes, it is a driver bug. > The doneq has gotten corrupted somehow. The only real way that this could happen is if xpt_done() was called twice on the same ccb. Whether this is a hardware bug (hardware completing the same command twice) or a driver bug is unknown. I'll try to add some seatbelts to CAM to detect this kind of condition. But yes, it's ultimately something in the arcmsr subsystem that is at fault. Scott From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 20:24:36 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3594C16A404; Fri, 13 Jul 2007 20:24:36 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (nagual.pp.ru [194.87.13.69]) by mx1.freebsd.org (Postfix) with ESMTP id 585A113C4DA; Fri, 13 Jul 2007 20:24:35 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.14.1/8.14.1) with ESMTP id l6DKOXXC020108; Sat, 14 Jul 2007 00:24:33 +0400 (MSD) (envelope-from ache@nagual.pp.ru) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nagual.pp.ru; s=default; t=1184358274; bh=qqqn3KUQ+hwVHN251k1mH0eddIdgijVEjEKtLM5 A2Fo=; l=997; h=Received:Date:From:To:Cc:Subject:Message-ID: Mail-Followup-To:References:MIME-Version:Content-Type: Content-Disposition:In-Reply-To:User-Agent; b=P4e766jyjWL9Ln9VAgHM a8tRuuLq7/2kZ+dhje/aQtqXLydtvpTdnvByoctAU006AWg0ch2k2GshjRbCCwL8e1r 3+I3OMepkvwaJucIxXosgXS+HD2R8zuFZt/AQwtuss+B4il0o4uVEMvM5IEU4H1kLaM H1YNO7qTs81SFgtgs= Received: (from ache@localhost) by nagual.pp.ru (8.14.1/8.14.1/Submit) id l6DKOXKB020107; Sat, 14 Jul 2007 00:24:33 +0400 (MSD) (envelope-from ache) Date: Sat, 14 Jul 2007 00:24:33 +0400 From: Andrey Chernov To: "Sean C. Farley" Message-ID: <20070713202433.GA19856@nagual.pp.ru> Mail-Followup-To: Andrey Chernov , "Sean C. Farley" , freebsd-current References: <20070705105922.F98700@thor.farley.org> <20070707130859.GA96605@nagual.pp.ru> <20070707131359.GB96605@nagual.pp.ru> <20070707133102.C14065@thor.farley.org> <20070707191835.GA4368@nagual.pp.ru> <20070707205410.B14065@thor.farley.org> <20070708020940.GA80166@nagual.pp.ru> <20070708171727.GA90490@nagual.pp.ru> <20070713162742.GA16260@nagual.pp.ru> <20070713142545.K26096@thor.farley.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070713142545.K26096@thor.farley.org> User-Agent: Mutt/1.5.16 (2007-06-09) Cc: freebsd-current Subject: Re: Environment handling broken in /bin/sh with changes to {get,set,put}env() X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2007 20:24:36 -0000 On Fri, Jul 13, 2007 at 02:39:30PM -0500, Sean C. Farley wrote: > FreeBSD 6 will also dump if the length of the value was less than or > equal to "/bin" since it reuses this string. This will core dump: > > nenv[0] = "PATH=/bin"; > nenv[1] = NULL; > environ = nenv; > setenv("PATH", "/bin", 1); 1) I care in first hand about unsetenv() as my example states. There nowhere said in the specs that unsetenv() may modify environ _content_, manpage says about pointers only. 2) That example not fail under FreeBSD 6 but fail under new code: nenv[0] = "PATH=/bin"; nenv[1] = NULL; environ = nenv; setenv("HOME", "/xxx", 1); (that is because new code will touch "PATH=/bin" string in anycase while old ones looks for "HOME" only). The most safest way is do not touch environ content outside of scope of requested modification. That means I agree that nenv[0] = "PATH=/bin"; setenv("PATH", "/bin", 1); may fail, but not about the cases 1) and 2) -- http://ache.pp.ru/ From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 20:33:28 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 247B516A404 for ; Fri, 13 Jul 2007 20:33:28 +0000 (UTC) (envelope-from erikt@midgard.homeip.net) Received: from ch-smtp02.sth.basefarm.net (ch-smtp02.sth.basefarm.net [80.76.149.213]) by mx1.freebsd.org (Postfix) with ESMTP id 941D213C474 for ; Fri, 13 Jul 2007 20:33:27 +0000 (UTC) (envelope-from erikt@midgard.homeip.net) Received: from c83-253-10-135.bredband.comhem.se ([83.253.10.135]:58216 helo=falcon.midgard.homeip.net) by ch-smtp02.sth.basefarm.net with smtp (Exim 4.66) (envelope-from ) id 1I9RpO-0001ED-86 for freebsd-current@freebsd.org; Fri, 13 Jul 2007 22:33:26 +0200 Received: (qmail 27321 invoked from network); 13 Jul 2007 22:33:23 +0200 Received: from owl.midgard.homeip.net (10.1.5.7) by falcon.midgard.homeip.net with SMTP; 13 Jul 2007 22:33:23 +0200 Received: (qmail 48349 invoked by uid 1001); 13 Jul 2007 22:33:23 +0200 Date: Fri, 13 Jul 2007 22:33:23 +0200 From: Erik Trulsson To: Volker Message-ID: <20070713203323.GA48160@owl.midgard.homeip.net> Mail-Followup-To: Volker , John Baldwin , freebsd-current@freebsd.org, Ivan Voras References: <200707130831.44748.jhb@freebsd.org> <4697CFF2.5020001@vwsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4697CFF2.5020001@vwsoft.com> User-Agent: Mutt/1.5.14 (2007-02-12) X-Originating-IP: 83.253.10.135 X-ACL-Warn: Too high rate of unknown addresses received from you X-Scan-Result: No virus found in message 1I9RpO-0001ED-86. X-Scan-Signature: ch-smtp02.sth.basefarm.net 1I9RpO-0001ED-86 e1d403d8eff45b4a25b1a64db6d0d1a5 Cc: freebsd-current@freebsd.org, Ivan Voras Subject: Re: Quick hardware survey - disk INT13 "EDD" services? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2007 20:33:28 -0000 On Fri, Jul 13, 2007 at 09:18:10PM +0200, Volker wrote: > On 12/23/-58 20:59, John Baldwin wrote: > > On Saturday 19 May 2007 11:39:53 am Ivan Voras wrote: > >> Hi! > >> > >> Does anyone have a machine that doesn't support EDD / packet interface / > >> "Extended INT13" interface on its hard drive(s) and is capable of > >> running 7-CURRENT? (486 and early Pentium class machines?) > > > > Specifically, you'd have to have a BIOS with a copyright date older than 1995. > > > > I don't know anything about EDD or 'packet interface' but I do have a > Epox MVP-3C or MVP-3G board (socket 7, BIOS dated 1999) and a CPU K6-2 > anything laying around. I think the board will fit your needs (quite a > bit unsure). I'm somewhat limited on IDE devices (just a 4 or 8g is > laying around, scsi is not a problem). EDD is short for 'Enhanced Disk Drive Services' and is an extension to the BIOS that allows the BIOS to use drives larger than 8 GiB. ("Extended INT 13" and "packet interface" are just other names for the same thing.) It was introduced in 1995, so almost all motherboards produced after 1995 will have support for it. You motherboard is thus probably much too modern and not suitable for this purpose. I believe that almost all Socket 7 mainboards (except possibly some of the very earliest models) are too modern. > > Unfortunately rebuilding world + kernel on a machine like that takes > ~18 hours but I'm able to set this up. What do you want to test? Do > you need remote (ssh/openvpn) access to it? Interested in that machine? > > Volker > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" -- Erik Trulsson ertr1013@student.uu.se From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 20:39:17 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9E75716A402; Fri, 13 Jul 2007 20:39:17 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (nagual.pp.ru [194.87.13.69]) by mx1.freebsd.org (Postfix) with ESMTP id F39A713C471; Fri, 13 Jul 2007 20:39:16 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.14.1/8.14.1) with ESMTP id l6DKdFmV020317; Sat, 14 Jul 2007 00:39:15 +0400 (MSD) (envelope-from ache@nagual.pp.ru) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nagual.pp.ru; s=default; t=1184359155; bh=+sq9crwS3gV31ZzaSw8uiJXswahYgndUB6F7ucP wz5U=; l=1014; h=Received:Date:From:To:Subject:Message-ID: Mail-Followup-To:References:MIME-Version:Content-Type: Content-Disposition:In-Reply-To:User-Agent; b=DgFxfu50gI4vZWi7sc6/ 2uMd7HpdvJY89y2G0I76qaRGzboektt9U2W6m+g/d0Lv3+el5QalLv+zMZRcC6jFY3j hFf6VfgyOz/SU4Dd8fJi8mzWIPbilvbuWOg8QzNakYuRdeUNqnATH12+wARjn+gJfSo fXwXcY3QWy+o4iNP8= Received: (from ache@localhost) by nagual.pp.ru (8.14.1/8.14.1/Submit) id l6DKdF3i020316; Sat, 14 Jul 2007 00:39:15 +0400 (MSD) (envelope-from ache) Date: Sat, 14 Jul 2007 00:39:15 +0400 From: Andrey Chernov To: "Sean C. Farley" , freebsd-current Message-ID: <20070713203915.GA20270@nagual.pp.ru> Mail-Followup-To: Andrey Chernov , "Sean C. Farley" , freebsd-current References: <20070707130859.GA96605@nagual.pp.ru> <20070707131359.GB96605@nagual.pp.ru> <20070707133102.C14065@thor.farley.org> <20070707191835.GA4368@nagual.pp.ru> <20070707205410.B14065@thor.farley.org> <20070708020940.GA80166@nagual.pp.ru> <20070708171727.GA90490@nagual.pp.ru> <20070713162742.GA16260@nagual.pp.ru> <20070713142545.K26096@thor.farley.org> <20070713202433.GA19856@nagual.pp.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070713202433.GA19856@nagual.pp.ru> User-Agent: Mutt/1.5.16 (2007-06-09) Cc: Subject: Re: Environment handling broken in /bin/sh with changes to {get,set,put}env() X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2007 20:39:17 -0000 On Sat, Jul 14, 2007 at 12:24:33AM +0400, Andrey Chernov wrote: > 1) I care in first hand about unsetenv() as my example states. There > nowhere said in the specs that unsetenv() may modify environ _content_, > manpage says about pointers only. Moreover, they directly states (at least for some cases) that environment should be left completely untouched, like that: "If the named variable does not exist in the current environment, the environment shall be unchanged and the function is considered to have completed successfully." > 2) That example not fail under FreeBSD 6 but fail under new code: > > nenv[0] = "PATH=/bin"; > nenv[1] = NULL; > environ = nenv; > setenv("HOME", "/xxx", 1); Similar thing to the setenv example: nenv[0] = "PATH=/bin"; setenv("PATH", "/bin", 0); "If the environment variable named by envname already exists and the value of overwrite is zero, the function shall return success and the environment shall remain unchanged." -- http://ache.pp.ru/ From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 20:46:24 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4D92416A40A for ; Fri, 13 Jul 2007 20:46:24 +0000 (UTC) (envelope-from mattjreimer@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.242]) by mx1.freebsd.org (Postfix) with ESMTP id EF13213C4AC for ; Fri, 13 Jul 2007 20:46:23 +0000 (UTC) (envelope-from mattjreimer@gmail.com) Received: by an-out-0708.google.com with SMTP id c14so149969anc for ; Fri, 13 Jul 2007 13:46:23 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=WW3Wg50jZxIIUv8hCmsmQlTwKf35/GA9AgTb0vM7Xtg9pWeJkLaCf4F28meTdk/5DvUlb3Zs7v88h1ghxnDca3kW/beOUKBf6afHHiQSxbXMAhrAy7Jk8APuhxQvKGEBL2ZINIXrXBcHl22zejeNRjjF2VcaMV+bv22fn2Dk4sg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=iLfNp60afIPTBotoVxgkHjP1Lin4mg0hxo5YVhLjVVeodvAzakxqf6dl0Jxhs8kGxACTRhHIl9Jkjq0GWSZsMzsIO914toHtk1Pgt5xFBSnrHKhYmhEZJPpU45OQTC067t/eH2LWYodUxhPmB8qwUzwFFgpLe1jdpC4Fuk9kAEg= Received: by 10.100.166.14 with SMTP id o14mr1121869ane.1184359583421; Fri, 13 Jul 2007 13:46:23 -0700 (PDT) Received: by 10.100.142.3 with HTTP; Fri, 13 Jul 2007 13:46:23 -0700 (PDT) Message-ID: Date: Fri, 13 Jul 2007 13:46:23 -0700 From: "Matt Reimer" To: "Scott Long" In-Reply-To: <4697DE41.7090100@samsco.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200707131528.51396.jhb@freebsd.org> <4697DE41.7090100@samsco.org> Cc: erich , freebsd-current@freebsd.org Subject: Re: arcmsr crash X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2007 20:46:24 -0000 On 7/13/07, Scott Long wrote: > John Baldwin wrote: > > On Tuesday 05 June 2007 05:22:38 pm Matt Reimer wrote: > >> Once a week or so we're seeing a panic with a -current kernel built > >> just before the gcc 4.2 import (maybe three weeks ago). The box has a > >> Supermicro X7DBE/X7DBE+ motherboard with two Xeon 5160s, 16G RAM, and > >> an Areca 1220 controller with eight 500G disks connected. > >> > >> Does this indicate that the arcmsr driver is at fault: > >> > >> Tracing command irq16: arcmsr0 pid 26 tid 100018 td 0xffffff040fc5b000 > >> cpustop_handler() at cpustop_handler+0x35 > >> ipi_nmi_handler() at ipi_nmi_handler+0x2e > >> trap() at trap+0x365 > >> nmi_calltrap() at nmi_calltrap+0x8 > >> --- trap 0x13, rip = 0xffffffff8041ab11, rsp = 0xffffffffab59eff0, rbp > >> = 0xffffffffac0a37d0 --- > >> siocnclose() at siocnclose+0x21 > >> sio_cnputc() at sio_cnputc+0x89 > >> cnputc() at cnputc+0x6a > >> putchar() at putchar+0x5f > >> kvprintf() at kvprintf+0xd45 > >> printf() at printf+0xe1 > >> panic() at panic+0x145 > >> xpt_done() at xpt_done+0x14a > >> arcmsr_interrupt() at arcmsr_interrupt+0x2df > >> ithread_loop() at ithread_loop+0x108 > >> fork_exit() at fork_exit+0xaa > >> fork_trampoline() at fork_trampoline+0xe > >> --- trap 0, rip = 0, rsp = 0xffffffffac0a3d30, rbp = 0 --- > > > > Looks like it has panic'd here: > > > > switch (done_ccb->ccb_h.path->periph->type) { > > case CAM_PERIPH_BIO: > > mtx_lock(&cam_bioq_lock); > > TAILQ_INSERT_TAIL(&cam_bioq, &done_ccb->ccb_h, > > sim_links.tqe); > > done_ccb->ccb_h.pinfo.index = CAM_DONEQ_INDEX; > > mtx_unlock(&cam_bioq_lock); > > swi_sched(cambio_ih, 0); > > break; > > default: > > panic("unknown periph type %d", > > done_ccb->ccb_h.path->periph->type); > > } > > > > which should seem to indicate that, yes, it is a driver bug. > > > > The doneq has gotten corrupted somehow. The only real way that this > could happen is if xpt_done() was called twice on the same ccb. Whether > this is a hardware bug (hardware completing the same command twice) or > a driver bug is unknown. I'll try to add some seatbelts to CAM to > detect this kind of condition. But yes, it's ultimately something in > the arcmsr subsystem that is at fault. Do you have any suggestions of instrumentation printfs I could add to zero in on what part of the driver is at fault? Matt From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 21:00:14 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 63F7016A402 for ; Fri, 13 Jul 2007 21:00:14 +0000 (UTC) (envelope-from mattjreimer@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.244]) by mx1.freebsd.org (Postfix) with ESMTP id 238F613C4AA for ; Fri, 13 Jul 2007 21:00:14 +0000 (UTC) (envelope-from mattjreimer@gmail.com) Received: by an-out-0708.google.com with SMTP id c14so150832anc for ; Fri, 13 Jul 2007 14:00:13 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=nTAr6VmdlEBQ38ncAEeJPCf8I7gtmLAGA81xnUwOJ3T1vH4AnkbtgA/5kOIbO/gkfkSE3Pn8hqsyF2xzzI14cQpIdxBP2yxmxZgiX0zEMYRZPVfRE+e30dsecrb0pg2dtvO67ERP2RlAJ49Y7zNr88vZdTt3e1itTc77r1idGzo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=NSVRi/ncm3bBL0ADVDbUgTc+ZQa/xzRZIAIINrXINwtp8c3cqdkiusLYqpdnyDEaPi3SJY4lGUt/RQXv9Rf/SGP66y5ORvxGtplW64sS+vcOA8q54JXrwRQ+JR2YSxkeNlfaCsekRngFhvoYWrTPp6BhyYHe2y6CWe9F6JtPhfY= Received: by 10.100.125.5 with SMTP id x5mr1121528anc.1184358972064; Fri, 13 Jul 2007 13:36:12 -0700 (PDT) Received: by 10.100.142.3 with HTTP; Fri, 13 Jul 2007 13:36:11 -0700 (PDT) Message-ID: Date: Fri, 13 Jul 2007 13:36:11 -0700 From: "Matt Reimer" To: "John Baldwin" In-Reply-To: <200707131528.51396.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200707131528.51396.jhb@freebsd.org> Cc: freebsd-current@freebsd.org, scottl@freebsd.org Subject: Re: arcmsr crash X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2007 21:00:14 -0000 On 7/13/07, John Baldwin wrote: > On Tuesday 05 June 2007 05:22:38 pm Matt Reimer wrote: > > Once a week or so we're seeing a panic with a -current kernel built > > just before the gcc 4.2 import (maybe three weeks ago). The box has a > > Supermicro X7DBE/X7DBE+ motherboard with two Xeon 5160s, 16G RAM, and > > an Areca 1220 controller with eight 500G disks connected. > > > > Does this indicate that the arcmsr driver is at fault: > > > > Tracing command irq16: arcmsr0 pid 26 tid 100018 td 0xffffff040fc5b000 > > cpustop_handler() at cpustop_handler+0x35 > > ipi_nmi_handler() at ipi_nmi_handler+0x2e > > trap() at trap+0x365 > > nmi_calltrap() at nmi_calltrap+0x8 > > --- trap 0x13, rip = 0xffffffff8041ab11, rsp = 0xffffffffab59eff0, rbp > > = 0xffffffffac0a37d0 --- > > siocnclose() at siocnclose+0x21 > > sio_cnputc() at sio_cnputc+0x89 > > cnputc() at cnputc+0x6a > > putchar() at putchar+0x5f > > kvprintf() at kvprintf+0xd45 > > printf() at printf+0xe1 > > panic() at panic+0x145 > > xpt_done() at xpt_done+0x14a > > arcmsr_interrupt() at arcmsr_interrupt+0x2df > > ithread_loop() at ithread_loop+0x108 > > fork_exit() at fork_exit+0xaa > > fork_trampoline() at fork_trampoline+0xe > > --- trap 0, rip = 0, rsp = 0xffffffffac0a3d30, rbp = 0 --- > > Looks like it has panic'd here: > > switch (done_ccb->ccb_h.path->periph->type) { > case CAM_PERIPH_BIO: > mtx_lock(&cam_bioq_lock); > TAILQ_INSERT_TAIL(&cam_bioq, &done_ccb->ccb_h, > sim_links.tqe); > done_ccb->ccb_h.pinfo.index = CAM_DONEQ_INDEX; > mtx_unlock(&cam_bioq_lock); > swi_sched(cambio_ih, 0); > break; > default: > panic("unknown periph type %d", > done_ccb->ccb_h.path->periph->type); > } > > which should seem to indicate that, yes, it is a driver bug. That code in -CURRENT looks a bit different (cam_simq_lock instead of cam_bioq_lock, etc.). Is that relevant to your analysis? Matt From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 21:01:00 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E6FCA16A403 for ; Fri, 13 Jul 2007 21:01:00 +0000 (UTC) (envelope-from dominique.goncalves@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.235]) by mx1.freebsd.org (Postfix) with ESMTP id 9397913C4A3 for ; Fri, 13 Jul 2007 21:01:00 +0000 (UTC) (envelope-from dominique.goncalves@gmail.com) Received: by wr-out-0506.google.com with SMTP id i23so429522wra for ; Fri, 13 Jul 2007 14:01:00 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=qfVZ7/H3M8hzDXYmDYpmCj7WZTp9FyT0n8Jogw7abXEhqTkFiYOQ4y9RkjuFdqVCGN4dE/B9Ts8qGoyx//LLOcHW7qckY67ICEJykilJSEwjsxbwVxJyEVz0FP1TR5TOo6p4vVhriCAKWobA3aJt+nihcDvud5omMtTRAEccLzs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=BgNyVJLb32VJY99hN0qhoQiGde81+4+IdlFId+DDrykYB4W1B2L6hBqK8o+zL9bbI0hAG78AUnywOpIbQ6wjDvZLIpvUGO2/rYZ64k3UB6UpKCxQUqt6Mxbgux1OrrrZsfXRRgwmNX3G9jajKQFaTCyN/La4eJ2D7EI5UyYvOJg= Received: by 10.90.104.14 with SMTP id b14mr2083052agc.1184358832668; Fri, 13 Jul 2007 13:33:52 -0700 (PDT) Received: by 10.90.96.3 with HTTP; Fri, 13 Jul 2007 13:33:52 -0700 (PDT) Message-ID: <7daacbbe0707131333q7a290e2bn6d0999151f6d5777@mail.gmail.com> Date: Fri, 13 Jul 2007 22:33:52 +0200 From: "Dominique Goncalves" To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: FreeBSD uses the year 1936 in qemu X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2007 21:01:01 -0000 Hi, I'm trying to run FreeBSD 7.0-CURRENT as a guest in qemu-0.9.0 (using freesbie), but FreeBSD thinks the current date is Sat 31 oct 1936. newsyslog and syslogd do not start correctly. Creating and/or trimming log files: newsyslog: malformed 'at' value: /var/log/all.log 600 7 * @T00 J . Starting syslogd. Oct 31 17:01:25 syslogd: /var/log/messages: No such file or directory Oct 31 17:01:25 syslogd: /var/log/security: No such file or directory Oct 31 17:01:25 syslogd: /var/log/auth.log: No such file or directory Oct 31 17:01:25 syslogd: /var/log/maillog: No such file or directory Oct 31 17:01:25 syslogd: /var/log/lpd-errs: No such file or directory Oct 31 17:01:25 syslogd: /var/log/xferlog: No such file or directory Oct 31 17:01:25 syslogd: /var/log/cron: No such file or directory Oct 31 17:01:25 syslogd: /var/log/debug.log: No such file or directory Oct 31 17:01:25 syslogd: /var/log/slip.log: No such file or directory Oct 31 17:01:25 syslogd: /var/log/ppp.log: No such file or directory Of course I can use ntpd or ntpdate but it's too late in the startup order. I found a similar problem [1] reported which proposes a fix [2]. I applied the patch in PR i386/111117 and the date is now set correclty inside qemu. Is this a bug in FreeBSD or qemu ? Thanks, Regards. [1] : http://lists.freebsd.org/pipermail/freebsd-current/2007-April/070394.html [2] : http://www.freebsd.org/cgi/query-pr.cgi?pr=111117 -- There's this old saying: "Give a man a fish, feed him for a day. Teach a man to fish, feed him for life." From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 21:36:50 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E665316A401 for ; Fri, 13 Jul 2007 21:36:50 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from pne-smtpout2-sn1.fre.skanova.net (pne-smtpout2-sn1.fre.skanova.net [81.228.11.159]) by mx1.freebsd.org (Postfix) with ESMTP id A8D9C13C461 for ; Fri, 13 Jul 2007 21:36:50 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from [192.168.1.5] (217.211.83.81) by pne-smtpout2-sn1.fre.skanova.net (7.2.075) id 4668007E00810CB6; Fri, 13 Jul 2007 23:36:49 +0200 In-Reply-To: <7daacbbe0707131333q7a290e2bn6d0999151f6d5777@mail.gmail.com> References: <7daacbbe0707131333q7a290e2bn6d0999151f6d5777@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Thomas Backman Date: Fri, 13 Jul 2007 23:36:49 +0200 To: Dominique Goncalves X-Mailer: Apple Mail (2.752.3) Cc: freebsd-current@freebsd.org Subject: Re: FreeBSD uses the year 1936 in qemu X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2007 21:36:51 -0000 On Jul 13, 2007, at 10:33 PM, Dominique Goncalves wrote: > Hi, > > I'm trying to run FreeBSD 7.0-CURRENT as a guest in qemu-0.9.0 (using > freesbie), but FreeBSD thinks the current date is Sat 31 oct 1936. > newsyslog and syslogd do not start correctly. > > Creating and/or trimming log files: > newsyslog: > malformed 'at' value: > /var/log/all.log 600 7 * @T00 J > > . > > Of course I can use ntpd or ntpdate but it's too late in the > startup order. > I found a similar problem [1] reported which proposes a fix [2]. > I applied the patch in PR i386/111117 and the date is now set > correclty inside qemu. > > Is this a bug in FreeBSD or qemu ? This happens in VMWare (VMWare Fusion, to be exact) as well. The same topic was up recently (last post today), "Debugging time". According to the last post, the issue seems to be resolved (but with no patch commited). /Thomas From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 21:57:58 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C579D16A406; Fri, 13 Jul 2007 21:57:58 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 5CF6C13C4A6; Fri, 13 Jul 2007 21:57:58 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from scott-longs-computer.local (phobos.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.8/8.13.8) with ESMTP id l6DLvpPQ017537; Fri, 13 Jul 2007 15:57:52 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <4697F551.4090801@samsco.org> Date: Fri, 13 Jul 2007 15:57:37 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.4) Gecko/20070509 SeaMonkey/1.1.2 MIME-Version: 1.0 To: Matt Reimer References: <200707131528.51396.jhb@freebsd.org> In-Reply-To: X-Enigmail-Version: 0.95.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (pooker.samsco.org [168.103.85.57]); Fri, 13 Jul 2007 15:57:52 -0600 (MDT) X-Spam-Status: No, score=-1.4 required=5.5 tests=ALL_TRUSTED autolearn=failed version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: freebsd-current@freebsd.org, scottl@freebsd.org Subject: Re: arcmsr crash X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2007 21:57:58 -0000 Matt Reimer wrote: > On 7/13/07, John Baldwin wrote: >> On Tuesday 05 June 2007 05:22:38 pm Matt Reimer wrote: >> > Once a week or so we're seeing a panic with a -current kernel built >> > just before the gcc 4.2 import (maybe three weeks ago). The box has a >> > Supermicro X7DBE/X7DBE+ motherboard with two Xeon 5160s, 16G RAM, and >> > an Areca 1220 controller with eight 500G disks connected. >> > >> > Does this indicate that the arcmsr driver is at fault: >> > >> > Tracing command irq16: arcmsr0 pid 26 tid 100018 td 0xffffff040fc5b000 >> > cpustop_handler() at cpustop_handler+0x35 >> > ipi_nmi_handler() at ipi_nmi_handler+0x2e >> > trap() at trap+0x365 >> > nmi_calltrap() at nmi_calltrap+0x8 >> > --- trap 0x13, rip = 0xffffffff8041ab11, rsp = 0xffffffffab59eff0, rbp >> > = 0xffffffffac0a37d0 --- >> > siocnclose() at siocnclose+0x21 >> > sio_cnputc() at sio_cnputc+0x89 >> > cnputc() at cnputc+0x6a >> > putchar() at putchar+0x5f >> > kvprintf() at kvprintf+0xd45 >> > printf() at printf+0xe1 >> > panic() at panic+0x145 >> > xpt_done() at xpt_done+0x14a >> > arcmsr_interrupt() at arcmsr_interrupt+0x2df >> > ithread_loop() at ithread_loop+0x108 >> > fork_exit() at fork_exit+0xaa >> > fork_trampoline() at fork_trampoline+0xe >> > --- trap 0, rip = 0, rsp = 0xffffffffac0a3d30, rbp = 0 --- >> >> Looks like it has panic'd here: >> >> switch (done_ccb->ccb_h.path->periph->type) { >> case CAM_PERIPH_BIO: >> mtx_lock(&cam_bioq_lock); >> TAILQ_INSERT_TAIL(&cam_bioq, &done_ccb->ccb_h, >> sim_links.tqe); >> done_ccb->ccb_h.pinfo.index = CAM_DONEQ_INDEX; >> mtx_unlock(&cam_bioq_lock); >> swi_sched(cambio_ih, 0); >> break; >> default: >> panic("unknown periph type %d", >> done_ccb->ccb_h.path->periph->type); >> } >> >> which should seem to indicate that, yes, it is a driver bug. > > That code in -CURRENT looks a bit different (cam_simq_lock instead of > cam_bioq_lock, etc.). Is that relevant to your analysis? > > Matt The locking is different, but the problem is basically the same. Are you using 7-CURRENT or 6.x? Scott From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 22:06:29 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5638316A400 for ; Fri, 13 Jul 2007 22:06:29 +0000 (UTC) (envelope-from volker@vwsoft.com) Received: from frontmail.ipactive.de (frontmail.maindns.de [85.214.95.103]) by mx1.freebsd.org (Postfix) with ESMTP id 1BDF213C494 for ; Fri, 13 Jul 2007 22:06:28 +0000 (UTC) (envelope-from volker@vwsoft.com) Received: from mail.vtec.ipme.de (F72b3.f.ppp-pool.de [195.4.114.179]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by frontmail.ipactive.de (Postfix) with ESMTP id F175712883F for ; Sat, 14 Jul 2007 00:06:21 +0200 (CEST) Received: from cesar.sz.vwsoft.com (cesar.sz.vwsoft.com [192.168.16.3]) by mail.vtec.ipme.de (Postfix) with ESMTP id 165843F440 for ; Sat, 14 Jul 2007 00:05:51 +0200 (CEST) Message-ID: <4697F753.5060304@vwsoft.com> Date: Sat, 14 Jul 2007 00:06:11 +0200 From: Volker User-Agent: Thunderbird 2.0.0.4 (X11/20070615) MIME-Version: 1.0 To: current@freebsd.org X-Enigmail-Version: 0.95.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-VWSoft-MailScanner: Found to be clean X-MailScanner-From: volker@vwsoft.com X-ipactive-MailScanner-Information: Please contact the ISP for more information X-ipactive-MailScanner: Found to be clean X-ipactive-MailScanner-From: volker@vwsoft.com Cc: Subject: zfs refuses to load pool on boot, zpool denies import X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2007 22:06:29 -0000 I'm constantly getting this error on bootup: ZFS: WARNING: pool 'mypool' could not be loaded as it was last accessed by another system (host: hostid: 0x0). See: http://www.sun.com/msg/ZFS-8000-EY As I've put /usr into zfs, I need to reboot into single user and issue a `zpool import -f mypool' (w/o -forcing, zpool denies to import the pool). It's strange as this pool has been created on that machine (probably while having booted from a different disk - I don't actually remember). I already imported, exported and re-imported but it didn't help. Any ideas? %kenv smbios.system.uuid ccf8597d-74fe-d511-a413-782ede476378 FreeBSD 7.0-CURRENT #2: Fri Jul 13 19:29:31 CEST 2007 (i386) csup'd & rebuild today, kernel mostly GENERIC (+ALTQ added) Thx Volker From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 22:14:38 2007 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B2D4116A401; Fri, 13 Jul 2007 22:14:38 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 7337F13C481; Fri, 13 Jul 2007 22:14:38 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.13.8/8.13.4) with ESMTP id l6DMBqOK066616; Fri, 13 Jul 2007 16:11:52 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Fri, 13 Jul 2007 16:11:45 -0600 (MDT) Message-Id: <20070713.161145.1324584079.imp@bsdimp.com> To: attilio@FreeBSD.org From: "M. Warner Losh" In-Reply-To: <46972B28.1010409@FreeBSD.org> References: <46970DF7.3000803@elischer.org> <46972B28.1010409@FreeBSD.org> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Fri, 13 Jul 2007 16:11:53 -0600 (MDT) Cc: julian@elischer.org, current@FreeBSD.org Subject: Re: crash in tty code in 6.1.. fixed since? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2007 22:14:38 -0000 In message: <46972B28.1010409@FreeBSD.org> Attilio Rao writes: : I think it has been fixed some months ago IIRC. : The problem here, should be that if sx_slock() let thread sleep, Giant : is released before to sleep and tp->t_session can be accessed in racy way. : Another nice side-effect about having tty Giant :) I've been having crashes right and left in cblock code. I've had good luck converting it to using a mutext. However, someone else was telling me they had big problems going all the way and locking the entire TTY subsystem. The evidence is in p4... Warner From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 22:15:56 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4B3BA16A405 for ; Fri, 13 Jul 2007 22:15:56 +0000 (UTC) (envelope-from scf@FreeBSD.org) Received: from mail.farley.org (farley.org [67.64.95.201]) by mx1.freebsd.org (Postfix) with ESMTP id C996613C4BA for ; Fri, 13 Jul 2007 22:15:55 +0000 (UTC) (envelope-from scf@FreeBSD.org) Received: from thor.farley.org (thor.farley.org [192.168.1.5]) by mail.farley.org (8.14.1/8.14.1) with ESMTP id l6DMHjbQ055803; Fri, 13 Jul 2007 17:17:45 -0500 (CDT) (envelope-from scf@FreeBSD.org) Date: Fri, 13 Jul 2007 17:15:37 -0500 (CDT) From: "Sean C. Farley" To: Andrey Chernov In-Reply-To: <20070713202433.GA19856@nagual.pp.ru> Message-ID: <20070713152644.I26096@thor.farley.org> References: <20070705105922.F98700@thor.farley.org> <20070707130859.GA96605@nagual.pp.ru> <20070707131359.GB96605@nagual.pp.ru> <20070707133102.C14065@thor.farley.org> <20070707191835.GA4368@nagual.pp.ru> <20070707205410.B14065@thor.farley.org> <20070708020940.GA80166@nagual.pp.ru> <20070708171727.GA90490@nagual.pp.ru> <20070713162742.GA16260@nagual.pp.ru> <20070713142545.K26096@thor.farley.org> <20070713202433.GA19856@nagual.pp.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.1 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on mail.farley.org Cc: freebsd-current Subject: Re: Environment handling broken in /bin/sh with changes to t,set,put}env() X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2007 22:15:56 -0000 On Sat, 14 Jul 2007, Andrey Chernov wrote: > On Fri, Jul 13, 2007 at 02:39:30PM -0500, Sean C. Farley wrote: >> FreeBSD 6 will also dump if the length of the value was less than or >> equal to "/bin" since it reuses this string. This will core dump: >> >> nenv[0] = "PATH=/bin"; >> nenv[1] = NULL; >> environ = nenv; >> setenv("PATH", "/bin", 1); > > 1) I care in first hand about unsetenv() as my example states. There > nowhere said in the specs that unsetenv() may modify environ _content_, > manpage says about pointers only. Well technically, for setenv() and unsetenv() (the Open Group): If the application modifies environ or the pointers to which it points, the behavior of unsetenv() is undefined. However, I would like to have *env() functions work in this case. > 2) That example not fail under FreeBSD 6 but fail under new code: > > nenv[0] = "PATH=/bin"; > nenv[1] = NULL; > environ = nenv; > setenv("HOME", "/xxx", 1); > > (that is because new code will touch "PATH=/bin" string in anycase while > old ones looks for "HOME" only). > > The most safest way is do not touch environ content outside of > scope of requested modification. That means I agree that > nenv[0] = "PATH=/bin"; > setenv("PATH", "/bin", 1); > may fail, but not about the cases 1) and 2) Choices: 1. Call putenv() instead. The change is small, but it would create variables that are unusable to setenv() in future calls. Memory allocations could be the result. 2. Copy each string to use with setenv(). I am trying to avoid needless allocations. 3. Restructure setenv() to avoid memory allocations. I chose #3. Try the patch[1] again. It creates a setenv() function which is a wrapper around __setenv(). __setenv() takes the lengths of name and value to allow the caller to calculate the length using pointer arithmetic instead of strlen(). Sean 1. http://www.farley.org/freebsd/tmp/setenv/clearenv/patch -- scf@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 22:19:11 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B58CF16A401 for ; Fri, 13 Jul 2007 22:19:11 +0000 (UTC) (envelope-from dan@dan.emsphone.com) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.freebsd.org (Postfix) with ESMTP id 4D1EB13C4AC for ; Fri, 13 Jul 2007 22:19:00 +0000 (UTC) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.14.1/8.13.8) id l6DMItDi011491; Fri, 13 Jul 2007 17:18:55 -0500 (CDT) (envelope-from dan) Date: Fri, 13 Jul 2007 17:18:55 -0500 From: Dan Nelson To: Volker Message-ID: <20070713221854.GC44766@dan.emsphone.com> References: <4697F753.5060304@vwsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4697F753.5060304@vwsoft.com> X-OS: FreeBSD 7.0-CURRENT User-Agent: Mutt/1.5.16 (2007-06-09) Cc: current@freebsd.org Subject: Re: zfs refuses to load pool on boot, zpool denies import X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2007 22:19:11 -0000 In the last episode (Jul 14), Volker said: > I'm constantly getting this error on bootup: > > ZFS: WARNING: pool 'mypool' could not be loaded as it was last > accessed by another system (host: hostid: 0x0). See: > http://www.sun.com/msg/ZFS-8000-EY > > As I've put /usr into zfs, I need to reboot into single user and > issue a `zpool import -f mypool' (w/o -forcing, zpool denies to > import the pool). It's strange as this pool has been created on that > machine (probably while having booted from a different disk - I don't > actually remember). > > I already imported, exported and re-imported but it didn't help. > > Any ideas? > > %kenv smbios.system.uuid > ccf8597d-74fe-d511-a413-782ede476378 That may be what's causing your problem. If you boot into single-user, make sure to run "/etc/rc.d/hostid start", which sets kern.hostuuid from /etc/hostid or smbios.system.uuid if /etc/hostid doesn't exist. -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 22:23:45 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 87B5416A400 for ; Fri, 13 Jul 2007 22:23:45 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.175]) by mx1.freebsd.org (Postfix) with ESMTP id 1964E13C4A5 for ; Fri, 13 Jul 2007 22:23:44 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by ug-out-1314.google.com with SMTP id o4so734635uge for ; Fri, 13 Jul 2007 15:23:40 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:reply-to:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding:sender; b=EF0gQWeDF3K5Si33fUPIL9ML81foBUQk7LrajIap4HvgK94BNlKTqGdvC7IL7B9i3cQbuQA0Kvtp1/WcakargM8/FuNnGPMswBVfpacT6BVc5dZZ7MEsXLZGeihVM4Kn/XoNXYpfSpeZcE9cIg4AwUXO/Y44mfg/rsfqGCJIzbQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:reply-to:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding:sender; b=MSB0VAyIrGzlQKEwl1Hc6jQ88yzTekDG/j0EGsZ5mCXNOz2qStk7NAOHuW295p2dZJQFHJIEpdaULrcaz+tb/YSYi76v8nGGeg05QGp7sH3NjCUNliQUdAf0AAWyd1yY+tmb/JSneVjrR/GZS32KL0LGaQjkZCvHCfwRUykAbJU= Received: by 10.66.243.4 with SMTP id q4mr2314044ugh.1184365420412; Fri, 13 Jul 2007 15:23:40 -0700 (PDT) Received: from ?151.75.219.248? ( [151.75.219.248]) by mx.google.com with ESMTPS id o56sm84639uga.2007.07.13.15.23.39 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 13 Jul 2007 15:23:40 -0700 (PDT) Message-ID: <4697FB3F.9030802@FreeBSD.org> Date: Sat, 14 Jul 2007 00:22:55 +0200 From: Attilio Rao User-Agent: Thunderbird 1.5 (X11/20060526) MIME-Version: 1.0 To: "M. Warner Losh" References: <46970DF7.3000803@elischer.org> <46972B28.1010409@FreeBSD.org> <20070713.161145.1324584079.imp@bsdimp.com> In-Reply-To: <20070713.161145.1324584079.imp@bsdimp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: Attilio Rao Cc: julian@elischer.org, current@FreeBSD.org Subject: Re: crash in tty code in 6.1.. fixed since? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: attilio@FreeBSD.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2007 22:23:45 -0000 M. Warner Losh wrote: > In message: <46972B28.1010409@FreeBSD.org> > Attilio Rao writes: > : I think it has been fixed some months ago IIRC. > : The problem here, should be that if sx_slock() let thread sleep, Giant > : is released before to sleep and tp->t_session can be accessed in racy way. > : Another nice side-effect about having tty Giant :) > > I've been having crashes right and left in cblock code. I've had good > luck converting it to using a mutext. However, someone else was > telling me they had big problems going all the way and locking the > entire TTY subsystem. The evidence is in p4... What depot do you refer exactly? Attilio From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 22:28:18 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4513716A404 for ; Fri, 13 Jul 2007 22:28:18 +0000 (UTC) (envelope-from scf@FreeBSD.org) Received: from mail.farley.org (farley.org [67.64.95.201]) by mx1.freebsd.org (Postfix) with ESMTP id 057A713C4A7 for ; Fri, 13 Jul 2007 22:28:17 +0000 (UTC) (envelope-from scf@FreeBSD.org) Received: from thor.farley.org (thor.farley.org [192.168.1.5]) by mail.farley.org (8.14.1/8.14.1) with ESMTP id l6DMU67f055977; Fri, 13 Jul 2007 17:30:06 -0500 (CDT) (envelope-from scf@FreeBSD.org) Date: Fri, 13 Jul 2007 17:27:58 -0500 (CDT) From: "Sean C. Farley" To: Andrey Chernov In-Reply-To: <20070713203915.GA20270@nagual.pp.ru> Message-ID: <20070713171942.Q26096@thor.farley.org> References: <20070707130859.GA96605@nagual.pp.ru> <20070707131359.GB96605@nagual.pp.ru> <20070707133102.C14065@thor.farley.org> <20070707191835.GA4368@nagual.pp.ru> <20070707205410.B14065@thor.farley.org> <20070708020940.GA80166@nagual.pp.ru> <20070708171727.GA90490@nagual.pp.ru> <20070713162742.GA16260@nagual.pp.ru> <20070713142545.K26096@thor.farley.org> <20070713202433.GA19856@nagual.pp.ru> <20070713203915.GA20270@nagual.pp.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.1 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on mail.farley.org Cc: freebsd-current Subject: Re: Environment handling broken in /bin/sh with changes to t,set,put}env() X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2007 22:28:18 -0000 On Sat, 14 Jul 2007, Andrey Chernov wrote: > On Sat, Jul 14, 2007 at 12:24:33AM +0400, Andrey Chernov wrote: >> 1) I care in first hand about unsetenv() as my example states. There >> nowhere said in the specs that unsetenv() may modify environ _content_, >> manpage says about pointers only. > > Moreover, they directly states (at least for some cases) that environment > should be left completely untouched, like that: > > "If the named variable does not exist in the current environment, the > environment shall be unchanged and the function is considered to have > completed successfully." *snipped part about setenv()* I agree that setenv() and unsetenv() follow the same requirement. Does that mean that environ is untouched or that the environment is unchanged? They seem to use both words (environ and environment) in the documentation making me think they are not necessarily the same thing. Currently, non-getenv() calls rebuilds the environ array if having never been changed before, but the "environment" is "unchanged" if the variable does not exist. Should that not meet that requirement? Sean -- scf@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 22:30:15 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6DA6616A4A5 for ; Fri, 13 Jul 2007 22:30:15 +0000 (UTC) (envelope-from scf@FreeBSD.org) Received: from mail.farley.org (farley.org [67.64.95.201]) by mx1.freebsd.org (Postfix) with ESMTP id 1D25E13C4AC for ; Fri, 13 Jul 2007 22:30:14 +0000 (UTC) (envelope-from scf@FreeBSD.org) Received: from thor.farley.org (thor.farley.org [192.168.1.5]) by mail.farley.org (8.14.1/8.14.1) with ESMTP id l6DMW5Rm055989; Fri, 13 Jul 2007 17:32:05 -0500 (CDT) (envelope-from scf@FreeBSD.org) Date: Fri, 13 Jul 2007 17:29:57 -0500 (CDT) From: "Sean C. Farley" To: Harald Schmalzbauer In-Reply-To: <200707132155.43783.h.schmalzbauer@omnisec.de> Message-ID: <20070713172842.K26096@thor.farley.org> References: <200707131834.27131.h.schmalzbauer@omnisec.de> <4697CCEB.9080707@FreeBSD.org> <200707132155.43783.h.schmalzbauer@omnisec.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.1 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on mail.farley.org Cc: attilio@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: kqemu crash (page fault) with -current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2007 22:30:15 -0000 On Fri, 13 Jul 2007, Harald Schmalzbauer wrote: > I could install various OS, only when I enable -kernel-kqemu most > installer quit with page fault. As a side note, I found -kernel-kqemu to be slower for me than without it on STABLE. Sean -- scf@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 22:40:56 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6DB1516A409; Fri, 13 Jul 2007 22:40:56 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (nagual.pp.ru [194.87.13.69]) by mx1.freebsd.org (Postfix) with ESMTP id D437A13C4B4; Fri, 13 Jul 2007 22:40:55 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.14.1/8.14.1) with ESMTP id l6DMesK1021849; Sat, 14 Jul 2007 02:40:54 +0400 (MSD) (envelope-from ache@nagual.pp.ru) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nagual.pp.ru; s=default; t=1184366454; bh=lFTc1ju+KhrORT0bPjN5kehAEP7bS5lxYck4UtX mccc=; l=776; h=Received:Date:From:To:Cc:Subject:Message-ID: Mail-Followup-To:References:MIME-Version:Content-Type: Content-Disposition:In-Reply-To:User-Agent; b=KLAznw9OOgJtULdZsUWn TtQ+7pb7mFkp87DGfmnCsJoTeJMfoayEn37hgX4wALc/pT2A5xIFIwC+c94sykEQQBl lc8CMsjAELpJ5V8/o4KSiU+EuyAYHa0gqBLi56vdH3Gbl+qtGbkYA9gc+ud/zobQ1Y4 ntr2IjbLwZI9yjTQw= Received: (from ache@localhost) by nagual.pp.ru (8.14.1/8.14.1/Submit) id l6DMesHZ021848; Sat, 14 Jul 2007 02:40:54 +0400 (MSD) (envelope-from ache) Date: Sat, 14 Jul 2007 02:40:53 +0400 From: Andrey Chernov To: "Sean C. Farley" Message-ID: <20070713224053.GA21695@nagual.pp.ru> Mail-Followup-To: Andrey Chernov , "Sean C. Farley" , freebsd-current References: <20070707131359.GB96605@nagual.pp.ru> <20070707133102.C14065@thor.farley.org> <20070707191835.GA4368@nagual.pp.ru> <20070707205410.B14065@thor.farley.org> <20070708020940.GA80166@nagual.pp.ru> <20070708171727.GA90490@nagual.pp.ru> <20070713162742.GA16260@nagual.pp.ru> <20070713142545.K26096@thor.farley.org> <20070713202433.GA19856@nagual.pp.ru> <20070713152644.I26096@thor.farley.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070713152644.I26096@thor.farley.org> User-Agent: Mutt/1.5.16 (2007-06-09) Cc: freebsd-current Subject: Re: Environment handling broken in /bin/sh with changes to t,set,put}env() X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2007 22:40:56 -0000 On Fri, Jul 13, 2007 at 05:15:37PM -0500, Sean C. Farley wrote: > Well technically, for setenv() and unsetenv() (the Open Group): > > If the application modifies environ or the pointers to which it > points, the behavior of unsetenv() is undefined. > > However, I would like to have *env() functions work in this case. It seems that anybody will agree with that. > I chose #3. Try the patch[1] again. It creates a setenv() function > which is a wrapper around __setenv(). __setenv() takes the lengths of > name and value to allow the caller to calculate the length using pointer > arithmetic instead of strlen(). > > Sean > 1. http://www.farley.org/freebsd/tmp/setenv/clearenv/patch The wrapper version finally looks OK for me. -- http://ache.pp.ru/ From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 22:44:57 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1A8E016A406 for ; Fri, 13 Jul 2007 22:44:57 +0000 (UTC) (envelope-from volker@vwsoft.com) Received: from frontmail.ipactive.de (frontmail.maindns.de [85.214.95.103]) by mx1.freebsd.org (Postfix) with ESMTP id D064913C467 for ; Fri, 13 Jul 2007 22:44:56 +0000 (UTC) (envelope-from volker@vwsoft.com) Received: from mail.vtec.ipme.de (F72b3.f.ppp-pool.de [195.4.114.179]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by frontmail.ipactive.de (Postfix) with ESMTP id E135712883F for ; Sat, 14 Jul 2007 00:44:49 +0200 (CEST) Received: from cesar.sz.vwsoft.com (cesar.sz.vwsoft.com [192.168.16.3]) by mail.vtec.ipme.de (Postfix) with ESMTP id D2B2E3F43D; Sat, 14 Jul 2007 00:44:22 +0200 (CEST) Message-ID: <4698005B.3010100@vwsoft.com> Date: Sat, 14 Jul 2007 00:44:43 +0200 From: Volker User-Agent: Thunderbird 2.0.0.4 (X11/20070615) MIME-Version: 1.0 To: Dan Nelson References: <4697F753.5060304@vwsoft.com> <20070713221854.GC44766@dan.emsphone.com> In-Reply-To: <20070713221854.GC44766@dan.emsphone.com> X-Enigmail-Version: 0.95.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-VWSoft-MailScanner: Found to be clean X-MailScanner-From: volker@vwsoft.com X-ipactive-MailScanner-Information: Please contact the ISP for more information X-ipactive-MailScanner: Found to be clean X-ipactive-MailScanner-From: volker@vwsoft.com Cc: current@freebsd.org Subject: Re: zfs refuses to load pool on boot, zpool denies import X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2007 22:44:57 -0000 On 07/14/07 00:18, Dan Nelson wrote: > In the last episode (Jul 14), Volker said: >> I'm constantly getting this error on bootup: >> >> ZFS: WARNING: pool 'mypool' could not be loaded as it was last >> accessed by another system (host: hostid: 0x0). See: >> http://www.sun.com/msg/ZFS-8000-EY >> >> As I've put /usr into zfs, I need to reboot into single user and >> issue a `zpool import -f mypool' (w/o -forcing, zpool denies to >> import the pool). It's strange as this pool has been created on that >> machine (probably while having booted from a different disk - I don't >> actually remember). >> >> I already imported, exported and re-imported but it didn't help. >> >> Any ideas? >> >> %kenv smbios.system.uuid >> ccf8597d-74fe-d511-a413-782ede476378 > > That may be what's causing your problem. If you boot into single-user, > make sure to run "/etc/rc.d/hostid start", which sets kern.hostuuid > from /etc/hostid or smbios.system.uuid if /etc/hostid doesn't exist. > Dan, damned... that's it. Thanks a lot. I was wondering about that because I've already seen a system uuid in kenv (only checked smbios.system.uuid) while in single user mode so I did not see the need to manually fire `/etc/rc.d/hostid start'. This may be taken into the documentation - I guess more will step into this. Or what about checking the hostid before doing any `zpool create | import' and refuse operation (with a useful hint to the operator) if hostid is 0x0? Volker From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 22:46:09 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BD0AB16A402; Fri, 13 Jul 2007 22:46:09 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (nagual.pp.ru [194.87.13.69]) by mx1.freebsd.org (Postfix) with ESMTP id 37ED113C4B2; Fri, 13 Jul 2007 22:46:09 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.14.1/8.14.1) with ESMTP id l6DMk8ni021920; Sat, 14 Jul 2007 02:46:08 +0400 (MSD) (envelope-from ache@nagual.pp.ru) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nagual.pp.ru; s=default; t=1184366768; bh=j16Q0XK0gPcEMqsDl4Sqzbj/jV20Yz7X6AreaUn tYc0=; l=698; h=Received:Date:From:To:Cc:Subject:Message-ID: Mail-Followup-To:References:MIME-Version:Content-Type: Content-Disposition:In-Reply-To:User-Agent; b=lLiumzZD938jyM3Zhr63 fL4LZxrUxqBGMC+tfyJEgQ6K3LquYO1u6+t3ASPlwEtjeBZJ68ur5+PIsTTKDZHVgd5 qW50G491v+Ew68dUmOodd5mtlwaEas+OwkIFd0412Eg307hSTtVrKeCmELyxyRTsHSp x/DNpi5LF33MidsqI= Received: (from ache@localhost) by nagual.pp.ru (8.14.1/8.14.1/Submit) id l6DMk8GP021919; Sat, 14 Jul 2007 02:46:08 +0400 (MSD) (envelope-from ache) Date: Sat, 14 Jul 2007 02:46:08 +0400 From: Andrey Chernov To: "Sean C. Farley" Message-ID: <20070713224608.GB21695@nagual.pp.ru> Mail-Followup-To: Andrey Chernov , "Sean C. Farley" , freebsd-current References: <20070707133102.C14065@thor.farley.org> <20070707191835.GA4368@nagual.pp.ru> <20070707205410.B14065@thor.farley.org> <20070708020940.GA80166@nagual.pp.ru> <20070708171727.GA90490@nagual.pp.ru> <20070713162742.GA16260@nagual.pp.ru> <20070713142545.K26096@thor.farley.org> <20070713202433.GA19856@nagual.pp.ru> <20070713203915.GA20270@nagual.pp.ru> <20070713171942.Q26096@thor.farley.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070713171942.Q26096@thor.farley.org> User-Agent: Mutt/1.5.16 (2007-06-09) Cc: freebsd-current Subject: Re: Environment handling broken in /bin/sh with changes to t,set,put}env() X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2007 22:46:09 -0000 On Fri, Jul 13, 2007 at 05:27:58PM -0500, Sean C. Farley wrote: > Does that mean that environ is untouched or that the environment is > unchanged? They seem to use both words (environ and environment) in the > documentation making me think they are not necessarily the same thing. > Currently, non-getenv() calls rebuilds the environ array if having never > been changed before, but the "environment" is "unchanged" if the > variable does not exist. Should that not meet that requirement? IMHO by the environment they means environ contents, not pointers, because they say: "The setenv() function shall update the list of pointers to which environ points." -- http://ache.pp.ru/ From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 22:11:21 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EEA1316A405 for ; Fri, 13 Jul 2007 22:11:21 +0000 (UTC) (envelope-from gelsemap@superhero.nl) Received: from superman.superhero.nl (superhero.nl [82.95.198.17]) by mx1.freebsd.org (Postfix) with ESMTP id 34FA813C48E for ; Fri, 13 Jul 2007 22:11:21 +0000 (UTC) (envelope-from gelsemap@superhero.nl) Received: (qmail 12061 invoked by uid 80); 13 Jul 2007 22:11:24 -0000 Received: from robin.ad.superhero.nl ([10.202.77.103]) (SquirrelMail authenticated user gelsemap) by webmail.superhero.nl with HTTP; Sat, 14 Jul 2007 00:11:23 +0200 (CEST) Message-ID: <1084.10.202.77.103.1184364683.squirrel@webmail.superhero.nl> In-Reply-To: <462CDDA5.9080304@samsco.org> References: <200704162247.29909.gelsemap@superhero.nl> <16295.195.50.100.20.1176825375.squirrel@www.superhero.nl> <4624F4C3.30006@samsco.org> <200704182222.32069.gelsemap@superhero.nl> <462684E0.20105@samsco.org> <9987.195.50.100.20.1176979371.squirrel@www.superhero.nl> <46277B98.7080007@samsco.org> <2712.195.50.100.20.1176996182.squirrel@www.superhero.nl> <462A7CCB.6020302@samsco.org> <1193.10.202.77.103.1177345281.squirrel@webmail.superhero.nl> <462CDDA5.9080304@samsco.org> Date: Sat, 14 Jul 2007 00:11:23 +0200 (CEST) From: "Gelsema, P \(Patrick\)" To: "Scott Long" User-Agent: SquirrelMail/1.4.8 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Mailman-Approved-At: Fri, 13 Jul 2007 22:50:37 +0000 Cc: "Gelsema, P \(Patrick\)" Subject: Re: Difference between 6.2 and 7.0 Adaptec 39320D - 7.0 performing less X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2007 22:11:22 -0000 On Mon, April 23, 2007 18:24, Scott Long wrote: > Gelsema, P (Patrick) wrote: >> On Sat, April 21, 2007 23:06, Scott Long wrote: >>> Gelsema, P (Patrick) wrote: >>>> On Thu, April 19, 2007 16:24, Scott Long wrote: >>>>> Gelsema, P (Patrick) wrote: >>>>>> On Wed, April 18, 2007 22:51, Scott Long wrote: >>>>>>> Gelsema, P (Patrick) wrote: >>>>>>>> On Tuesday 17 April 2007 18:24, Scott Long wrote: >>>>>>>>> Gelsema, P (Patrick) - FreeBSD wrote: >>>>>>>>>> On Tue, April 17, 2007 16:45, Scott Long wrote: >>>>>>>>>>> Gelsema, P (Patrick) - FreeBSD wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> The 39320D is a finicky card. I don't recall putting in the >>>>>>>>>>> code >>>>>>>>>>> that >>>>>>>>>>> would downshift the speed like this, but it wouldn't surprise >>>>>>>>>>> me >>>>>>>>>>> if >>>>>>>>>>> it >>>>>>>>>>> is a side effect of the system going slower. Anyways, it >>>>>>>>>>> sounds >>>>>>>>>>> like >>>>>>>>>>> you're a good candidate/victim for the MPSAFE locking changes >>>>>>>>>>> that >>>>>>>>>>> I >>>>>>>>>>> just made to the SCSI layer and the ahc/ahd drivers. Would you >>>>>>>>>>> mind >>>>>>>>>>> testing it out (just update to the latest 7-CURRENT sources) >>>>>>>>>>> and >>>>>>>>>>> let >>>>>>>>>>> me >>>>>>>>>>> know how it works for you? >>>>>>>> >>>>>>>> >>>>>>>>>> Is building world/kernel sufficient as test or do you want me to >>>>>>>>>> do >>>>>>>>>> more >>>>>>>>>> tests? >>>>>>>>> Any amount of testing that you can do is appreciated. Even >>>>>>>>> verifying >>>>>>>>> that it boots is helpful =-) >>>>>>>> Cvsupped this evening at about 6.15 UTC time (20:15 CET zone) >>>>>>>> FreeBSD hulk.superhero.nl 7.0-CURRENT FreeBSD 7.0-CURRENT #0: Wed >>>>>>>> Apr >>>>>>>> 18 >>>>>>>> 21:56:58 CEST 2007 >>>>>>>> root@hulk.superhero.nl:/usr/obj/usr/src/sys/GENERIC >>>>>>>> amd64 >>>>>>>> >>>>>>>> After buildworld and the whole lot the computer boots fine, >>>>>>>> however >>>>>>>> the >>>>>>>> disk >>>>>>>> is still detected as only 160.00MB/s. >>>>>>>> >>>>>>>> I do get the following crash. It seems to be related to pressing >>>>>>>> scroll >>>>>>>> lock >>>>>>>> on the console and hitting the page up/down buttons. When I just >>>>>>>> log >>>>>>>> on >>>>>>>> locally or remotely it seems to be ok. When I hit the scroll lock >>>>>>>> key >>>>>>>> before >>>>>>>> or after logging on I get the below crash. >>>>>>>> >>>>>>>> Apr 18 22:08:22 hulk kernel: lock order reversal: (Giant after >>>>>>>> non-sleepable) >>>>>>>> Apr 18 22:08:22 hulk kernel: 1st 0xffffff007b413358 ahd_lock >>>>>>>> (ahd_lock) >>>>>>>> @ /usr/src/sys/cam/cam_periph.c:559 >>>>>>>> Apr 18 22:08:22 hulk kernel: 2nd 0xffffffff80977f20 Giant (Giant) >>>>>>>> @ /usr/src/sys/vm/vm_contig.c:590 >>>>>>>> Apr 18 22:08:22 hulk kernel: KDB: stack backtrace: >>>>>>>> Apr 18 22:08:22 hulk kernel: db_trace_self_wrapper() at >>>>>>>> db_trace_self_wrapper+0x3a >>>>>>>> Apr 18 22:08:22 hulk kernel: witness_checkorder() at >>>>>>>> witness_checkorder+0x4f9 >>>>>>>> Apr 18 22:08:22 hulk kernel: _mtx_lock_flags() at >>>>>>>> _mtx_lock_flags+0x75 >>>>>>>> Apr 18 22:08:22 hulk kernel: contigmalloc() at contigmalloc+0x63 >>>>>>>> Apr 18 22:08:22 hulk kernel: bus_dmamem_alloc() at >>>>>>>> bus_dmamem_alloc+0x8d >>>>>>>> Apr 18 22:08:22 hulk kernel: ahd_alloc_scbs() at >>>>>>>> ahd_alloc_scbs+0x32a >>>>>>>> Apr 18 22:08:22 hulk kernel: ahd_get_scb() at ahd_get_scb+0x69 >>>>>>>> Apr 18 22:08:22 hulk kernel: ahd_action() at ahd_action+0x47c >>>>>>>> Apr 18 22:08:22 hulk kernel: xpt_run_dev_sendq() at >>>>>>>> xpt_run_dev_sendq+0x1ae >>>>>>>> Apr 18 22:08:22 hulk kernel: xpt_action() at xpt_action+0x4d3 >>>>>>>> Apr 18 22:08:22 hulk kernel: dastart() at dastart+0x211 >>>>>>>> Apr 18 22:08:22 hulk kernel: xpt_run_dev_allocq() at >>>>>>>> xpt_run_dev_allocq+0xf4 >>>>>>>> Apr 18 22:08:22 hulk kernel: dastrategy() at dastrategy+0x78 >>>>>>>> Apr 18 22:08:22 hulk kernel: g_disk_start() at g_disk_start+0xe6 >>>>>>>> Apr 18 22:08:22 hulk kernel: g_io_schedule_down() at >>>>>>>> g_io_schedule_down+0x189 >>>>>>>> Apr 18 22:08:22 hulk kernel: g_down_procbody() at >>>>>>>> g_down_procbody+0x7a >>>>>>>> Apr 18 22:08:22 hulk kernel: fork_exit() at fork_exit+0xaa >>>>>>>> Apr 18 22:08:22 hulk kernel: fork_trampoline() at >>>>>>>> fork_trampoline+0xe >>>>>>>> Apr 18 22:08:22 hulk kernel: --- trap 0, rip = 0, rsp = >>>>>>>> 0xffffffffac102d30, >>>>>>>> rbp = 0 --- >>>>>>>> >>>>>>>> Is this information sufficient? If not please let me know what >>>>>>>> more >>>>>>>> is >>>>>>>> required. >>>>>>>> >>>>>>>> Rgds, >>>>>>>> >>>>>>>> Patrick >>>>>>>> >>>>>>> Thanks for the info. Fixing this problem is going to be a royal >>>>>>> pain. >>>>>>> You can probably get around it by disabling WITNESS and INVARIANTS. >>>>>>> >>>>>>> Scott >>>>>> The computer seems to remain working even with the crash. Disabling >>>>>> WINTNESS and INVARIANTS only disables the checking but not the >>>>>> actual >>>>>> problem, is that correct? >>>>>> >>>>>> If you want I can provide you full SSH access to the box to make >>>>>> working >>>>>> on the fix of this problem easier? I am not using this box for >>>>>> anything >>>>>> else than just toying, getting a better understanding. Just let me >>>>>> know. >>>>>> HTH. >>>>>> >>>>> Thanks for the offer. I have tons of hardware, I just didn't think >>>>> to >>>>> check the adaptec drivers on amd64 specifically. On i386 they don't >>>>> trigger the warning (though they do still have the same problem) so I >>>>> didn't notice it. >>>> In case you require it later on, just let me know. It is the least I >>>> can >>>> do after bombarding you with mails ;-) >>>> >>>>>> Also the disk is still detected as only 160.00MB/s, any thought >>>>>> about >>>>>> this? >>>>>> >>>>> I'll look into this as well. Actually, it might be a result of the >>>>> simple domain validation code that was added to 7-current a while >>>>> back. >>>>> DV is both very tricky to implement and very tricky to predict in >>>>> operation, so what you're seeing might be a bug or it might be a >>>>> legitimate problem with your disk or cables. >>>> Ok. The drive is brand new, the cable a bit less. But this is >>>> something >>>> I >>>> can easily test. I got a Maxtor disk spare, I will install 7.0 on that >>>> one. Cable is going to be a bit more cumbersome as I don't have any >>>> spare. >>>> That might have to wait till late next week. >>>> >>>> Rgds, >>>> >>>> Patrick >>>> >>> Regarding the speed problem, can you try the following change? >>> >>> ==== >>> //depot/projects/scottl-camlock/src/sys/dev/aic7xxx/aic79xx_osm.c#18 - >>> /home/scottl/p4/camlock/src/sys/dev/aic7xxx/aic79xx_osm.c ==== >>> @@ -579,7 +579,7 @@ >>> } else { >>> cpi->target_sprt = 0; >>> } >>> - cpi->hba_misc = 0; >>> + cpi->hba_misc = PIM_SEQSCAN; >>> cpi->hba_eng_cnt = 0; >>> cpi->max_target = (ahd->features & AHD_WIDE) ? 15 : 7; >>> cpi->max_lun = AHD_NUM_LUNS_NONPKT - 1; >>> >>> Scott >>> >> Tested, no success. Disk still recognised at 160MB/s and half the Mhz >> (80). >> I have tested 7-Current now with 3 different Disks (all seagate brand) >> and all of them recognised with only half the speed. When I insert the >> 6.2Release they get recognised at 320MB. >> >> Rgds, >> >> Patrick >> > > Ok, I'll work on putting in a knob to turn off DV. I plan to completely > re-write the DV code anyways. Thanks for testing and helping out. I'll > let you know when I have something more to test. > > Scott > Hi Scott, Finally I was able to buy a proper SCSI cable. QUite hard to get one from the normal computershops. Anyways, I still have the same problem. Disks still recognised as 160MB instead of 320. I am also having problems now installing Current on AMD64 with 4GB of memory. Seems to be something with memoryhole. Anyways.. I did a verbose boot and I've put the results on my webserver. http://www.superhero.nl/messages Hope this helps. Also, any suggestions why I get mangled entry panics or after rebuilding world/kernel I am unable to mount the root system? I believe it has something to do with the memory hole, but am not sure.. Rgds, Patrick From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 22:56:44 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F3EF116A400 for ; Fri, 13 Jul 2007 22:56:43 +0000 (UTC) (envelope-from freebsd@superhero.nl) Received: from superman.superhero.nl (superhero.nl [82.95.198.17]) by mx1.freebsd.org (Postfix) with ESMTP id 4E0E113C494 for ; Fri, 13 Jul 2007 22:56:43 +0000 (UTC) (envelope-from freebsd@superhero.nl) Received: (qmail 12881 invoked by uid 80); 13 Jul 2007 22:30:05 -0000 Received: from robin.ad.superhero.nl ([10.202.77.103]) (SquirrelMail authenticated user gelsemap) by webmail.superhero.nl with HTTP; Sat, 14 Jul 2007 00:30:05 +0200 (CEST) Message-ID: <1185.10.202.77.103.1184365805.squirrel@webmail.superhero.nl> Date: Sat, 14 Jul 2007 00:30:05 +0200 (CEST) From: "Gelsema, P \(Patrick\) - FreeBSD" To: freebsd-current@freebsd.org User-Agent: SquirrelMail/1.4.8 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: Console output stops - machine keeps on working X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2007 22:56:44 -0000 Hi List, I've got an Asus M2N motherboard which I just upgraded to the latest available BIOS found on the Asus website. All went smooth. I am running FreeBSD 7-Current-200706. Everything seems to be detected during boot and all goes ok until the moment the message that the fxp0 link state changed to up. After that moment the console output stops. I cannot get to other tty;s or get output running again. However the machine is responsive and I can log on by SSH remotely and do everything as if I were at the console. When I login by typing blind at the console and issue the reboot command or when I press the power off button on the workstation the console shows output again (not any use as it is then rebooting or powering off). See http://www.superhero.nl/messages.txt for the message output during boot. Anyone seen this kind of behaviour? Rgds, Patrick From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 23:00:00 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 932CE16A402 for ; Fri, 13 Jul 2007 23:00:00 +0000 (UTC) (envelope-from dwhite@gumbysoft.com) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.freebsd.org (Postfix) with ESMTP id 7F4C513C474 for ; Fri, 13 Jul 2007 23:00:00 +0000 (UTC) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id 6120D72DAA; Fri, 13 Jul 2007 15:59:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id 5980872DA1; Fri, 13 Jul 2007 15:59:00 -0700 (PDT) Date: Fri, 13 Jul 2007 15:59:00 -0700 (PDT) From: Doug White To: Steve Kargl In-Reply-To: <20070712202707.GA91647@troutmask.apl.washington.edu> Message-ID: <20070713155713.F21019@carver.gumbysoft.com> References: <20070712141110.7D67756539@rebar.astron.com> <20070712114328.F4608@carver.gumbysoft.com> <499c70c0707121237vf6901b7of83d5764c6c2ca15@mail.gmail.com> <20070712202707.GA91647@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: current@freebsd.org, Abdullah Ibn Hamad Al-Marri Subject: Re: tcsh backtick hang info X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2007 23:00:00 -0000 Dropping Christos and tcsh-bugs from CC: for now. On Thu, 12 Jul 2007, Steve Kargl wrote: > On Thu, Jul 12, 2007 at 10:37:50PM +0300, Abdullah Ibn Hamad Al-Marri wrote: >> >> As for GDB, why don't you import 6.6? it's already in the ports and >> works smoothly in 7.0 and 6.2-stable as well. >> > > GDB 6.6 doesn't magically fix tcsh. As I noted in my PR followup, I wasn't able to reproduce your issue with current SVN GCC and HEAD. I'm looking for either something thats different in our environments (library versions?) or a different test case that triggers the issue on -CURRENT. Have you verified the issue still exists with current everything (including a freshened mpfr library)? -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 23:02:44 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9F4C116A401; Fri, 13 Jul 2007 23:02:44 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (nagual.pp.ru [194.87.13.69]) by mx1.freebsd.org (Postfix) with ESMTP id 1A92413C4B3; Fri, 13 Jul 2007 23:02:43 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.14.1/8.14.1) with ESMTP id l6DN2gtL022205; Sat, 14 Jul 2007 03:02:42 +0400 (MSD) (envelope-from ache@nagual.pp.ru) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nagual.pp.ru; s=default; t=1184367762; bh=OHF5dc3w+1oLpnhcQUIjtyhM7pIzBKsnPk3IEMD 7VbA=; l=676; h=Received:Date:From:To:Subject:Message-ID: Mail-Followup-To:References:MIME-Version:Content-Type: Content-Disposition:In-Reply-To:User-Agent; b=C0D2vwahJHYfAwRZFsX3 yhj7tjjF4nfprya1nBzgnVLu054+CRGFJ10IXpXO7PpH7hQ9gjfMpheltVvIIOkb2bE 5DQ+EofDbSINZu0IAsZZlaO3qQvvbPRgy29XNbpc2tNZgSao3l6FMuHOO8foqeOfDj1 ZYqDNDUrBRSxu7i14= Received: (from ache@localhost) by nagual.pp.ru (8.14.1/8.14.1/Submit) id l6DN2g8g022204; Sat, 14 Jul 2007 03:02:42 +0400 (MSD) (envelope-from ache) Date: Sat, 14 Jul 2007 03:02:41 +0400 From: Andrey Chernov To: "Sean C. Farley" , freebsd-current Message-ID: <20070713230241.GA22124@nagual.pp.ru> Mail-Followup-To: Andrey Chernov , "Sean C. Farley" , freebsd-current References: <20070707133102.C14065@thor.farley.org> <20070707191835.GA4368@nagual.pp.ru> <20070707205410.B14065@thor.farley.org> <20070708020940.GA80166@nagual.pp.ru> <20070708171727.GA90490@nagual.pp.ru> <20070713162742.GA16260@nagual.pp.ru> <20070713142545.K26096@thor.farley.org> <20070713202433.GA19856@nagual.pp.ru> <20070713152644.I26096@thor.farley.org> <20070713224053.GA21695@nagual.pp.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070713224053.GA21695@nagual.pp.ru> User-Agent: Mutt/1.5.16 (2007-06-09) Cc: Subject: Re: Environment handling broken in /bin/sh with changes to t,set,put}env() X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2007 23:02:44 -0000 On Sat, Jul 14, 2007 at 02:40:53AM +0400, Andrey Chernov wrote: > > I chose #3. Try the patch[1] again. It creates a setenv() function > > which is a wrapper around __setenv(). __setenv() takes the lengths of > > name and value to allow the caller to calculate the length using pointer > > arithmetic instead of strlen(). > > > > Sean > > 1. http://www.farley.org/freebsd/tmp/setenv/clearenv/patch > > The wrapper version finally looks OK for me. BTW, since strlen(value) is common part, you may decrease one argument to __setenv() call just passing value and doing strlen(value) inside it like before, i.e. valueLen = strlen(value); -- http://ache.pp.ru/ From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 23:09:09 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A6F7716A404; Fri, 13 Jul 2007 23:09:09 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (nagual.pp.ru [194.87.13.69]) by mx1.freebsd.org (Postfix) with ESMTP id 20EB413C461; Fri, 13 Jul 2007 23:09:08 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.14.1/8.14.1) with ESMTP id l6DN97ER022295; Sat, 14 Jul 2007 03:09:07 +0400 (MSD) (envelope-from ache@nagual.pp.ru) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nagual.pp.ru; s=default; t=1184368148; bh=OyN4fzwbOL12crGGTxE9fAcsU9WocFvk7IrgsGG j+l0=; l=734; h=Received:Date:From:To:Subject:Message-ID: Mail-Followup-To:References:MIME-Version:Content-Type: Content-Disposition:In-Reply-To:User-Agent; b=HF6Tsdq/D/n2noOx3DGk 2MMQXZB3Dsg7XSlFrd5FMijMABPyFY0PavILmXgJurHE8E74l4CNkk4KQZc7pjFAMOR VLtAe6Clw4bt23FX8q+N8cGx4FAsBnHXh2ft3HQ4K/p+WW3sVhyDNEPDiw8RPg0deF/ uGuPnLLSIyoIeXqf4= Received: (from ache@localhost) by nagual.pp.ru (8.14.1/8.14.1/Submit) id l6DN97XF022293; Sat, 14 Jul 2007 03:09:07 +0400 (MSD) (envelope-from ache) Date: Sat, 14 Jul 2007 03:09:06 +0400 From: Andrey Chernov To: "Sean C. Farley" , freebsd-current Message-ID: <20070713230906.GB22124@nagual.pp.ru> Mail-Followup-To: Andrey Chernov , "Sean C. Farley" , freebsd-current References: <20070707191835.GA4368@nagual.pp.ru> <20070707205410.B14065@thor.farley.org> <20070708020940.GA80166@nagual.pp.ru> <20070708171727.GA90490@nagual.pp.ru> <20070713162742.GA16260@nagual.pp.ru> <20070713142545.K26096@thor.farley.org> <20070713202433.GA19856@nagual.pp.ru> <20070713152644.I26096@thor.farley.org> <20070713224053.GA21695@nagual.pp.ru> <20070713230241.GA22124@nagual.pp.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070713230241.GA22124@nagual.pp.ru> User-Agent: Mutt/1.5.16 (2007-06-09) Cc: Subject: Re: Environment handling broken in /bin/sh with changes to t,set,put}env() X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2007 23:09:09 -0000 On Sat, Jul 14, 2007 at 03:02:41AM +0400, Andrey Chernov wrote: > > > Sean > > > 1. http://www.farley.org/freebsd/tmp/setenv/clearenv/patch > > > > The wrapper version finally looks OK for me. > > BTW, since strlen(value) is common part, you may decrease one argument to > __setenv() call just passing value and doing strlen(value) inside it like > before, i.e. > valueLen = strlen(value); One thing more - this is a user name space pollution because ends up into common block .global: +const char CorruptEnvFindMsg[] = "environment corrupt; unable to find %.*s"; +const char CorruptEnvValueMsg[] = "environment corrupt; missing value for %s"; Better replace with static const char ... -- http://ache.pp.ru/ From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 23:21:28 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 51F9C16A405 for ; Fri, 13 Jul 2007 23:21:28 +0000 (UTC) (envelope-from mattjreimer@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.241]) by mx1.freebsd.org (Postfix) with ESMTP id DAF6B13C481 for ; Fri, 13 Jul 2007 23:21:27 +0000 (UTC) (envelope-from mattjreimer@gmail.com) Received: by an-out-0708.google.com with SMTP id c14so156895anc for ; Fri, 13 Jul 2007 16:21:27 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Eda+KozRRbef5chF6elYaOypy/Su4THHInsUSbPKd1doVM0AKvv10yXFFTUwaZ/mvG4wEcqvhuMJMW/vKM0jc7Aa8RF/Jal3FYjbnQqLW1Xw5cQApUEPiYSrehkZ0OlzVUjZY3iAi8Qt5fY0PwhP33xqP+kI6ELTDUF+tp7geg0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=mJ+7H3ldDrcRWWdUTaM08oQMU6D8SQry20LWzIwGUkpYVLqfGlnORbyXYVMG4WN9xssW6ZBHojI1ws0UWeQfa6XT4Gz3MbxtzTzshYgsGC5kCbn5GTxmEBSFsKOs1l7Q7I3CXTJS/UvIiIV9SwH7ujRc4ZnGOQ6Qd5WyfJ4mlTk= Received: by 10.100.111.16 with SMTP id j16mr1177392anc.1184368886863; Fri, 13 Jul 2007 16:21:26 -0700 (PDT) Received: by 10.100.142.3 with HTTP; Fri, 13 Jul 2007 16:21:26 -0700 (PDT) Message-ID: Date: Fri, 13 Jul 2007 16:21:26 -0700 From: "Matt Reimer" To: "Scott Long" In-Reply-To: <4697F551.4090801@samsco.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200707131528.51396.jhb@freebsd.org> <4697F551.4090801@samsco.org> Cc: freebsd-current@freebsd.org, scottl@freebsd.org Subject: Re: arcmsr crash X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2007 23:21:28 -0000 On 7/13/07, Scott Long wrote: > Matt Reimer wrote: > > On 7/13/07, John Baldwin wrote: > >> On Tuesday 05 June 2007 05:22:38 pm Matt Reimer wrote: > >> > Once a week or so we're seeing a panic with a -current kernel built > >> > just before the gcc 4.2 import (maybe three weeks ago). The box has a > >> > Supermicro X7DBE/X7DBE+ motherboard with two Xeon 5160s, 16G RAM, and > >> > an Areca 1220 controller with eight 500G disks connected. > >> > > >> > Does this indicate that the arcmsr driver is at fault: > >> > > >> > Tracing command irq16: arcmsr0 pid 26 tid 100018 td 0xffffff040fc5b000 > >> > cpustop_handler() at cpustop_handler+0x35 > >> > ipi_nmi_handler() at ipi_nmi_handler+0x2e > >> > trap() at trap+0x365 > >> > nmi_calltrap() at nmi_calltrap+0x8 > >> > --- trap 0x13, rip = 0xffffffff8041ab11, rsp = 0xffffffffab59eff0, rbp > >> > = 0xffffffffac0a37d0 --- > >> > siocnclose() at siocnclose+0x21 > >> > sio_cnputc() at sio_cnputc+0x89 > >> > cnputc() at cnputc+0x6a > >> > putchar() at putchar+0x5f > >> > kvprintf() at kvprintf+0xd45 > >> > printf() at printf+0xe1 > >> > panic() at panic+0x145 > >> > xpt_done() at xpt_done+0x14a > >> > arcmsr_interrupt() at arcmsr_interrupt+0x2df > >> > ithread_loop() at ithread_loop+0x108 > >> > fork_exit() at fork_exit+0xaa > >> > fork_trampoline() at fork_trampoline+0xe > >> > --- trap 0, rip = 0, rsp = 0xffffffffac0a3d30, rbp = 0 --- > >> > >> Looks like it has panic'd here: > >> > >> switch (done_ccb->ccb_h.path->periph->type) { > >> case CAM_PERIPH_BIO: > >> mtx_lock(&cam_bioq_lock); > >> TAILQ_INSERT_TAIL(&cam_bioq, &done_ccb->ccb_h, > >> sim_links.tqe); > >> done_ccb->ccb_h.pinfo.index = CAM_DONEQ_INDEX; > >> mtx_unlock(&cam_bioq_lock); > >> swi_sched(cambio_ih, 0); > >> break; > >> default: > >> panic("unknown periph type %d", > >> done_ccb->ccb_h.path->periph->type); > >> } > >> > >> which should seem to indicate that, yes, it is a driver bug. > > > > That code in -CURRENT looks a bit different (cam_simq_lock instead of > > cam_bioq_lock, etc.). Is that relevant to your analysis? > > > > Matt > > The locking is different, but the problem is basically the same. Are > you using 7-CURRENT or 6.x? 7-CURRENT from right before the gcc upgrade. Matt From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 23:21:32 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 057DA16A503 for ; Fri, 13 Jul 2007 23:21:32 +0000 (UTC) (envelope-from gelsemap@superhero.nl) Received: from superman.superhero.nl (superhero.nl [82.95.198.17]) by mx1.freebsd.org (Postfix) with ESMTP id 1A3E813C4A6 for ; Fri, 13 Jul 2007 23:21:30 +0000 (UTC) (envelope-from gelsemap@superhero.nl) Received: (qmail 15271 invoked by uid 80); 13 Jul 2007 23:21:34 -0000 Received: from robin.ad.superhero.nl ([10.202.77.103]) (SquirrelMail authenticated user gelsemap) by webmail.superhero.nl with HTTP; Sat, 14 Jul 2007 01:21:34 +0200 (CEST) Message-ID: <1368.10.202.77.103.1184368894.squirrel@webmail.superhero.nl> Date: Sat, 14 Jul 2007 01:21:34 +0200 (CEST) From: "Gelsema, P \(Patrick\)" To: freebsd-current@freebsd.org User-Agent: SquirrelMail/1.4.8 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: Buildworld error: yacc: e - line 393 of "/usr/src/usr.bin/xlint/lint1/cgram.y", syntax error X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2007 23:21:32 -0000 ===> usr.bin/xlint/lint1 (obj,depend,all,install) /usr/obj/usr/src/tmp/usr/src/usr.bin/xlint/lint1 created for /usr/src/usr.bin/xlint/lint1 yacc -d -o cgram.c /usr/src/usr.bin/xlint/lint1/cgram.y lex -t /usr/src/usr.bin/xlint/lint1/scan.l > scan.c yacc: e - line 393 of "/usr/src/usr.bin/xlint/lint1/cgram.y", syntax error warning(3, ts == STRUCT ? "struct" : ^ *** Error code 1 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 I keep on having problems with installing FreeBSD on this box... considering Friday the 13th already passed. ;-D Rgds, Patrick From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 23:29:56 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 410BA16A406; Fri, 13 Jul 2007 23:29:56 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id E0A0813C471; Fri, 13 Jul 2007 23:29:55 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from scott-longs-computer.local (phobos.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.8/8.13.8) with ESMTP id l6DNTqg3018106; Fri, 13 Jul 2007 17:29:52 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <46980AE2.6070206@samsco.org> Date: Fri, 13 Jul 2007 17:29:38 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.4) Gecko/20070509 SeaMonkey/1.1.2 MIME-Version: 1.0 To: Matt Reimer References: <200707131528.51396.jhb@freebsd.org> <4697F551.4090801@samsco.org> In-Reply-To: X-Enigmail-Version: 0.95.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (pooker.samsco.org [168.103.85.57]); Fri, 13 Jul 2007 17:29:52 -0600 (MDT) X-Spam-Status: No, score=-1.4 required=5.5 tests=ALL_TRUSTED autolearn=failed version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: freebsd-current@freebsd.org Subject: Re: arcmsr crash X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2007 23:29:56 -0000 Matt Reimer wrote: > On 7/13/07, Scott Long wrote: >> Matt Reimer wrote: >> > On 7/13/07, John Baldwin wrote: >> >> On Tuesday 05 June 2007 05:22:38 pm Matt Reimer wrote: >> >> > Once a week or so we're seeing a panic with a -current kernel built >> >> > just before the gcc 4.2 import (maybe three weeks ago). The box >> has a >> >> > Supermicro X7DBE/X7DBE+ motherboard with two Xeon 5160s, 16G RAM, >> and >> >> > an Areca 1220 controller with eight 500G disks connected. >> >> > >> >> > Does this indicate that the arcmsr driver is at fault: >> >> > >> >> > Tracing command irq16: arcmsr0 pid 26 tid 100018 td >> 0xffffff040fc5b000 >> >> > cpustop_handler() at cpustop_handler+0x35 >> >> > ipi_nmi_handler() at ipi_nmi_handler+0x2e >> >> > trap() at trap+0x365 >> >> > nmi_calltrap() at nmi_calltrap+0x8 >> >> > --- trap 0x13, rip = 0xffffffff8041ab11, rsp = >> 0xffffffffab59eff0, rbp >> >> > = 0xffffffffac0a37d0 --- >> >> > siocnclose() at siocnclose+0x21 >> >> > sio_cnputc() at sio_cnputc+0x89 >> >> > cnputc() at cnputc+0x6a >> >> > putchar() at putchar+0x5f >> >> > kvprintf() at kvprintf+0xd45 >> >> > printf() at printf+0xe1 >> >> > panic() at panic+0x145 >> >> > xpt_done() at xpt_done+0x14a >> >> > arcmsr_interrupt() at arcmsr_interrupt+0x2df >> >> > ithread_loop() at ithread_loop+0x108 >> >> > fork_exit() at fork_exit+0xaa >> >> > fork_trampoline() at fork_trampoline+0xe >> >> > --- trap 0, rip = 0, rsp = 0xffffffffac0a3d30, rbp = 0 --- >> >> >> >> Looks like it has panic'd here: >> >> >> >> switch (done_ccb->ccb_h.path->periph->type) { >> >> case CAM_PERIPH_BIO: >> >> mtx_lock(&cam_bioq_lock); >> >> TAILQ_INSERT_TAIL(&cam_bioq, &done_ccb->ccb_h, >> >> sim_links.tqe); >> >> done_ccb->ccb_h.pinfo.index = CAM_DONEQ_INDEX; >> >> mtx_unlock(&cam_bioq_lock); >> >> swi_sched(cambio_ih, 0); >> >> break; >> >> default: >> >> panic("unknown periph type %d", >> >> done_ccb->ccb_h.path->periph->type); >> >> } >> >> >> >> which should seem to indicate that, yes, it is a driver bug. >> > >> > That code in -CURRENT looks a bit different (cam_simq_lock instead of >> > cam_bioq_lock, etc.). Is that relevant to your analysis? >> > >> > Matt >> >> The locking is different, but the problem is basically the same. Are >> you using 7-CURRENT or 6.x? > > 7-CURRENT from right before the gcc upgrade. > > Matt Crud.... now that I look closer, I can definitely see the locking problems in the driver. I think the locking will have to be completely overhauled. Can I use you as a guinea pig for testing? Scott From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 23:38:15 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 98B7E16A404 for ; Fri, 13 Jul 2007 23:38:15 +0000 (UTC) (envelope-from mattjreimer@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.250]) by mx1.freebsd.org (Postfix) with ESMTP id 543EE13C478 for ; Fri, 13 Jul 2007 23:38:15 +0000 (UTC) (envelope-from mattjreimer@gmail.com) Received: by an-out-0708.google.com with SMTP id c14so157533anc for ; Fri, 13 Jul 2007 16:38:14 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=YddXIDLGDBolKmyPM4ph2ZTsM7aGyS/WqmnNh8DRkywrrdFlm7jvGrS7Uk4ck6jtwo3NVy7I5WbzG68qqjvN6ho/9U9Qi0+267l9F4fswaP8DLul72k+mTOJEXnO86JSZHoWT4QZClK3ZAB8qmEf0OH7L7z9JA4ImeoOhGYmSsk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=reDP6wzvDP85rIpyovJnZvVXYM660Hnd2jHj0lnbxn5tOOxHDxwXc32Vywk5GeQt1FkOHAh8f6thLpkrKPfe9jEKXgG4PL1Qe3bP0vcwNDVIqvnAEKsCDNz8Mj+4R86/W8Q5Cd/arExFdCHq7UoFy1wfPAJ1T+RjTQYQ/6EQu3o= Received: by 10.100.153.17 with SMTP id a17mr1188861ane.1184369894390; Fri, 13 Jul 2007 16:38:14 -0700 (PDT) Received: by 10.100.142.3 with HTTP; Fri, 13 Jul 2007 16:38:14 -0700 (PDT) Message-ID: Date: Fri, 13 Jul 2007 16:38:14 -0700 From: "Matt Reimer" To: "Scott Long" In-Reply-To: <46980AE2.6070206@samsco.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200707131528.51396.jhb@freebsd.org> <4697F551.4090801@samsco.org> <46980AE2.6070206@samsco.org> Cc: freebsd-current@freebsd.org Subject: Re: arcmsr crash X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2007 23:38:15 -0000 On 7/13/07, Scott Long wrote: > Matt Reimer wrote: > > On 7/13/07, Scott Long wrote: > >> Matt Reimer wrote: > >> > On 7/13/07, John Baldwin wrote: > >> >> On Tuesday 05 June 2007 05:22:38 pm Matt Reimer wrote: > >> >> > Once a week or so we're seeing a panic with a -current kernel built > >> >> > just before the gcc 4.2 import (maybe three weeks ago). The box > >> has a > >> >> > Supermicro X7DBE/X7DBE+ motherboard with two Xeon 5160s, 16G RAM, > >> and > >> >> > an Areca 1220 controller with eight 500G disks connected. > >> >> > > >> >> > Does this indicate that the arcmsr driver is at fault: > >> >> > > >> >> > Tracing command irq16: arcmsr0 pid 26 tid 100018 td > >> 0xffffff040fc5b000 > >> >> > cpustop_handler() at cpustop_handler+0x35 > >> >> > ipi_nmi_handler() at ipi_nmi_handler+0x2e > >> >> > trap() at trap+0x365 > >> >> > nmi_calltrap() at nmi_calltrap+0x8 > >> >> > --- trap 0x13, rip = 0xffffffff8041ab11, rsp = > >> 0xffffffffab59eff0, rbp > >> >> > = 0xffffffffac0a37d0 --- > >> >> > siocnclose() at siocnclose+0x21 > >> >> > sio_cnputc() at sio_cnputc+0x89 > >> >> > cnputc() at cnputc+0x6a > >> >> > putchar() at putchar+0x5f > >> >> > kvprintf() at kvprintf+0xd45 > >> >> > printf() at printf+0xe1 > >> >> > panic() at panic+0x145 > >> >> > xpt_done() at xpt_done+0x14a > >> >> > arcmsr_interrupt() at arcmsr_interrupt+0x2df > >> >> > ithread_loop() at ithread_loop+0x108 > >> >> > fork_exit() at fork_exit+0xaa > >> >> > fork_trampoline() at fork_trampoline+0xe > >> >> > --- trap 0, rip = 0, rsp = 0xffffffffac0a3d30, rbp = 0 --- > >> >> > >> >> Looks like it has panic'd here: > >> >> > >> >> switch (done_ccb->ccb_h.path->periph->type) { > >> >> case CAM_PERIPH_BIO: > >> >> mtx_lock(&cam_bioq_lock); > >> >> TAILQ_INSERT_TAIL(&cam_bioq, &done_ccb->ccb_h, > >> >> sim_links.tqe); > >> >> done_ccb->ccb_h.pinfo.index = CAM_DONEQ_INDEX; > >> >> mtx_unlock(&cam_bioq_lock); > >> >> swi_sched(cambio_ih, 0); > >> >> break; > >> >> default: > >> >> panic("unknown periph type %d", > >> >> done_ccb->ccb_h.path->periph->type); > >> >> } > >> >> > >> >> which should seem to indicate that, yes, it is a driver bug. > >> > > >> > That code in -CURRENT looks a bit different (cam_simq_lock instead of > >> > cam_bioq_lock, etc.). Is that relevant to your analysis? > >> > > >> > Matt > >> > >> The locking is different, but the problem is basically the same. Are > >> you using 7-CURRENT or 6.x? > > > > 7-CURRENT from right before the gcc upgrade. > > > > Matt > > Crud.... now that I look closer, I can definitely see the locking > problems in the driver. I think the locking will have to be completely > overhauled. Can I use you as a guinea pig for testing? Please do! What's the gist of the problem? Matt From owner-freebsd-current@FreeBSD.ORG Sat Jul 14 00:08:56 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 44C2516A401 for ; Sat, 14 Jul 2007 00:08:56 +0000 (UTC) (envelope-from scf@FreeBSD.org) Received: from mail.farley.org (farley.org [67.64.95.201]) by mx1.freebsd.org (Postfix) with ESMTP id E037213C467 for ; Sat, 14 Jul 2007 00:08:55 +0000 (UTC) (envelope-from scf@FreeBSD.org) Received: from thor.farley.org (thor.farley.org [192.168.1.5]) by mail.farley.org (8.14.1/8.14.1) with ESMTP id l6E0AjoT057298; Fri, 13 Jul 2007 19:10:45 -0500 (CDT) (envelope-from scf@FreeBSD.org) Date: Fri, 13 Jul 2007 19:08:37 -0500 (CDT) From: "Sean C. Farley" To: Andrey Chernov In-Reply-To: <20070713224608.GB21695@nagual.pp.ru> Message-ID: <20070713184543.A26096@thor.farley.org> References: <20070707133102.C14065@thor.farley.org> <20070707191835.GA4368@nagual.pp.ru> <20070707205410.B14065@thor.farley.org> <20070708020940.GA80166@nagual.pp.ru> <20070708171727.GA90490@nagual.pp.ru> <20070713162742.GA16260@nagual.pp.ru> <20070713142545.K26096@thor.farley.org> <20070713202433.GA19856@nagual.pp.ru> <20070713203915.GA20270@nagual.pp.ru> <20070713171942.Q26096@thor.farley.org> <20070713224608.GB21695@nagual.pp.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.1 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on mail.farley.org Cc: freebsd-current Subject: Re: Environment handling broken in /bin/sh with changes to t,set,put}env() X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2007 00:08:56 -0000 On Sat, 14 Jul 2007, Andrey Chernov wrote: > On Fri, Jul 13, 2007 at 05:27:58PM -0500, Sean C. Farley wrote: >> Does that mean that environ is untouched or that the environment is >> unchanged? They seem to use both words (environ and environment) in >> the documentation making me think they are not necessarily the same >> thing. Currently, non-getenv() calls rebuilds the environ array if >> having never been changed before, but the "environment" is >> "unchanged" if the variable does not exist. Should that not meet >> that requirement? > > IMHO by the environment they means environ contents, not pointers, > because they say: > > "The setenv() function shall update the list of pointers to which > environ points." I want to make certain what you mean. Upon the first call to setenv() or unsetenv(), the environ is rebuilt. The contents are the same. Before and after execution if no data was changed, environ will look like this. The addresses to environ and to each pointer will be different. Are you saying that the addresses should not change for environ, environ[0-1] or all? environ[0] = "PATH=/bin" environ[1] = "USER=root" environ[2] = NULL I found this in the "Rationale" for getenv(): Conforming applications are required not to modify environ directly, but to use only the functions described here to manipulate the process environment as an abstract object. Thus, the implementation of the environment access functions has complete control over the data structure used to represent the environment (subject to the requirement that environ be maintained as a list of strings with embedded equal signs for applications that wish to scan the environment). This constraint allows the implementation to properly manage the memory it allocates, either by using allocated storage for all variables (copying them on the first invocation of setenv() or unsetenv()), or keeping track of which strings are currently in allocated space and which are not, via a separate table or some other means. This enables the implementation to free any allocated space used by strings (and perhaps the pointers to them) stored in environ when unsetenv() is called. A C runtime start-up procedure (that which invokes main() and perhaps initializes environ) can also initialize a flag indicating that none of the environment has yet been copied to allocated storage, or that the separate table has not yet been initialized. In fact, for higher performance of getenv(), the implementation could also maintain a separate copy of the environment in a data structure that could be searched much more quickly (such as an indexed hash table, or a binary tree), and update both it and the linear list at environ when setenv() or unsetenv() is invoked. It does not distinguish between whether or not any data changed when changing environ. It just says "first invocation of setenv() or unsetenv()". Sean -- scf@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Sat Jul 14 00:26:27 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AFC7C16A400 for ; Sat, 14 Jul 2007 00:26:27 +0000 (UTC) (envelope-from scf@FreeBSD.org) Received: from mail.farley.org (farley.org [67.64.95.201]) by mx1.freebsd.org (Postfix) with ESMTP id 7287C13C461 for ; Sat, 14 Jul 2007 00:26:27 +0000 (UTC) (envelope-from scf@FreeBSD.org) Received: from thor.farley.org (thor.farley.org [192.168.1.5]) by mail.farley.org (8.14.1/8.14.1) with ESMTP id l6E0SH19057529; Fri, 13 Jul 2007 19:28:17 -0500 (CDT) (envelope-from scf@FreeBSD.org) Date: Fri, 13 Jul 2007 19:26:09 -0500 (CDT) From: "Sean C. Farley" To: Andrey Chernov In-Reply-To: <20070713230906.GB22124@nagual.pp.ru> Message-ID: <20070713192533.B26096@thor.farley.org> References: <20070707191835.GA4368@nagual.pp.ru> <20070707205410.B14065@thor.farley.org> <20070708020940.GA80166@nagual.pp.ru> <20070708171727.GA90490@nagual.pp.ru> <20070713162742.GA16260@nagual.pp.ru> <20070713142545.K26096@thor.farley.org> <20070713202433.GA19856@nagual.pp.ru> <20070713152644.I26096@thor.farley.org> <20070713224053.GA21695@nagual.pp.ru> <20070713230241.GA22124@nagual.pp.ru> <20070713230906.GB22124@nagual.pp.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.1 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on mail.farley.org Cc: freebsd-current Subject: Re: Environment handling broken in /bin/sh with changes to t,set,put}env() X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2007 00:26:27 -0000 On Sat, 14 Jul 2007, Andrey Chernov wrote: > On Sat, Jul 14, 2007 at 03:02:41AM +0400, Andrey Chernov wrote: >>>> Sean >>>> 1. http://www.farley.org/freebsd/tmp/setenv/clearenv/patch >>> >>> The wrapper version finally looks OK for me. >> >> BTW, since strlen(value) is common part, you may decrease one >> argument to __setenv() call just passing value and doing >> strlen(value) inside it like before, i.e. >> valueLen = strlen(value); Thank you. > One thing more - this is a user name space pollution because ends up into > common block .global: > +const char CorruptEnvFindMsg[] = "environment corrupt; unable to find > %.*s"; > +const char CorruptEnvValueMsg[] = "environment corrupt; missing value for > %s"; > Better replace with > static const char ... Oops. I thought I had made them static. Fixed. Sean -- scf@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Sat Jul 14 00:41:18 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 85F7E16A408; Sat, 14 Jul 2007 00:41:18 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (nagual.pp.ru [194.87.13.69]) by mx1.freebsd.org (Postfix) with ESMTP id C7F9413C4B4; Sat, 14 Jul 2007 00:41:17 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.14.1/8.14.1) with ESMTP id l6E0fGqY024183; Sat, 14 Jul 2007 04:41:16 +0400 (MSD) (envelope-from ache@nagual.pp.ru) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nagual.pp.ru; s=default; t=1184373676; bh=bRnb1AfSPGA156CnZAa0VoS8l4axw0Ey8W5Qrso N9Lk=; l=1234; h=Received:Date:From:To:Cc:Subject:Message-ID: Mail-Followup-To:References:MIME-Version:Content-Type: Content-Disposition:In-Reply-To:User-Agent; b=Ie4uenIJxyv3ErGep0h0 v6VfaQI1+SWKfIrSUBMA6+tJRndC4g8XPUgDEweKVw0Y37H7pRXv6Mda0KoEbDmHaNT cRR2tqFcWpPB+I5c1/VThS0uz8kg89j2OXj38AHN3tiETB33NRw0fUfc1kXU1LjC5HH j7WN2M71XgauHHlRQ= Received: (from ache@localhost) by nagual.pp.ru (8.14.1/8.14.1/Submit) id l6E0fGW9024182; Sat, 14 Jul 2007 04:41:16 +0400 (MSD) (envelope-from ache) Date: Sat, 14 Jul 2007 04:41:16 +0400 From: Andrey Chernov To: "Sean C. Farley" Message-ID: <20070714004116.GA22909@nagual.pp.ru> Mail-Followup-To: Andrey Chernov , "Sean C. Farley" , freebsd-current References: <20070707205410.B14065@thor.farley.org> <20070708020940.GA80166@nagual.pp.ru> <20070708171727.GA90490@nagual.pp.ru> <20070713162742.GA16260@nagual.pp.ru> <20070713142545.K26096@thor.farley.org> <20070713202433.GA19856@nagual.pp.ru> <20070713203915.GA20270@nagual.pp.ru> <20070713171942.Q26096@thor.farley.org> <20070713224608.GB21695@nagual.pp.ru> <20070713184543.A26096@thor.farley.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070713184543.A26096@thor.farley.org> User-Agent: Mutt/1.5.16 (2007-06-09) Cc: freebsd-current Subject: Re: Environment handling broken in /bin/sh with changes to t,set,put}env() X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2007 00:41:18 -0000 On Fri, Jul 13, 2007 at 07:08:37PM -0500, Sean C. Farley wrote: > different. Are you saying that the addresses should not change for > environ, environ[0-1] or all? I try to say that *env() functions should avoid to change memory they not "own" when it is possible and feel free to change the memory they "own". What standard says is that initial copying all environ to the internal structure and changing it afterwards (exluding putenv case) is the right thing (because *env() functions "owns" that memory). To avoid even things like nenv[0] = "PATH=/bin"; setenv("PATH", "/bin", 1); fails, better way is to strdup() (i.e. copying) every string from the original environ and you already do that initially in build_env() but not do the safe way in previous merge_environ(). BTW, I find that code in build_env() very suspicious: if (environ[0] == NULL) goto SaveEnviron; ... SaveEnviron: origEnviron = environ; environ = NULL; if (envVarsTotal > 0) { ... } else rtrnVal = 0; return (rtrnVal); It ends up with environ = NULL; because envVarsTotal initialized to 0 i.e. makes from "environ[0] == NULL" case "environ == NULL" case which is different thing. -- http://ache.pp.ru/ From owner-freebsd-current@FreeBSD.ORG Sat Jul 14 01:10:51 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F0EA616A400 for ; Sat, 14 Jul 2007 01:10:51 +0000 (UTC) (envelope-from scf@FreeBSD.org) Received: from mail.farley.org (farley.org [67.64.95.201]) by mx1.freebsd.org (Postfix) with ESMTP id 9429513C4A7 for ; Sat, 14 Jul 2007 01:10:51 +0000 (UTC) (envelope-from scf@FreeBSD.org) Received: from thor.farley.org (thor.farley.org [192.168.1.5]) by mail.farley.org (8.14.1/8.14.1) with ESMTP id l6E1CftU058187; Fri, 13 Jul 2007 20:12:41 -0500 (CDT) (envelope-from scf@FreeBSD.org) Date: Fri, 13 Jul 2007 20:10:33 -0500 (CDT) From: "Sean C. Farley" To: Andrey Chernov In-Reply-To: <20070714004116.GA22909@nagual.pp.ru> Message-ID: <20070713200048.X26971@thor.farley.org> References: <20070707205410.B14065@thor.farley.org> <20070708020940.GA80166@nagual.pp.ru> <20070708171727.GA90490@nagual.pp.ru> <20070713162742.GA16260@nagual.pp.ru> <20070713142545.K26096@thor.farley.org> <20070713202433.GA19856@nagual.pp.ru> <20070713203915.GA20270@nagual.pp.ru> <20070713171942.Q26096@thor.farley.org> <20070713224608.GB21695@nagual.pp.ru> <20070713184543.A26096@thor.farley.org> <20070714004116.GA22909@nagual.pp.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.1 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on mail.farley.org Cc: freebsd-current Subject: Re: Environment handling broken in /bin/sh with changes to t,set,put}env() X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2007 01:10:52 -0000 On Sat, 14 Jul 2007, Andrey Chernov wrote: > On Fri, Jul 13, 2007 at 07:08:37PM -0500, Sean C. Farley wrote: >> different. Are you saying that the addresses should not change for >> environ, environ[0-1] or all? > > I try to say that *env() functions should avoid to change memory they > not "own" when it is possible and feel free to change the memory they > "own". > > What standard says is that initial copying all environ to the internal > structure and changing it afterwards (exluding putenv case) is the > right thing (because *env() functions "owns" that memory). > > To avoid even things like > > nenv[0] = "PATH=/bin"; > setenv("PATH", "/bin", 1); > > fails, better way is to strdup() (i.e. copying) every string from the > original environ and you already do that initially in build_env() but > not do the safe way in previous merge_environ(). OK. I thought you were saying that setenv(name, value, 0) and unsetenv(name) must not, as opposed to should not, alter environ if the name was found and not found respectively. It would require a careful change, but it would be more efficient in some cases. I would prefer to keep the code simple. At least as much as I would call it simple. :) On the bright side, keeping the current behavior of rebuilding after a non-getenv() call is safe since the program cannot assume environ is the same after such a call. For example, unsetenv(somename) will return a zero regardless if the name existed or not, therefore the program cannot assume that environ is still at the same address. > BTW, I find that code in build_env() very suspicious: > > if (environ[0] == NULL) > goto SaveEnviron; > ... > SaveEnviron: > origEnviron = environ; > environ = NULL; > if (envVarsTotal > 0) { > ... > } else > rtrnVal = 0; > > return (rtrnVal); > > It ends up with environ = NULL; because envVarsTotal initialized to 0 > i.e. makes from "environ[0] == NULL" case "environ == NULL" case > which is different thing. I changed it to return (0) if either environ or environ[0] equal NULL. The SaveEnviron label is removed as well as the (envVarsTotal > 0) check. Sean -- scf@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Sat Jul 14 01:11:07 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0B88116A401 for ; Sat, 14 Jul 2007 01:11:07 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from ns.trinitel.com (186.161.36.72.static.reverse.layeredtech.com [72.36.161.186]) by mx1.freebsd.org (Postfix) with ESMTP id D3F9213C428 for ; Sat, 14 Jul 2007 01:11:06 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from neutrino.vnode.org (r74-193-81-203.pfvlcmta01.grtntx.tl.dh.suddenlink.net [74.193.81.203]) (authenticated bits=0) by ns.trinitel.com (8.14.1/8.14.1) with ESMTP id l6E1B5X9001904 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Fri, 13 Jul 2007 20:11:06 -0500 (CDT) (envelope-from anderson@freebsd.org) Message-ID: <469822A3.80607@freebsd.org> Date: Fri, 13 Jul 2007 20:10:59 -0500 From: Eric Anderson User-Agent: Thunderbird 2.0.0.4 (X11/20070629) MIME-Version: 1.0 To: "Gelsema, P \(Patrick\) - FreeBSD" References: <1185.10.202.77.103.1184365805.squirrel@webmail.superhero.nl> In-Reply-To: <1185.10.202.77.103.1184365805.squirrel@webmail.superhero.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on ns.trinitel.com Cc: freebsd-current@freebsd.org Subject: Re: Console output stops - machine keeps on working X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2007 01:11:07 -0000 On 07/13/07 17:30, Gelsema, P (Patrick) - FreeBSD wrote: > Hi List, > > I've got an Asus M2N motherboard which I just upgraded to the latest > available BIOS found on the Asus website. All went smooth. > > I am running FreeBSD 7-Current-200706. Everything seems to be detected > during boot and all goes ok until the moment the message that the fxp0 > link state changed to up. After that moment the console output stops. I > cannot get to other tty;s or get output running again. > > However the machine is responsive and I can log on by SSH remotely and do > everything as if I were at the console. When I login by typing blind at > the console and issue the reboot command or when I press the power off > button on the workstation the console shows output again (not any use as > it is then rebooting or powering off). > > See http://www.superhero.nl/messages.txt for the message output during boot. > > Anyone seen this kind of behaviour? I have seen it before, but it was with some GEOM module (I think gjournal beta patches), and only when I was booting verbosely. If I turned off verbose booting, it never happened. I'm long past that now, so I have no recent input on it, sorry. My message is mostly a 'yea, me too, a while back'. You might try an updated -current, since there have been a few commits that *may* help, but.. I wouldn't gamble on it.. Eric From owner-freebsd-current@FreeBSD.ORG Sat Jul 14 01:43:24 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 576EA16A404; Sat, 14 Jul 2007 01:43:24 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (nagual.pp.ru [194.87.13.69]) by mx1.freebsd.org (Postfix) with ESMTP id 8AA8513C48D; Sat, 14 Jul 2007 01:43:23 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.14.1/8.14.1) with ESMTP id l6E1hM0w024846; Sat, 14 Jul 2007 05:43:22 +0400 (MSD) (envelope-from ache@nagual.pp.ru) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nagual.pp.ru; s=default; t=1184377402; bh=cqG1GgT7+17+LF0aB3isszVCX/lcICWoSAGN3lH S2X8=; l=434; h=Received:Date:From:To:Cc:Subject:Message-ID: Mail-Followup-To:References:MIME-Version:Content-Type: Content-Disposition:In-Reply-To:User-Agent; b=k6Cd/x9L1hhrDgfin21Y 6aIMF0UyppRLKjvqExfA8ZY1hVwxPI2lr3bVbnG+ESyH+QmxxCw5iYJop/gdCp6OxRX FLXKAfjzYWnulJodAa9cNxPB8wxLbBnmr7UrPDAfNBXScFRm3cioO8DCz3LC4x0XQGs KZMpbiRyYb7MJhW2c= Received: (from ache@localhost) by nagual.pp.ru (8.14.1/8.14.1/Submit) id l6E1hLVO024845; Sat, 14 Jul 2007 05:43:21 +0400 (MSD) (envelope-from ache) Date: Sat, 14 Jul 2007 05:43:20 +0400 From: Andrey Chernov To: "Sean C. Farley" Message-ID: <20070714014319.GA24701@nagual.pp.ru> Mail-Followup-To: Andrey Chernov , "Sean C. Farley" , freebsd-current References: <20070708171727.GA90490@nagual.pp.ru> <20070713162742.GA16260@nagual.pp.ru> <20070713142545.K26096@thor.farley.org> <20070713202433.GA19856@nagual.pp.ru> <20070713203915.GA20270@nagual.pp.ru> <20070713171942.Q26096@thor.farley.org> <20070713224608.GB21695@nagual.pp.ru> <20070713184543.A26096@thor.farley.org> <20070714004116.GA22909@nagual.pp.ru> <20070713200048.X26971@thor.farley.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070713200048.X26971@thor.farley.org> User-Agent: Mutt/1.5.16 (2007-06-09) Cc: freebsd-current Subject: Re: Environment handling broken in /bin/sh with changes to t,set,put}env() X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2007 01:43:24 -0000 On Fri, Jul 13, 2007 at 08:10:33PM -0500, Sean C. Farley wrote: >> It ends up with environ = NULL; because envVarsTotal initialized to 0 >> i.e. makes from "environ[0] == NULL" case "environ == NULL" case >> which is different thing. > > I changed it to return (0) if either environ or environ[0] equal NULL. > The SaveEnviron label is removed as well as the (envVarsTotal > 0) > check. Looks OK. -- http://ache.pp.ru/ From owner-freebsd-current@FreeBSD.ORG Sat Jul 14 01:46:28 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D186916A403 for ; Sat, 14 Jul 2007 01:46:28 +0000 (UTC) (envelope-from markir@paradise.net.nz) Received: from smtp3.clear.net.nz (smtp3.clear.net.nz [203.97.33.64]) by mx1.freebsd.org (Postfix) with ESMTP id A059913C471 for ; Sat, 14 Jul 2007 01:46:28 +0000 (UTC) (envelope-from markir@paradise.net.nz) Received: from zmori.markir.net (121-72-79-221.dsl.telstraclear.net [121.72.79.221]) by smtp3.clear.net.nz (CLEAR Net Mail) with ESMTP id <0JL5003PLAWE2330@smtp3.clear.net.nz> for current@freebsd.org; Sat, 14 Jul 2007 13:31:27 +1200 (NZST) Date: Sat, 14 Jul 2007 13:30:58 +1200 From: Mark Kirkwood To: current@freebsd.org Message-id: <46982752.3000508@paradise.net.nz> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit User-Agent: Thunderbird 2.0.0.0 (X11/20070613) Cc: Subject: anoncvs.FreeBSD.org problems? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2007 01:46:28 -0000 I tried to update my 7.0-current sources yesterday and today and have been having problems: Here's the repo: root # cd /usr/src root # cat CSV?Root :ext:freebsdanoncvs@anoncvs.FreeBSD.org:/home/ncvs Problem yesterday: root # cvs update -d -P Cannot access /home/ncvs/CVSROOT No such file or directory Problem today: root # cvs update -d -P ssh: connect to host anoncvs.FreeBSD.org port 22: Operation timed out Anyone else seeing this? I'll contact the host admins, but wondered if anyone else was seeing this.... Cheers Mark From owner-freebsd-current@FreeBSD.ORG Sat Jul 14 01:50:54 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 595B816A408; Sat, 14 Jul 2007 01:50:54 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from ns.trinitel.com (186.161.36.72.static.reverse.layeredtech.com [72.36.161.186]) by mx1.freebsd.org (Postfix) with ESMTP id 29D8E13C494; Sat, 14 Jul 2007 01:50:54 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from neutrino.vnode.org (r74-193-81-203.pfvlcmta01.grtntx.tl.dh.suddenlink.net [74.193.81.203]) (authenticated bits=0) by ns.trinitel.com (8.14.1/8.14.1) with ESMTP id l6E1oqDq004230 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Fri, 13 Jul 2007 20:50:53 -0500 (CDT) (envelope-from anderson@freebsd.org) Message-ID: <46982BF7.3010207@freebsd.org> Date: Fri, 13 Jul 2007 20:50:47 -0500 From: Eric Anderson User-Agent: Thunderbird 2.0.0.4 (X11/20070629) MIME-Version: 1.0 To: "Sean C. Farley" References: <200707131834.27131.h.schmalzbauer@omnisec.de> <4697CCEB.9080707@FreeBSD.org> <200707132155.43783.h.schmalzbauer@omnisec.de> <20070713172842.K26096@thor.farley.org> In-Reply-To: <20070713172842.K26096@thor.farley.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on ns.trinitel.com Cc: attilio@freebsd.org, freebsd-current@freebsd.org, Harald Schmalzbauer Subject: Re: kqemu crash (page fault) with -current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2007 01:50:54 -0000 On 07/13/07 17:29, Sean C. Farley wrote: > On Fri, 13 Jul 2007, Harald Schmalzbauer wrote: > >> I could install various OS, only when I enable -kernel-kqemu most >> installer quit with page fault. > > As a side note, I found -kernel-kqemu to be slower for me than without > it on STABLE. > > Sean Using ubench from ports on -CURRENT, I see these kinds of numbers (for CPU): Without any kqemu: 16000 -> 16800 With kqemu, kernelmode: 180000 -> 182000 With kqemu, usermode: 187000 -> 188000 RAW CPU: 202000 -> 203000 Eric From owner-freebsd-current@FreeBSD.ORG Sat Jul 14 02:26:40 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BCCB316A402; Sat, 14 Jul 2007 02:26:40 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (nagual.pp.ru [194.87.13.69]) by mx1.freebsd.org (Postfix) with ESMTP id 1F4CE13C46B; Sat, 14 Jul 2007 02:26:39 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.14.1/8.14.1) with ESMTP id l6E2QceW025383; Sat, 14 Jul 2007 06:26:38 +0400 (MSD) (envelope-from ache@nagual.pp.ru) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nagual.pp.ru; s=default; t=1184379998; bh=qVlicmtJX+jDeIXBZSMMPTUMslhZ0RUuWYbH7BS frok=; l=1222; h=Received:Date:From:To:Subject:Message-ID: Mail-Followup-To:References:MIME-Version:Content-Type: Content-Disposition:In-Reply-To:User-Agent; b=sN1Kkts7QCYDWBj0ahQW PuTBK9i2XUcCKWqKY5M/Ckh0QitMRZQaCL7BBZnP0wZZbVvQYneydjyf74dtId4CW7A vX3i5sj9MHqbVDlmMrzqYs+T9mwmx73B1J9RqLUhMdAWOt61Aop7KgGg6CdqFa/r31J cYURlIiFz79k1bcxQ= Received: (from ache@localhost) by nagual.pp.ru (8.14.1/8.14.1/Submit) id l6E2QcRU025382; Sat, 14 Jul 2007 06:26:38 +0400 (MSD) (envelope-from ache) Date: Sat, 14 Jul 2007 06:26:38 +0400 From: Andrey Chernov To: "Sean C. Farley" , freebsd-current Message-ID: <20070714022638.GA25256@nagual.pp.ru> Mail-Followup-To: Andrey Chernov , "Sean C. Farley" , freebsd-current References: <20070713162742.GA16260@nagual.pp.ru> <20070713142545.K26096@thor.farley.org> <20070713202433.GA19856@nagual.pp.ru> <20070713203915.GA20270@nagual.pp.ru> <20070713171942.Q26096@thor.farley.org> <20070713224608.GB21695@nagual.pp.ru> <20070713184543.A26096@thor.farley.org> <20070714004116.GA22909@nagual.pp.ru> <20070713200048.X26971@thor.farley.org> <20070714014319.GA24701@nagual.pp.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070714014319.GA24701@nagual.pp.ru> User-Agent: Mutt/1.5.16 (2007-06-09) Cc: Subject: Re: Environment handling broken in /bin/sh with changes to t,set,put}env() X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2007 02:26:40 -0000 On Sat, Jul 14, 2007 at 05:43:20AM +0400, Andrey Chernov wrote: > On Fri, Jul 13, 2007 at 08:10:33PM -0500, Sean C. Farley wrote: > >> It ends up with environ = NULL; because envVarsTotal initialized to 0 > >> i.e. makes from "environ[0] == NULL" case "environ == NULL" case > >> which is different thing. > > > > I changed it to return (0) if either environ or environ[0] equal NULL. > > The SaveEnviron label is removed as well as the (envVarsTotal > 0) > > check. > > Looks OK. BTW, I fear about another place on this matter, merge_environ(). Look at this example: ... some setenv's called before nenv[0] = NULL; environ = nenv; unsetenv("NONEXISTEN"); What happens to environ pointer _after_ that? unsetenv() leads to environ = watchEnviron; in the merge_environ() but this environ is never rebuilded because no single setenv() is called from merge_environ() and no rebuild_environ() is called from unsetenv() due to "NONEXISTENT" value not found. It means reassigned environ inherits stale pointers from non-rebuilded watchEnviron which not equals to environ[0] == NULL Did I miss something? The same about environ = NULL; unsetenv("NONEXISTEN"); -- http://ache.pp.ru/ From owner-freebsd-current@FreeBSD.ORG Sat Jul 14 04:26:34 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CEBF216A404 for ; Sat, 14 Jul 2007 04:26:34 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.177]) by mx1.freebsd.org (Postfix) with ESMTP id 9AC0313C441 for ; Sat, 14 Jul 2007 04:26:34 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by wa-out-1112.google.com with SMTP id j37so859961waf for ; Fri, 13 Jul 2007 21:26:34 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:received:received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=s94EmSQ+1jKjd/hbZhoDv8a1opxir6c8gHmQP/At8TOmNP8xP1dA0ACV3ki6mkmPXYyCJnoc67v1ojr1s1VXBG9XSIWHwCHvBPqCircb3SelGgnilg4VHSsxQgxmAm3evFGcV9qh4xR0lnRiANciqZ1aEtmtQQtZ2JYD+4rOTHg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=b6sMvk0xJdUEiKMGCgVmeh1qHjkISkYsWgxtB4lkADanVw4Tw3vzkhn4brGtXXRQeQd6+I8p/zRFf9vnrbmiBaaEwrcxJ7V4HLzHRZBtSoXS4G4urFwOcjLOl5rLus8fLZP9Nagrqfzdi3StEW1QPQm2XtPQLUyyMsDVWKMuDnw= Received: by 10.115.95.1 with SMTP id x1mr2262346wal.1184387194029; Fri, 13 Jul 2007 21:26:34 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTP id j7sm34569028wah.2007.07.13.21.26.30 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 13 Jul 2007 21:26:32 -0700 (PDT) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id l6E4QR7M023305 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 14 Jul 2007 13:26:27 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id l6E4QQPA023304; Sat, 14 Jul 2007 13:26:26 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Sat, 14 Jul 2007 13:26:26 +0900 From: Pyun YongHyeon To: Li-Lun Leland Wang Message-ID: <20070714042626.GA22511@cdnetworks.co.kr> References: <20070713084325.GA47351@Athena.infor.org> <20070713100829.GC17801@cdnetworks.co.kr> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Nq2Wo0NMKNjxTN9z" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@freebsd.org Subject: Re: threadlock and msk watchdog timeout X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2007 04:26:34 -0000 --Nq2Wo0NMKNjxTN9z Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Jul 13, 2007 at 09:27:00AM -0500, Li-Lun Leland Wang wrote: > On 7/13/07, Pyun YongHyeon wrote: > >Does msk(4) use shared interrupt? > >Show me the output of "vmstat -i". > > Here is the output of vmstat -i. > > interrupt total rate > irq1: atkbd0 677 1 > irq16: mskc0 uhci0 9423 15 > irq18: ehci0 uhci+ 9444 15 > irq19: atapci0++ 14362 22 > irq22: pcm0 15 0 > cpu0: timer 1251072 1995 > cpu1: timer 1251206 1995 > Total 2536199 4044 > > One thing I forgot to mention is that I've already disabled MSI on this > system. > Ok, try attached patch after adding 'hw.msk.legacy_intr="1"' to /boot/loader.conf. If you use msk(4) kernel module use kenv(1) to set the tunable. -- Regards, Pyun YongHyeon --Nq2Wo0NMKNjxTN9z Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="if_msk.legacy_intr.patch" Index: if_msk.c =================================================================== RCS file: /home/ncvs/src/sys/dev/msk/if_msk.c,v retrieving revision 1.17 diff -u -r1.17 if_msk.c --- if_msk.c 11 Jun 2007 02:00:50 -0000 1.17 +++ if_msk.c 14 Jul 2007 04:20:39 -0000 @@ -154,6 +154,8 @@ /* Tunables. */ static int msi_disable = 0; TUNABLE_INT("hw.msk.msi_disable", &msi_disable); +static int legacy_intr = 0; +TUNABLE_INT("hw.msk.legacy_intr", &legacy_intr); #define MSK_CSUM_FEATURES (CSUM_TCP | CSUM_UDP) @@ -229,6 +231,7 @@ static int msk_detach(device_t); static void msk_tick(void *); +static void msk_legacy_intr(void *); static int msk_intr(void *); static void msk_int_task(void *, int); static void msk_intr_phy(struct msk_if_softc *); @@ -1709,6 +1712,8 @@ * port cards with separate MSI messages, so for now I disable MSI * on dual port cards. */ + if (legacy_intr != 0) + msi_disable = 1; if (msic == 2 && msi_disable == 0 && sc->msk_num_port == 1 && pci_alloc_msi(dev, &msic) == 0) { if (msic == 2) { @@ -1778,18 +1783,25 @@ goto fail; } - TASK_INIT(&sc->msk_int_task, 0, msk_int_task, sc); - sc->msk_tq = taskqueue_create_fast("msk_taskq", M_WAITOK, - taskqueue_thread_enqueue, &sc->msk_tq); - taskqueue_start_threads(&sc->msk_tq, 1, PI_NET, "%s taskq", - device_get_nameunit(sc->msk_dev)); /* Hook interrupt last to avoid having to lock softc. */ - error = bus_setup_intr(dev, sc->msk_irq[0], INTR_TYPE_NET | - INTR_MPSAFE, msk_intr, NULL, sc, &sc->msk_intrhand[0]); + if (legacy_intr) + error = bus_setup_intr(dev, sc->msk_irq[0], INTR_TYPE_NET | + INTR_MPSAFE, NULL, msk_legacy_intr, sc, + &sc->msk_intrhand[0]); + else { + TASK_INIT(&sc->msk_int_task, 0, msk_int_task, sc); + sc->msk_tq = taskqueue_create_fast("msk_taskq", M_WAITOK, + taskqueue_thread_enqueue, &sc->msk_tq); + taskqueue_start_threads(&sc->msk_tq, 1, PI_NET, "%s taskq", + device_get_nameunit(sc->msk_dev)); + error = bus_setup_intr(dev, sc->msk_irq[0], INTR_TYPE_NET | + INTR_MPSAFE, msk_intr, NULL, sc, &sc->msk_intrhand[0]); + } if (error != 0) { device_printf(dev, "couldn't set up interrupt handler\n"); - taskqueue_free(sc->msk_tq); + if (legacy_intr == 0) + taskqueue_free(sc->msk_tq); sc->msk_tq = NULL; goto fail; } @@ -1892,7 +1904,7 @@ msk_status_dma_free(sc); - if (sc->msk_tq != NULL) { + if (legacy_intr == 0 && sc->msk_tq != NULL) { taskqueue_drain(sc->msk_tq, &sc->msk_int_task); taskqueue_free(sc->msk_tq); sc->msk_tq = NULL; @@ -3503,6 +3515,75 @@ return (sc->msk_stat_cons != CSR_READ_2(sc, STAT_PUT_IDX)); } +/* Legacy interrupt handler for shared interrupt. */ +static void +msk_legacy_intr(void *xsc) +{ + struct msk_softc *sc; + struct msk_if_softc *sc_if0, *sc_if1; + struct ifnet *ifp0, *ifp1; + uint32_t status; + + sc = xsc; + MSK_LOCK(sc); + + /* Reading B0_Y2_SP_ISRC2 masks further interrupts. */ + status = CSR_READ_4(sc, B0_Y2_SP_ISRC2); + if (status == 0 || status == 0xffffffff || sc->msk_suspended != 0 || + (status & sc->msk_intrmask) == 0) { + CSR_WRITE_4(sc, B0_Y2_SP_ICR, 2); + return; + } + + sc_if0 = sc->msk_if[MSK_PORT_A]; + sc_if1 = sc->msk_if[MSK_PORT_B]; + ifp0 = ifp1 = NULL; + if (sc_if0 != NULL) + ifp0 = sc_if0->msk_ifp; + if (sc_if1 != NULL) + ifp1 = sc_if1->msk_ifp; + + if ((status & Y2_IS_IRQ_PHY1) != 0 && sc_if0 != NULL) + msk_intr_phy(sc_if0); + if ((status & Y2_IS_IRQ_PHY2) != 0 && sc_if1 != NULL) + msk_intr_phy(sc_if1); + if ((status & Y2_IS_IRQ_MAC1) != 0 && sc_if0 != NULL) + msk_intr_gmac(sc_if0); + if ((status & Y2_IS_IRQ_MAC2) != 0 && sc_if1 != NULL) + msk_intr_gmac(sc_if1); + if ((status & (Y2_IS_CHK_RX1 | Y2_IS_CHK_RX2)) != 0) { + device_printf(sc->msk_dev, "Rx descriptor error\n"); + sc->msk_intrmask &= ~(Y2_IS_CHK_RX1 | Y2_IS_CHK_RX2); + CSR_WRITE_4(sc, B0_IMSK, sc->msk_intrmask); + CSR_READ_4(sc, B0_IMSK); + } + if ((status & (Y2_IS_CHK_TXA1 | Y2_IS_CHK_TXA2)) != 0) { + device_printf(sc->msk_dev, "Tx descriptor error\n"); + sc->msk_intrmask &= ~(Y2_IS_CHK_TXA1 | Y2_IS_CHK_TXA2); + CSR_WRITE_4(sc, B0_IMSK, sc->msk_intrmask); + CSR_READ_4(sc, B0_IMSK); + } + if ((status & Y2_IS_HW_ERR) != 0) + msk_intr_hwerr(sc); + + while (msk_handle_events(sc) != 0) + ; + if ((status & Y2_IS_STAT_BMU) != 0) + CSR_WRITE_4(sc, STAT_CTRL, SC_STAT_CLR_IRQ); + + /* Reenable interrupts. */ + CSR_WRITE_4(sc, B0_Y2_SP_ICR, 2); + + if (ifp0 != NULL && (ifp0->if_drv_flags & IFF_DRV_RUNNING) != 0 && + !IFQ_DRV_IS_EMPTY(&ifp0->if_snd)) + taskqueue_enqueue(taskqueue_fast, &sc_if0->msk_tx_task); + if (ifp1 != NULL && (ifp1->if_drv_flags & IFF_DRV_RUNNING) != 0 && + !IFQ_DRV_IS_EMPTY(&ifp1->if_snd)) + taskqueue_enqueue(taskqueue_fast, &sc_if1->msk_tx_task); + + MSK_UNLOCK(sc); +} + static int msk_intr(void *xsc) { --Nq2Wo0NMKNjxTN9z-- From owner-freebsd-current@FreeBSD.ORG Sat Jul 14 04:41:24 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3DD3C16A400 for ; Sat, 14 Jul 2007 04:41:24 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.freebsd.org (Postfix) with ESMTP id 053F013C4A5 for ; Sat, 14 Jul 2007 04:41:23 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.1/8.13.8) with ESMTP id l6E4dIne008428; Fri, 13 Jul 2007 21:39:18 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.1/8.13.8/Submit) id l6E4dIxc008427; Fri, 13 Jul 2007 21:39:18 -0700 (PDT) (envelope-from sgk) Date: Fri, 13 Jul 2007 21:39:18 -0700 From: Steve Kargl To: Doug White Message-ID: <20070714043918.GA8338@troutmask.apl.washington.edu> References: <20070712141110.7D67756539@rebar.astron.com> <20070712114328.F4608@carver.gumbysoft.com> <499c70c0707121237vf6901b7of83d5764c6c2ca15@mail.gmail.com> <20070712202707.GA91647@troutmask.apl.washington.edu> <20070713155713.F21019@carver.gumbysoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070713155713.F21019@carver.gumbysoft.com> User-Agent: Mutt/1.4.2.2i Cc: current@freebsd.org, Abdullah Ibn Hamad Al-Marri Subject: Re: tcsh backtick hang info X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2007 04:41:24 -0000 On Fri, Jul 13, 2007 at 03:59:00PM -0700, Doug White wrote: > Dropping Christos and tcsh-bugs from CC: for now. > > On Thu, 12 Jul 2007, Steve Kargl wrote: > > >On Thu, Jul 12, 2007 at 10:37:50PM +0300, Abdullah Ibn Hamad Al-Marri > >wrote: > >> > >>As for GDB, why don't you import 6.6? it's already in the ports and > >>works smoothly in 7.0 and 6.2-stable as well. > >> > > > >GDB 6.6 doesn't magically fix tcsh. > > As I noted in my PR followup, I wasn't able to reproduce your issue with > current SVN GCC and HEAD. I'm looking for either something thats > different in our environments (library versions?) or a different test case > that triggers the issue on -CURRENT. > > Have you verified the issue still exists with current everything > (including a freshened mpfr library)? > This has absolutely nothing to do with SVN GCC. tcsh 6.15.0 is BROKEN. In one xterm: mobile:kargl[204] cd tmp mobile:kargl[205] cat > h.c #include int main(void) { printf("hello\n"); return 0; } mobile:kargl[206] cc -o z -g h.c mobile:kargl[207] gdb z GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd"... (gdb) run Starting program: /usr/home/kargl/tmp/z ^C ^C^C^C^C^C^C^C^C ^Z Terminated In a 2nd xterm: 44 processes: 2 running, 40 sleeping, 1 stopped, 1 zombie CPU states: % user, % nice, % system, % interrupt, % idle Mem: 113M Active, 223M Inact, 91M Wired, 25M Cache, 60M Buf, 41M Free Swap: 712M Total, 19M Used, 694M Free, 2% Inuse PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU COMMAND 25340 kargl 1 107 0 5844K 3920K RUN 0:19 64.12% gdb 25341 kargl 1 101 0 4472K 1712K STOP 0:08 28.44% tcsh mobile:kargl[203] killall gdb The 'killall gdb' is the cause of the 'Terminated' message in the first xterm. You can also visit the tcsh mailing list http://mx.gw.com/pipermail/tcsh-bugs/2007-May/thread.html -- Steve From owner-freebsd-current@FreeBSD.ORG Sat Jul 14 04:42:42 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 38C2F16A401 for ; Sat, 14 Jul 2007 04:42:42 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.freebsd.org (Postfix) with ESMTP id 0305813C4BB for ; Sat, 14 Jul 2007 04:42:41 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.1/8.13.8) with ESMTP id l6E4eaFP008455; Fri, 13 Jul 2007 21:40:36 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.1/8.13.8/Submit) id l6E4eagG008454; Fri, 13 Jul 2007 21:40:36 -0700 (PDT) (envelope-from sgk) Date: Fri, 13 Jul 2007 21:40:36 -0700 From: Steve Kargl To: Mark Kirkwood Message-ID: <20070714044036.GB8338@troutmask.apl.washington.edu> References: <46982752.3000508@paradise.net.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46982752.3000508@paradise.net.nz> User-Agent: Mutt/1.4.2.2i Cc: current@freebsd.org Subject: Re: anoncvs.FreeBSD.org problems? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2007 04:42:42 -0000 On Sat, Jul 14, 2007 at 01:30:58PM +1200, Mark Kirkwood wrote: > Problem today: > > root # cvs update -d -P > ssh: connect to host anoncvs.FreeBSD.org port 22: Operation timed out > > Anyone else seeing this? I'll contact the host admins, but wondered if > anyone else was seeing this.... > anoncvs.FreeBSD.org has been broken for about 3 weeks. -- Steve From owner-freebsd-current@FreeBSD.ORG Sat Jul 14 06:15:50 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 02CFA16A409 for ; Sat, 14 Jul 2007 06:15:50 +0000 (UTC) (envelope-from philip.weaver@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.176]) by mx1.freebsd.org (Postfix) with ESMTP id CD4A813C4AC for ; Sat, 14 Jul 2007 06:15:49 +0000 (UTC) (envelope-from philip.weaver@gmail.com) Received: by wa-out-1112.google.com with SMTP id j37so887655waf for ; Fri, 13 Jul 2007 23:15:49 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; b=TSSAw8qLjE5QOU9M89Ddd4oF9QIq1BSDOrdDxFRVI0C88Cearw+UOHQMkZzCCzeOOgsrgelFAQFXwSVMK+abaNf5y1JmXbODAt3+JFFzERKUY9biuNcA0+PV8jkTjKLpJUH3n/gtB/0F1aIISbAFu0DzRUODriTw+TaL0Q41UpM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=d889/B9Nium4+8UkuwK87CNcyGAxoNM+rgyBlClUFnuUJAXMEuBamGMbUbxc54U+LN3t0dNn5KNkBhkaURRVrvJwcRWKjmnjuuQ1SXNJSlVBXxqVLamivzFfJFB/N8ykQlNP3VjWxKEWXPHOdycwFNH5ikKGrY6HmGoBrr9g5bM= Received: by 10.114.157.1 with SMTP id f1mr2318277wae.1184392133613; Fri, 13 Jul 2007 22:48:53 -0700 (PDT) Received: by 10.114.26.5 with HTTP; Fri, 13 Jul 2007 22:48:53 -0700 (PDT) Message-ID: Date: Sat, 14 Jul 2007 00:48:53 -0500 From: "Philip Weaver" To: current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: xauth package can't find libXau.so.6 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2007 06:15:50 -0000 On a fairly fresh amd64 7-current system (nothing X-related installed yet), I installed this tightvnc package: ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-7-current/net/tightvnc-1.3.8_2.tbz This pulled in libXau and xauth packages. However, whenever I run xauth (as root or not), I get this error: /libexec/ld-elf.so.1: Shared object "libXau.so.6" not found, required by "xauth" The file /usr/local/lib/libXau.so.6 does exist. I have tried removing both libXau and xauth and reinstalling the packages (I cannot install them from source because I get errors like this: /usr/bin/ld: skipping incompatible /usr/local/lib/libXau.a when searching for -lXau) This is my first post here, so I'm sorry if I didn't follow the, erm, protocol for posting :) - Phil From owner-freebsd-current@FreeBSD.ORG Sat Jul 14 06:53:53 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 22F4316A402 for ; Sat, 14 Jul 2007 06:53:53 +0000 (UTC) (envelope-from llwang@llwang.org) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.169]) by mx1.freebsd.org (Postfix) with ESMTP id B6E7813C48D for ; Sat, 14 Jul 2007 06:53:52 +0000 (UTC) (envelope-from llwang@llwang.org) Received: by ug-out-1314.google.com with SMTP id o4so775369uge for ; Fri, 13 Jul 2007 23:53:51 -0700 (PDT) Received: by 10.78.149.13 with SMTP id w13mr666515hud.1184396031119; Fri, 13 Jul 2007 23:53:51 -0700 (PDT) Received: by 10.78.121.3 with HTTP; Fri, 13 Jul 2007 23:53:51 -0700 (PDT) Message-ID: Date: Sat, 14 Jul 2007 01:53:51 -0500 From: "Li-Lun \"Leland\" Wang" Sender: llwang@llwang.org To: pyunyh@gmail.com In-Reply-To: <20070714042626.GA22511@cdnetworks.co.kr> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070713084325.GA47351@Athena.infor.org> <20070713100829.GC17801@cdnetworks.co.kr> <20070714042626.GA22511@cdnetworks.co.kr> X-Google-Sender-Auth: 62304d9b59cdf98f Cc: freebsd-current@freebsd.org Subject: Re: threadlock and msk watchdog timeout X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2007 06:53:53 -0000 On 7/13/07, Pyun YongHyeon wrote: > Ok, try attached patch after adding 'hw.msk.legacy_intr="1"' to > /boot/loader.conf. If you use msk(4) kernel module use > kenv(1) to set the tunable. The patch seems to be working. The interface hasn't hung once ever since. Thank you very much for you work. I greatly appreciate it. -- llwang From owner-freebsd-current@FreeBSD.ORG Sat Jul 14 07:07:58 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 33D5B16A402 for ; Sat, 14 Jul 2007 07:07:58 +0000 (UTC) (envelope-from waconstruct@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.183]) by mx1.freebsd.org (Postfix) with ESMTP id 0C3B413C4B2 for ; Sat, 14 Jul 2007 07:07:57 +0000 (UTC) (envelope-from waconstruct@gmail.com) Received: by wa-out-1112.google.com with SMTP id j37so902822waf for ; Sat, 14 Jul 2007 00:07:57 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=uI3KAnFRKOfcxOGZkUT45Y3/5agr+Vqa9hvlMSqiF57f4lMlVcGLmJ7fqXu05JfxU9btqTzE8tyrxU08eyGkFu7NLwGG2l7IxSWRDLxwDGrul8r9y3QyzTIzvmTBGmiFyr7Am7GqCDU2ejMnuKNzlJtJX5t707VPNfuRJAEscIQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=i3jj/X/6XZSQaXFhwF0DOIK2ds3yjcpjmK+3fLsxzSS++S9CEzW0M16TUdvAJNgMz4Jse2Q92SBaIPlMK3f6B8Kd9OdCg2NN4AX6voiktx7yGImvA9utfgEVPTwnahV/ZGF44Mrv1hY6qoRDkom87CNXq8Sgb6EXi33vC2G5wWo= Received: by 10.114.173.15 with SMTP id v15mr2328858wae.1184395309539; Fri, 13 Jul 2007 23:41:49 -0700 (PDT) Received: by 10.115.32.9 with HTTP; Fri, 13 Jul 2007 23:41:49 -0700 (PDT) Message-ID: Date: Sat, 14 Jul 2007 00:41:49 -0600 From: "Will Andrews" Sender: waconstruct@gmail.com To: current@freebsd.org In-Reply-To: <20070714044036.GB8338@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <46982752.3000508@paradise.net.nz> <20070714044036.GB8338@troutmask.apl.washington.edu> X-Google-Sender-Auth: 770d451842d98878 Cc: Subject: Re: anoncvs.FreeBSD.org problems? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2007 07:07:58 -0000 On 7/13/07, Steve Kargl wrote: > anoncvs.FreeBSD.org has been broken for about 3 weeks. It will be back soon. In the meantime, people can use anoncvs1.freebsd.org too. --Will. From owner-freebsd-current@FreeBSD.ORG Sat Jul 14 08:09:13 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id ACC9E16A408 for ; Sat, 14 Jul 2007 08:09:13 +0000 (UTC) (envelope-from aturetta@commit.it) Received: from mailbox.rainbownet.com (mailbox.logital.it [85.18.201.116]) by mx1.freebsd.org (Postfix) with ESMTP id 2F10B13C4BB for ; Sat, 14 Jul 2007 08:09:12 +0000 (UTC) (envelope-from aturetta@commit.it) Received: from 192.168.44.150 ([151.38.125.171]) (authenticated user aturetta@rainbownet.com) by rainbownet.com (mailbox.rainbownet.com [127.0.0.1]) (MDaemon.PRO.v6.8.5.R) with ESMTP id 60-md50000000085.tmp for ; Sat, 14 Jul 2007 09:57:25 +0200 Message-ID: <469881E4.3000808@commit.it> Date: Sat, 14 Jul 2007 09:57:24 +0200 From: Angelo Turetta User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated-Sender: aturetta@rainbownet.com X-Spam-Processed: mailbox.rainbownet.com, Sat, 14 Jul 2007 09:57:25 +0200 (not processed: message from valid local sender) X-MDRemoteIP: 151.38.125.171 X-Return-Path: aturetta@commit.it X-MDaemon-Deliver-To: freebsd-current@freebsd.org Subject: Build error (make related?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2007 08:09:13 -0000 This morning I'm trying to update my current system (7.0-CURRENT #14: Mon Jul 9 21:55:06 CEST 2007) and when I issue the usual #make buildworld KERNCONF="GENERIC VIDEO VIDEODBG" buildkernel after 5 seconds I get: (....) -------------------------------------------------------------- >>> stage 2.1: cleaning up the object tree -------------------------------------------------------------- cd /usr/src; MAKEOBJDIRPREFIX=/usr/obj MACHINE_ARCH=amd64 MACHINE=amd64 CPUTYPE= GROFF_BIN_PATH=/usr/obj/usr/src/tmp/legacy/usr/bin GROFF_FONT_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/groff_font GROFF_TMAC_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/tmac _SHLIBDIRPREFIX=/usr/obj/usr/src/tmp INSTALL="sh /usr/src/tools/install.sh" PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin make -f Makefile.inc1 DESTDIR=/usr/obj/usr/src/tmp par-cleandir ===> share/info (cleandir) ===> lib (cleandir) ===> lib/csu/amd64 (cleandir) rm -f crt1.o crti.o crtn.o gcrt1.o rm -f .depend GPATH GRTAGS GSYMS GTAGS ===> lib/libc (cleandir) 2 open conditionals: at line 10 (evaluated to true) at line 3 (evaluated to true) make: fatal errors encountered -- cannot continue *** Error code 1 Deleting /usr/obj/* doesn not change anything, and I already tried deleting /usr/src and re-cvsup. I've not seen any recent tinderbox error, so is there something I could try do on my part? Thanks, Angelo. From owner-freebsd-current@FreeBSD.ORG Sat Jul 14 10:07:52 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3023116A400 for ; Sat, 14 Jul 2007 10:07:52 +0000 (UTC) (envelope-from Thomas.Sparrevohn@btinternet.com) Received: from smtp801.mail.ird.yahoo.com (smtp801.mail.ird.yahoo.com [217.146.188.61]) by mx1.freebsd.org (Postfix) with SMTP id 81E7613C461 for ; Sat, 14 Jul 2007 10:07:51 +0000 (UTC) (envelope-from Thomas.Sparrevohn@btinternet.com) Received: (qmail 59678 invoked from network); 14 Jul 2007 10:07:50 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=btinternet.com; h=Received:X-YMail-OSG:From:To:Subject:Date:User-Agent:Cc:References:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Content-Disposition:Message-Id; b=K0jt/SCXFXvYOKKEWBh7zI7oUDra/YKsZcz2nIUSm8Z+0B+Kg9/hfyVt1FhnFblsPmGIYOFmC7jgoFytEs2qgl8n0xcyZ1Wl2leFts7hIopbMfVmV13h7GiNOQAOOGFYcmbCvKAevmy6h6a68iRNm7/thhcr+BiCWEqgnvfJaho= ; Received: from unknown (HELO w2fzz0vc03.aah-go-on.com) (thomas.sparrevohn@btinternet.com@86.148.49.61 with login) by smtp801.mail.ird.yahoo.com with SMTP; 14 Jul 2007 10:07:49 -0000 X-YMail-OSG: CZmkBIYVM1lwKDTq6HQkEFtr4clkCEPKOzcdiwBCFVsYmCzQ6ejoVp8mYGzAyP9Lp4BYw8tjig-- From: Thomas Sparrevohn To: freebsd-current@freebsd.org Date: Sat, 14 Jul 2007 11:07:48 +0100 User-Agent: KMail/1.9.7 References: <4697F753.5060304@vwsoft.com> <20070713221854.GC44766@dan.emsphone.com> <4698005B.3010100@vwsoft.com> In-Reply-To: <4698005B.3010100@vwsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200707141107.48714.Thomas.Sparrevohn@btinternet.com> Cc: Volker , Dan Nelson , current@freebsd.org Subject: Re: zfs refuses to load pool on boot, zpool denies import X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2007 10:07:52 -0000 On Friday 13 July 2007 23:44:43 Volker wrote: > damned... that's it. Thanks a lot. I was wondering about that because > I've already seen a system uuid in kenv (only checked > smbios.system.uuid) while in single user mode so I did not see the > need to manually fire `/etc/rc.d/hostid start'. > > This may be taken into the documentation - I guess more will step into > this. > > Or what about checking the hostid before doing any `zpool create | > import' and refuse operation (with a useful hint to the operator) if > hostid is 0x0? > I got burned by that one as well - I am vondering if ZFS should check system.uuid as a fall back - It does not seem correct that we have to run specific startup shell scripts in order to get a filesystem to work From owner-freebsd-current@FreeBSD.ORG Sat Jul 14 10:34:32 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5377116A405 for ; Sat, 14 Jul 2007 10:34:32 +0000 (UTC) (envelope-from Thomas.Sparrevohn@btinternet.com) Received: from smtp801.mail.ird.yahoo.com (smtp801.mail.ird.yahoo.com [217.146.188.61]) by mx1.freebsd.org (Postfix) with SMTP id A48DF13C481 for ; Sat, 14 Jul 2007 10:34:31 +0000 (UTC) (envelope-from Thomas.Sparrevohn@btinternet.com) Received: (qmail 59678 invoked from network); 14 Jul 2007 10:07:50 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=btinternet.com; h=Received:X-YMail-OSG:From:To:Subject:Date:User-Agent:Cc:References:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Content-Disposition:Message-Id; b=K0jt/SCXFXvYOKKEWBh7zI7oUDra/YKsZcz2nIUSm8Z+0B+Kg9/hfyVt1FhnFblsPmGIYOFmC7jgoFytEs2qgl8n0xcyZ1Wl2leFts7hIopbMfVmV13h7GiNOQAOOGFYcmbCvKAevmy6h6a68iRNm7/thhcr+BiCWEqgnvfJaho= ; Received: from unknown (HELO w2fzz0vc03.aah-go-on.com) (thomas.sparrevohn@btinternet.com@86.148.49.61 with login) by smtp801.mail.ird.yahoo.com with SMTP; 14 Jul 2007 10:07:49 -0000 X-YMail-OSG: CZmkBIYVM1lwKDTq6HQkEFtr4clkCEPKOzcdiwBCFVsYmCzQ6ejoVp8mYGzAyP9Lp4BYw8tjig-- From: Thomas Sparrevohn To: freebsd-current@freebsd.org Date: Sat, 14 Jul 2007 11:07:48 +0100 User-Agent: KMail/1.9.7 References: <4697F753.5060304@vwsoft.com> <20070713221854.GC44766@dan.emsphone.com> <4698005B.3010100@vwsoft.com> In-Reply-To: <4698005B.3010100@vwsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200707141107.48714.Thomas.Sparrevohn@btinternet.com> Cc: Volker , Dan Nelson , current@freebsd.org Subject: Re: zfs refuses to load pool on boot, zpool denies import X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2007 10:34:32 -0000 On Friday 13 July 2007 23:44:43 Volker wrote: > damned... that's it. Thanks a lot. I was wondering about that because > I've already seen a system uuid in kenv (only checked > smbios.system.uuid) while in single user mode so I did not see the > need to manually fire `/etc/rc.d/hostid start'. > > This may be taken into the documentation - I guess more will step into > this. > > Or what about checking the hostid before doing any `zpool create | > import' and refuse operation (with a useful hint to the operator) if > hostid is 0x0? > I got burned by that one as well - I am vondering if ZFS should check system.uuid as a fall back - It does not seem correct that we have to run specific startup shell scripts in order to get a filesystem to work From owner-freebsd-current@FreeBSD.ORG Sat Jul 14 11:16:44 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D902216A402; Sat, 14 Jul 2007 11:16:44 +0000 (UTC) (envelope-from simon@zaphod.nitro.dk) Received: from mx.nitro.dk (zarniwoop.nitro.dk [83.92.207.38]) by mx1.freebsd.org (Postfix) with ESMTP id 918CF13C47E; Sat, 14 Jul 2007 11:16:44 +0000 (UTC) (envelope-from simon@zaphod.nitro.dk) Received: from zaphod.nitro.dk (unknown [192.168.3.39]) by mx.nitro.dk (Postfix) with ESMTP id A49DC2D60E8; Sat, 14 Jul 2007 11:00:17 +0000 (UTC) Received: by zaphod.nitro.dk (Postfix, from userid 3000) id 607411145C; Sat, 14 Jul 2007 13:00:17 +0200 (CEST) Date: Sat, 14 Jul 2007 13:00:17 +0200 From: "Simon L. Nielsen" To: Joe Marcus Clarke Message-ID: <20070714110016.GA999@zaphod.nitro.dk> References: <469504D2.8000200@errno.com> <46951B50.3020601@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46951B50.3020601@FreeBSD.org> User-Agent: Mutt/1.5.16 (2007-06-09) Cc: freebsd-current@FreeBSD.org Subject: Re: HEADSUP: new wpa_supplicant and hostapd [ndis users read] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2007 11:16:44 -0000 On 2007.07.11 14:02:56 -0400, Joe Marcus Clarke wrote: > Sam Leffler wrote: > > These applications have been updated to the 0.5.8 "stable release" from > > Jouni Malinen. This gets us back on Jouni's stable release branch (as > > opposed to the abandoned code base we were using). There are many new > > features (read the docs in contrib) and you should now be able to use > > 802.1x over wired nic's though it may not be configured by default > > (please send patches after testing and I will try stuff updated). > > > > ndis support in wpa_supplicant has been tested but requires fixups in > > the kernel that are pending. However people using ndis should also be > > aware that the in-kernel ndis support has badly rotted and appears > > chock-a-block with issues. Unless someone steps up to work on it expect > > instability. Thanks to Andrew Thompson for patching things up. > > Are there plans to add the patch to the base system OpenSSL needed to > enable EAP-FAST? This would greatly help me at work. Which patch do you mean? While I don't have a problem with taking stuff off the vendor branch if needed, I general I prefer not to change OpenSSL unless there is a good reason (critical bugs, security issues etc). -- Simon L. Nielsen Hat: OpenSSL Janitor From owner-freebsd-current@FreeBSD.ORG Sat Jul 14 12:12:47 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 96D8116A407; Sat, 14 Jul 2007 12:12:47 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 4688C13C4AA; Sat, 14 Jul 2007 12:12:47 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.13.8/8.13.8) with ESMTP id l6ECCkP9014044; Sat, 14 Jul 2007 08:12:46 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.8/8.13.8) with ESMTP id l6ECCkBI056028; Sat, 14 Jul 2007 08:12:46 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id E809A73068; Sat, 14 Jul 2007 08:12:45 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070714121245.E809A73068@freebsd-current.sentex.ca> Date: Sat, 14 Jul 2007 08:12:45 -0400 (EDT) X-Virus-Scanned: ClamAV version devel-20070108, clamav-milter version devel-111206 on clamscanner2 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2007 12:12:47 -0000 TB --- 2007-07-14 10:15:00 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-07-14 10:15:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2007-07-14 10:15:00 - cleaning the object tree TB --- 2007-07-14 10:15:38 - checking out the source tree TB --- 2007-07-14 10:15:38 - cd /tinderbox/HEAD/amd64/amd64 TB --- 2007-07-14 10:15:38 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-07-14 10:26:53 - building world (CFLAGS=-O2 -pipe) TB --- 2007-07-14 10:26:53 - cd /src TB --- 2007-07-14 10:26:53 - /usr/bin/make -B buildworld >>> World build started on Sat Jul 14 10:26:55 UTC 2007 >>> 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 Sat Jul 14 12:12:44 UTC 2007 TB --- 2007-07-14 12:12:45 - generating LINT kernel config TB --- 2007-07-14 12:12:45 - cd /src/sys/amd64/conf TB --- 2007-07-14 12:12:45 - /usr/bin/make -B LINT TB --- 2007-07-14 12:12:45 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-07-14 12:12:45 - cd /src TB --- 2007-07-14 12:12:45 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Jul 14 12:12:45 UTC 2007 >>> stage 1: configuring the kernel -------------------------------------------------------------- cd /src/sys/amd64/conf; PATH=/obj/amd64/src/tmp/legacy/usr/sbin:/obj/amd64/src/tmp/legacy/usr/bin:/obj/amd64/src/tmp/legacy/usr/games:/obj/amd64/src/tmp/usr/sbin:/obj/amd64/src/tmp/usr/bin:/obj/amd64/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin config -d /obj/amd64/src/sys/LINT /src/sys/amd64/conf/LINT WARNING: duplicate option `GEOM_BSD' encountered. WARNING: duplicate option `GEOM_MBR' encountered. WARNING: duplicate option `DEV_MEM' encountered. WARNING: duplicate device `mem' encountered. WARNING: duplicate option `DEV_ISA' encountered. WARNING: duplicate device `isa' encountered. /src/sys/amd64/conf/LINT: unknown option "SCTP_HIGH_SPEED" *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-07-14 12:12:45 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-07-14 12:12:45 - ERROR: failed to build lint kernel TB --- 2007-07-14 12:12:45 - tinderbox aborted TB --- 0.91 user 3.77 system 7064.93 real http://tinderbox.des.no/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Sat Jul 14 13:05:34 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5E8A016A401; Sat, 14 Jul 2007 13:05:34 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 0DF1F13C467; Sat, 14 Jul 2007 13:05:33 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.13.8/8.13.8) with ESMTP id l6ED5XhW016373; Sat, 14 Jul 2007 09:05:33 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.8/8.13.8) with ESMTP id l6ED5Xcp065539; Sat, 14 Jul 2007 09:05:33 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 3613873068; Sat, 14 Jul 2007 09:05:33 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070714130533.3613873068@freebsd-current.sentex.ca> Date: Sat, 14 Jul 2007 09:05:33 -0400 (EDT) X-Virus-Scanned: ClamAV version devel-20070108, clamav-milter version devel-111206 on news X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2007 13:05:34 -0000 TB --- 2007-07-14 11:39:09 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-07-14 11:39:09 - starting HEAD tinderbox run for i386/i386 TB --- 2007-07-14 11:39:09 - cleaning the object tree TB --- 2007-07-14 11:39:44 - checking out the source tree TB --- 2007-07-14 11:39:44 - cd /tinderbox/HEAD/i386/i386 TB --- 2007-07-14 11:39:44 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-07-14 11:48:39 - building world (CFLAGS=-O2 -pipe) TB --- 2007-07-14 11:48:39 - cd /src TB --- 2007-07-14 11:48:39 - /usr/bin/make -B buildworld >>> World build started on Sat Jul 14 11:48:40 UTC 2007 >>> 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 Sat Jul 14 13:05:32 UTC 2007 TB --- 2007-07-14 13:05:32 - generating LINT kernel config TB --- 2007-07-14 13:05:32 - cd /src/sys/i386/conf TB --- 2007-07-14 13:05:32 - /usr/bin/make -B LINT TB --- 2007-07-14 13:05:32 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-07-14 13:05:32 - cd /src TB --- 2007-07-14 13:05:32 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Jul 14 13:05:32 UTC 2007 >>> stage 1: configuring the kernel [...] WARNING: duplicate option `GEOM_MBR' encountered. WARNING: duplicate option `DEV_MEM' encountered. WARNING: duplicate device `mem' encountered. WARNING: duplicate option `DEV_ISA' encountered. WARNING: duplicate device `isa' encountered. WARNING: duplicate option `DEV_NPX' encountered. WARNING: duplicate device `npx' encountered. /src/sys/i386/conf/LINT: unknown option "SCTP_HIGH_SPEED" *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-07-14 13:05:32 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-07-14 13:05:32 - ERROR: failed to build lint kernel TB --- 2007-07-14 13:05:32 - tinderbox aborted TB --- 0.87 user 3.02 system 5183.97 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Sat Jul 14 13:36:24 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8A38B16A400; Sat, 14 Jul 2007 13:36:24 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 3A19713C442; Sat, 14 Jul 2007 13:36:24 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.13.8/8.13.8) with ESMTP id l6EDaNqf019022; Sat, 14 Jul 2007 09:36:23 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.8/8.13.8) with ESMTP id l6EDaN77030612; Sat, 14 Jul 2007 09:36:23 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 39C0B73068; Sat, 14 Jul 2007 09:36:23 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070714133623.39C0B73068@freebsd-current.sentex.ca> Date: Sat, 14 Jul 2007 09:36:23 -0400 (EDT) X-Virus-Scanned: ClamAV version devel-20070108, clamav-milter version devel-111206 on news X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2007 13:36:24 -0000 TB --- 2007-07-14 12:12:45 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-07-14 12:12:45 - starting HEAD tinderbox run for i386/pc98 TB --- 2007-07-14 12:12:46 - cleaning the object tree TB --- 2007-07-14 12:13:15 - checking out the source tree TB --- 2007-07-14 12:13:15 - cd /tinderbox/HEAD/i386/pc98 TB --- 2007-07-14 12:13:15 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-07-14 12:21:05 - building world (CFLAGS=-O2 -pipe) TB --- 2007-07-14 12:21:05 - cd /src TB --- 2007-07-14 12:21:05 - /usr/bin/make -B buildworld >>> World build started on Sat Jul 14 12:21:06 UTC 2007 >>> 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 Sat Jul 14 13:36:22 UTC 2007 TB --- 2007-07-14 13:36:22 - generating LINT kernel config TB --- 2007-07-14 13:36:22 - cd /src/sys/pc98/conf TB --- 2007-07-14 13:36:22 - /usr/bin/make -B LINT TB --- 2007-07-14 13:36:22 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-07-14 13:36:22 - cd /src TB --- 2007-07-14 13:36:22 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Jul 14 13:36:22 UTC 2007 >>> stage 1: configuring the kernel [...] WARNING: duplicate option `GEOM_PC98' encountered. WARNING: duplicate option `DEV_MEM' encountered. WARNING: duplicate device `mem' encountered. WARNING: duplicate option `DEV_ISA' encountered. WARNING: duplicate device `isa' encountered. WARNING: duplicate option `DEV_NPX' encountered. WARNING: duplicate device `npx' encountered. /src/sys/pc98/conf/LINT: unknown option "SCTP_HIGH_SPEED" *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-07-14 13:36:22 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-07-14 13:36:22 - ERROR: failed to build lint kernel TB --- 2007-07-14 13:36:22 - tinderbox aborted TB --- 0.91 user 2.81 system 5016.95 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Sat Jul 14 14:52:51 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0E47C16A51A; Sat, 14 Jul 2007 14:52:51 +0000 (UTC) (envelope-from dan@dan.emsphone.com) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.freebsd.org (Postfix) with ESMTP id 8D89813C48D; Sat, 14 Jul 2007 14:52:27 +0000 (UTC) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.14.1/8.13.8) id l6EEqJnR002629; Sat, 14 Jul 2007 09:52:19 -0500 (CDT) (envelope-from dan) Date: Sat, 14 Jul 2007 09:52:19 -0500 From: Dan Nelson To: Thomas Sparrevohn Message-ID: <20070714145219.GH44766@dan.emsphone.com> References: <4697F753.5060304@vwsoft.com> <20070713221854.GC44766@dan.emsphone.com> <4698005B.3010100@vwsoft.com> <200707141107.48714.Thomas.Sparrevohn@btinternet.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200707141107.48714.Thomas.Sparrevohn@btinternet.com> X-OS: FreeBSD 7.0-CURRENT User-Agent: Mutt/1.5.16 (2007-06-09) Cc: Volker , freebsd-current@freebsd.org, current@freebsd.org Subject: Re: zfs refuses to load pool on boot, zpool denies import X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2007 14:52:51 -0000 In the last episode (Jul 14), Thomas Sparrevohn said: > On Friday 13 July 2007 23:44:43 Volker wrote: > > damned... that's it. Thanks a lot. I was wondering about that > > because I've already seen a system uuid in kenv (only checked > > smbios.system.uuid) while in single user mode so I did not see the > > need to manually fire `/etc/rc.d/hostid start'. > > > > This may be taken into the documentation - I guess more will step into > > this. > > > > Or what about checking the hostid before doing any `zpool create | > > import' and refuse operation (with a useful hint to the operator) if > > hostid is 0x0? That would be useful.. > I got burned by that one as well - I am vondering if ZFS should check > system.uuid as a fall back - It does not seem correct that we have to > run specific startup shell scripts in order to get a filesystem to > work Might work in some cases, but none of my systems have the system.uuid kenv. I'm not even sure how my zfs root volume gets mounted; the kernel has to mount it to even find init, so it does blindly mount zpools in some cases. Maybe the kernl mount logic assumes if it can only see one zpool, it's got to be the right one? :) -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-current@FreeBSD.ORG Sat Jul 14 14:52:51 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0E47C16A51A; Sat, 14 Jul 2007 14:52:51 +0000 (UTC) (envelope-from dan@dan.emsphone.com) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.freebsd.org (Postfix) with ESMTP id 8D89813C48D; Sat, 14 Jul 2007 14:52:27 +0000 (UTC) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.14.1/8.13.8) id l6EEqJnR002629; Sat, 14 Jul 2007 09:52:19 -0500 (CDT) (envelope-from dan) Date: Sat, 14 Jul 2007 09:52:19 -0500 From: Dan Nelson To: Thomas Sparrevohn Message-ID: <20070714145219.GH44766@dan.emsphone.com> References: <4697F753.5060304@vwsoft.com> <20070713221854.GC44766@dan.emsphone.com> <4698005B.3010100@vwsoft.com> <200707141107.48714.Thomas.Sparrevohn@btinternet.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200707141107.48714.Thomas.Sparrevohn@btinternet.com> X-OS: FreeBSD 7.0-CURRENT User-Agent: Mutt/1.5.16 (2007-06-09) Cc: Volker , freebsd-current@freebsd.org, current@freebsd.org Subject: Re: zfs refuses to load pool on boot, zpool denies import X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2007 14:52:51 -0000 In the last episode (Jul 14), Thomas Sparrevohn said: > On Friday 13 July 2007 23:44:43 Volker wrote: > > damned... that's it. Thanks a lot. I was wondering about that > > because I've already seen a system uuid in kenv (only checked > > smbios.system.uuid) while in single user mode so I did not see the > > need to manually fire `/etc/rc.d/hostid start'. > > > > This may be taken into the documentation - I guess more will step into > > this. > > > > Or what about checking the hostid before doing any `zpool create | > > import' and refuse operation (with a useful hint to the operator) if > > hostid is 0x0? That would be useful.. > I got burned by that one as well - I am vondering if ZFS should check > system.uuid as a fall back - It does not seem correct that we have to > run specific startup shell scripts in order to get a filesystem to > work Might work in some cases, but none of my systems have the system.uuid kenv. I'm not even sure how my zfs root volume gets mounted; the kernel has to mount it to even find init, so it does blindly mount zpools in some cases. Maybe the kernl mount logic assumes if it can only see one zpool, it's got to be the right one? :) -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-current@FreeBSD.ORG Sat Jul 14 14:54:57 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1324E16A403; Sat, 14 Jul 2007 14:54:57 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id A9FAA13C4BD; Sat, 14 Jul 2007 14:54:56 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.13.8/8.13.8) with ESMTP id l6EEsuFt022831; Sat, 14 Jul 2007 10:54:56 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.8/8.13.8) with ESMTP id l6EEsuZl098066; Sat, 14 Jul 2007 10:54:56 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id C385373068; Sat, 14 Jul 2007 10:54:55 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070714145455.C385373068@freebsd-current.sentex.ca> Date: Sat, 14 Jul 2007 10:54:55 -0400 (EDT) X-Virus-Scanned: ClamAV version devel-20070108, clamav-milter version devel-111206 on clamscanner2 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2007 14:54:57 -0000 TB --- 2007-07-14 13:05:33 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-07-14 13:05:33 - starting HEAD tinderbox run for ia64/ia64 TB --- 2007-07-14 13:05:33 - cleaning the object tree TB --- 2007-07-14 13:06:05 - checking out the source tree TB --- 2007-07-14 13:06:05 - cd /tinderbox/HEAD/ia64/ia64 TB --- 2007-07-14 13:06:05 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-07-14 13:13:28 - building world (CFLAGS=-O2 -pipe) TB --- 2007-07-14 13:13:28 - cd /src TB --- 2007-07-14 13:13:28 - /usr/bin/make -B buildworld >>> World build started on Sat Jul 14 13:13:30 UTC 2007 >>> 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 Sat Jul 14 14:54:54 UTC 2007 TB --- 2007-07-14 14:54:54 - generating LINT kernel config TB --- 2007-07-14 14:54:54 - cd /src/sys/ia64/conf TB --- 2007-07-14 14:54:54 - /usr/bin/make -B LINT TB --- 2007-07-14 14:54:54 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-07-14 14:54:54 - cd /src TB --- 2007-07-14 14:54:54 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Jul 14 14:54:55 UTC 2007 >>> stage 1: configuring the kernel [...] WARNING: duplicate option `GEOM_BSD' encountered. WARNING: duplicate option `GEOM_PART_GPT' encountered. WARNING: duplicate option `GEOM_PART_MBR' encountered. WARNING: duplicate option `DEV_MEM' encountered. WARNING: duplicate device `mem' encountered. WARNING: duplicate option `DEV_ACPI' encountered. WARNING: duplicate device `acpi' encountered. /src/sys/ia64/conf/LINT: unknown option "SCTP_HIGH_SPEED" *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-07-14 14:54:55 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-07-14 14:54:55 - ERROR: failed to build lint kernel TB --- 2007-07-14 14:54:55 - tinderbox aborted TB --- 0.71 user 2.71 system 6562.27 real http://tinderbox.des.no/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Sat Jul 14 15:01:18 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8008416A402; Sat, 14 Jul 2007 15:01:18 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 2E64E13C4B5; Sat, 14 Jul 2007 15:01:18 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.13.8/8.13.8) with ESMTP id l6EF1HNf023155; Sat, 14 Jul 2007 11:01:17 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.8/8.13.8) with ESMTP id l6EF1Hj6011573; Sat, 14 Jul 2007 11:01:17 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 4FA1973068; Sat, 14 Jul 2007 11:01:17 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070714150117.4FA1973068@freebsd-current.sentex.ca> Date: Sat, 14 Jul 2007 11:01:17 -0400 (EDT) X-Virus-Scanned: ClamAV version devel-20070108, clamav-milter version devel-111206 on clamscanner2 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2007 15:01:18 -0000 TB --- 2007-07-14 13:36:23 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-07-14 13:36:23 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2007-07-14 13:36:23 - cleaning the object tree TB --- 2007-07-14 13:36:44 - checking out the source tree TB --- 2007-07-14 13:36:44 - cd /tinderbox/HEAD/powerpc/powerpc TB --- 2007-07-14 13:36:44 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-07-14 13:44:46 - building world (CFLAGS=-O2 -pipe) TB --- 2007-07-14 13:44:46 - cd /src TB --- 2007-07-14 13:44:46 - /usr/bin/make -B buildworld >>> World build started on Sat Jul 14 13:44:47 UTC 2007 >>> 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 Sat Jul 14 15:01:16 UTC 2007 TB --- 2007-07-14 15:01:16 - generating LINT kernel config TB --- 2007-07-14 15:01:16 - cd /src/sys/powerpc/conf TB --- 2007-07-14 15:01:16 - /usr/bin/make -B LINT TB --- 2007-07-14 15:01:16 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-07-14 15:01:16 - cd /src TB --- 2007-07-14 15:01:16 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Jul 14 15:01:16 UTC 2007 >>> stage 1: configuring the kernel -------------------------------------------------------------- cd /src/sys/powerpc/conf; PATH=/obj/powerpc/src/tmp/legacy/usr/sbin:/obj/powerpc/src/tmp/legacy/usr/bin:/obj/powerpc/src/tmp/legacy/usr/games:/obj/powerpc/src/tmp/usr/sbin:/obj/powerpc/src/tmp/usr/bin:/obj/powerpc/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin config -d /obj/powerpc/src/sys/LINT /src/sys/powerpc/conf/LINT WARNING: duplicate option `GEOM_PART_APM' encountered. WARNING: duplicate option `GEOM_PART_MBR' encountered. WARNING: duplicate option `DEV_MEM' encountered. WARNING: duplicate device `mem' encountered. /src/sys/powerpc/conf/LINT: unknown option "SCTP_HIGH_SPEED" *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-07-14 15:01:17 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-07-14 15:01:17 - ERROR: failed to build lint kernel TB --- 2007-07-14 15:01:17 - tinderbox aborted TB --- 0.81 user 2.43 system 5093.99 real http://tinderbox.des.no/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Sat Jul 14 15:12:59 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 32E2A16A402 for ; Sat, 14 Jul 2007 15:12:59 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.173]) by mx1.freebsd.org (Postfix) with ESMTP id B72E513C441 for ; Sat, 14 Jul 2007 15:12:58 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by ug-out-1314.google.com with SMTP id o4so824976uge for ; Sat, 14 Jul 2007 08:12:57 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:reply-to:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding:sender; b=A3HLEoUAgYxwhLpknno8x90/lj34yPAbzaskcYQQu3PIAOSvaqR8HGKPL4MyXhHUlJl0CP42edeK5sdPSz38RHYnnrfEH1u9gAXRNFOB5fDAc9qMCgIe0Q3CATQ4gNwgYk+0YqSl2xYv17gEBIm78IBCuj+vlEu5Kjcs59fH5uE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:reply-to:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding:sender; b=GCDqbTjzdYneJm+konzscs+1VstFDVgquAK2TQji2aogTI5PaDHPfvaEJgak/RTRkmIZfXQ4emmEjOb7xIfbpLcWI43ipSD2q0LTiMVfpgMLXPPYsVcKY6CJZFQCUZLBx2m7vdrwqkf2svvpP/AEOY8NP3CWXjXPUm6ISfFumzk= Received: by 10.66.236.13 with SMTP id j13mr2842017ugh.1184425977599; Sat, 14 Jul 2007 08:12:57 -0700 (PDT) Received: from ?151.75.207.4? ( [151.75.207.4]) by mx.google.com with ESMTP id 5sm22484458nfv.2007.07.14.08.12.53 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 14 Jul 2007 08:12:57 -0700 (PDT) Message-ID: <4698E7C4.9080001@FreeBSD.org> Date: Sat, 14 Jul 2007 17:12:04 +0200 From: Attilio Rao User-Agent: Thunderbird 1.5 (X11/20060526) MIME-Version: 1.0 To: Harald Schmalzbauer References: <200707131834.27131.h.schmalzbauer@omnisec.de> <4697CCEB.9080707@FreeBSD.org> <200707132155.43783.h.schmalzbauer@omnisec.de> In-Reply-To: <200707132155.43783.h.schmalzbauer@omnisec.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: Attilio Rao Cc: freebsd-current@freebsd.org Subject: Re: kqemu crash (page fault) with -current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: attilio@FreeBSD.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2007 15:12:59 -0000 Harald Schmalzbauer wrote: > Am Freitag, 13. Juli 2007 schrieb Attilio Rao: >> Harald Schmalzbauer wrote: >>> Hello, >>> >>> today I tried qemu for the first time and I love it. >>> Now I'd need some speed and tried kqemu, but it immediately reboots my >>> machine. >>> Here is what I could transcribe: >> Could you please try this patch and see if it helps?: >> http://people.freebsd.org/~attilio/kqemu.diff > > I applied it, rebuilt my kernel and kqemu, but machine crashes immedately > after running qemu (without disabled kqemu). > Should I also rebuild qemu itself? I don't think it's needed. > But CFLAGS+= -DKSE helped! > I could install various OS, only when I enable -kernel-kqemu most installer > quit with page fault. Hello Harry, could you please download again the patch and try again? It seems I missed a bit... And, please, compile again qemu any time beacause I'm not sure how much are exposed to userland "struct thread" and "struct proc", for this problem. You should firstly try the canonical case of kernel clean compilation (so with KSE) and kqemu clean compilation (so without KSE, without the -DKSE option). Let me know, Thanks. Attilio From owner-freebsd-current@FreeBSD.ORG Sat Jul 14 15:25:21 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B213F16A403 for ; Sat, 14 Jul 2007 15:25:21 +0000 (UTC) (envelope-from scf@FreeBSD.org) Received: from mail.farley.org (farley.org [67.64.95.201]) by mx1.freebsd.org (Postfix) with ESMTP id 7374213C441 for ; Sat, 14 Jul 2007 15:25:21 +0000 (UTC) (envelope-from scf@FreeBSD.org) Received: from thor.farley.org (thor.farley.org [192.168.1.5]) by mail.farley.org (8.14.1/8.14.1) with ESMTP id l6EFRBjC072535; Sat, 14 Jul 2007 10:27:11 -0500 (CDT) (envelope-from scf@FreeBSD.org) Date: Sat, 14 Jul 2007 10:25:03 -0500 (CDT) From: "Sean C. Farley" To: Andrey Chernov In-Reply-To: <20070714022638.GA25256@nagual.pp.ru> Message-ID: <20070714080553.I27236@thor.farley.org> References: <20070713162742.GA16260@nagual.pp.ru> <20070713142545.K26096@thor.farley.org> <20070713202433.GA19856@nagual.pp.ru> <20070713203915.GA20270@nagual.pp.ru> <20070713171942.Q26096@thor.farley.org> <20070713224608.GB21695@nagual.pp.ru> <20070713184543.A26096@thor.farley.org> <20070714004116.GA22909@nagual.pp.ru> <20070713200048.X26971@thor.farley.org> <20070714014319.GA24701@nagual.pp.ru> <20070714022638.GA25256@nagual.pp.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.1 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on mail.farley.org Cc: freebsd-current Subject: Re: Environment handling broken in /bin/sh with changes to t,set,put}env() X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2007 15:25:21 -0000 On Sat, 14 Jul 2007, Andrey Chernov wrote: *snip* > BTW, I fear about another place on this matter, merge_environ(). > Look at this example: > > ... some setenv's called before > > nenv[0] = NULL; > environ = nenv; > unsetenv("NONEXISTEN"); > > What happens to environ pointer _after_ that? > > unsetenv() leads to environ = watchEnviron; in the merge_environ() but > this environ is never rebuilded because no single setenv() is called > from merge_environ() and no rebuild_environ() is called from > unsetenv() due to "NONEXISTENT" value not found. It means reassigned > environ inherits stale pointers from non-rebuilded watchEnviron which > not equals to environ[0] == NULL > > Did I miss something? No. I see it too. Here are the changes: 1. __merge_environ no longer touches environ. Only __rebuild_environ(), __build_env() and __clean_env() alter environ. 2. watchEnviron renamed to intEnviron. 3. __rebuild_environ() uses intEnviron when cycling through the environment; it only sets environ. This way environ is not changed unless it has at least one name-value pair. The new patch is here: http://www.farley.org/freebsd/tmp/setenv/clearenv/patch2 Sean -- scf@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Sat Jul 14 15:31:13 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 586D016A404 for ; Sat, 14 Jul 2007 15:31:13 +0000 (UTC) (envelope-from wilkinsa@obelix.dsto.defence.gov.au) Received: from digger1.defence.gov.au (digger1.defence.gov.au [203.5.217.4]) by mx1.freebsd.org (Postfix) with ESMTP id BBC2013C491 for ; Sat, 14 Jul 2007 15:31:12 +0000 (UTC) (envelope-from wilkinsa@obelix.dsto.defence.gov.au) Received: from ednmsw510.dsto.defence.gov.au (ednmsw510.dsto.defence.gov.au [131.185.68.11]) by digger1.defence.gov.au (8.13.8/8.13.8) with ESMTP id l6EFKjgf027257 for ; Sun, 15 Jul 2007 00:50:45 +0930 (CST) Received: from ednex510.dsto.defence.gov.au (ednex510.dsto.defence.gov.au) by ednmsw510.dsto.defence.gov.au (Clearswift SMTPRS 5.2.9) with ESMTP id for ; Sun, 15 Jul 2007 01:01:06 +0930 Received: from obelix.dsto.defence.gov.au ([203.6.60.208]) by ednex510.dsto.defence.gov.au with Microsoft SMTPSVC(6.0.3790.1830); Sun, 15 Jul 2007 01:01:06 +0930 Received: from obelix.dsto.defence.gov.au (localhost [127.0.0.1]) by obelix.dsto.defence.gov.au (8.14.1/8.14.1) with ESMTP id l6EFUqLE046235 for ; Sat, 14 Jul 2007 23:30:52 +0800 (WST) (envelope-from wilkinsa@obelix.dsto.defence.gov.au) Received: (from wilkinsa@localhost) by obelix.dsto.defence.gov.au (8.14.1/8.14.1/Submit) id l6EFUqAq046234 for freebsd-current@freebsd.org; Sat, 14 Jul 2007 23:30:52 +0800 (WST) (envelope-from wilkinsa) Date: Sat, 14 Jul 2007 23:30:52 +0800 From: "Wilkinson, Alex" To: freebsd-current@freebsd.org Message-ID: <20070714153052.GH44319@obelix.dsto.defence.gov.au> Mail-Followup-To: freebsd-current@freebsd.org References: <469504D2.8000200@errno.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <469504D2.8000200@errno.com> Organisation: Defence Science Technology Organisation User-Agent: Mutt/1.5.16 (2007-06-09) X-OriginalArrivalTime: 14 Jul 2007 15:31:06.0497 (UTC) FILETIME=[FEDA6F10:01C7C62B] X-TM-AS-Product-Ver: SMEX-7.0.0.1526-5.0.1021-15296.001 X-TM-AS-Result: No--0.037200-0.000000-31 Content-Transfer-Encoding: 7bit Subject: Re: HEADSUP: new wpa_supplicant and hostapd [ndis users read] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2007 15:31:13 -0000 0n Wed, Jul 11, 2007 at 09:26:58AM -0700, Sam Leffler wrote: >ndis support in wpa_supplicant has been tested but requires fixups in the >kernel that are pending. However people using ndis should also be aware >that the in-kernel ndis support has badly rotted and appears chock-a-block >with issues. Unless someone steps up to work on it expect instability. >Thanks to Andrew Thompson for patching things up. What ever happened to wpaul@ ? -aW IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914. If you have received this email in error, you are requested to contact the sender and delete the email. From owner-freebsd-current@FreeBSD.ORG Sat Jul 14 16:07:50 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5077B16A402 for ; Sat, 14 Jul 2007 16:07:50 +0000 (UTC) (envelope-from Thomas.Sparrevohn@btinternet.com) Received: from smtp811.mail.ird.yahoo.com (smtp811.mail.ird.yahoo.com [217.146.188.71]) by mx1.freebsd.org (Postfix) with SMTP id A205C13C428 for ; Sat, 14 Jul 2007 16:07:49 +0000 (UTC) (envelope-from Thomas.Sparrevohn@btinternet.com) Received: (qmail 71335 invoked from network); 14 Jul 2007 16:07:48 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=btinternet.com; h=Received:X-YMail-OSG:From:To:Subject:Date:User-Agent:References:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Content-Disposition:Message-Id; b=HywsRK+IPrBvBc4Jf1eQIkVX5AJVGWdS90+2QwQUsaSzV6+P5ODtWcn7xrvMGcnwPnCkx9UO2IOmnBwNB1th7+BNJfiFyJiRXN7B7g/gBf7qiIRFSsQuG+vX4cDFAku1eFi7FQIBs8omn8wbd/oqVO8C0ftGsC0TB2/MEZItM1s= ; Received: from unknown (HELO w2fzz0vc03.aah-go-on.com) (thomas.sparrevohn@btinternet.com@81.159.90.61 with login) by smtp811.mail.ird.yahoo.com with SMTP; 14 Jul 2007 16:07:48 -0000 X-YMail-OSG: 53RWy28VM1lBS_bA6eyBqCKxSFkI4ld.g_hUDQCCBo..wd5i484m2ZcuVXvAJ3WSTuSUOrHk5A-- From: Thomas Sparrevohn To: freebsd-current@freebsd.org Date: Sat, 14 Jul 2007 17:07:47 +0100 User-Agent: KMail/1.9.7 References: <4697F753.5060304@vwsoft.com> <200707141107.48714.Thomas.Sparrevohn@btinternet.com> <20070714145219.GH44766@dan.emsphone.com> In-Reply-To: <20070714145219.GH44766@dan.emsphone.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200707141707.47310.Thomas.Sparrevohn@btinternet.com> Subject: Re: zfs refuses to load pool on boot, zpool denies import X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2007 16:07:50 -0000 On Saturday 14 July 2007 15:52:19 Dan Nelson wrote: > > > I got burned by that one as well - I am vondering if ZFS should check > > system.uuid as a fall back - It does not seem correct that we have to > > run specific startup shell scripts in order to get a filesystem to > > work > > Might work in some cases, but none of my systems have the system.uuid > kenv. I'm not even sure how my zfs root volume gets mounted; the > kernel has to mount it to even find init, so it does blindly mount > zpools in some cases. Maybe the kernl mount logic assumes if it can > only see one zpool, it's got to be the right one? :) > Hmm - I must admit I did not think about that - but it looks like that if hostid does not find system.uuid it falls back on uuidgen(1) and uuidgen(2) - so it should be possibly to get a sensible value prior to rc.d From owner-freebsd-current@FreeBSD.ORG Sat Jul 14 16:19:01 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A412516A400; Sat, 14 Jul 2007 16:19:01 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 50F7E13C46B; Sat, 14 Jul 2007 16:19:01 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.13.8/8.13.8) with ESMTP id l6EGJ0mC026658; Sat, 14 Jul 2007 12:19:00 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.8/8.13.8) with ESMTP id l6EGJ087096303; Sat, 14 Jul 2007 12:19:00 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 69A9573068; Sat, 14 Jul 2007 12:19:00 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070714161900.69A9573068@freebsd-current.sentex.ca> Date: Sat, 14 Jul 2007 12:19:00 -0400 (EDT) X-Virus-Scanned: ClamAV version devel-20070102, clamav-milter version devel-111206 on clamscanner5 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2007 16:19:01 -0000 TB --- 2007-07-14 14:54:55 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-07-14 14:54:55 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2007-07-14 14:54:55 - cleaning the object tree TB --- 2007-07-14 14:55:19 - checking out the source tree TB --- 2007-07-14 14:55:19 - cd /tinderbox/HEAD/sparc64/sparc64 TB --- 2007-07-14 14:55:19 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-07-14 15:05:50 - building world (CFLAGS=-O2 -pipe) TB --- 2007-07-14 15:05:50 - cd /src TB --- 2007-07-14 15:05:50 - /usr/bin/make -B buildworld >>> World build started on Sat Jul 14 15:05:52 UTC 2007 >>> 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 Sat Jul 14 16:18:59 UTC 2007 TB --- 2007-07-14 16:18:59 - generating LINT kernel config TB --- 2007-07-14 16:18:59 - cd /src/sys/sparc64/conf TB --- 2007-07-14 16:18:59 - /usr/bin/make -B LINT TB --- 2007-07-14 16:18:59 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-07-14 16:18:59 - cd /src TB --- 2007-07-14 16:18:59 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Jul 14 16:19:00 UTC 2007 >>> stage 1: configuring the kernel -------------------------------------------------------------- cd /src/sys/sparc64/conf; PATH=/obj/sparc64/src/tmp/legacy/usr/sbin:/obj/sparc64/src/tmp/legacy/usr/bin:/obj/sparc64/src/tmp/legacy/usr/games:/obj/sparc64/src/tmp/usr/sbin:/obj/sparc64/src/tmp/usr/bin:/obj/sparc64/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin config -d /obj/sparc64/src/sys/LINT /src/sys/sparc64/conf/LINT WARNING: duplicate option `GEOM_BSD' encountered. WARNING: duplicate option `GEOM_SUNLABEL' encountered. WARNING: duplicate option `DEV_MEM' encountered. WARNING: duplicate device `mem' encountered. /src/sys/sparc64/conf/LINT: unknown option "SCTP_HIGH_SPEED" *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-07-14 16:19:00 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-07-14 16:19:00 - ERROR: failed to build lint kernel TB --- 2007-07-14 16:19:00 - tinderbox aborted TB --- 0.83 user 2.51 system 5044.24 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Sat Jul 14 16:22:43 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AEBD616A403; Sat, 14 Jul 2007 16:22:43 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 5D95B13C494; Sat, 14 Jul 2007 16:22:43 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.13.8/8.13.8) with ESMTP id l6EGMgXc026795; Sat, 14 Jul 2007 12:22:42 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.8/8.13.8) with ESMTP id l6EGMg4W099567; Sat, 14 Jul 2007 12:22:42 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 5949073068; Sat, 14 Jul 2007 12:22:42 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070714162242.5949073068@freebsd-current.sentex.ca> Date: Sat, 14 Jul 2007 12:22:42 -0400 (EDT) X-Virus-Scanned: ClamAV version devel-20070102, clamav-milter version devel-111206 on clamscanner3 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on sparc64/sun4v X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2007 16:22:43 -0000 TB --- 2007-07-14 15:01:17 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-07-14 15:01:17 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2007-07-14 15:01:17 - cleaning the object tree TB --- 2007-07-14 15:01:41 - checking out the source tree TB --- 2007-07-14 15:01:41 - cd /tinderbox/HEAD/sparc64/sun4v TB --- 2007-07-14 15:01:41 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-07-14 15:10:55 - building world (CFLAGS=-O2 -pipe) TB --- 2007-07-14 15:10:55 - cd /src TB --- 2007-07-14 15:10:55 - /usr/bin/make -B buildworld >>> World build started on Sat Jul 14 15:10:56 UTC 2007 >>> 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 Sat Jul 14 16:22:41 UTC 2007 TB --- 2007-07-14 16:22:41 - generating LINT kernel config TB --- 2007-07-14 16:22:41 - cd /src/sys/sun4v/conf TB --- 2007-07-14 16:22:41 - /usr/bin/make -B LINT TB --- 2007-07-14 16:22:42 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-07-14 16:22:42 - cd /src TB --- 2007-07-14 16:22:42 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Jul 14 16:22:42 UTC 2007 >>> stage 1: configuring the kernel -------------------------------------------------------------- cd /src/sys/sun4v/conf; PATH=/obj/sun4v/src/tmp/legacy/usr/sbin:/obj/sun4v/src/tmp/legacy/usr/bin:/obj/sun4v/src/tmp/legacy/usr/games:/obj/sun4v/src/tmp/usr/sbin:/obj/sun4v/src/tmp/usr/bin:/obj/sun4v/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin config -d /obj/sun4v/src/sys/LINT /src/sys/sun4v/conf/LINT WARNING: duplicate option `GEOM_BSD' encountered. WARNING: duplicate option `GEOM_SUNLABEL' encountered. WARNING: duplicate option `DEV_MEM' encountered. WARNING: duplicate device `mem' encountered. WARNING: duplicate option `DEV_GENCLOCK' encountered. WARNING: duplicate device `genclock' encountered. /src/sys/sun4v/conf/LINT: unknown option "SCTP_HIGH_SPEED" *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-07-14 16:22:42 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-07-14 16:22:42 - ERROR: failed to build lint kernel TB --- 2007-07-14 16:22:42 - tinderbox aborted TB --- 0.52 user 2.16 system 4884.91 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From owner-freebsd-current@FreeBSD.ORG Sat Jul 14 16:28:11 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 339F416A401 for ; Sat, 14 Jul 2007 16:28:11 +0000 (UTC) (envelope-from keramida@freebsd.org) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.freebsd.org (Postfix) with ESMTP id 9E06713C4A6 for ; Sat, 14 Jul 2007 16:28:10 +0000 (UTC) (envelope-from keramida@freebsd.org) Received: from kobe.laptop (dialup14.ach.sch.gr [81.186.70.14]) (authenticated bits=128) by igloo.linux.gr (8.13.8/8.13.8/Debian-3) with ESMTP id l6EGRotZ000400 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 14 Jul 2007 19:28:01 +0300 Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.14.1/8.14.1) with ESMTP id l6EGRhZQ002124; Sat, 14 Jul 2007 19:27:44 +0300 (EEST) (envelope-from keramida@freebsd.org) Received: (from keramida@localhost) by kobe.laptop (8.14.1/8.14.1/Submit) id l6E0u09c006812; Sat, 14 Jul 2007 03:56:00 +0300 (EEST) (envelope-from keramida@freebsd.org) Date: Sat, 14 Jul 2007 03:55:59 +0300 From: Giorgos Keramidas To: Christos Zoulas Message-ID: <20070714005559.GB6661@kobe.laptop> References: <20070712114328.F4608@carver.gumbysoft.com> <20070712185616.2BA2D56539@rebar.astron.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070712185616.2BA2D56539@rebar.astron.com> X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (cached, score=-3.942, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.46, BAYES_00 -2.60) X-Hellug-MailScanner-From: keramida@freebsd.org X-Spam-Status: No Cc: tcsh-bugs@mx.gw.com, current@freebsd.org Subject: Re: tcsh backtick hang info X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2007 16:28:11 -0000 On 2007-07-12 14:56, Christos Zoulas wrote: > On Jul 12, 11:48am, dwhite@gumbysoft.com (Doug White) wrote: > -- Subject: Re: tcsh backtick hang info > > | Thanks for the good words, Christos! If you can confirm this will be the > | official patch then we can apply it to our vendor sources. If there are > | any other fixes for nasty bugs in 6.15.00 that you're hanging on to it'd > | be good to get those out and imported as well. > > You are welcome! > This will be the official patch, and yes I have another 9 bug fixes since > 6.15.00. In general, I don't make 6.15.XX generally available, but the > severity of some of those problems fixed is high enough to possibly justify > a 6.16.00 sooner than later. Here's the list of fixes: > > 10. kill `foo` got stuck because sigchld was disabled too soon (Mark Peek) > 9. Avoid null pointer dereference in proc cwd (Kurt Miller) > 8. eval "foreach a b c" exits (Anthony Menasse) > 7. Quoting was broken in substitutions (Joe Wells) > 6. QNX patches via pkgsrc > 5. cd - twice from a directory that contained a glob pattern, > expands the glob twice (Mark Santcroos) > 4. MidnightBsd support (Lucas Holt) > 3. Fix history substitution core-dump with no history entries > 2. Merge two character tables that are the same (Martin Kraemer) > 1. On ancient 7 bit locales, punctuation characters are used to > denote special characters such as umlaut, adiaresis, etc. > These characters return true for isalpha/isalnum. Ignore them > because they break parsing (Martin Kraemer) Hi Christos, Can we persuade you to include the following local patch I keep for autologout detection with /dev/pts/XXX ptys in FreeBSD? %%% Fix pty detection logic of tcsh autologout initialization. Noticed by: kris diff --git a/contrib/tcsh/sh.c b/contrib/tcsh/sh.c --- a/contrib/tcsh/sh.c +++ b/contrib/tcsh/sh.c @@ -457,7 +457,7 @@ main(int argc, char **argv) if (*cp) { /* only for login shells or root and we must have a tty */ if ((cp2 = Strrchr(cp, (Char) '/')) != NULL) { - cp = cp2 + 1; + cp2 = cp2 + 1; } else cp2 = cp; %%% From owner-freebsd-current@FreeBSD.ORG Sat Jul 14 16:44:33 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 64F0216A401 for ; Sat, 14 Jul 2007 16:44:33 +0000 (UTC) (envelope-from alex.kovalenko@verizon.net) Received: from vms040pub.verizon.net (vms040pub.verizon.net [206.46.252.40]) by mx1.freebsd.org (Postfix) with ESMTP id 480A613C471 for ; Sat, 14 Jul 2007 16:44:33 +0000 (UTC) (envelope-from alex.kovalenko@verizon.net) Received: from [10.0.3.231] ([70.21.131.146]) by vms040.mailsrvcs.net (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPA id <0JL600EOHH68KV51@vms040.mailsrvcs.net> for freebsd-current@freebsd.org; Sat, 14 Jul 2007 11:44:32 -0500 (CDT) Date: Thu, 12 Jul 2007 22:15:40 -0400 From: "Alexandre \"Sunny\" Kovalenko" In-reply-to: <469504D2.8000200@errno.com> To: Sam Leffler Message-id: <1184292940.825.4.camel@RabbitsDen> MIME-version: 1.0 X-Mailer: Evolution 2.10.2 FreeBSD GNOME Team Port Content-type: text/plain Content-transfer-encoding: 7bit References: <469504D2.8000200@errno.com> Cc: freebsd-current@freebsd.org Subject: Re: HEADSUP: new wpa_supplicant and hostapd [ndis users read] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2007 16:44:33 -0000 On Wed, 2007-07-11 at 09:26 -0700, Sam Leffler wrote: > These applications have been updated to the 0.5.8 "stable release" from > Jouni Malinen. This gets us back on Jouni's stable release branch (as > opposed to the abandoned code base we were using). There are many new > features (read the docs in contrib) and you should now be able to use > 802.1x over wired nic's though it may not be configured by default > (please send patches after testing and I will try stuff updated). Just to report that wpa_supplicant works well here on both WEP and WPA-PSK networks. Thank you. -- Alexandre "Sunny" Kovalenko From owner-freebsd-current@FreeBSD.ORG Sat Jul 14 17:03:31 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.ORG Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BC44616A403; Sat, 14 Jul 2007 17:03:31 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (nagual.pp.ru [194.87.13.69]) by mx1.freebsd.org (Postfix) with ESMTP id 1D0A413C4A3; Sat, 14 Jul 2007 17:03:30 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.14.1/8.14.1) with ESMTP id l6EH3TOD037479; Sat, 14 Jul 2007 21:03:29 +0400 (MSD) (envelope-from ache@nagual.pp.ru) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nagual.pp.ru; s=default; t=1184432609; bh=T6BxPsSE8Vh6yIWrACRXJtlr5/0eJJZruYuR2jT HvD0=; l=1028; h=Received:Date:From:To:Cc:Subject:Message-ID: Mail-Followup-To:References:MIME-Version:Content-Type: Content-Disposition:In-Reply-To:User-Agent; b=TbjiBmKgCjqVpHn+q2ZN 86g5px1/osrBCl/sU5b3JjRLuRXxBL8KMj6/ww+toAM3+kKajuVB/xkggxy+wHvp83F iRKUJ0Vtn3w8IeiXerKg0qnNTPoMlgVVMjdVslUe3j4YjEnQtScqfZbCmiiCBG6EobH n822QEELILxRwAsBY= Received: (from ache@localhost) by nagual.pp.ru (8.14.1/8.14.1/Submit) id l6EH3TII037478; Sat, 14 Jul 2007 21:03:29 +0400 (MSD) (envelope-from ache) Date: Sat, 14 Jul 2007 21:03:28 +0400 From: Andrey Chernov To: "Sean C. Farley" Message-ID: <20070714170328.GA37383@nagual.pp.ru> Mail-Followup-To: Andrey Chernov , "Sean C. Farley" , freebsd-current References: <20070713202433.GA19856@nagual.pp.ru> <20070713203915.GA20270@nagual.pp.ru> <20070713171942.Q26096@thor.farley.org> <20070713224608.GB21695@nagual.pp.ru> <20070713184543.A26096@thor.farley.org> <20070714004116.GA22909@nagual.pp.ru> <20070713200048.X26971@thor.farley.org> <20070714014319.GA24701@nagual.pp.ru> <20070714022638.GA25256@nagual.pp.ru> <20070714080553.I27236@thor.farley.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070714080553.I27236@thor.farley.org> User-Agent: Mutt/1.5.16 (2007-06-09) Cc: freebsd-current Subject: Re: Environment handling broken in /bin/sh with changes to t,set,put}env() X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2007 17:03:31 -0000 On Sat, Jul 14, 2007 at 10:25:03AM -0500, Sean C. Farley wrote: > No. I see it too. Here are the changes: > 1. __merge_environ no longer touches environ. Only __rebuild_environ(), > __build_env() and __clean_env() alter environ. > 2. watchEnviron renamed to intEnviron. > 3. __rebuild_environ() uses intEnviron when cycling through the > environment; it only sets environ. > > This way environ is not changed unless it has at least one name-value > pair. > > The new patch is here: > http://www.farley.org/freebsd/tmp/setenv/clearenv/patch2 Ok. BTW, I see no needs to duplicate code here: rtrnVal = __rebuild_environ(envVarsTotal); if (rtrnVal == -1) { savedErrno = errno; __clean_env(true); errno = savedErrno; } return (rtrnVal); Failure: savedErrno = errno; __clean_env(true); errno = savedErrno; return (-1); instead of simple: rtrnVal = __rebuild_environ(envVarsTotal); if (rtrnVal == -1) goto Failure; like before in this function. -- http://ache.pp.ru/ From owner-freebsd-current@FreeBSD.ORG Sat Jul 14 17:20:33 2007 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 440FD16A401 for ; Sat, 14 Jul 2007 17:20:33 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 2071913C461 for ; Sat, 14 Jul 2007 17:20:33 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id B3BD548B6E for ; Sat, 14 Jul 2007 13:20:32 -0400 (EDT) Date: Sat, 14 Jul 2007 18:20:32 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: current@FreeBSD.org Message-ID: <20070714181315.V67691@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Subject: HEADS UP: netatm disabling taking place shortly X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2007 17:20:33 -0000 This is a warning to CVS HEAD users -- per countless previous e-mail threads, I will shortly be committing a patch to disable the build of netatm. As you may well know from earlier e-mails, netatm is one of three ATM stacks in the FreeBSD CVS repository, and currently the only one that is not MPSAFE. We will be disabling the build of netatm in 7.0, but continuing to ship source code so that efforts to make it MPSAFE are made easier. If we don't have MPSAFEty work done in the next few months, we can remove the source code from 7.x/8.x. I will send out a reversion patch that may be applied with "patch -R" to re-enable the netatm build once the final patch is committed. As this patch touches quite a few bits of build infrastructure, there may well be a window in which the build is broken during merging of the parts, but hopefully not long. Once this has settled I will be removing NET_NEEDS_GIANT, the compile-time compatibility functionality that allowed non-MPSAFE network protocols to operate in the stack. This will substantially simplify the socket code, which currently jumps through quite a few hoops to optionally acquire Giant when non-MPSAFE components are compiled into the stack. As has been observed, this may lead to problems with credential-based firewall rules, which currently rely on debug.mpsafenet to prevent deadlock scenarios due to bugs in the locking of the firewalls. Hopefully this will motivate fixing those problems in short order. Once the NET_NEEDS_GIANT removal is dealt with, I'm happy to help investigate those bugs. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Sat Jul 14 17:58:15 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C392716A400 for ; Sat, 14 Jul 2007 17:58:15 +0000 (UTC) (envelope-from scf@FreeBSD.org) Received: from mail.farley.org (farley.org [67.64.95.201]) by mx1.freebsd.org (Postfix) with ESMTP id 85E4D13C467 for ; Sat, 14 Jul 2007 17:58:15 +0000 (UTC) (envelope-from scf@FreeBSD.org) Received: from thor.farley.org (thor.farley.org [192.168.1.5]) by mail.farley.org (8.14.1/8.14.1) with ESMTP id l6EI056i074618; Sat, 14 Jul 2007 13:00:05 -0500 (CDT) (envelope-from scf@FreeBSD.org) Date: Sat, 14 Jul 2007 12:57:57 -0500 (CDT) From: "Sean C. Farley" To: Andrey Chernov In-Reply-To: <20070714170328.GA37383@nagual.pp.ru> Message-ID: <20070714125346.U27236@thor.farley.org> References: <20070713202433.GA19856@nagual.pp.ru> <20070713203915.GA20270@nagual.pp.ru> <20070713171942.Q26096@thor.farley.org> <20070713224608.GB21695@nagual.pp.ru> <20070713184543.A26096@thor.farley.org> <20070714004116.GA22909@nagual.pp.ru> <20070713200048.X26971@thor.farley.org> <20070714014319.GA24701@nagual.pp.ru> <20070714022638.GA25256@nagual.pp.ru> <20070714080553.I27236@thor.farley.org> <20070714170328.GA37383@nagual.pp.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.1 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on mail.farley.org Cc: freebsd-current Subject: Re: Environment handling broken in /bin/sh with changes to t,set,put}env() X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2007 17:58:15 -0000 On Sat, 14 Jul 2007, Andrey Chernov wrote: > On Sat, Jul 14, 2007 at 10:25:03AM -0500, Sean C. Farley wrote: *snip* >> The new patch is here: >> http://www.farley.org/freebsd/tmp/setenv/clearenv/patch2 > > Ok. > > BTW, I see no needs to duplicate code here: > > rtrnVal = __rebuild_environ(envVarsTotal); > if (rtrnVal == -1) { > savedErrno = errno; > __clean_env(true); > errno = savedErrno; > } > > return (rtrnVal); > > Failure: > savedErrno = errno; > __clean_env(true); > errno = savedErrno; > > return (-1); > > instead of simple: > > rtrnVal = __rebuild_environ(envVarsTotal); > if (rtrnVal == -1) > goto Failure; > > like before in this function. True. I also changed it to: if (__rebuild_environ(envVarsTotal) == 0) return (0); to get rid of the rtrnVal variable. Sean -- scf@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Sat Jul 14 19:07:54 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8178E16A401 for ; Sat, 14 Jul 2007 19:07:54 +0000 (UTC) (envelope-from marcus@FreeBSD.org) Received: from creme-brulee.marcuscom.com (creme-brulee.marcuscom.com [24.172.16.118]) by mx1.freebsd.org (Postfix) with ESMTP id D53F513C442 for ; Sat, 14 Jul 2007 19:07:53 +0000 (UTC) (envelope-from marcus@FreeBSD.org) Received: from [IPv6:2001:470:1f00:2464::4] (shumai.marcuscom.com [IPv6:2001:470:1f00:2464::4]) by creme-brulee.marcuscom.com (8.14.1/8.14.1) with ESMTP id l6EIVE0X080204; Sat, 14 Jul 2007 14:31:14 -0400 (EDT) (envelope-from marcus@FreeBSD.org) From: Joe Marcus Clarke To: "Simon L. Nielsen" In-Reply-To: <20070714110016.GA999@zaphod.nitro.dk> References: <469504D2.8000200@errno.com> <46951B50.3020601@FreeBSD.org> <20070714110016.GA999@zaphod.nitro.dk> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-vSaM99LokGtltJ2iM+V/" Organization: FreeBSD, Inc. Date: Sat, 14 Jul 2007 14:30:55 -0400 Message-Id: <1184437855.92518.1.camel@shumai.marcuscom.com> Mime-Version: 1.0 X-Mailer: Evolution 2.10.3 FreeBSD GNOME Team Port X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,NO_RELAYS autolearn=ham version=3.2.1 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on creme-brulee.marcuscom.com Cc: freebsd-current@FreeBSD.org Subject: Re: HEADSUP: new wpa_supplicant and hostapd [ndis users read] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2007 19:07:54 -0000 --=-vSaM99LokGtltJ2iM+V/ Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Sat, 2007-07-14 at 13:00 +0200, Simon L. Nielsen wrote: > On 2007.07.11 14:02:56 -0400, Joe Marcus Clarke wrote: >=20 > > Sam Leffler wrote: > > > These applications have been updated to the 0.5.8 "stable release" fr= om > > > Jouni Malinen. This gets us back on Jouni's stable release branch (a= s > > > opposed to the abandoned code base we were using). There are many ne= w > > > features (read the docs in contrib) and you should now be able to use > > > 802.1x over wired nic's though it may not be configured by default > > > (please send patches after testing and I will try stuff updated). > > >=20 > > > ndis support in wpa_supplicant has been tested but requires fixups in > > > the kernel that are pending. However people using ndis should also b= e > > > aware that the in-kernel ndis support has badly rotted and appears > > > chock-a-block with issues. Unless someone steps up to work on it exp= ect > > > instability. Thanks to Andrew Thompson for patching things up. > >=20 > > Are there plans to add the patch to the base system OpenSSL needed to > > enable EAP-FAST? This would greatly help me at work. >=20 > Which patch do you mean? While I don't have a problem with taking > stuff off the vendor branch if needed, I general I prefer not to > change OpenSSL unless there is a good reason (critical bugs, security > issues etc). /usr/src/contrib/wpa_supplicant/openssl-0.9.8d-tls-extensions.patch Joe --=20 Joe Marcus Clarke FreeBSD GNOME Team :: gnome@FreeBSD.org FreeNode / #freebsd-gnome http://www.FreeBSD.org/gnome --=-vSaM99LokGtltJ2iM+V/ Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQBGmRZeb2iPiv4Uz4cRArlBAJ4ks2+EnlQzzLDSUhLZLEwzsFWMlQCfbGzD lZ1euGl7Hhz1lTezIZ6ix34= =UAke -----END PGP SIGNATURE----- --=-vSaM99LokGtltJ2iM+V/-- From owner-freebsd-current@FreeBSD.ORG Sat Jul 14 21:52:40 2007 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B05D316A403 for ; Sat, 14 Jul 2007 21:52:40 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id EA16F13C428 for ; Sat, 14 Jul 2007 21:52:39 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id E7FE64730F for ; Sat, 14 Jul 2007 17:52:38 -0400 (EDT) Date: Sat, 14 Jul 2007 22:52:38 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: current@FreeBSD.org In-Reply-To: <20070714181315.V67691@fledge.watson.org> Message-ID: <20070714225047.N94899@fledge.watson.org> References: <20070714181315.V67691@fledge.watson.org> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-188303047-1184449958=:94899" Cc: Subject: Re: HEADS UP: netatm disabling taking place shortly X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2007 21:52:40 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-188303047-1184449958=:94899 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed On Sat, 14 Jul 2007, Robert Watson wrote: > This is a warning to CVS HEAD users -- per countless previous e-mail > threads, I will shortly be committing a patch to disable the build of > netatm. As you may well know from earlier e-mails, netatm is one of three > ATM stacks in the FreeBSD CVS repository, and currently the only one that is > not MPSAFE. We will be disabling the build of netatm in 7.0, but continuing > to ship source code so that efforts to make it MPSAFE are made easier. If > we don't have MPSAFEty work done in the next few months, we can remove the > source code from 7.x/8.x. I will send out a reversion patch that may be > applied with "patch -R" to re-enable the netatm build once the final patch > is committed. This patch has now been committed. The commit message is below, and a patch for use with "patch -R" is attached. An updated NET_NEEDS_GIANT patch will likely be sent out tonight or tomorrow. rwatson 2007-07-14 21:49:24 UTC FreeBSD src repository Modified files: etc/mtree BSD.include.dist BSD.usr.dist include Makefile lib Makefile rescue/rescue Makefile sbin/atm Makefile share/examples Makefile sys/conf NOTES files options sys/modules Makefile sys/modules/netgraph/atm Makefile sys/netatm atm_proto.c usr.bin/kdump mkioctls usr.sbin Makefile Log: Disconnect netatm from the build as it is not MPSAFE and relies on NET_NEEDS_GIANT, which will shortly be removed. This is done in a away that it may be easily reattached to the build before 7.1 if appropriate locking is added. Specifics: - Don't install netatm include files - Disconnect netatm command line management tools - Don't build libatm - Don't include ATM parts in rescue or sysinstall - Don't install sample configuration files and documents - Don't build kernel support as a module or in NOTES - Don't build netgraph wrapper nodes for netatm This removes the last remaining consumer of NET_NEEDS_GIANT. Reviewed by: harti Discussed with: bz, bms Approved by: re (kensmith) Revision Changes Path 1.118 +11 -10 src/etc/mtree/BSD.include.dist 1.327 +3 -2 src/etc/mtree/BSD.usr.dist 1.274 +3 -2 src/include/Makefile 1.222 +2 -1 src/lib/Makefile 1.56 +4 -2 src/rescue/rescue/Makefile 1.6 +6 -4 src/sbin/atm/Makefile 1.51 +14 -10 src/share/examples/Makefile 1.1444 +9 -7 src/sys/conf/NOTES 1.1238 +103 -99 src/sys/conf/files 1.602 +6 -6 src/sys/conf/options 1.536 +10 -3 src/sys/modules/Makefile 1.7 +3 -1 src/sys/modules/netgraph/atm/Makefile 1.16 +1 -1 src/sys/netatm/atm_proto.c 1.39 +5 -4 src/usr.bin/kdump/mkioctls 1.370 +4 -3 src/usr.sbin/Makefile Robert N M Watson Computer Laboratory University of Cambridge --0-188303047-1184449958=:94899 Content-Type: TEXT/plain; charset=US-ASCII; name=atm.diff Content-Transfer-Encoding: BASE64 Content-ID: <20070714225238.C94899@fledge.watson.org> Content-Description: Content-Disposition: attachment; filename=atm.diff SW5kZXg6IGV0Yy9tdHJlZS9CU0QuaW5jbHVkZS5kaXN0DQo9PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09DQpSQ1MgZmlsZTogL3pvby9jdnN1cC9GcmVlQlNELUNW Uy9zcmMvZXRjL210cmVlL0JTRC5pbmNsdWRlLmRpc3Qsdg0KcmV0cmlldmlu ZyByZXZpc2lvbiAxLjExNw0KZGlmZiAtdSAtcjEuMTE3IEJTRC5pbmNsdWRl LmRpc3QNCi0tLSBldGMvbXRyZWUvQlNELmluY2x1ZGUuZGlzdAk2IEp1bCAy MDA3IDA3OjIwOjU5IC0wMDAwCTEuMTE3DQorKysgZXRjL210cmVlL0JTRC5p bmNsdWRlLmRpc3QJMTEgSnVsIDIwMDcgMTQ6Mzk6MzkgLTAwMDANCkBAIC0y MDUsMTYgKzIwNSwxNyBAQA0KICAgICAuLg0KICAgICBuZXRhdGFsaw0KICAg ICAuLg0KLSAgICBuZXRhdG0NCi0gICAgICAgIGlwYXRtDQotICAgICAgICAu Lg0KLSAgICAgICAgc2lncHZjDQotICAgICAgICAuLg0KLSAgICAgICAgc3Bh bnMNCi0gICAgICAgIC4uDQotICAgICAgICB1bmkNCi0gICAgICAgIC4uDQot ICAgIC4uDQorIyBEaXNhYmxlZCBpbiA3LjAgYXMgbmV0YXRtIGlzIG5vdCBN UFNBRkUuDQorIyAgICBuZXRhdG0NCisjICAgICAgICBpcGF0bQ0KKyMgICAg ICAgIC4uDQorIyAgICAgICAgc2lncHZjDQorIyAgICAgICAgLi4NCisjICAg ICAgICBzcGFucw0KKyMgICAgICAgIC4uDQorIyAgICAgICAgdW5pDQorIyAg ICAgICAgLi4NCisjICAgIC4uDQogICAgIG5ldGdyYXBoDQogICAgICAgICBh dG0NCiAgICAgICAgIC4uDQpJbmRleDogZXRjL210cmVlL0JTRC51c3IuZGlz dA0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PQ0KUkNTIGZpbGU6IC96b28vY3Zz dXAvRnJlZUJTRC1DVlMvc3JjL2V0Yy9tdHJlZS9CU0QudXNyLmRpc3Qsdg0K cmV0cmlldmluZyByZXZpc2lvbiAxLjMyNg0KZGlmZiAtdSAtcjEuMzI2IEJT RC51c3IuZGlzdA0KLS0tIGV0Yy9tdHJlZS9CU0QudXNyLmRpc3QJMiBNYXIg MjAwNyAxNDo1NjoxNCAtMDAwMAkxLjMyNg0KKysrIGV0Yy9tdHJlZS9CU0Qu dXNyLmRpc3QJMTEgSnVsIDIwMDcgMTQ6NDA6MTggLTAwMDANCkBAIC0xODcs OCArMTg3LDkgQEANCiAgICAgICAgICAgICAuLg0KICAgICAgICAgICAgIElQ djYNCiAgICAgICAgICAgICAuLg0KLSAgICAgICAgICAgIGF0bQ0KLSAgICAg ICAgICAgIC4uDQorIyBEaXNhYmxlZCBpbiA3LjAgYXMgbmV0YXRtIGlzIG5v dCBNUFNBRkUuDQorIyAgICAgICAgICAgIGF0bQ0KKyMgICAgICAgICAgICAu Lg0KICAgICAgICAgICAgIGJjDQogICAgICAgICAgICAgLi4NCiAgICAgICAg ICAgICBib290Zm9ydGgNCkluZGV4OiBpbmNsdWRlL01ha2VmaWxlDQo9PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09DQpSQ1MgZmlsZTogL3pvby9jdnN1cC9GcmVl QlNELUNWUy9zcmMvaW5jbHVkZS9NYWtlZmlsZSx2DQpyZXRyaWV2aW5nIHJl dmlzaW9uIDEuMjczDQpkaWZmIC11IC1yMS4yNzMgTWFrZWZpbGUNCi0tLSBp bmNsdWRlL01ha2VmaWxlCTYgSnVsIDIwMDcgMDc6MjA6NTkgLTAwMDAJMS4y NzMNCisrKyBpbmNsdWRlL01ha2VmaWxlCTEwIEp1bCAyMDA3IDIzOjQ2OjA2 IC0wMDAwDQpAQCAtMzYsMTAgKzM2LDExIEBADQogTEhEUlM9CWFpby5oIGVy cm5vLmggZmNudGwuaCBsaW5rZXJfc2V0LmggcG9sbC5oIHN0ZGludC5oIHN5 c2xvZy5oIFwNCiAJdGVybWlvcy5oIHVjb250ZXh0LmgNCiANCi1MRElSUz0J YnNtIGNhbSBnZW9tIG5ldCBuZXQ4MDIxMSBuZXRhdGFsayBuZXRhdG0gbmV0 Z3JhcGggbmV0aW5ldCBuZXRpbmV0NiBcDQorTERJUlM9CWJzbSBjYW0gZ2Vv bSBuZXQgbmV0ODAyMTEgbmV0YXRhbGsgbmV0Z3JhcGggbmV0aW5ldCBuZXRp bmV0NiBcDQogCW5ldGlwc2VjICR7X25ldGlweH0gbmV0bmF0bSAke19uZXRu Y3B9IG5ldHNtYiBcDQogCW5mcyBuZnNjbGllbnQgbmZzc2VydmVyIFwNCiAJ cGNjYXJkIHN5cyB2bQ0KKyNMRElSUys9CW5ldGF0bQ0KIA0KIExTVUJESVJT PQljYW0vc2NzaSBcDQogCWRldi9hY3BpY2EgZGV2L2FuIGRldi9ia3RyIGRl di9maXJld2lyZSBkZXYvaHdwbWMgXA0KQEAgLTQ5LDEyICs1MCwxMiBAQA0K IAkke19mc19ud2ZzfSBmcy9wb3J0YWxmcyBmcy9wcm9jZnMgZnMvc21iZnMg ZnMvdWRmIGZzL3VuaW9uZnMgXA0KIAlnZW9tL2NhY2hlIGdlb20vY29uY2F0 IGdlb20vZWxpIGdlb20vZ2F0ZSBnZW9tL2pvdXJuYWwgZ2VvbS9sYWJlbCBc DQogCWdlb20vbWlycm9yIGdlb20vbm9wIGdlb20vcmFpZDMgZ2VvbS9zaHNl YyBnZW9tL3N0cmlwZSBcDQotCW5ldGF0bS9pcGF0bSBuZXRhdG0vc2lncHZj IG5ldGF0bS9zcGFucyBuZXRhdG0vdW5pIFwNCiAJbmV0Z3JhcGgvYXRtIG5l dGdyYXBoL25ldGZsb3cgXA0KIAlzZWN1cml0eS9hdWRpdCBcDQogCXNlY3Vy aXR5L21hY19iaWJhIHNlY3VyaXR5L21hY19ic2RleHRlbmRlZCBzZWN1cml0 eS9tYWNfbG9tYWMgXA0KIAlzZWN1cml0eS9tYWNfbWxzIHNlY3VyaXR5L21h Y19wYXJ0aXRpb24gXA0KIAl1ZnMvZmZzIHVmcy91ZnMNCisjTFNVQkRJUlMr PQluZXRhdG0vaXBhdG0gbmV0YXRtL3NpZ3B2YyBuZXRhdG0vc3BhbnMgbmV0 YXRtL3VuaQ0KIA0KIC5pZiAke01BQ0hJTkVfQVJDSH0gPT0gInBvd2VycGMi DQogX2Rldl9wb3dlcm1hY19udnJhbT0JZGV2L3Bvd2VybWFjX252cmFtDQpJ bmRleDogbGliL01ha2VmaWxlDQo9PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQpS Q1MgZmlsZTogL3pvby9jdnN1cC9GcmVlQlNELUNWUy9zcmMvbGliL01ha2Vm aWxlLHYNCnJldHJpZXZpbmcgcmV2aXNpb24gMS4yMjENCmRpZmYgLXUgLXIx LjIyMSBNYWtlZmlsZQ0KLS0tIGxpYi9NYWtlZmlsZQkxOSBNYXkgMjAwNyAw NDo1NToxNCAtMDAwMAkxLjIyMQ0KKysrIGxpYi9NYWtlZmlsZQkxMCBKdWwg MjAwNyAyMDowOTo1OSAtMDAwMA0KQEAgLTQ4LDcgKzQ4LDggQEANCiAuZW5k aWYNCiANCiAuaWYgJHtNS19BVE19ICE9ICJubyINCi1fbGliYXRtPQlsaWJh dG0NCisjIERpc2FibGVkIGluIDcuMCBhcyBuZXRhdG0gaXMgbm90IE1QU0FG RS4NCisjX2xpYmF0bT0JbGliYXRtDQogX2xpYm5nYXRtPQlsaWJuZ2F0bQ0K IC5lbmRpZg0KIA0KSW5kZXg6IHJlc2N1ZS9yZXNjdWUvTWFrZWZpbGUNCj09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT0NClJDUyBmaWxlOiAvem9vL2N2c3VwL0Zy ZWVCU0QtQ1ZTL3NyYy9yZXNjdWUvcmVzY3VlL01ha2VmaWxlLHYNCnJldHJp ZXZpbmcgcmV2aXNpb24gMS41NQ0KZGlmZiAtdSAtcjEuNTUgTWFrZWZpbGUN Ci0tLSByZXNjdWUvcmVzY3VlL01ha2VmaWxlCTI1IEp1biAyMDA3IDA1OjA2 OjUzIC0wMDAwCTEuNTUNCisrKyByZXNjdWUvcmVzY3VlL01ha2VmaWxlCTEw IEp1bCAyMDA3IDIwOjEwOjE0IC0wMDAwDQpAQCAtMTE5LDggKzExOSwxMCBA QA0KIAlzbGF0dGFjaCBzcHBwY29udHJvbCBzdGFydHNsaXAgc3dhcG9uIHN5 c2N0bCB0dW5lZnMgdW1vdW50IA0KIA0KIC5pZiAke01LX0FUTX0gIT0gIm5v Ig0KLUNSVU5DSF9QUk9HU19zYmluKz0gYXRtIGF0bWNvbmZpZyBmb3JlX2Ru bGQgaWxtaWQNCi1DUlVOQ0hfTElCUys9IC1sYXRtDQorQ1JVTkNIX1BST0dT X3NiaW4rPSBhdG1jb25maWcNCisjIERpc2FibGVkIGluIDcuMCBhcyBuZXRh dG0gaXMgbm90IE1QU0FGRS4NCisjQ1JVTkNIX1BST0dTX3NiaW4rPSBhdG0g Zm9yZV9kbmxkIGlsbWlkDQorI0NSVU5DSF9MSUJTKz0gLWxhdG0NCiAuZW5k aWYNCiANCiAuaWYgJHtNS19JTkVUNl9TVVBQT1JUfSAhPSAibm8iDQpJbmRl eDogc2Jpbi9hdG0vTWFrZWZpbGUNCj09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0N ClJDUyBmaWxlOiAvem9vL2N2c3VwL0ZyZWVCU0QtQ1ZTL3NyYy9zYmluL2F0 bS9NYWtlZmlsZSx2DQpyZXRyaWV2aW5nIHJldmlzaW9uIDEuNQ0KZGlmZiAt dSAtcjEuNSBNYWtlZmlsZQ0KLS0tIHNiaW4vYXRtL01ha2VmaWxlCTE4IEF1 ZyAyMDAzIDE1OjMyOjE2IC0wMDAwCTEuNQ0KKysrIHNiaW4vYXRtL01ha2Vm aWxlCTEwIEp1bCAyMDA3IDIwOjEwOjI2IC0wMDAwDQpAQCAtMjMsOSArMjMs MTEgQEANCiAjCUAoIykgJElkOiBNYWtlZmlsZSx2IDEuNSAxOTk4LzA3LzEw IDE2OjAxOjU4IGpwdCBFeHAgJA0KICMgJEZyZWVCU0Q6IHNyYy9zYmluL2F0 bS9NYWtlZmlsZSx2IDEuNSAyMDAzLzA4LzE4IDE1OjMyOjE2IG9icmllbiBF eHAgJA0KIA0KLVNVQkRJUj0JYXRtIFwNCi0JYXRtY29uZmlnIFwNCi0JZm9y ZV9kbmxkIFwNCi0JaWxtaWQNCitTVUJESVI9CWF0bWNvbmZpZw0KKw0KKyMg RGlzYWJsZWQgaW4gNy4wIGFzIG5ldGF0bSBpcyBub3QgTVBTQUZFLg0KKyMJ YXRtIFwNCisjCWZvcmVfZG5sZCBcDQorIwlpbG1pZA0KIA0KIC5pbmNsdWRl IDxic2Quc3ViZGlyLm1rPg0KSW5kZXg6IHNoYXJlL2V4YW1wbGVzL01ha2Vm aWxlDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09DQpSQ1MgZmlsZTogL3pvby9j dnN1cC9GcmVlQlNELUNWUy9zcmMvc2hhcmUvZXhhbXBsZXMvTWFrZWZpbGUs dg0KcmV0cmlldmluZyByZXZpc2lvbiAxLjUwDQpkaWZmIC11IC1yMS41MCBN YWtlZmlsZQ0KLS0tIHNoYXJlL2V4YW1wbGVzL01ha2VmaWxlCTI0IEFwciAy MDA3IDE2OjU4OjU0IC0wMDAwCTEuNTANCisrKyBzaGFyZS9leGFtcGxlcy9N YWtlZmlsZQkxMSBKdWwgMjAwNyAxMDozNjoyNiAtMDAwMA0KQEAgLTcsNyAr Nyw2IEBADQogTERJUlM9CUJTRF9kYWVtb24gXA0KIAlGcmVlQlNEX3ZlcnNp b24gXA0KIAlJUHY2IFwNCi0JYXRtIFwNCiAJYm9vdGZvcnRoIFwNCiAJY3Zz dXAgXA0KIAlkaXNrbGVzcyBcDQpAQCAtMzUsNiArMzQsOSBAQA0KIAlzdGFy dHNsaXAgXA0KIAlzdW5ycGMNCiANCisjIERpc2FibGVkIGluIDcuMCBhcyBu ZXRhdG0gaXMgbm90IE1QU0FGRS4NCisjTERJUlMrPQlhdG0NCisNCiBYRklM RVM9CUJTRF9kYWVtb24vRnJlZUJTRC5wZmEgXA0KIAlCU0RfZGFlbW9uL1JF QURNRSBcDQogCUJTRF9kYWVtb24vYmVhc3RpZS5lcHMgXA0KQEAgLTQ1LDE1 ICs0Nyw2IEBADQogCUZyZWVCU0RfdmVyc2lvbi9NYWtlZmlsZSBcDQogCUZy ZWVCU0RfdmVyc2lvbi9SRUFETUUgXA0KIAlJUHY2L1VTQUdFIFwNCi0JYXRt L05PVEVTIFwNCi0JYXRtL1JFQURNRSBcDQotCWF0bS9TdGFydHVwIFwNCi0J YXRtL2F0bS1jb25maWcuc2ggXA0KLQlhdG0vYXRtLXNvY2tldHMudHh0IFwN Ci0JYXRtL2NwY3MtZGVzaWduLnR4dCBcDQotCWF0bS9mb3JlLW1pY3JvY29k ZS50eHQgXA0KLQlhdG0vc3NjZi1kZXNpZ24udHh0IFwNCi0JYXRtL3NzY29w LWRlc2lnbi50eHQgXA0KIAlib290Zm9ydGgvUkVBRE1FIFwNCiAJYm9vdGZv cnRoL2Jvb3QuNHRoIFwNCiAJYm9vdGZvcnRoL2ZyYW1lcy40dGggXA0KQEAg LTI0Niw2ICsyMzksMTcgQEANCiAJc3VucnBjL3NvcnQvc29ydC54IFwNCiAJ c3VucnBjL3NvcnQvc29ydF9wcm9jLmMNCiANCisjIERpc2FibGVkIGluIDcu MCBhcyBuZXRhdG0gaXMgbm90IE1QU0FGRS4NCisjWEZJTEVTKz0JYXRtL05P VEVTIFwNCisjCWF0bS9SRUFETUUgXA0KKyMJYXRtL1N0YXJ0dXAgXA0KKyMJ YXRtL2F0bS1jb25maWcuc2ggXA0KKyMJYXRtL2F0bS1zb2NrZXRzLnR4dCBc DQorIwlhdG0vY3Bjcy1kZXNpZ24udHh0IFwNCisjCWF0bS9mb3JlLW1pY3Jv Y29kZS50eHQgXA0KKyMJYXRtL3NzY2YtZGVzaWduLnR4dCBcDQorIwlhdG0v c3Njb3AtZGVzaWduLnR4dA0KKw0KIEJJTkRJUj0gJHtTSEFSRURJUn0vZXhh bXBsZXMNCiANCiBOT19PQko9DQpJbmRleDogc3lzL2NvbmYvTk9URVMNCj09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT0NClJDUyBmaWxlOiAvem9vL2N2c3VwL0Zy ZWVCU0QtQ1ZTL3NyYy9zeXMvY29uZi9OT1RFUyx2DQpyZXRyaWV2aW5nIHJl dmlzaW9uIDEuMTQ0MQ0KZGlmZiAtdSAtcjEuMTQ0MSBOT1RFUw0KLS0tIHN5 cy9jb25mL05PVEVTCTUgSnVsIDIwMDcgMTU6MzM6MTMgLTAwMDAJMS4xNDQx DQorKysgc3lzL2NvbmYvTk9URVMJNiBKdWwgMjAwNyAxMjo1MjoxOSAtMDAw MA0KQEAgLTg5OSw2ICs4OTksOCBAQA0KICMNCiAjIEFUTSAoSEFSUCB2ZXJz aW9uKSBvcHRpb25zDQogIw0KKyMgWFhYOiBUaGVzZSBoYXZlIGJlZW4gZGlz YWJsZWQgaW4gRnJlZUJTRCA3LjAgYXMgdGhleSBhcmUgbm90IE1QU0FGRS4N CisjDQogIyBBVE1fQ09SRSBpbmNsdWRlcyB0aGUgYmFzZSBBVE0gZnVuY3Rp b25hbGl0eSBjb2RlLiAgVGhpcyBtdXN0IGJlIGluY2x1ZGVkDQogIwlmb3Ig QVRNIHN1cHBvcnQuDQogIw0KQEAgLTkxNywxNCArOTE5LDE0IEBADQogIw0K ICMgVGhlIGBoYXJwJyBwc2V1ZG8tZHJpdmVyIG1ha2VzIGFsbCBOQVRNIGlu dGVyZmFjZSBkcml2ZXJzIGF2YWlsYWJsZSB0byBIQVJQLg0KICMNCi1vcHRp b25zIAlBVE1fQ09SRQkJI2NvcmUgQVRNIHByb3RvY29sIGZhbWlseQ0KLW9w dGlvbnMgCUFUTV9JUAkJCSNJUCBvdmVyIEFUTSBzdXBwb3J0DQotb3B0aW9u cyAJQVRNX1NJR1BWQwkJI1NJR1BWQyBzaWduYWxsaW5nIG1hbmFnZXINCi1v cHRpb25zIAlBVE1fU1BBTlMJCSNTUEFOUyBzaWduYWxsaW5nIG1hbmFnZXIN Ci1vcHRpb25zIAlBVE1fVU5JCQkJI1VOSSBzaWduYWxsaW5nIG1hbmFnZXIN Cisjb3B0aW9ucyAJQVRNX0NPUkUJCSNjb3JlIEFUTSBwcm90b2NvbCBmYW1p bHkNCisjb3B0aW9ucyAJQVRNX0lQCQkJI0lQIG92ZXIgQVRNIHN1cHBvcnQN Cisjb3B0aW9ucyAJQVRNX1NJR1BWQwkJI1NJR1BWQyBzaWduYWxsaW5nIG1h bmFnZXINCisjb3B0aW9ucyAJQVRNX1NQQU5TCQkjU1BBTlMgc2lnbmFsbGlu ZyBtYW5hZ2VyDQorI29wdGlvbnMgCUFUTV9VTkkJCQkjVU5JIHNpZ25hbGxp bmcgbWFuYWdlcg0KIA0KLWRldmljZQkJaGZhCQkJI0ZPUkUgUENBLTIwMEUg QVRNIFBDSQ0KLWRldmljZQkJaGFycAkJCSNQc2V1ZG8taW50ZXJmYWNlIGZv ciBOQVRNDQorI2RldmljZQkJaGZhCQkJI0ZPUkUgUENBLTIwMEUgQVRNIFBD SQ0KKyNkZXZpY2UJCWhhcnAJCQkjUHNldWRvLWludGVyZmFjZSBmb3IgTkFU TQ0KIA0KIAwNCiAjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMNCkluZGV4OiBz eXMvY29uZi9maWxlcw0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KUkNTIGZp bGU6IC96b28vY3ZzdXAvRnJlZUJTRC1DVlMvc3JjL3N5cy9jb25mL2ZpbGVz LHYNCnJldHJpZXZpbmcgcmV2aXNpb24gMS4xMjM0DQpkaWZmIC11IC1yMS4x MjM0IGZpbGVzDQotLS0gc3lzL2NvbmYvZmlsZXMJNSBKdWwgMjAwNyAxNToy ODo1OSAtMDAwMAkxLjEyMzQNCisrKyBzeXMvY29uZi9maWxlcwk2IEp1bCAy MDA3IDEyOjUyOjE5IC0wMDAwDQpAQCAtNjY2LDI4ICs2NjYsMjggQEANCiBk ZXYvZnhwL2lmX2Z4cC5jCQlvcHRpb25hbCBmeHANCiBkZXYvZ2VtL2lmX2dl bS5jCQlvcHRpb25hbCBnZW0NCiBkZXYvZ2VtL2lmX2dlbV9wY2kuYwkJb3B0 aW9uYWwgZ2VtIHBjaQ0KLWRldi9oYXJwL2lmX2hhcnAuYwkJb3B0aW9uYWwg aGFycCBwY2kNCisjZGV2L2hhcnAvaWZfaGFycC5jCQlvcHRpb25hbCBoYXJw IHBjaQ0KIGRldi9oYXRtL2lmX2hhdG0uYwkJb3B0aW9uYWwgaGF0bSBwY2kN CiBkZXYvaGF0bS9pZl9oYXRtX2ludHIuYwkJb3B0aW9uYWwgaGF0bSBwY2kN CiBkZXYvaGF0bS9pZl9oYXRtX2lvY3RsLmMJb3B0aW9uYWwgaGF0bSBwY2kN CiBkZXYvaGF0bS9pZl9oYXRtX3J4LmMJCW9wdGlvbmFsIGhhdG0gcGNpDQog ZGV2L2hhdG0vaWZfaGF0bV90eC5jCQlvcHRpb25hbCBoYXRtIHBjaQ0KLWRl di9oZmEvZm9yZV9idWZmZXIuYwkJb3B0aW9uYWwgaGZhDQotZGV2L2hmYS9m b3JlX2NvbW1hbmQuYwkJb3B0aW9uYWwgaGZhDQotZGV2L2hmYS9mb3JlX2ds b2JhbHMuYwkJb3B0aW9uYWwgaGZhDQotZGV2L2hmYS9mb3JlX2lmLmMJCW9w dGlvbmFsIGhmYQ0KLWRldi9oZmEvZm9yZV9pbml0LmMJCW9wdGlvbmFsIGhm YQ0KLWRldi9oZmEvZm9yZV9pbnRyLmMJCW9wdGlvbmFsIGhmYQ0KLWRldi9o ZmEvZm9yZV9vdXRwdXQuYwkJb3B0aW9uYWwgaGZhDQotZGV2L2hmYS9mb3Jl X3JlY2VpdmUuYwkJb3B0aW9uYWwgaGZhDQotZGV2L2hmYS9mb3JlX3N0YXRz LmMJCW9wdGlvbmFsIGhmYQ0KLWRldi9oZmEvZm9yZV90aW1lci5jCQlvcHRp b25hbCBoZmENCi1kZXYvaGZhL2ZvcmVfdHJhbnNtaXQuYwkJb3B0aW9uYWwg aGZhDQotZGV2L2hmYS9mb3JlX3ZjbS5jCQlvcHRpb25hbCBoZmENCi0jZGV2 L2hmYS9oZmFfZWlzYS5jCQlvcHRpb25hbCBoZmEgZWlzYQ0KLWRldi9oZmEv aGZhX2ZyZWVic2QuYwkJb3B0aW9uYWwgaGZhDQotZGV2L2hmYS9oZmFfcGNp LmMJCW9wdGlvbmFsIGhmYSBwY2kNCi0jZGV2L2hmYS9oZmFfc2J1cy5jCQlv cHRpb25hbCBoZmEgc2J1cw0KKyNkZXYvaGZhL2ZvcmVfYnVmZmVyLmMJCW9w dGlvbmFsIGhmYQ0KKyNkZXYvaGZhL2ZvcmVfY29tbWFuZC5jCQlvcHRpb25h bCBoZmENCisjZGV2L2hmYS9mb3JlX2dsb2JhbHMuYwkJb3B0aW9uYWwgaGZh DQorI2Rldi9oZmEvZm9yZV9pZi5jCQlvcHRpb25hbCBoZmENCisjZGV2L2hm YS9mb3JlX2luaXQuYwkJb3B0aW9uYWwgaGZhDQorI2Rldi9oZmEvZm9yZV9p bnRyLmMJCW9wdGlvbmFsIGhmYQ0KKyNkZXYvaGZhL2ZvcmVfb3V0cHV0LmMJ CW9wdGlvbmFsIGhmYQ0KKyNkZXYvaGZhL2ZvcmVfcmVjZWl2ZS5jCQlvcHRp b25hbCBoZmENCisjZGV2L2hmYS9mb3JlX3N0YXRzLmMJCW9wdGlvbmFsIGhm YQ0KKyNkZXYvaGZhL2ZvcmVfdGltZXIuYwkJb3B0aW9uYWwgaGZhDQorI2Rl di9oZmEvZm9yZV90cmFuc21pdC5jCQlvcHRpb25hbCBoZmENCisjZGV2L2hm YS9mb3JlX3ZjbS5jCQlvcHRpb25hbCBoZmENCisjI2Rldi9oZmEvaGZhX2Vp c2EuYwkJb3B0aW9uYWwgaGZhIGVpc2ENCisjZGV2L2hmYS9oZmFfZnJlZWJz ZC5jCQlvcHRpb25hbCBoZmENCisjZGV2L2hmYS9oZmFfcGNpLmMJCW9wdGlv bmFsIGhmYSBwY2kNCisjI2Rldi9oZmEvaGZhX3NidXMuYwkJb3B0aW9uYWwg aGZhIHNidXMNCiBkZXYvaGlmbi9oaWZuNzc1MS5jCQlvcHRpb25hbCBoaWZu DQogZGV2L2htZS9pZl9obWUuYwkJb3B0aW9uYWwgaG1lDQogZGV2L2htZS9p Zl9obWVfcGNpLmMJCW9wdGlvbmFsIGhtZSBwY2kNCkBAIC0xNjUwLDg4ICsx NjUwLDkyIEBADQogbmV0YXRhbGsvZGRwX291dHB1dC5jCQlvcHRpb25hbCBu ZXRhdGFsaw0KIG5ldGF0YWxrL2RkcF9wY2IuYwkJb3B0aW9uYWwgbmV0YXRh bGsNCiBuZXRhdGFsay9kZHBfdXNycmVxLmMJCW9wdGlvbmFsIG5ldGF0YWxr DQotbmV0YXRtL2F0bV9hYWw1LmMJCW9wdGlvbmFsIGF0bV9jb3JlDQotbmV0 YXRtL2F0bV9jbS5jCQkJb3B0aW9uYWwgYXRtX2NvcmUNCi1uZXRhdG0vYXRt X2RldmljZS5jCQlvcHRpb25hbCBhdG1fY29yZQ0KLW5ldGF0bS9hdG1faWYu YwkJCW9wdGlvbmFsIGF0bV9jb3JlDQotbmV0YXRtL2F0bV9wcm90by5jCQlv cHRpb25hbCBhdG1fY29yZQ0KLW5ldGF0bS9hdG1fc2lnbmFsLmMJCW9wdGlv bmFsIGF0bV9jb3JlDQotbmV0YXRtL2F0bV9zb2NrZXQuYwkJb3B0aW9uYWwg YXRtX2NvcmUNCi1uZXRhdG0vYXRtX3N1YnIuYwkJb3B0aW9uYWwgYXRtX2Nv cmUNCi1uZXRhdG0vYXRtX3VzcnJlcS5jCQlvcHRpb25hbCBhdG1fY29yZQ0K LW5ldGF0bS9pcGF0bS9pcGF0bV9ldmVudC5jCW9wdGlvbmFsIGF0bV9pcCBh dG1fY29yZQ0KLW5ldGF0bS9pcGF0bS9pcGF0bV9pZi5jCQlvcHRpb25hbCBh dG1faXAgYXRtX2NvcmUNCi1uZXRhdG0vaXBhdG0vaXBhdG1faW5wdXQuYwlv cHRpb25hbCBhdG1faXAgYXRtX2NvcmUNCi1uZXRhdG0vaXBhdG0vaXBhdG1f bG9hZC5jCW9wdGlvbmFsIGF0bV9pcCBhdG1fY29yZQ0KLW5ldGF0bS9pcGF0 bS9pcGF0bV9vdXRwdXQuYwlvcHRpb25hbCBhdG1faXAgYXRtX2NvcmUNCi1u ZXRhdG0vaXBhdG0vaXBhdG1fdXNycmVxLmMJb3B0aW9uYWwgYXRtX2lwIGF0 bV9jb3JlDQotbmV0YXRtL2lwYXRtL2lwYXRtX3ZjbS5jCW9wdGlvbmFsIGF0 bV9pcCBhdG1fY29yZQ0KLW5ldGF0bS9zaWdwdmMvc2lncHZjX2lmLmMJb3B0 aW9uYWwgYXRtX3NpZ3B2YyBhdG1fY29yZQ0KLW5ldGF0bS9zaWdwdmMvc2ln cHZjX3N1YnIuYwlvcHRpb25hbCBhdG1fc2lncHZjIGF0bV9jb3JlDQotbmV0 YXRtL3NwYW5zL3NwYW5zX2FycC5jCW9wdGlvbmFsIGF0bV9zcGFucyBhdG1f Y29yZQlcDQotCWRlcGVuZGVuY3kJInNwYW5zX3hkci5oIg0KLW5ldGF0bS9z cGFucy9zcGFuc19jbHMuYwlvcHRpb25hbCBhdG1fc3BhbnMgYXRtX2NvcmUN Ci1uZXRhdG0vc3BhbnMvc3BhbnNfaWYuYwkJb3B0aW9uYWwgYXRtX3NwYW5z IGF0bV9jb3JlDQotbmV0YXRtL3NwYW5zL3NwYW5zX2t4ZHIuYwlvcHRpb25h bCBhdG1fc3BhbnMgYXRtX2NvcmUNCi1uZXRhdG0vc3BhbnMvc3BhbnNfbXNn LmMJb3B0aW9uYWwgYXRtX3NwYW5zIGF0bV9jb3JlDQotbmV0YXRtL3NwYW5z L3NwYW5zX3ByaW50LmMJb3B0aW9uYWwgYXRtX3NwYW5zIGF0bV9jb3JlDQot bmV0YXRtL3NwYW5zL3NwYW5zX3Byb3RvLmMJb3B0aW9uYWwgYXRtX3NwYW5z IGF0bV9jb3JlDQotbmV0YXRtL3NwYW5zL3NwYW5zX3N1YnIuYwlvcHRpb25h bCBhdG1fc3BhbnMgYXRtX2NvcmUNCi1uZXRhdG0vc3BhbnMvc3BhbnNfdXRp bC5jCW9wdGlvbmFsIGF0bV9zcGFucyBhdG1fY29yZQ0KLXNwYW5zX3hkci5o CQkJb3B0aW9uYWwgYXRtX3NwYW5zIGF0bV9jb3JlCVwNCi0JYmVmb3JlLWRl cGVuZAkJCQkJCVwNCi0JZGVwZW5kZW5jeQkiJFMvbmV0YXRtL3NwYW5zL3Nw YW5zX3hkci54IgkJXA0KLQljb21waWxlLXdpdGgJInJwY2dlbiAtaCAtQyAk Uy9uZXRhdG0vc3BhbnMvc3BhbnNfeGRyLnggfCBncmVwIC12IHJwYy9ycGMu aCA+IHNwYW5zX3hkci5oIiBcDQotCWNsZWFuCQkic3BhbnNfeGRyLmgiCQkJ CVwNCi0Jbm8tb2JqIG5vLWltcGxpY2l0LXJ1bGUNCi1zcGFuc194ZHIuYwkJ CW9wdGlvbmFsIGF0bV9zcGFucyBhdG1fY29yZQlcDQotCWJlZm9yZS1kZXBl bmQJCQkJCQlcDQotCWRlcGVuZGVuY3kJIiRTL25ldGF0bS9zcGFucy9zcGFu c194ZHIueCIJCVwNCi0JY29tcGlsZS13aXRoCSJycGNnZW4gLWMgLUMgJFMv bmV0YXRtL3NwYW5zL3NwYW5zX3hkci54IHwgZ3JlcCAtdiBycGMvcnBjLmgg PiBzcGFuc194ZHIuYyIgXA0KLQljbGVhbgkJInNwYW5zX3hkci5jIgkJCQlc DQotCW5vLW9iaiBuby1pbXBsaWNpdC1ydWxlIGxvY2FsDQotc3BhbnNfeGRy Lm8JCQlvcHRpb25hbCBhdG1fc3BhbnMgYXRtX2NvcmUJXA0KLQlkZXBlbmRl bmN5CSIkUy9uZXRhdG0vc3BhbnMvc3BhbnNfeGRyLngiCQlcDQotCWNvbXBp bGUtd2l0aAkiJHtOT1JNQUxfQ30iCQkJCVwNCi0Jbm8taW1wbGljaXQtcnVs ZSBsb2NhbA0KLW5ldGF0bS91bmkvcTIxMTBfc2lnYWEuYwlvcHRpb25hbCBh dG1fdW5pIGF0bV9jb3JlDQotbmV0YXRtL3VuaS9xMjExMF9zaWdjcGNzLmMJ b3B0aW9uYWwgYXRtX3VuaSBhdG1fY29yZQ0KLW5ldGF0bS91bmkvcTIxMTBf c3Vici5jCQlvcHRpb25hbCBhdG1fdW5pIGF0bV9jb3JlDQotbmV0YXRtL3Vu aS9xc2FhbDFfc2lnYWEuYwlvcHRpb25hbCBhdG1fdW5pIGF0bV9jb3JlDQot bmV0YXRtL3VuaS9xc2FhbDFfc2lnY3Bjcy5jCW9wdGlvbmFsIGF0bV91bmkg YXRtX2NvcmUNCi1uZXRhdG0vdW5pL3FzYWFsMV9zdWJyLmMJb3B0aW9uYWwg YXRtX3VuaSBhdG1fY29yZQ0KLW5ldGF0bS91bmkvc3NjZl91bmkuYwkJb3B0 aW9uYWwgYXRtX3VuaSBhdG1fY29yZQ0KLW5ldGF0bS91bmkvc3NjZl91bmlf bG93ZXIuYwlvcHRpb25hbCBhdG1fdW5pIGF0bV9jb3JlDQotbmV0YXRtL3Vu aS9zc2NmX3VuaV91cHBlci5jCW9wdGlvbmFsIGF0bV91bmkgYXRtX2NvcmUN Ci1uZXRhdG0vdW5pL3NzY29wLmMJCW9wdGlvbmFsIGF0bV91bmkgYXRtX2Nv cmUNCi1uZXRhdG0vdW5pL3NzY29wX2xvd2VyLmMJb3B0aW9uYWwgYXRtX3Vu aSBhdG1fY29yZQ0KLW5ldGF0bS91bmkvc3Njb3BfcGR1LmMJCW9wdGlvbmFs IGF0bV91bmkgYXRtX2NvcmUNCi1uZXRhdG0vdW5pL3NzY29wX3NpZ2FhLmMJ b3B0aW9uYWwgYXRtX3VuaSBhdG1fY29yZQ0KLW5ldGF0bS91bmkvc3Njb3Bf c2lnY3Bjcy5jCW9wdGlvbmFsIGF0bV91bmkgYXRtX2NvcmUNCi1uZXRhdG0v dW5pL3NzY29wX3N1YnIuYwkJb3B0aW9uYWwgYXRtX3VuaSBhdG1fY29yZQ0K LW5ldGF0bS91bmkvc3Njb3BfdGltZXIuYwlvcHRpb25hbCBhdG1fdW5pIGF0 bV9jb3JlDQotbmV0YXRtL3VuaS9zc2NvcF91cHBlci5jCW9wdGlvbmFsIGF0 bV91bmkgYXRtX2NvcmUNCi1uZXRhdG0vdW5pL3VuaV9sb2FkLmMJCW9wdGlv bmFsIGF0bV91bmkgYXRtX2NvcmUNCi1uZXRhdG0vdW5pL3VuaWFycC5jCQlv cHRpb25hbCBhdG1fdW5pIGF0bV9jb3JlDQotbmV0YXRtL3VuaS91bmlhcnBf Y2FjaGUuYwlvcHRpb25hbCBhdG1fdW5pIGF0bV9jb3JlDQotbmV0YXRtL3Vu aS91bmlhcnBfaW5wdXQuYwlvcHRpb25hbCBhdG1fdW5pIGF0bV9jb3JlDQot bmV0YXRtL3VuaS91bmlhcnBfb3V0cHV0LmMJb3B0aW9uYWwgYXRtX3VuaSBh dG1fY29yZQ0KLW5ldGF0bS91bmkvdW5pYXJwX3RpbWVyLmMJb3B0aW9uYWwg YXRtX3VuaSBhdG1fY29yZQ0KLW5ldGF0bS91bmkvdW5pYXJwX3ZjbS5jCQlv cHRpb25hbCBhdG1fdW5pIGF0bV9jb3JlDQotbmV0YXRtL3VuaS91bmlpcC5j CQlvcHRpb25hbCBhdG1fdW5pIGF0bV9jb3JlDQotbmV0YXRtL3VuaS91bmlz aWdfZGVjb2RlLmMJb3B0aW9uYWwgYXRtX3VuaSBhdG1fY29yZQ0KLW5ldGF0 bS91bmkvdW5pc2lnX2VuY29kZS5jCW9wdGlvbmFsIGF0bV91bmkgYXRtX2Nv cmUNCi1uZXRhdG0vdW5pL3VuaXNpZ19pZi5jCQlvcHRpb25hbCBhdG1fdW5p IGF0bV9jb3JlDQotbmV0YXRtL3VuaS91bmlzaWdfbWJ1Zi5jCW9wdGlvbmFs IGF0bV91bmkgYXRtX2NvcmUNCi1uZXRhdG0vdW5pL3VuaXNpZ19tc2cuYwkJ b3B0aW9uYWwgYXRtX3VuaSBhdG1fY29yZQ0KLW5ldGF0bS91bmkvdW5pc2ln X3ByaW50LmMJb3B0aW9uYWwgYXRtX3VuaSBhdG1fY29yZQ0KLW5ldGF0bS91 bmkvdW5pc2lnX3Byb3RvLmMJb3B0aW9uYWwgYXRtX3VuaSBhdG1fY29yZQ0K LW5ldGF0bS91bmkvdW5pc2lnX3NpZ21ncl9zdGF0ZS5jIG9wdGlvbmFsIGF0 bV91bmkgYXRtX2NvcmUNCi1uZXRhdG0vdW5pL3VuaXNpZ19zdWJyLmMJb3B0 aW9uYWwgYXRtX3VuaSBhdG1fY29yZQ0KLW5ldGF0bS91bmkvdW5pc2lnX3V0 aWwuYwlvcHRpb25hbCBhdG1fdW5pIGF0bV9jb3JlDQotbmV0YXRtL3VuaS91 bmlzaWdfdmNfc3RhdGUuYwlvcHRpb25hbCBhdG1fdW5pIGF0bV9jb3JlDQot bmV0Z3JhcGgvYXRtL2F0bXBpZi9uZ19hdG1waWYuYwlvcHRpb25hbCBuZXRn cmFwaF9hdG1fYXRtcGlmDQotbmV0Z3JhcGgvYXRtL2F0bXBpZi9uZ19hdG1w aWZfaGFycC5jIG9wdGlvbmFsIG5ldGdyYXBoX2F0bV9hdG1waWYNCisjDQor IyBuZXRhdG0gaGFzIGJlZW4gZGlzY29ubmVjdGVkIGZyb20gdGhlIGJ1aWxk IHVudGlsIGl0IGlzIE1QU0FGRSwgb3INCisjIGFsdGVybmF0aXZlbHksIHVu dGlsIGl0IGlzIHJlbW92ZWQuDQorIw0KKyNuZXRhdG0vYXRtX2FhbDUuYwkJ b3B0aW9uYWwgYXRtX2NvcmUNCisjbmV0YXRtL2F0bV9jbS5jCQkJb3B0aW9u YWwgYXRtX2NvcmUNCisjbmV0YXRtL2F0bV9kZXZpY2UuYwkJb3B0aW9uYWwg YXRtX2NvcmUNCisjbmV0YXRtL2F0bV9pZi5jCQkJb3B0aW9uYWwgYXRtX2Nv cmUNCisjbmV0YXRtL2F0bV9wcm90by5jCQlvcHRpb25hbCBhdG1fY29yZQ0K KyNuZXRhdG0vYXRtX3NpZ25hbC5jCQlvcHRpb25hbCBhdG1fY29yZQ0KKyNu ZXRhdG0vYXRtX3NvY2tldC5jCQlvcHRpb25hbCBhdG1fY29yZQ0KKyNuZXRh dG0vYXRtX3N1YnIuYwkJb3B0aW9uYWwgYXRtX2NvcmUNCisjbmV0YXRtL2F0 bV91c3JyZXEuYwkJb3B0aW9uYWwgYXRtX2NvcmUNCisjbmV0YXRtL2lwYXRt L2lwYXRtX2V2ZW50LmMJb3B0aW9uYWwgYXRtX2lwIGF0bV9jb3JlDQorI25l dGF0bS9pcGF0bS9pcGF0bV9pZi5jCQlvcHRpb25hbCBhdG1faXAgYXRtX2Nv cmUNCisjbmV0YXRtL2lwYXRtL2lwYXRtX2lucHV0LmMJb3B0aW9uYWwgYXRt X2lwIGF0bV9jb3JlDQorI25ldGF0bS9pcGF0bS9pcGF0bV9sb2FkLmMJb3B0 aW9uYWwgYXRtX2lwIGF0bV9jb3JlDQorI25ldGF0bS9pcGF0bS9pcGF0bV9v dXRwdXQuYwlvcHRpb25hbCBhdG1faXAgYXRtX2NvcmUNCisjbmV0YXRtL2lw YXRtL2lwYXRtX3VzcnJlcS5jCW9wdGlvbmFsIGF0bV9pcCBhdG1fY29yZQ0K KyNuZXRhdG0vaXBhdG0vaXBhdG1fdmNtLmMJb3B0aW9uYWwgYXRtX2lwIGF0 bV9jb3JlDQorI25ldGF0bS9zaWdwdmMvc2lncHZjX2lmLmMJb3B0aW9uYWwg YXRtX3NpZ3B2YyBhdG1fY29yZQ0KKyNuZXRhdG0vc2lncHZjL3NpZ3B2Y19z dWJyLmMJb3B0aW9uYWwgYXRtX3NpZ3B2YyBhdG1fY29yZQ0KKyNuZXRhdG0v c3BhbnMvc3BhbnNfYXJwLmMJb3B0aW9uYWwgYXRtX3NwYW5zIGF0bV9jb3Jl CVwNCisjCWRlcGVuZGVuY3kJInNwYW5zX3hkci5oIg0KKyNuZXRhdG0vc3Bh bnMvc3BhbnNfY2xzLmMJb3B0aW9uYWwgYXRtX3NwYW5zIGF0bV9jb3JlDQor I25ldGF0bS9zcGFucy9zcGFuc19pZi5jCQlvcHRpb25hbCBhdG1fc3BhbnMg YXRtX2NvcmUNCisjbmV0YXRtL3NwYW5zL3NwYW5zX2t4ZHIuYwlvcHRpb25h bCBhdG1fc3BhbnMgYXRtX2NvcmUNCisjbmV0YXRtL3NwYW5zL3NwYW5zX21z Zy5jCW9wdGlvbmFsIGF0bV9zcGFucyBhdG1fY29yZQ0KKyNuZXRhdG0vc3Bh bnMvc3BhbnNfcHJpbnQuYwlvcHRpb25hbCBhdG1fc3BhbnMgYXRtX2NvcmUN CisjbmV0YXRtL3NwYW5zL3NwYW5zX3Byb3RvLmMJb3B0aW9uYWwgYXRtX3Nw YW5zIGF0bV9jb3JlDQorI25ldGF0bS9zcGFucy9zcGFuc19zdWJyLmMJb3B0 aW9uYWwgYXRtX3NwYW5zIGF0bV9jb3JlDQorI25ldGF0bS9zcGFucy9zcGFu c191dGlsLmMJb3B0aW9uYWwgYXRtX3NwYW5zIGF0bV9jb3JlDQorI3NwYW5z X3hkci5oCQkJb3B0aW9uYWwgYXRtX3NwYW5zIGF0bV9jb3JlCVwNCisjCWJl Zm9yZS1kZXBlbmQJCQkJCQlcDQorIwlkZXBlbmRlbmN5CSIkUy9uZXRhdG0v c3BhbnMvc3BhbnNfeGRyLngiCQlcDQorIwljb21waWxlLXdpdGgJInJwY2dl biAtaCAtQyAkUy9uZXRhdG0vc3BhbnMvc3BhbnNfeGRyLnggfCBncmVwIC12 IHJwYy9ycGMuaCA+IHNwYW5zX3hkci5oIiBcDQorIwljbGVhbgkJInNwYW5z X3hkci5oIgkJCQlcDQorIwluby1vYmogbm8taW1wbGljaXQtcnVsZQ0KKyNz cGFuc194ZHIuYwkJCW9wdGlvbmFsIGF0bV9zcGFucyBhdG1fY29yZQlcDQor IwliZWZvcmUtZGVwZW5kCQkJCQkJXA0KKyMJZGVwZW5kZW5jeQkiJFMvbmV0 YXRtL3NwYW5zL3NwYW5zX3hkci54IgkJXA0KKyMJY29tcGlsZS13aXRoCSJy cGNnZW4gLWMgLUMgJFMvbmV0YXRtL3NwYW5zL3NwYW5zX3hkci54IHwgZ3Jl cCAtdiBycGMvcnBjLmggPiBzcGFuc194ZHIuYyIgXA0KKyMJY2xlYW4JCSJz cGFuc194ZHIuYyIJCQkJXA0KKyMJbm8tb2JqIG5vLWltcGxpY2l0LXJ1bGUg bG9jYWwNCisjc3BhbnNfeGRyLm8JCQlvcHRpb25hbCBhdG1fc3BhbnMgYXRt X2NvcmUJXA0KKyMJZGVwZW5kZW5jeQkiJFMvbmV0YXRtL3NwYW5zL3NwYW5z X3hkci54IgkJXA0KKyMJY29tcGlsZS13aXRoCSIke05PUk1BTF9DfSIJCQkJ XA0KKyMJbm8taW1wbGljaXQtcnVsZSBsb2NhbA0KKyNuZXRhdG0vdW5pL3Ey MTEwX3NpZ2FhLmMJb3B0aW9uYWwgYXRtX3VuaSBhdG1fY29yZQ0KKyNuZXRh dG0vdW5pL3EyMTEwX3NpZ2NwY3MuYwlvcHRpb25hbCBhdG1fdW5pIGF0bV9j b3JlDQorI25ldGF0bS91bmkvcTIxMTBfc3Vici5jCQlvcHRpb25hbCBhdG1f dW5pIGF0bV9jb3JlDQorI25ldGF0bS91bmkvcXNhYWwxX3NpZ2FhLmMJb3B0 aW9uYWwgYXRtX3VuaSBhdG1fY29yZQ0KKyNuZXRhdG0vdW5pL3FzYWFsMV9z aWdjcGNzLmMJb3B0aW9uYWwgYXRtX3VuaSBhdG1fY29yZQ0KKyNuZXRhdG0v dW5pL3FzYWFsMV9zdWJyLmMJb3B0aW9uYWwgYXRtX3VuaSBhdG1fY29yZQ0K KyNuZXRhdG0vdW5pL3NzY2ZfdW5pLmMJCW9wdGlvbmFsIGF0bV91bmkgYXRt X2NvcmUNCisjbmV0YXRtL3VuaS9zc2NmX3VuaV9sb3dlci5jCW9wdGlvbmFs IGF0bV91bmkgYXRtX2NvcmUNCisjbmV0YXRtL3VuaS9zc2NmX3VuaV91cHBl ci5jCW9wdGlvbmFsIGF0bV91bmkgYXRtX2NvcmUNCisjbmV0YXRtL3VuaS9z c2NvcC5jCQlvcHRpb25hbCBhdG1fdW5pIGF0bV9jb3JlDQorI25ldGF0bS91 bmkvc3Njb3BfbG93ZXIuYwlvcHRpb25hbCBhdG1fdW5pIGF0bV9jb3JlDQor I25ldGF0bS91bmkvc3Njb3BfcGR1LmMJCW9wdGlvbmFsIGF0bV91bmkgYXRt X2NvcmUNCisjbmV0YXRtL3VuaS9zc2NvcF9zaWdhYS5jCW9wdGlvbmFsIGF0 bV91bmkgYXRtX2NvcmUNCisjbmV0YXRtL3VuaS9zc2NvcF9zaWdjcGNzLmMJ b3B0aW9uYWwgYXRtX3VuaSBhdG1fY29yZQ0KKyNuZXRhdG0vdW5pL3NzY29w X3N1YnIuYwkJb3B0aW9uYWwgYXRtX3VuaSBhdG1fY29yZQ0KKyNuZXRhdG0v dW5pL3NzY29wX3RpbWVyLmMJb3B0aW9uYWwgYXRtX3VuaSBhdG1fY29yZQ0K KyNuZXRhdG0vdW5pL3NzY29wX3VwcGVyLmMJb3B0aW9uYWwgYXRtX3VuaSBh dG1fY29yZQ0KKyNuZXRhdG0vdW5pL3VuaV9sb2FkLmMJCW9wdGlvbmFsIGF0 bV91bmkgYXRtX2NvcmUNCisjbmV0YXRtL3VuaS91bmlhcnAuYwkJb3B0aW9u YWwgYXRtX3VuaSBhdG1fY29yZQ0KKyNuZXRhdG0vdW5pL3VuaWFycF9jYWNo ZS5jCW9wdGlvbmFsIGF0bV91bmkgYXRtX2NvcmUNCisjbmV0YXRtL3VuaS91 bmlhcnBfaW5wdXQuYwlvcHRpb25hbCBhdG1fdW5pIGF0bV9jb3JlDQorI25l dGF0bS91bmkvdW5pYXJwX291dHB1dC5jCW9wdGlvbmFsIGF0bV91bmkgYXRt X2NvcmUNCisjbmV0YXRtL3VuaS91bmlhcnBfdGltZXIuYwlvcHRpb25hbCBh dG1fdW5pIGF0bV9jb3JlDQorI25ldGF0bS91bmkvdW5pYXJwX3ZjbS5jCQlv cHRpb25hbCBhdG1fdW5pIGF0bV9jb3JlDQorI25ldGF0bS91bmkvdW5paXAu YwkJb3B0aW9uYWwgYXRtX3VuaSBhdG1fY29yZQ0KKyNuZXRhdG0vdW5pL3Vu aXNpZ19kZWNvZGUuYwlvcHRpb25hbCBhdG1fdW5pIGF0bV9jb3JlDQorI25l dGF0bS91bmkvdW5pc2lnX2VuY29kZS5jCW9wdGlvbmFsIGF0bV91bmkgYXRt X2NvcmUNCisjbmV0YXRtL3VuaS91bmlzaWdfaWYuYwkJb3B0aW9uYWwgYXRt X3VuaSBhdG1fY29yZQ0KKyNuZXRhdG0vdW5pL3VuaXNpZ19tYnVmLmMJb3B0 aW9uYWwgYXRtX3VuaSBhdG1fY29yZQ0KKyNuZXRhdG0vdW5pL3VuaXNpZ19t c2cuYwkJb3B0aW9uYWwgYXRtX3VuaSBhdG1fY29yZQ0KKyNuZXRhdG0vdW5p L3VuaXNpZ19wcmludC5jCW9wdGlvbmFsIGF0bV91bmkgYXRtX2NvcmUNCisj bmV0YXRtL3VuaS91bmlzaWdfcHJvdG8uYwlvcHRpb25hbCBhdG1fdW5pIGF0 bV9jb3JlDQorI25ldGF0bS91bmkvdW5pc2lnX3NpZ21ncl9zdGF0ZS5jIG9w dGlvbmFsIGF0bV91bmkgYXRtX2NvcmUNCisjbmV0YXRtL3VuaS91bmlzaWdf c3Vici5jCW9wdGlvbmFsIGF0bV91bmkgYXRtX2NvcmUNCisjbmV0YXRtL3Vu aS91bmlzaWdfdXRpbC5jCW9wdGlvbmFsIGF0bV91bmkgYXRtX2NvcmUNCisj bmV0YXRtL3VuaS91bmlzaWdfdmNfc3RhdGUuYwlvcHRpb25hbCBhdG1fdW5p IGF0bV9jb3JlDQorI25ldGdyYXBoL2F0bS9hdG1waWYvbmdfYXRtcGlmLmMJ b3B0aW9uYWwgbmV0Z3JhcGhfYXRtX2F0bXBpZg0KKyNuZXRncmFwaC9hdG0v YXRtcGlmL25nX2F0bXBpZl9oYXJwLmMgb3B0aW9uYWwgbmV0Z3JhcGhfYXRt X2F0bXBpZg0KIG5ldGdyYXBoL2F0bS9jY2F0bS9uZ19jY2F0bS5jCW9wdGlv bmFsIG5nYXRtX2NjYXRtIFwNCiAJY29tcGlsZS13aXRoICIke05PUk1BTF9D fSAtSSRTL2NvbnRyaWIvbmdhdG0iDQogbmV0Z3JhcGgvYXRtL25nX2F0bS5j CQlvcHRpb25hbCBuZ2F0bV9hdG0NCkluZGV4OiBzeXMvY29uZi9vcHRpb25z DQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09DQpSQ1MgZmlsZTogL3pvby9jdnN1 cC9GcmVlQlNELUNWUy9zcmMvc3lzL2NvbmYvb3B0aW9ucyx2DQpyZXRyaWV2 aW5nIHJldmlzaW9uIDEuNjAwDQpkaWZmIC11IC1yMS42MDAgb3B0aW9ucw0K LS0tIHN5cy9jb25mL29wdGlvbnMJNiBKdWwgMjAwNyAxMzoyMDo0MyAtMDAw MAkxLjYwMA0KKysrIHN5cy9jb25mL29wdGlvbnMJNyBKdWwgMjAwNyAxMzox Mjo1MyAtMDAwMA0KQEAgLTQ4MSwxMiArNDgxLDEyIEBADQogVElfUFJJVkFU RV9KVU1CT1MJb3B0X3RpLmgNCiBUSV9KVU1CT19IRFJTUExJVAlvcHRfdGku aA0KIA0KLSMgQVRNIChIQVJQIHZlcnNpb24pDQotQVRNX0NPUkUJCW9wdF9h dG0uaA0KLUFUTV9JUAkJCW9wdF9hdG0uaA0KLUFUTV9TSUdQVkMJCW9wdF9h dG0uaA0KLUFUTV9TUEFOUwkJb3B0X2F0bS5oDQotQVRNX1VOSQkJCW9wdF9h dG0uaA0KKyMgQVRNIChIQVJQIHZlcnNpb24pIC0gZGlzYWJsZWQgYXMgbm90 IE1QU0FGRSBpbiA3LjANCisjQVRNX0NPUkUJCW9wdF9hdG0uaA0KKyNBVE1f SVAJCQlvcHRfYXRtLmgNCisjQVRNX1NJR1BWQwkJb3B0X2F0bS5oDQorI0FU TV9TUEFOUwkJb3B0X2F0bS5oDQorI0FUTV9VTkkJCQlvcHRfYXRtLmgNCiAN CiAjIFhYWCBDb25mbGljdDogIyBvZiBkZXZpY2VzIHZzIG5ldHdvcmsgcHJv dG9jb2wgKE5hdGl2ZSBBVE0pLg0KICMgVGhpcyBtYWtlcyAiYXRtLmgiIHVu dXNhYmxlLg0KSW5kZXg6IHN5cy9tb2R1bGVzL01ha2VmaWxlDQo9PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09DQpSQ1MgZmlsZTogL3pvby9jdnN1cC9GcmVlQlNE LUNWUy9zcmMvc3lzL21vZHVsZXMvTWFrZWZpbGUsdg0KcmV0cmlldmluZyBy ZXZpc2lvbiAxLjUzNQ0KZGlmZiAtdSAtcjEuNTM1IE1ha2VmaWxlDQotLS0g c3lzL21vZHVsZXMvTWFrZWZpbGUJMzAgSnVuIDIwMDcgMDQ6MzU6MzQgLTAw MDAJMS41MzUNCisrKyBzeXMvbW9kdWxlcy9NYWtlZmlsZQkxMCBKdWwgMjAw NyAyMDoxMDo0OCAtMDAwMA0KQEAgLTg4LDcgKzg4LDcgQEANCiAJZnhwIFwN CiAJJHtfZ2VtfSBcDQogCWdlb20gXA0KLQloYXJwIFwNCisJJHtfaGFycH0g XA0KIAloYXRtIFwNCiAJJHtfaGZhfSBcDQogCWhpZm4gXA0KQEAgLTMyMSw2 ICszMjEsMTEgQEANCiBfdWZzPQkJdWZzDQogLmVuZGlmDQogDQorIyBEaXNh YmxlZCBpbiA3LjAgYXMgbmV0YXRtIGlzIG5vdCBNUFNBRkUuDQorI2lmICR7 TUtfQVRNfSAhPSAibm8iDQorI19oYXJwPQkJaGFycA0KKyMuZW5kaWYNCisN CiAuaWYgJHtNS19DUllQVH0gIT0gIm5vIiB8fCBkZWZpbmVkKEFMTF9NT0RV TEVTKQ0KIC5pZiBleGlzdHMoJHsuQ1VSRElSfS8uLi9vcGVuY3J5cHRvKQ0K IF9jcnlwdG89CWNyeXB0bw0KQEAgLTM3Niw3ICszODEsOCBAQA0KIF9leGNh PQkJZXhjYQ0KIF9leHQyZnM9CWV4dDJmcw0KIF9mZT0JCWZlDQotX2hmYT0J CWhmYQ0KKyMgRGlzYWJsZWQgZHVlIHRvIG5vbi1NUFNBRkV0eSBpbiA3LjAN CisjX2hmYT0JCWhmYQ0KIF9pMmM9CQlpMmMNCiBfaWJjczI9CQlpYmNzMg0K IF9pZT0JCWllDQpAQCAtNDM3LDcgKzQ0Myw4IEBADQogX2hwdG12PQkJaHB0 bXYNCiBfaWNod2Q9CQlpY2h3ZA0KIF9pZGE9CQlpZGENCi1faWR0PQkJaWR0 DQorIyBEaXNhYmxlZCBkdWUgdG8gbm9uLU1QU0FGRXR5IGluIDcuMA0KKyNf aWR0PQkJaWR0DQogX2lpcj0JCWlpcg0KIF9pcG1pPQkJaXBtaQ0KIF9pcHM9 CQlpcHMNCkluZGV4OiBzeXMvbW9kdWxlcy9uZXRncmFwaC9hdG0vTWFrZWZp bGUNCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT0NClJDUyBmaWxlOiAvem9vL2N2 c3VwL0ZyZWVCU0QtQ1ZTL3NyYy9zeXMvbW9kdWxlcy9uZXRncmFwaC9hdG0v TWFrZWZpbGUsdg0KcmV0cmlldmluZyByZXZpc2lvbiAxLjYNCmRpZmYgLXUg LXIxLjYgTWFrZWZpbGUNCi0tLSBzeXMvbW9kdWxlcy9uZXRncmFwaC9hdG0v TWFrZWZpbGUJMTggRmViIDIwMDYgMjM6NDk6MjcgLTAwMDAJMS42DQorKysg c3lzL21vZHVsZXMvbmV0Z3JhcGgvYXRtL01ha2VmaWxlCTQgSnVsIDIwMDcg MDc6NTg6MTcgLTAwMDANCkBAIC0zLDEwICszLDEyIEBADQogU1VCRElSPQkJ CVwNCiAJYXRtIAkJXA0KIAlhdG1iYXNlCQlcDQotCWF0bXBpZgkJXA0KIAlj Y2F0bQkJXA0KIAlzc2NmdQkJXA0KIAlzc2NvcAkJXA0KIAl1bmkNCiANCisj IGF0bXBpZiBkaXNhYmxlZCBkdWUgdG8gbm9uLU1QU0FGRXR5IGluIDcuMA0K KyMJYXRtcGlmCQlcDQorDQogLmluY2x1ZGUgPGJzZC5zdWJkaXIubWs+DQpJ bmRleDogc3lzL25ldGF0bS9hdG1fcHJvdG8uYw0KPT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PQ0KUkNTIGZpbGU6IC96b28vY3ZzdXAvRnJlZUJTRC1DVlMvc3Jj L3N5cy9uZXRhdG0vYXRtX3Byb3RvLmMsdg0KcmV0cmlldmluZyByZXZpc2lv biAxLjE1DQpkaWZmIC11IC1yMS4xNSBhdG1fcHJvdG8uYw0KLS0tIHN5cy9u ZXRhdG0vYXRtX3Byb3RvLmMJMSBBcHIgMjAwNiAxNToxNTowMyAtMDAwMAkx LjE1DQorKysgc3lzL25ldGF0bS9hdG1fcHJvdG8uYwkxMCBKdWwgMjAwNyAy MDoxMTowNyAtMDAwMA0KQEAgLTUxLDcgKzUxLDcgQEANCiAjaW5jbHVkZSA8 bmV0YXRtL2F0bV9wY2IuaD4NCiAjaW5jbHVkZSA8bmV0YXRtL2F0bV92YXIu aD4NCiANCi1ORVRfTkVFRFNfR0lBTlQoIm5ldGF0bSIpOw0KKyNlcnJvciAi TkVUX05FRURTX0dJQU5UIg0KIA0KIHN0cnVjdCBwcm90b3N3IGF0bXN3W10g PSB7DQogew0KSW5kZXg6IHVzci5iaW4va2R1bXAvbWtpb2N0bHMNCj09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT0NClJDUyBmaWxlOiAvem9vL2N2c3VwL0ZyZWVC U0QtQ1ZTL3NyYy91c3IuYmluL2tkdW1wL21raW9jdGxzLHYNCnJldHJpZXZp bmcgcmV2aXNpb24gMS4zOA0KZGlmZiAtdSAtcjEuMzggbWtpb2N0bHMNCi0t LSB1c3IuYmluL2tkdW1wL21raW9jdGxzCTUgSnVuIDIwMDYgMTA6MDY6NTEg LTAwMDAJMS4zOA0KKysrIHVzci5iaW4va2R1bXAvbWtpb2N0bHMJMTEgSnVs IDIwMDcgMDE6NTA6MDQgLTAwMDANCkBAIC00NCwxMCArNDQsMTEgQEANCiAJ cHJpbnQgIiNpbmNsdWRlIDxuZXQvaWZfdmFyLmg+Ig0KIAlwcmludCAiI2lu Y2x1ZGUgPG5ldC9wZnZhci5oPiINCiAJcHJpbnQgIiNpbmNsdWRlIDxuZXQv cm91dGUuaD4iDQotCXByaW50ICIjaW5jbHVkZSA8bmV0YXRtL2F0bS5oPiIN Ci0JcHJpbnQgIiNpbmNsdWRlIDxuZXRhdG0vYXRtX2lmLmg+Ig0KLQlwcmlu dCAiI2luY2x1ZGUgPG5ldGF0bS9hdG1fc2FwLmg+Ig0KLQlwcmludCAiI2lu Y2x1ZGUgPG5ldGF0bS9hdG1fc3lzLmg+Ig0KKyMgRGlzYWJsZWQgaW4gNy4w IGFzIG5ldGF0bSBpcyBub3QgTVBTQUZFLg0KKyMJcHJpbnQgIiNpbmNsdWRl IDxuZXRhdG0vYXRtLmg+Ig0KKyMJcHJpbnQgIiNpbmNsdWRlIDxuZXRhdG0v YXRtX2lmLmg+Ig0KKyMJcHJpbnQgIiNpbmNsdWRlIDxuZXRhdG0vYXRtX3Nh cC5oPiINCisjCXByaW50ICIjaW5jbHVkZSA8bmV0YXRtL2F0bV9zeXMuaD4i DQogCXByaW50ICIjaW5jbHVkZSA8bmV0aW5ldC9pbi5oPiINCiAJcHJpbnQg IiNpbmNsdWRlIDxuZXRpbmV0L2lwX21yb3V0ZS5oPiINCiAJcHJpbnQgIiNp bmNsdWRlIDxuZXRpbmV0Ni9pbjZfdmFyLmg+Ig0KSW5kZXg6IHVzci5zYmlu L01ha2VmaWxlDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQpSQ1MgZmlsZTog L3pvby9jdnN1cC9GcmVlQlNELUNWUy9zcmMvdXNyLnNiaW4vTWFrZWZpbGUs dg0KcmV0cmlldmluZyByZXZpc2lvbiAxLjM2OQ0KZGlmZiAtdSAtcjEuMzY5 IE1ha2VmaWxlDQotLS0gdXNyLnNiaW4vTWFrZWZpbGUJMyBKdWwgMjAwNyAx Mjo0NjowNyAtMDAwMAkxLjM2OQ0KKysrIHVzci5zYmluL01ha2VmaWxlCTEw IEp1bCAyMDA3IDIwOjExOjIyIC0wMDAwDQpAQCAtMTk3LDkgKzE5NywxMCBA QA0KIF9zeXNpbnN0YWxsPQlzeXNpbnN0YWxsDQogLmVuZGlmDQogDQotLmlm ICR7TUtfQVRNfSAhPSAibm8iDQotX2F0bT0JCWF0bQ0KLS5lbmRpZg0KKyMg RGlzYWJsZWQgaW4gNy4wIGFzIG5ldGF0bSBpcyBub3QgTVBTQUZFLg0KKyMu aWYgJHtNS19BVE19ICE9ICJubyINCisjX2F0bT0JCWF0bQ0KKyMuZW5kaWYN CiANCiAuaWYgJHtNS19BVURJVH0gIT0gIm5vIg0KIF9hdWRpdD0gCWF1ZGl0 DQo= --0-188303047-1184449958=:94899--