From owner-freebsd-current@FreeBSD.ORG Sun Aug 5 00:56:34 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EB76A1065670; Sun, 5 Aug 2012 00:56:34 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 50B3B8FC08; Sun, 5 Aug 2012 00:56:33 +0000 (UTC) Received: by weyx56 with SMTP id x56so1518311wey.13 for ; Sat, 04 Aug 2012 17:56:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=llYCzuYon5y45b7ICIpEwXIxpUoDeRIGiZApDwd76FI=; b=mkDFNCFj7j8+rPa2ka+oX5dYymD7weLnAJdzJ/F5EGl+LpL9trs5QFvadRnPOVc5lH vlsBqme0v+XRAGGHJ4MKHtk3s6gTwLNU/Hq2oikRV+dfGFwZx+qlT2W3MIxNtWKt6eJL Lo9ObzbPuUV2LCOCc7CCoqDZWZ1CbmgYA6R6IT/DK6gJUlqWWVyRN5aN/QxaXvRrqjn1 KaoosT1JH/1nes214eyxtRsPQ92VcwPAr6A9L+IXnEzozYcwPJCFdWPhWMthV6QD5pLr laDrqrCL2+Mf6tpBYiwtMvMaOgPs529pKHTdmzsfVtNa0Zobcr6FKp6UuJmTrM1HiJFr wkLA== MIME-Version: 1.0 Received: by 10.180.97.33 with SMTP id dx1mr7507995wib.18.1344128192888; Sat, 04 Aug 2012 17:56:32 -0700 (PDT) Received: by 10.223.60.147 with HTTP; Sat, 4 Aug 2012 17:56:32 -0700 (PDT) In-Reply-To: <501D9476.80902@FreeBSD.org> References: <501A323E.6000106@zedat.fu-berlin.de> <1343972667.4952.5.camel@Nokia-N900-42-11> <20120803134123.GA52965@onelab2.iet.unipi.it> <501CD1F8.1070404@zedat.fu-berlin.de> <501D8589.50205@FreeBSD.org> <501D9476.80902@FreeBSD.org> Date: Sat, 4 Aug 2012 17:56:32 -0700 Message-ID: From: Kevin Oberman To: Doug Barton Content-Type: text/plain; charset=UTF-8 Cc: Garrett Cooper , FreeBSD Current , "O. Hartmann" Subject: Re: VirtualBox: Eating up 100% CPU, freezing Windows 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, 05 Aug 2012 00:56:35 -0000 On Sat, Aug 4, 2012 at 2:30 PM, Doug Barton wrote: > On 08/04/2012 14:26, Garrett Cooper wrote: >> On Sat, Aug 4, 2012 at 1:26 PM, Doug Barton wrote: >> >>> On 08/04/2012 00:40, O. Hartmann wrote: >>>> No, also in my case. I build world and the VBox software with each >>>> kernel - usually. >>> >>> You can ensure that by putting this in src.conf: >>> >>> PORTS_MODULES= emulators/virtualbox-ose-kmod >>> >>> You can place other modules in that list as well. I use vbox so you can >>> be pretty confident that this is going to keep working. :) >> >> That doesn't work > > I assure you that it does. I have put a non-zero amount of work into > fixing it, I use this method, and the resulting kernel module works just > fine. > > If you actually try it and find something is not as it should be, then > yes; please do file a PR and feel free to cc me. > > Doug I am only aware of this because of your posts. No reference to it at all in src.conf(5). It would be nice to see it there. It is mentioned in build(7), but only as a MAKE option and a lot of people are not going to realize it can be placed in src.conf. Also, for those not fairly conversant in make, it is not clear whether multiple ports should be space, comma, colon, or otherwise delimited This is a very nice option as it is very easy to overlook rebuilding kernel modules in ports when building the kernel. Thanks or working on it. -- R. Kevin Oberman, Network Engineer E-mail: kob6558@gmail.com From owner-freebsd-current@FreeBSD.ORG Sun Aug 5 08:28:46 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 362571065741; Sun, 5 Aug 2012 08:28:46 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id DA5238FC17; Sun, 5 Aug 2012 08:28:45 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1SxwCV-0006Ap-H6>; Sun, 05 Aug 2012 10:28:39 +0200 Received: from e178022145.adsl.alicedsl.de ([85.178.22.145] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1SxwCV-0001b3-Bo>; Sun, 05 Aug 2012 10:28:39 +0200 Message-ID: <501E2EB1.3030606@zedat.fu-berlin.de> Date: Sun, 05 Aug 2012 10:28:33 +0200 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:14.0) Gecko/20120801 Thunderbird/14.0 MIME-Version: 1.0 To: Doug Barton References: <501A323E.6000106@zedat.fu-berlin.de> <1343972667.4952.5.camel@Nokia-N900-42-11> <20120803134123.GA52965@onelab2.iet.unipi.it> <501CD1F8.1070404@zedat.fu-berlin.de> <501D8589.50205@FreeBSD.org> In-Reply-To: <501D8589.50205@FreeBSD.org> X-Enigmail-Version: 1.4.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigEDC2810A3E0B299695545143" X-Originating-IP: 85.178.22.145 Cc: FreeBSD Current Subject: Re: VirtualBox: Eating up 100% CPU, freezing Windows 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, 05 Aug 2012 08:28:46 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigEDC2810A3E0B299695545143 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Am 08/04/12 22:26, schrieb Doug Barton: > On 08/04/2012 00:40, O. Hartmann wrote: >> No, also in my case. I build world and the VBox software with each >> kernel - usually. >=20 > You can ensure that by putting this in src.conf: >=20 > PORTS_MODULES=3D emulators/virtualbox-ose-kmod >=20 > You can place other modules in that list as well. I use vbox so you can= > be pretty confident that this is going to keep working. :) >=20 > Doug >=20 Hello Doug. This is exactly how I build the kernel modules for nvidia and VBox ;-) So I guess this makes it unlikely - in my case - that the problems occur due to unsynchronized kernel/modules. Oliver --------------enigEDC2810A3E0B299695545143 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBAgAGBQJQHi63AAoJEOgBcD7A/5N8WNUH/24efB4qItA6BUs7XpIFg92v DYJimVYT16mCwOxMCFeRQ9zNqwi1IAJCGrjkh6K0vUJJ0NMseBZeQkwbOzed5Esc Tb51ial2qd1iHb8YL8SW5DjGcvN11n05XgsCFfhc8jlLEIRUhyLuJ+OaNjwXZ81G jkFGLWWjIevPircAM/Zv/8mWGdenot3aXyjJRMgAzqb0H7gX8suobJZjuEDpMbqm qLpoJu2RCYnpwpvGOMHAVogiKEZ5zZZqCayHbERNkp/lZgPLiKx371x10FgBeLqM ofLDLQWryzni/Xl7UcvrXcbVhmeFOfGHt8M5t10b4cPLlsg6QxZ/7J3uaOQaiJ8= =CTtF -----END PGP SIGNATURE----- --------------enigEDC2810A3E0B299695545143-- From owner-freebsd-current@FreeBSD.ORG Sun Aug 5 08:37:56 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1F9941065672 for ; Sun, 5 Aug 2012 08:37:56 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe08.c2i.net [212.247.154.226]) by mx1.freebsd.org (Postfix) with ESMTP id 9CFFD8FC14 for ; Sun, 5 Aug 2012 08:37:54 +0000 (UTC) X-T2-Spam-Status: No, hits=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 Received: from [176.74.212.201] (account mc467741@c2i.net HELO laptop015.hselasky.homeunix.org) by mailfe08.swip.net (CommuniGate Pro SMTP 5.4.4) with ESMTPA id 305440475; Sun, 05 Aug 2012 10:32:45 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Sun, 5 Aug 2012 10:33:13 +0200 User-Agent: KMail/1.13.7 (FreeBSD/9.0-STABLE; KDE/4.7.4; amd64; ; ) References: <20120801160323.GN2676@deviant.kiev.zoral.com.ua> <201208012341.25509.hselasky@c2i.net> In-Reply-To: X-Face: 'mmZ:T{)),Oru^0c+/}w'`gU1$ubmG?lp!=R4Wy\ELYo2)@'UZ24N@d2+AyewRX}mAm; Yp |U[@, _z/([?1bCfM{_"B<.J>mICJCHAzzGHI{y7{%JVz%R~yJHIji`y>Y}k1C4TfysrsUI -%GU9V5]iUZF&nRn9mJ'?&>O MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201208051033.13486.hselasky@c2i.net> Cc: Konstantin Belousov , Ed Schouten Subject: Re: ttydev_cdevsw has no d_purge X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Aug 2012 08:37:56 -0000 On Friday 03 August 2012 10:32:47 Ed Schouten wrote: > 2012/8/1 Hans Petter Selasky : > > I think the problem is like this, that in order to re-use the unit > > numbers for USB serial tty devices, the USB stack needs to wait until a > > TTY is actually freed, right? Else you will have a panic on creating > > devfs entries having the same name. > > Indeed. So the USB code could simply pick a different unit number. Hi Ed, USB could use a different Unit number. Some questions: When can the previous unit number be re-used? Is there a callback for this? When can the USB serial code assume that it will not be called again and that all callbacks are drained? --HPS From owner-freebsd-current@FreeBSD.ORG Sun Aug 5 15:33:51 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9E07E106566C; Sun, 5 Aug 2012 15:33:51 +0000 (UTC) (envelope-from nox@jelal.kn-bremen.de) Received: from smtp.kn-bremen.de (gelbbaer.kn-bremen.de [78.46.108.116]) by mx1.freebsd.org (Postfix) with ESMTP id EB13A8FC15; Sun, 5 Aug 2012 15:33:50 +0000 (UTC) Received: by smtp.kn-bremen.de (Postfix, from userid 10) id C01471E00244; Sun, 5 Aug 2012 17:33:49 +0200 (CEST) Received: from triton8.kn-bremen.de (noident@localhost [127.0.0.1]) by triton8.kn-bremen.de (8.14.4/8.14.4) with ESMTP id q75FVJCl087730; Sun, 5 Aug 2012 17:31:19 +0200 (CEST) (envelope-from nox@triton8.kn-bremen.de) Received: (from nox@localhost) by triton8.kn-bremen.de (8.14.4/8.14.3/Submit) id q75FVJjO087729; Sun, 5 Aug 2012 17:31:19 +0200 (CEST) (envelope-from nox) Date: Sun, 5 Aug 2012 17:31:19 +0200 (CEST) From: Juergen Lock Message-Id: <201208051531.q75FVJjO087729@triton8.kn-bremen.de> To: gljennjohn@googlemail.com X-Newsgroups: local.list.freebsd.ports In-Reply-To: <20120804110952.4f3a9cfd@ernst.jennejohn.org> References: <20120730191515.GA9678@triton8.kn-bremen.de> <20120801213128.7956cef34d5f5a5419f78de2@alkumuna.eu> <201208021921.q72JLT4k040018@triton8.kn-bremen.de> <1361725.y2QOXzX10J@pcoliver.heesakkers.info> <20120802205625.GA43980@triton8.kn-bremen.de> <20120803142711.1cb981b3@ernst.jennejohn.org> <501BE795.8070407@gwdg.de> <20120803163633.GA2046@triton8.kn-bremen.de> <20120804110952.4f3a9cfd@ernst.jennejohn.org> Organization: Cc: kib@freebsd.org, current@freebsd.org, freebsd-ports@freebsd.org Subject: Segfault in rtld - dlopen RTLD_LAZY (was: Re: CFT: vlc 2.0.3 - want to know where it works and where only partly) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Aug 2012 15:33:51 -0000 Hi kib, -current, seems we have a segfault in rtld when updating the multimedia/vlc port from the version currently in ports to the 2.0.3 CFT version from here: http://people.freebsd.org/~nox/tmp/vlc-2.0.3-006.patch (If you test the LIVEMEDIA knob you also need this update: http://people.freebsd.org/~nox/tmp/livemedia-20120404-001.patch ) In article <20120804110952.4f3a9cfd@ernst.jennejohn.org> you write: >On Fri, 3 Aug 2012 18:36:33 +0200 >Juergen Lock wrote: > >> On Fri, Aug 03, 2012 at 05:00:37PM +0200, Rainer Hurling wrote: >> > On 03.08.2012 14:27 (UTC+2), Gary Jennejohn wrote: >> > > On Thu, 2 Aug 2012 22:56:26 +0200 >> > > Juergen Lock wrote: >> > > >> > > [trimmed irrelevant content] >> > >> Ok I added that check: >> > >> >> > >> http://people.freebsd.org/~nox/tmp/vlc-2.0.3-005.patch >> > >> >> > >> Enjoy, :) >> > >> >> > > >> > > AMD64 on HEAD. >> > > >> > > I always get this error, no matter which patch I use: >> > > >> > > GEN ../modules/plugins.dat >> > > gmake[2]: *** [../modules/plugins.dat] Segmentation fault: 11 (core dumped) >> > > gmake[2]: Leaving directory `/usr/ports/multimedia/vlc/work/vlc-2.0.3/bin' >> > > gmake[1]: *** [all-recursive] Error 1 >> > > gmake[1]: Leaving directory `/usr/ports/multimedia/vlc/work/vlc-2.0.3' >> > > gmake: *** [all] Error 2 >> > > *** [do-build] Error code 1 >> > >> > I get exactly the same error with CURRENT amd64. >> > >> Hm how old are both your installed src and ports? You two are the >> first to report this and I just tried to reproduce it on a head >> checkout from May 13 and ports from June 18, and couldn't. >> > >I update the ports and source trees almost every day. I do not install >new ports binaries unless absolutely necessary, so the ports binaries >are pretty much rather old. > >Just installed a new world/kernel today (updated yesterdya), r239006. > >> > BTW, mplayer from ports does not build with liveMedia-20120404 ... >> > >> > > Stop in /usr/ports/multimedia/vlc. >> > > *** [build] Error code 1 >> > > >> > > and there's a work/vlc-2.0.3/bin/vlc-cache-gen.core generated. >> > > >> > > May be because I have a mix of old and new dependencies, although the vlc >> > > port never tries to update any of them. >> > > >> Well ports never update dependencies themselves, you need to use >> tools like portmaster for that. >> > >I avoid using tools whenever possible. Maybe I will have to try >portmaster, but I dread seeing 50 ports updated just because I >want to update one port. > >I turned on -g in make.conf and ran vlc-cache-gen in gdb. Here's the >result. > >gdb /usr/ports/multimedia/vlc/work/vlc-2.0.3/bin/.libs/vlc-cache-gen >GNU gdb 6.1.1 [FreeBSD] >Copyright 2004 Free Software Foundation, Inc. >GDB is free software, covered by the GNU General Public License, and you are >welcome to change it and/or distribute copies of it under certain conditions. >Type "show copying" to see the conditions. >There is absolutely no warranty for GDB. Type "show warranty" for details. >This GDB was configured as "amd64-marcel-freebsd"... >(gdb) r ../modules/ >Starting program: /usr/ports/multimedia/vlc/work/vlc-2.0.3/bin/.libs/vlc-cache-gen ../modules/ >[New LWP 100125] >[New Thread 802406400 (LWP 100125/vlc-cache-gen)] > >Program received signal SIGSEGV, Segmentation fault. >[Switching to Thread 802406400 (LWP 100125/vlc-cache-gen)] >0x0000000800606588 in matched_symbol () from /libexec/ld-elf.so.1 >(gdb) bt >#0 0x0000000800606588 in matched_symbol () from /libexec/ld-elf.so.1 >#1 0x00000008006087e4 in symlook_obj () from /libexec/ld-elf.so.1 >#2 0x0000000800608ae7 in symlook_list () from /libexec/ld-elf.so.1 >#3 0x000000080060911b in symlook_default () from /libexec/ld-elf.so.1 >#4 0x000000080060939d in find_symdef () from /libexec/ld-elf.so.1 >#5 0x000000080060375b in reloc_non_plt () from /libexec/ld-elf.so.1 >#6 0x0000000800606ae8 in relocate_object () from /libexec/ld-elf.so.1 >#7 0x00000008006084a8 in dlopen_object () from /libexec/ld-elf.so.1 >#8 0x0000000800608f67 in rtld_dlopen () from /libexec/ld-elf.so.1 >#9 0x0000000800affe95 in module_Load (p_this=0x80244c198, > psz_file=0x802472c00 "../modules//codec/.libs/libfluidsynth_plugin.so", > p_handle=0x7fffffffd180, lazy=true) at posix/plugin.c:62 >#10 0x0000000800adef4b in module_InitDynamic (obj=0x80244c198, > path=0x802472c00 "../modules//codec/.libs/libfluidsynth_plugin.so", > fast=true) at modules/bank.c:536 >#11 0x0000000800adede2 in AllocatePluginFile (bank=0x7fffffffd490, > abspath=0x802472c00 "../modules//codec/.libs/libfluidsynth_plugin.so", > relpath=0x802472b80 "codec/.libs/libfluidsynth_plugin.so", > st=0x7fffffffd210) at modules/bank.c:479 >#12 0x0000000800adeca3 in AllocatePluginDir (bank=0x7fffffffd490, maxdepth=2, > absdir=0x802472b00 "../modules//codec/.libs", > reldir=0x802472a80 "codec/.libs") at modules/bank.c:440 >#13 0x0000000800adecd7 in AllocatePluginDir (bank=0x7fffffffd490, maxdepth=3, > absdir=0x802472a00 "../modules//codec", reldir=0x8024704f0 "codec") > at modules/bank.c:444 >#14 0x0000000800adecd7 in AllocatePluginDir (bank=0x7fffffffd490, maxdepth=4, > absdir=0x802452c20 "../modules/", reldir=0x0) at modules/bank.c:444 >#15 0x0000000800ade9b8 in AllocatePluginPath (p_this=0x80244c198, > path=0x802452c20 "../modules/", mode=CACHE_USE) at modules/bank.c:353 >#16 0x0000000800ade823 in AllocateAllPlugins (p_this=0x80244c198) > at modules/bank.c:298 >#17 0x0000000800ade55d in module_LoadPlugins (obj=0x80244c198) > at modules/bank.c:189 >#18 0x0000000800a53e63 in libvlc_InternalInit (p_libvlc=0x80244c198, i_argc=3, > ppsz_argv=0x7fffffffd6f0) at libvlc.c:247 >#19 0x000000080082234d in libvlc_new (argc=2, argv=0x7fffffffd7a0) at core.c:59 >#20 0x0000000000400d1c in main (argc=2, argv=0x7fffffffd858) at cachegen.c:107 >(gdb) > >If I remove enough plugins then I can build and install vlc, but the >result isn't very useful. > >The old port builds, installs and works just fine with all the plugins I >want to use so I'll stick to it. I Cc'd -current and kib (who did the majority of the recent rtld commits), maybe he has an idea. Seems dlopen() was called from here, /usr/ports/multimedia/vlc/work/vlc-2.0.3/src/posix/plugin.c , line 62: /** * Load a dynamically linked library using a system dependent method. * * \param p_this vlc object * \param psz_file library file * \param p_handle the module handle returned * \return 0 on success as well as the module handle. */ int module_Load( vlc_object_t *p_this, const char *psz_file, module_handle_t *p_handle, bool lazy ) { #if defined (RTLD_NOW) const int flags = lazy ? RTLD_LAZY : RTLD_NOW; #elif defined (DL_LAZY) const int flags = DL_LAZY; #else const int flags = 0; #endif char *path = ToLocale( psz_file ); module_handle_t handle = dlopen( path, flags ); if( handle == NULL ) { msg_Warn( p_this, "cannot load module `%s' (%s)", path, dlerror() ); LocaleFree( path ); return -1; } LocaleFree( path ); *p_handle = handle; return 0; } Thanx, :) Juergen From owner-freebsd-current@FreeBSD.ORG Sun Aug 5 16:13:59 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C72F8106564A; Sun, 5 Aug 2012 16:13:59 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 3298B8FC08; Sun, 5 Aug 2012 16:13:58 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q75GE6G7033496; Sun, 5 Aug 2012 19:14: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.5/8.14.5) with ESMTP id q75GDr56020462; Sun, 5 Aug 2012 19:13:53 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q75GDrQK020461; Sun, 5 Aug 2012 19:13:53 +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, 5 Aug 2012 19:13:53 +0300 From: Konstantin Belousov To: Juergen Lock Message-ID: <20120805161353.GF2676@deviant.kiev.zoral.com.ua> References: <20120730191515.GA9678@triton8.kn-bremen.de> <20120801213128.7956cef34d5f5a5419f78de2@alkumuna.eu> <201208021921.q72JLT4k040018@triton8.kn-bremen.de> <1361725.y2QOXzX10J@pcoliver.heesakkers.info> <20120802205625.GA43980@triton8.kn-bremen.de> <20120803142711.1cb981b3@ernst.jennejohn.org> <501BE795.8070407@gwdg.de> <20120803163633.GA2046@triton8.kn-bremen.de> <20120804110952.4f3a9cfd@ernst.jennejohn.org> <201208051531.q75FVJjO087729@triton8.kn-bremen.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="l3V33RQEOxIe3sMQ" Content-Disposition: inline In-Reply-To: <201208051531.q75FVJjO087729@triton8.kn-bremen.de> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: current@freebsd.org, freebsd-ports@freebsd.org Subject: Re: Segfault in rtld - dlopen RTLD_LAZY (was: Re: CFT: vlc 2.0.3 - want to know where it works and where only partly) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Aug 2012 16:13:59 -0000 --l3V33RQEOxIe3sMQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Aug 05, 2012 at 05:31:19PM +0200, Juergen Lock wrote: > Hi kib, -current, seems we have a segfault in rtld when updating > the multimedia/vlc port from the version currently in ports to the > 2.0.3 CFT version from here: >=20 > http://people.freebsd.org/~nox/tmp/vlc-2.0.3-006.patch >=20 > (If you test the LIVEMEDIA knob you also need this update: >=20 > http://people.freebsd.org/~nox/tmp/livemedia-20120404-001.patch >=20 > ) Please do two things. 1. Provide me the output of readelf -a for the module that was loaded. 2. Recompile rtld with debug symbols and redo the build to get the useful backtrace from core: cd /usr/src/libexec/rtld-elf make clean make all install DEBUG_FLAGS=3D-g >=20 > In article <20120804110952.4f3a9cfd@ernst.jennejohn.org> you write: > >On Fri, 3 Aug 2012 18:36:33 +0200 > >Juergen Lock wrote: > > > >> On Fri, Aug 03, 2012 at 05:00:37PM +0200, Rainer Hurling wrote: > >> > On 03.08.2012 14:27 (UTC+2), Gary Jennejohn wrote: > >> > > On Thu, 2 Aug 2012 22:56:26 +0200 > >> > > Juergen Lock wrote: > >> > > > >> > > [trimmed irrelevant content] > >> > >> Ok I added that check: > >> > >> > >> > >> http://people.freebsd.org/~nox/tmp/vlc-2.0.3-005.patch > >> > >> > >> > >> Enjoy, :) > >> > >> > >> > > > >> > > AMD64 on HEAD. > >> > > > >> > > I always get this error, no matter which patch I use: > >> > > > >> > > GEN ../modules/plugins.dat > >> > > gmake[2]: *** [../modules/plugins.dat] Segmentation fault: 11 (cor= e dumped) > >> > > gmake[2]: Leaving directory `/usr/ports/multimedia/vlc/work/vlc-2.= 0.3/bin' > >> > > gmake[1]: *** [all-recursive] Error 1 > >> > > gmake[1]: Leaving directory `/usr/ports/multimedia/vlc/work/vlc-2.= 0.3' > >> > > gmake: *** [all] Error 2 > >> > > *** [do-build] Error code 1 > >> >=20 > >> > I get exactly the same error with CURRENT amd64. > >> >=20 > >> Hm how old are both your installed src and ports? You two are the > >> first to report this and I just tried to reproduce it on a head > >> checkout from May 13 and ports from June 18, and couldn't. > >>=20 > > > >I update the ports and source trees almost every day. I do not install > >new ports binaries unless absolutely necessary, so the ports binaries > >are pretty much rather old. > > > >Just installed a new world/kernel today (updated yesterdya), r239006. > > > >> > BTW, mplayer from ports does not build with liveMedia-20120404 ... > >> >=20 > >> > > Stop in /usr/ports/multimedia/vlc. > >> > > *** [build] Error code 1 > >> > > > >> > > and there's a work/vlc-2.0.3/bin/vlc-cache-gen.core generated. > >> > > > >> > > May be because I have a mix of old and new dependencies, although = the vlc > >> > > port never tries to update any of them. > >> > > > >> Well ports never update dependencies themselves, you need to use > >> tools like portmaster for that. > >>=20 > > > >I avoid using tools whenever possible. Maybe I will have to try > >portmaster, but I dread seeing 50 ports updated just because I > >want to update one port. > > > >I turned on -g in make.conf and ran vlc-cache-gen in gdb. Here's the > >result. > > > >gdb /usr/ports/multimedia/vlc/work/vlc-2.0.3/bin/.libs/vlc-cache-gen > >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 condit= ions. > >Type "show copying" to see the conditions. > >There is absolutely no warranty for GDB. Type "show warranty" for detai= ls. > >This GDB was configured as "amd64-marcel-freebsd"... > >(gdb) r ../modules/ > >Starting program: /usr/ports/multimedia/vlc/work/vlc-2.0.3/bin/.libs/vlc= -cache-gen ../modules/ > >[New LWP 100125] > >[New Thread 802406400 (LWP 100125/vlc-cache-gen)] > > > >Program received signal SIGSEGV, Segmentation fault. > >[Switching to Thread 802406400 (LWP 100125/vlc-cache-gen)] > >0x0000000800606588 in matched_symbol () from /libexec/ld-elf.so.1 > >(gdb) bt > >#0 0x0000000800606588 in matched_symbol () from /libexec/ld-elf.so.1 > >#1 0x00000008006087e4 in symlook_obj () from /libexec/ld-elf.so.1 > >#2 0x0000000800608ae7 in symlook_list () from /libexec/ld-elf.so.1 > >#3 0x000000080060911b in symlook_default () from /libexec/ld-elf.so.1 > >#4 0x000000080060939d in find_symdef () from /libexec/ld-elf.so.1 > >#5 0x000000080060375b in reloc_non_plt () from /libexec/ld-elf.so.1 > >#6 0x0000000800606ae8 in relocate_object () from /libexec/ld-elf.so.1 > >#7 0x00000008006084a8 in dlopen_object () from /libexec/ld-elf.so.1 > >#8 0x0000000800608f67 in rtld_dlopen () from /libexec/ld-elf.so.1 > >#9 0x0000000800affe95 in module_Load (p_this=3D0x80244c198, > > psz_file=3D0x802472c00 "../modules//codec/.libs/libfluidsynth_plugin= .so", > > p_handle=3D0x7fffffffd180, lazy=3Dtrue) at posix/plugin.c:62 > >#10 0x0000000800adef4b in module_InitDynamic (obj=3D0x80244c198, > > path=3D0x802472c00 "../modules//codec/.libs/libfluidsynth_plugin.so", > > fast=3Dtrue) at modules/bank.c:536 > >#11 0x0000000800adede2 in AllocatePluginFile (bank=3D0x7fffffffd490, > > abspath=3D0x802472c00 "../modules//codec/.libs/libfluidsynth_plugin.= so", > > relpath=3D0x802472b80 "codec/.libs/libfluidsynth_plugin.so", > > st=3D0x7fffffffd210) at modules/bank.c:479 > >#12 0x0000000800adeca3 in AllocatePluginDir (bank=3D0x7fffffffd490, maxd= epth=3D2, > > absdir=3D0x802472b00 "../modules//codec/.libs", > > reldir=3D0x802472a80 "codec/.libs") at modules/bank.c:440 > >#13 0x0000000800adecd7 in AllocatePluginDir (bank=3D0x7fffffffd490, maxd= epth=3D3, > > absdir=3D0x802472a00 "../modules//codec", reldir=3D0x8024704f0 "code= c") > > at modules/bank.c:444 > >#14 0x0000000800adecd7 in AllocatePluginDir (bank=3D0x7fffffffd490, maxd= epth=3D4, > > absdir=3D0x802452c20 "../modules/", reldir=3D0x0) at modules/bank.c:= 444 > >#15 0x0000000800ade9b8 in AllocatePluginPath (p_this=3D0x80244c198, > > path=3D0x802452c20 "../modules/", mode=3DCACHE_USE) at modules/bank.= c:353 > >#16 0x0000000800ade823 in AllocateAllPlugins (p_this=3D0x80244c198) > > at modules/bank.c:298 > >#17 0x0000000800ade55d in module_LoadPlugins (obj=3D0x80244c198) > > at modules/bank.c:189 > >#18 0x0000000800a53e63 in libvlc_InternalInit (p_libvlc=3D0x80244c198, i= _argc=3D3, > > ppsz_argv=3D0x7fffffffd6f0) at libvlc.c:247 > >#19 0x000000080082234d in libvlc_new (argc=3D2, argv=3D0x7fffffffd7a0) a= t core.c:59 > >#20 0x0000000000400d1c in main (argc=3D2, argv=3D0x7fffffffd858) at cach= egen.c:107 > >(gdb) > > > >If I remove enough plugins then I can build and install vlc, but the > >result isn't very useful. > > > >The old port builds, installs and works just fine with all the plugins I > >want to use so I'll stick to it. >=20 > I Cc'd -current and kib (who did the majority of the recent rtld commits= ), > maybe he has an idea. Seems dlopen() was called from here, > /usr/ports/multimedia/vlc/work/vlc-2.0.3/src/posix/plugin.c , line 62: >=20 > /** > * Load a dynamically linked library using a system dependent method. > * > * \param p_this vlc object > * \param psz_file library file > * \param p_handle the module handle returned > * \return 0 on success as well as the module handle. > */ > int module_Load( vlc_object_t *p_this, const char *psz_file, > module_handle_t *p_handle, bool lazy ) > { > #if defined (RTLD_NOW) > const int flags =3D lazy ? RTLD_LAZY : RTLD_NOW; > #elif defined (DL_LAZY) > const int flags =3D DL_LAZY; > #else > const int flags =3D 0; > #endif > char *path =3D ToLocale( psz_file ); >=20 > module_handle_t handle =3D dlopen( path, flags ); > if( handle =3D=3D NULL ) > { > msg_Warn( p_this, "cannot load module `%s' (%s)", path, dlerror()= ); > LocaleFree( path ); > return -1; > } > LocaleFree( path ); > *p_handle =3D handle; > return 0; > } >=20 > Thanx, :) > Juergen --l3V33RQEOxIe3sMQ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAlAem8EACgkQC3+MBN1Mb4h/9QCg7Iq+v1Yg0TfVEAt7n8NQFfDa olsAn1zZMurAAPw34FHF5jwTT5U7IzTU =7pP6 -----END PGP SIGNATURE----- --l3V33RQEOxIe3sMQ-- From owner-freebsd-current@FreeBSD.ORG Sun Aug 5 17:01:39 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 288E0106564A; Sun, 5 Aug 2012 17:01:39 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id D21118FC08; Sun, 5 Aug 2012 17:01:38 +0000 (UTC) Received: by obbun3 with SMTP id un3so5759277obb.13 for ; Sun, 05 Aug 2012 10:01:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=lqt6zcQSeME/UIgZkEfVbEBaKBHjk3rEm7YvnixpP6E=; b=yVwC6lmhW1YEwpUSF6vMYyy0pa629PJEcl4fz+IoG0DDAOJLFUV4pgyM/9+Oxuua+9 XqpGE6gOQ/Di7rPVCz3FJz/leoPloOYUQYKk3VsvMTZvVYUlIkfYGIPORHFeQLb/eJbF 41VsIeeu1Iwazp8puvUgG2Kz7kKNI90gxSYgDs6np7BSUNX/NxlarT6NOJoYxWuNohve Ysq3Do76VKc80uh0FKBWi5tdgxetPVLJeA1HY3G76M6YFd9MPCMF1MIY185JOMMWkXaB sRRI1Bh4LoVG0rUOGqA86GYEy+ZFkXzK1DZdHkB8LqRYrUPIlZrHnTJ0CRqOUVl3aylc KH8g== Received: by 10.50.47.196 with SMTP id f4mr3354516ign.21.1344186097604; Sun, 05 Aug 2012 10:01:37 -0700 (PDT) Received: from oddish ([69.166.24.234]) by mx.google.com with ESMTPS id k5sm4270769igq.12.2012.08.05.10.01.35 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 05 Aug 2012 10:01:36 -0700 (PDT) Date: Sun, 5 Aug 2012 13:03:37 -0400 From: Mark Johnston To: Hans Petter Selasky Message-ID: <20120805170337.GA28327@oddish> References: <201207182322.50655.hselasky@c2i.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201207182322.50655.hselasky@c2i.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-multimedia@freebsd.org, freebsd-current@freebsd.org Subject: Re: IPod crash seen with FreeBSD only X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Aug 2012 17:01:39 -0000 On Wed, Jul 18, 2012 at 11:22:50PM +0200, Hans Petter Selasky wrote: > Hi, > > I have one of those locked down silvery IPod's, and wanted to try out gnupod > to get some MP3's transferred to the device. I made it once, but then my luck > ended :-) Anyway I found what looks like a remote crash vulnerability in the > IPod firmware. How to make it crash: I had the same problem, but it only occurs when I plug in my ipod after the battery dies. I previously had to plug it into a Linux or Windows machine first and let it charge for a minute or two before I could plug into a FreeBSD machine without triggering the reset loop. Adding the quirk (with the correct product ID) fixes the problem for me. Thanks so much! -Mark From owner-freebsd-current@FreeBSD.ORG Sun Aug 5 17:40:33 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B31CB1065670; Sun, 5 Aug 2012 17:40:33 +0000 (UTC) (envelope-from nox@jelal.kn-bremen.de) Received: from smtp.kn-bremen.de (gelbbaer.kn-bremen.de [78.46.108.116]) by mx1.freebsd.org (Postfix) with ESMTP id 054608FC14; Sun, 5 Aug 2012 17:40:32 +0000 (UTC) Received: by smtp.kn-bremen.de (Postfix, from userid 10) id 7BEB01E000F2; Sun, 5 Aug 2012 19:40:31 +0200 (CEST) Received: from triton8.kn-bremen.de (noident@localhost [127.0.0.1]) by triton8.kn-bremen.de (8.14.4/8.14.4) with ESMTP id q75HcCOp091282; Sun, 5 Aug 2012 19:38:12 +0200 (CEST) (envelope-from nox@triton8.kn-bremen.de) Received: (from nox@localhost) by triton8.kn-bremen.de (8.14.4/8.14.3/Submit) id q75HcBje091281; Sun, 5 Aug 2012 19:38:11 +0200 (CEST) (envelope-from nox) From: Juergen Lock Date: Sun, 5 Aug 2012 19:38:11 +0200 To: Konstantin Belousov Message-ID: <20120805173811.GA91260@triton8.kn-bremen.de> References: <20120801213128.7956cef34d5f5a5419f78de2@alkumuna.eu> <201208021921.q72JLT4k040018@triton8.kn-bremen.de> <1361725.y2QOXzX10J@pcoliver.heesakkers.info> <20120802205625.GA43980@triton8.kn-bremen.de> <20120803142711.1cb981b3@ernst.jennejohn.org> <501BE795.8070407@gwdg.de> <20120803163633.GA2046@triton8.kn-bremen.de> <20120804110952.4f3a9cfd@ernst.jennejohn.org> <201208051531.q75FVJjO087729@triton8.kn-bremen.de> <20120805161353.GF2676@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120805161353.GF2676@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: current@freebsd.org, Juergen Lock , freebsd-ports@freebsd.org Subject: Re: Segfault in rtld - dlopen RTLD_LAZY (was: Re: CFT: vlc 2.0.3 - want to know where it works and where only partly) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Aug 2012 17:40:33 -0000 On Sun, Aug 05, 2012 at 07:13:53PM +0300, Konstantin Belousov wrote: > On Sun, Aug 05, 2012 at 05:31:19PM +0200, Juergen Lock wrote: > > Hi kib, -current, seems we have a segfault in rtld when updating > > the multimedia/vlc port from the version currently in ports to the > > 2.0.3 CFT version from here: > > > > http://people.freebsd.org/~nox/tmp/vlc-2.0.3-006.patch > > > > (If you test the LIVEMEDIA knob you also need this update: > > > > http://people.freebsd.org/~nox/tmp/livemedia-20120404-001.patch > > > > ) > Please do two things. > > 1. Provide me the output of readelf -a for the module that was loaded. > > 2. Recompile rtld with debug symbols and redo the build to get the useful > backtrace from core: > cd /usr/src/libexec/rtld-elf > make clean > make all install DEBUG_FLAGS=-g > Ok, someone who got the crash will have to do this as I couln't reproduce it here (sorry forgot to say...) Thanx, :) Juergen > > > > In article <20120804110952.4f3a9cfd@ernst.jennejohn.org> you write: > > >On Fri, 3 Aug 2012 18:36:33 +0200 > > >Juergen Lock wrote: > > > > > >> On Fri, Aug 03, 2012 at 05:00:37PM +0200, Rainer Hurling wrote: > > >> > On 03.08.2012 14:27 (UTC+2), Gary Jennejohn wrote: > > >> > > On Thu, 2 Aug 2012 22:56:26 +0200 > > >> > > Juergen Lock wrote: > > >> > > > > >> > > [trimmed irrelevant content] > > >> > >> Ok I added that check: > > >> > >> > > >> > >> http://people.freebsd.org/~nox/tmp/vlc-2.0.3-005.patch > > >> > >> > > >> > >> Enjoy, :) > > >> > >> > > >> > > > > >> > > AMD64 on HEAD. > > >> > > > > >> > > I always get this error, no matter which patch I use: > > >> > > > > >> > > GEN ../modules/plugins.dat > > >> > > gmake[2]: *** [../modules/plugins.dat] Segmentation fault: 11 (core dumped) > > >> > > gmake[2]: Leaving directory `/usr/ports/multimedia/vlc/work/vlc-2.0.3/bin' > > >> > > gmake[1]: *** [all-recursive] Error 1 > > >> > > gmake[1]: Leaving directory `/usr/ports/multimedia/vlc/work/vlc-2.0.3' > > >> > > gmake: *** [all] Error 2 > > >> > > *** [do-build] Error code 1 > > >> > > > >> > I get exactly the same error with CURRENT amd64. > > >> > > > >> Hm how old are both your installed src and ports? You two are the > > >> first to report this and I just tried to reproduce it on a head > > >> checkout from May 13 and ports from June 18, and couldn't. > > >> > > > > > >I update the ports and source trees almost every day. I do not install > > >new ports binaries unless absolutely necessary, so the ports binaries > > >are pretty much rather old. > > > > > >Just installed a new world/kernel today (updated yesterdya), r239006. > > > > > >> > BTW, mplayer from ports does not build with liveMedia-20120404 ... > > >> > > > >> > > Stop in /usr/ports/multimedia/vlc. > > >> > > *** [build] Error code 1 > > >> > > > > >> > > and there's a work/vlc-2.0.3/bin/vlc-cache-gen.core generated. > > >> > > > > >> > > May be because I have a mix of old and new dependencies, although the vlc > > >> > > port never tries to update any of them. > > >> > > > > >> Well ports never update dependencies themselves, you need to use > > >> tools like portmaster for that. > > >> > > > > > >I avoid using tools whenever possible. Maybe I will have to try > > >portmaster, but I dread seeing 50 ports updated just because I > > >want to update one port. > > > > > >I turned on -g in make.conf and ran vlc-cache-gen in gdb. Here's the > > >result. > > > > > >gdb /usr/ports/multimedia/vlc/work/vlc-2.0.3/bin/.libs/vlc-cache-gen > > >GNU gdb 6.1.1 [FreeBSD] > > >Copyright 2004 Free Software Foundation, Inc. > > >GDB is free software, covered by the GNU General Public License, and you are > > >welcome to change it and/or distribute copies of it under certain conditions. > > >Type "show copying" to see the conditions. > > >There is absolutely no warranty for GDB. Type "show warranty" for details. > > >This GDB was configured as "amd64-marcel-freebsd"... > > >(gdb) r ../modules/ > > >Starting program: /usr/ports/multimedia/vlc/work/vlc-2.0.3/bin/.libs/vlc-cache-gen ../modules/ > > >[New LWP 100125] > > >[New Thread 802406400 (LWP 100125/vlc-cache-gen)] > > > > > >Program received signal SIGSEGV, Segmentation fault. > > >[Switching to Thread 802406400 (LWP 100125/vlc-cache-gen)] > > >0x0000000800606588 in matched_symbol () from /libexec/ld-elf.so.1 > > >(gdb) bt > > >#0 0x0000000800606588 in matched_symbol () from /libexec/ld-elf.so.1 > > >#1 0x00000008006087e4 in symlook_obj () from /libexec/ld-elf.so.1 > > >#2 0x0000000800608ae7 in symlook_list () from /libexec/ld-elf.so.1 > > >#3 0x000000080060911b in symlook_default () from /libexec/ld-elf.so.1 > > >#4 0x000000080060939d in find_symdef () from /libexec/ld-elf.so.1 > > >#5 0x000000080060375b in reloc_non_plt () from /libexec/ld-elf.so.1 > > >#6 0x0000000800606ae8 in relocate_object () from /libexec/ld-elf.so.1 > > >#7 0x00000008006084a8 in dlopen_object () from /libexec/ld-elf.so.1 > > >#8 0x0000000800608f67 in rtld_dlopen () from /libexec/ld-elf.so.1 > > >#9 0x0000000800affe95 in module_Load (p_this=0x80244c198, > > > psz_file=0x802472c00 "../modules//codec/.libs/libfluidsynth_plugin.so", > > > p_handle=0x7fffffffd180, lazy=true) at posix/plugin.c:62 > > >#10 0x0000000800adef4b in module_InitDynamic (obj=0x80244c198, > > > path=0x802472c00 "../modules//codec/.libs/libfluidsynth_plugin.so", > > > fast=true) at modules/bank.c:536 > > >#11 0x0000000800adede2 in AllocatePluginFile (bank=0x7fffffffd490, > > > abspath=0x802472c00 "../modules//codec/.libs/libfluidsynth_plugin.so", > > > relpath=0x802472b80 "codec/.libs/libfluidsynth_plugin.so", > > > st=0x7fffffffd210) at modules/bank.c:479 > > >#12 0x0000000800adeca3 in AllocatePluginDir (bank=0x7fffffffd490, maxdepth=2, > > > absdir=0x802472b00 "../modules//codec/.libs", > > > reldir=0x802472a80 "codec/.libs") at modules/bank.c:440 > > >#13 0x0000000800adecd7 in AllocatePluginDir (bank=0x7fffffffd490, maxdepth=3, > > > absdir=0x802472a00 "../modules//codec", reldir=0x8024704f0 "codec") > > > at modules/bank.c:444 > > >#14 0x0000000800adecd7 in AllocatePluginDir (bank=0x7fffffffd490, maxdepth=4, > > > absdir=0x802452c20 "../modules/", reldir=0x0) at modules/bank.c:444 > > >#15 0x0000000800ade9b8 in AllocatePluginPath (p_this=0x80244c198, > > > path=0x802452c20 "../modules/", mode=CACHE_USE) at modules/bank.c:353 > > >#16 0x0000000800ade823 in AllocateAllPlugins (p_this=0x80244c198) > > > at modules/bank.c:298 > > >#17 0x0000000800ade55d in module_LoadPlugins (obj=0x80244c198) > > > at modules/bank.c:189 > > >#18 0x0000000800a53e63 in libvlc_InternalInit (p_libvlc=0x80244c198, i_argc=3, > > > ppsz_argv=0x7fffffffd6f0) at libvlc.c:247 > > >#19 0x000000080082234d in libvlc_new (argc=2, argv=0x7fffffffd7a0) at core.c:59 > > >#20 0x0000000000400d1c in main (argc=2, argv=0x7fffffffd858) at cachegen.c:107 > > >(gdb) > > > > > >If I remove enough plugins then I can build and install vlc, but the > > >result isn't very useful. > > > > > >The old port builds, installs and works just fine with all the plugins I > > >want to use so I'll stick to it. > > > > I Cc'd -current and kib (who did the majority of the recent rtld commits), > > maybe he has an idea. Seems dlopen() was called from here, > > /usr/ports/multimedia/vlc/work/vlc-2.0.3/src/posix/plugin.c , line 62: > > > > /** > > * Load a dynamically linked library using a system dependent method. > > * > > * \param p_this vlc object > > * \param psz_file library file > > * \param p_handle the module handle returned > > * \return 0 on success as well as the module handle. > > */ > > int module_Load( vlc_object_t *p_this, const char *psz_file, > > module_handle_t *p_handle, bool lazy ) > > { > > #if defined (RTLD_NOW) > > const int flags = lazy ? RTLD_LAZY : RTLD_NOW; > > #elif defined (DL_LAZY) > > const int flags = DL_LAZY; > > #else > > const int flags = 0; > > #endif > > char *path = ToLocale( psz_file ); > > > > module_handle_t handle = dlopen( path, flags ); > > if( handle == NULL ) > > { > > msg_Warn( p_this, "cannot load module `%s' (%s)", path, dlerror() ); > > LocaleFree( path ); > > return -1; > > } > > LocaleFree( path ); > > *p_handle = handle; > > return 0; > > } > > > > Thanx, :) > > Juergen From owner-freebsd-current@FreeBSD.ORG Sun Aug 5 18:21:42 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4A0D3106566C for ; Sun, 5 Aug 2012 18:21:42 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 16A8B8FC08 for ; Sun, 5 Aug 2012 18:21:41 +0000 (UTC) Received: by pbbrp2 with SMTP id rp2so19175pbb.13 for ; Sun, 05 Aug 2012 11:21:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=C3Dx/PzxTyg6WEOELmNX1J0ZXeRElSLjcGNBsOqZNXI=; b=suLP6Cpu5gyFRG7KjlmRUComaYR6/rvlJpvvfskEfJDBmlCAS8GKHt5WJYGhYUvN17 v7AZTRCw18JIrEoU8y+Y8GZ6zZpI+ww7LgrKgJW7oaqY1oKCN0lBjUD+6+FZoTlJ1qSK gint1kphxGHysOmgeQTev7Ne/btMPdXSpE2vc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=C3Dx/PzxTyg6WEOELmNX1J0ZXeRElSLjcGNBsOqZNXI=; b=T5hM9nzU58XsqeX5XSeIvVnym/I5SwTL1FqQr0y9rxggP9rlHplZC5QQmv0/w0yPi/ vijDxyiSIlYj4xiVpteUcz19KZjUOGksv2chyxy7qs3eoGaOMbOgDeKRdV2xn802KDbB 580Cj2w8PcBrTUyETidZtnl7N+kqVVw3VgVCjn5WeTdbwWw8/RYYU6uqaGEUcepe5U24 ANu8tpJj9hJ7ePnXE66G4C2tcJcI7vZAzb1Dgrfn755Wv4ieCmQIj9BH8T2imajSeSrP mu+3MTY9Hokpyo2VycN0puHqUWKStAz00drO4gTO43sibWXvrZe+/fR6OOZX5cKJpuOO dRIw== Received: by 10.66.77.71 with SMTP id q7mr12982710paw.0.1344190901319; Sun, 05 Aug 2012 11:21:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.67.52 with HTTP; Sun, 5 Aug 2012 11:21:11 -0700 (PDT) In-Reply-To: References: From: Eitan Adler Date: Sun, 5 Aug 2012 11:21:11 -0700 Message-ID: To: David Boyd Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQnnh9/uI7YqTvSpdO5KzL4wf1Tnx1Fsc+IYK88Shgc3qpTkZO+/AbMOJ8eop2xRfxwNDykq Cc: freebsd-current@freebsd.org Subject: Re: pucdata.c addition X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Aug 2012 18:21:42 -0000 On 4 August 2012 10:52, David Boyd wrote: > Can someone please add the following definition to pucdata.c? > > { 0x1415, 0x950a, 0x131f, 0x2032, > "SIIG Cyber Serial Dual PCI 16C850 (20x family)", > DEFAULT_RCLK * 10, > PUC_PORT_4S, 0x10, 0, 8, > }, I'll deal with it. In general, submitting a PR (http://www.freebsd.org/send-pr.html) makes it easier to track these things. -- Eitan Adler From owner-freebsd-current@FreeBSD.ORG Mon Aug 6 01:48:04 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 902A9106564A; Mon, 6 Aug 2012 01:48:04 +0000 (UTC) (envelope-from randy@psg.com) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by mx1.freebsd.org (Postfix) with ESMTP id 5E7498FC08; Mon, 6 Aug 2012 01:48:04 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SyCQN-000I33-OA; Mon, 06 Aug 2012 01:48:03 +0000 Date: Sun, 05 Aug 2012 18:48:03 -0700 Message-ID: From: Randy Bush To: Kevin Oberman In-Reply-To: References: <612DA8A3-121E-4E72-9E5B-F3CBA9DEB7F7@bsdimp.com> <501A0258.4010101@FreeBSD.org> <45815622-3CE2-42E3-B118-702AA70C7E4C@samsco.org> <501AB08E.8020008@FreeBSD.org> <501B1D3A.6080501@freebsd.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: FreeBSD Hackers , FreeBSD Current Subject: Re: On cooperative work [Was: Re: newbus' ivar's limitation..] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Aug 2012 01:48:04 -0000 > I suggest the starting point is a webpage with a link to the slides > being presented and a simple audio stream. two way, please. i am amazed that ietf had two-way back when it was the mbone. with multicast actually deployed, now it is one-way. randy From owner-freebsd-current@FreeBSD.ORG Mon Aug 6 03:49:17 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by hub.freebsd.org (Postfix) with ESMTP id A7898106564A; Mon, 6 Aug 2012 03:49:17 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from opti.dougb.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 4089214DA83; Mon, 6 Aug 2012 03:49:17 +0000 (UTC) Message-ID: <501F3EBC.50100@FreeBSD.org> Date: Sun, 05 Aug 2012 20:49:16 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:14.0) Gecko/20120728 Thunderbird/14.0 MIME-Version: 1.0 To: David Chisnall References: <612DA8A3-121E-4E72-9E5B-F3CBA9DEB7F7@bsdimp.com> <501A0258.4010101@FreeBSD.org> <501AAEF2.8060202@FreeBSD.org> <501AB8C0.3020102@FreeBSD.org> <501ABD43.5090604@FreeBSD.org> <501AC7EF.4070605@FreeBSD.org> <0F923CD6-BCF1-4722-8E4A-9485A7D6E279@freebsd.org> In-Reply-To: <0F923CD6-BCF1-4722-8E4A-9485A7D6E279@freebsd.org> X-Enigmail-Version: 1.4.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Hackers , freebsd-current@freebsd.org Subject: Re: On cooperative work [Was: Re: newbus' ivar's limitation..] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Aug 2012 03:49:17 -0000 On 08/02/2012 12:18, David Chisnall wrote: > Thank you for your thoughtful reply, You too ... I let some time go by to see what others had to say. I think it's disappointing that more people aren't concerned about this issue. > On 2 Aug 2012, at 19:33, Doug Barton wrote: > >> However, my point is that in spite of the fact that it's >> non-trivial, the mindset on this topic needs to change if the dev >> summits are going to continue to be significant focii of both work >> being done and decisions being made (which of course, they are). > > I believe that, before that decision can be made, there needs to be > some consensus on what the purpose of the DevSummits is. In my view, > DevSummits do not exist to set project policy. And yet, that's exactly what happens. It's easy to understand why ... you have a bunch of people together in the same place, they all agree on a topic, and after all, since they are the ones who are there, they should be the ones to make the decision, right? It's not necessarily that they are trying to do something malicious, it's just human nature. I know, I used to travel to conferences for a living. > They are places where: > > - People can talk face to face about their current and planned > projects. - Developers can meet on a social basis, making remote > working easier. > > The latter is very important - I've found in other projects that it's > far easier to work with someone on the other side of the world when > you've chatted with them over a few beverages-of-choice. I agree with these points as well. (Again, been there, done that.) In fact I'm quite confident that a lot of the "issues" people have with me are related to this deficiency. :) > Any official conversations happen on the mailing lists. This should be true, but it isn't. This is my point. > DevSummits > are for people working on similar things to meet and discuss their > plans, and for people to have a chance to get to know what everyone > else is doing, ... so far, so good .. > for a limited set of 'everyone else'. ... and this is where I call shenanigans. This is an open project. Anything that is going to be done is going to be seen. If there are problems with a proposal it's better to see them early. If it's a good proposal, there is no reason not to share it. > Slides and > summaries so on from the more structured parts of this are available > afterwards, which helps people who can't attend get the same benefit > - they know what other people are working on. In the IETF context proposals often benefit from the real-time focus of attention, from both local and remote participants, that the meetings provide. There is no reason to believe that this would not be true in FreeBSD as well. > The original complaint that spawned this long discussion was that > decisions about the project are made behind closed doors. This is > obviously true in the literal sense, as code always wins over chatter > in an open source project, and the person willing to sit down and > write the code gets the final say on how it should work, That's an oft-repeated maxim, especially around here. But we've already demonstrated that it isn't true. The only time that this is true is if the work being done is in line with what the PTB want. I've demonstrated this time after time by volunteering to do various projects "my way" and being told that my efforts weren't welcome. Not to mention having my finished, working code reverted by a core team member for an inferior, broken result. So can we please stop repeating that BS and focus on the real issues? > although > ideally with code review, design feedback and so on from others. > Even if we broadcast everything that happens in the official parts of > the DevSummits, that won't necessarily fix anything because a lot of > the most productive conversations happen over dinner or in the pub. The community needs to not be accepting of the status quo, and demand that things be publicized on the lists first before decisions are made. Once again, if they are good decisions, they won't be harmed by sharing them in advance. If they are less-good, we could be saving someone efforts that would be otherwise wasted. > If there is a real problem to address, then it is people making > policy decisions at DevSummits, without adequate consultation. I > have not observed this happening, but I would regard it as no > different to people making policy decisions via private email, and > something that should be subject to the same response: revisit the > decisions in public if there are legitimate concerns raised about it, > subject to the usual open source rule that the person actually > willing to do the work gets to make the final call. Exactly. > Finance is not the only obstacle. In some venues, bandwidth is a > problem (not at Cambridge hopefully - people will have stopped using > it all to stream the olympics by then), but in other venues we only > have WiFi, which is shared with a room full of developers. If we buy > some equipment (decent microphones are not always available - we were > unable to find one at FOSDEM for remote attendees, for example), then > it would need to be transported between events, and someone would > need to be responsible for looking after it and ensuring that it is > set up correctly at each event. It's already been explained that this is a soluble problem, and Julian has already solved it. The only obstacle at this point is desire of the organizers. > Remote participation is bidirectional, and I am a lot more wary about > that. The productivity of a meeting is usually inversely > proportional to the number of attendees, and allowing a lot more > people in does not necessarily improve anything for anyone. It's > always tempting to speak up and make A Contribution (I have certainly > been guilty of this in the past, and no doubt will be in the future) > when really the meeting needs everyone to shut up and move on to the > next item. That's up to the leader of the session to draw a line. Allowing remote participation doesn't change this dynamic, as it's actually *easier* for someone in the room to be a mic-hog; especially if remote input is via jabber. > The main advantage of the small group meetings is that > they don't degenerate into bikesheds as easily. Of course, the down > side is that they also lack any kind of mandate because they are not > including everyone's opinions, which is why summaries are posted on > the wiki and linked to from the mailing list so that longer > discussions can take place online. I think you've covered the tradeoffs. But again, see above on how allowing remote participation doesn't change anything. > Encouraging remote participation also has the unintended side effect > of discouraging real participation. I've seen in other projects that > when you try to make remote participation easy it means a lot of > people think 'well, I can just join in remotely, I don't need to make > the effort to turn up'. In all of the many organizations I participate in, both in person and remotely, I've never seen this dynamic; primarily because of the "fringe" benefits you describe so well above. I doubt it would happen in FreeBSD. > If the majority are not present in person, then we may as well not > have a DevSummit at all, and just have a regular conference call > that's open to all. Or, to save bandwidth, a mailing list or IRC > channel... I think you're failing to understand the scale of the problem. We have over 300 unique committers alone, never mind the community of non-committer developers. Expecting that even a significant percentage of them will be able to attend any given summit, never mind the one(s) where the things they care about are going to be discussed, is not realistic. Doug -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909) From owner-freebsd-current@FreeBSD.ORG Mon Aug 6 07:57:49 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by hub.freebsd.org (Postfix) with ESMTP id 44FDA106564A for ; Mon, 6 Aug 2012 07:57:49 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from opti.dougb.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 11CD314E15B; Mon, 6 Aug 2012 07:57:48 +0000 (UTC) Message-ID: <501F78FC.6060600@FreeBSD.org> Date: Mon, 06 Aug 2012 00:57:48 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:14.0) Gecko/20120728 Thunderbird/14.0 MIME-Version: 1.0 To: Kevin Oberman References: <501A323E.6000106@zedat.fu-berlin.de> <1343972667.4952.5.camel@Nokia-N900-42-11> <20120803134123.GA52965@onelab2.iet.unipi.it> <501CD1F8.1070404@zedat.fu-berlin.de> <501D8589.50205@FreeBSD.org> <501D9476.80902@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.4.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Garrett Cooper , FreeBSD Current , "O. Hartmann" Subject: Re: VirtualBox: Eating up 100% CPU, freezing Windows 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, 06 Aug 2012 07:57:49 -0000 On 08/04/2012 17:56, Kevin Oberman wrote: > On Sat, Aug 4, 2012 at 2:30 PM, Doug Barton wrote: >> On 08/04/2012 14:26, Garrett Cooper wrote: >>> On Sat, Aug 4, 2012 at 1:26 PM, Doug Barton wrote: >>> >>>> On 08/04/2012 00:40, O. Hartmann wrote: >>>>> No, also in my case. I build world and the VBox software with each >>>>> kernel - usually. >>>> >>>> You can ensure that by putting this in src.conf: >>>> >>>> PORTS_MODULES= emulators/virtualbox-ose-kmod >>>> >>>> You can place other modules in that list as well. I use vbox so you can >>>> be pretty confident that this is going to keep working. :) >>> >>> That doesn't work >> >> I assure you that it does. I have put a non-zero amount of work into >> fixing it, I use this method, and the resulting kernel module works just >> fine. >> >> If you actually try it and find something is not as it should be, then >> yes; please do file a PR and feel free to cc me. >> >> Doug > > I am only aware of this because of your posts. No reference to it at > all in src.conf(5). It would be nice to see it there. It's in make.conf(5) for historical reasons, along with a lot of other options that should be moved. > It is mentioned in build(7), but only as a MAKE option and a lot of > people are not going to realize it can be placed in src.conf. It can also go in make.conf, so that's not a total loss I suppose. > Also, > for those not fairly conversant in make, it is not clear whether > multiple ports should be space, comma, colon, or otherwise delimited > > This is a very nice option as it is very easy to overlook rebuilding > kernel modules in ports when building the kernel. Thanks or working on > it. My pleasure ... it was one of those things on "the list" and I finally got around to it. Doug -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909) From owner-freebsd-current@FreeBSD.ORG Mon Aug 6 09:28:02 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AE3A6106564A for ; Mon, 6 Aug 2012 09:28:02 +0000 (UTC) (envelope-from edschouten@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 7129E8FC08 for ; Mon, 6 Aug 2012 09:28:02 +0000 (UTC) Received: by obbun3 with SMTP id un3so7149928obb.13 for ; Mon, 06 Aug 2012 02:28:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=iYPPO2FtJZwEaKI0wSowDXiU6pTDBpqfxJuCTlzeX1M=; b=WFatFe6Dql/OY6hzdn1N5jCH+Dk/0jF6xDeNckd89L5mo8BrXIEfHUD1WpVv9ccImR 4OTzquTs3lDEvyxP1KlPoMzsSSdMgJdD0FD7HBlcd1JzBXaHwo1rDB1ENWKPalQeMZiG 4mdUNxI2rwXzGxpNk3kOP8D5Ov3jQ+2o40uJm6JewXMMjBrQrCRuShJMBhpkSCU70x6z UxZy0cIX7DklBlMpSr0j3L2EuRjymVVvRhH1Q8ZYJk0F6cxuJv2TfZ/h8uN2NPy+zQTX mMxqDfoNJalAhy6Bbn9eJYO7h2tOzSTm/R4qXjQiirrbSw6zvobfD/mEPI1j97VoTdkJ w1ow== MIME-Version: 1.0 Received: by 10.182.174.68 with SMTP id bq4mr18340614obc.53.1344245281583; Mon, 06 Aug 2012 02:28:01 -0700 (PDT) Sender: edschouten@gmail.com Received: by 10.76.153.195 with HTTP; Mon, 6 Aug 2012 02:28:01 -0700 (PDT) In-Reply-To: <201208051033.13486.hselasky@c2i.net> References: <20120801160323.GN2676@deviant.kiev.zoral.com.ua> <201208012341.25509.hselasky@c2i.net> <201208051033.13486.hselasky@c2i.net> Date: Mon, 6 Aug 2012 11:28:01 +0200 X-Google-Sender-Auth: uAprNcNZ1D7oF_005uvxGZRzc1M Message-ID: From: Ed Schouten To: Hans Petter Selasky Content-Type: text/plain; charset=UTF-8 Cc: Konstantin Belousov , freebsd-current@freebsd.org Subject: Re: ttydev_cdevsw has no d_purge X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Aug 2012 09:28:02 -0000 Hi Hans, 2012/8/5 Hans Petter Selasky : > When can the previous unit number be re-used? Is there a callback for this? The unit number can be reused after .tsw_free() has been called. > When can the USB serial code assume that it will not be called again and that > all callbacks are drained? The tty_rel_gone() function has to be called while holding the TTY lock. Also, all calls done by the TTY layer into the driver also hold the TTY lock and will assert that the TTY is not in the `gone' state. So you can safely assume that you will not get any driver calls as soon as tty_rel_gone() returns. I hope this helps. If you have any further questions, let me know! -- Ed Schouten From owner-freebsd-current@FreeBSD.ORG Mon Aug 6 12:08:17 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9D693106564A; Mon, 6 Aug 2012 12:08:17 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 1C89C8FC14; Mon, 6 Aug 2012 12:08:16 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 6B9577300A; Mon, 6 Aug 2012 14:28:25 +0200 (CEST) Date: Mon, 6 Aug 2012 14:28:25 +0200 From: Luigi Rizzo To: current@freebsd.org, net@freebsd.org Message-ID: <20120806122825.GA96329@onelab2.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: Subject: [RFC] changes in struct dn_pkt_tag ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Aug 2012 12:08:17 -0000 I just realized that the struct dn_pkt_tag is 232 bytes, with the majority of space taken by an unused field, struct _ip6dn_args (192 bytes), which I'd like to remove. The structure constitutes the body of a PACKET_TAG_DUMMYNET, is defined in sys/netinet/ipfw/ip_dn_io.c and private to the dummynet module. Do I still need to bump __FreeBSD_version if i remove the unused field from the structure ? Related to this, struct _ip6dn_args is also an unused part of struct ip_fw_args, which however is used by other ipfw clients such as ng_ipfw, so i am a bit reluctant to "fix" that too. cheers luigi From owner-freebsd-current@FreeBSD.ORG Mon Aug 6 12:20:40 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C214C106564A for ; Mon, 6 Aug 2012 12:20:40 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 9A79F8FC17 for ; Mon, 6 Aug 2012 12:20:40 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 0B383B94A for ; Mon, 6 Aug 2012 08:20:40 -0400 (EDT) From: John Baldwin To: current@freebsd.org Date: Mon, 6 Aug 2012 08:20:39 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p17; KDE/4.5.5; amd64; ; ) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201208060820.39553.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 06 Aug 2012 08:20:40 -0400 (EDT) Cc: Subject: [PATCH] Make ida(4) MPSAFE and a host of other fixes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Aug 2012 12:20:40 -0000 ida(4) is a driver for older Compaq RAID adapters (PCI and EISA). It is one of the few remaining non-MPSAFE storage drivers. I have a patch to add locking to it, but while doing that I fixed several other issues including incorrect bus_dma support (it didn't handle deferred callbacks and EINPROGRESS at all). It also did not pre-allocate dma maps but attempted to create them on the fly (despite a comment claiming that it did pre-allocate them). It now probes disks using a configintrhook rather than using polled commands. The drive number for each logical disk is passed to the child disk device via ivars. I've added bus_dma sync ops for the hardware QCB accesses. I've also reworked it's queuing mechanism so that it should now queue multiple commands to the controller (before it only queued one command at a time even though it had free QCBs). The patch compiles, but I have no hardware to test it. Given that this is an old driver, if I can't find anyone to test it, I will remove it from HEAD after committing the fixes (so if someone shows up in the future there is a better base to start from). http://www.FreeBSD.org/~jhb/patches/ida_locking_dma.patch -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Aug 6 15:34:27 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B4D891065670; Mon, 6 Aug 2012 15:34:27 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 84C178FC0A; Mon, 6 Aug 2012 15:34:27 +0000 (UTC) Received: by pbbrp2 with SMTP id rp2so1472912pbb.13 for ; Mon, 06 Aug 2012 08:34:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Bhatse6eIYi+jpDu407lYDba2TCGJX00+Zxrywh14co=; b=DM13ISCthz4MzitsqX38uMx3jYGUt21ao7Uoi2PgPKhUjg9G13N9r0kw4YbdXhCnZX aXtdxLtOt18g0u0C/P9QC3nZwIMtxINOJK3JU+0j+VEI8emM+bv4gPxViOXbRzfnKRe5 CSXSMaS+QBagdzfVfc2IIcHHhcbuBHkaQiIeGSa5FuMoDCXc66A9gZpn8nY5NmtwrSXE hmOk0WC6i7dwplFl3vFohPbASTIUx+nHXmrMV8HFDzI5BbWey81+SJv3NZ6iHIncIkxH pOwhnKVhFoqAgzLVW24ACU7Tr7DaUODpduW3xCA0Y4RwUFm6UdD+UB31CNDryJ3e0i9R ngiQ== MIME-Version: 1.0 Received: by 10.68.231.168 with SMTP id th8mr20194464pbc.14.1344267267088; Mon, 06 Aug 2012 08:34:27 -0700 (PDT) Received: by 10.68.72.233 with HTTP; Mon, 6 Aug 2012 08:34:26 -0700 (PDT) In-Reply-To: <501D52AD.4010105@protected-networks.net> References: <501D52AD.4010105@protected-networks.net> Date: Mon, 6 Aug 2012 08:34:26 -0700 Message-ID: From: Maksim Yevmenkin To: Michael Butler Content-Type: text/plain; charset=ISO-8859-1 Cc: stable@freebsd.org, current@freebsd.org Subject: Re: geom mirror now rebuilding on every 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: Mon, 06 Aug 2012 15:34:27 -0000 Michael, > Something in -current and recently MFC'd to -stable is causing all of my > gmirror drives to rebuild on reboot :-( > > Being remote and these being production machines, I suspect SVN r237929 > and r237930 in -current and SVN r238500 to -stable but haven't yet been > able to prove it. > > Is anyone else seeing this? yes, i've seem something similar only much, much worse. one of our production systems completely kept loosing its gmirror volumes on every reboot. it looked like gmirror metadata were completely corrupted. rebuilding mirrors and reverting back to previous kernel seemed to work. someone else is tracking it down. thanks, max From owner-freebsd-current@FreeBSD.ORG Mon Aug 6 16:23:05 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7A44A1065672; Mon, 6 Aug 2012 16:23:05 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 320EA8FC15; Mon, 6 Aug 2012 16:23:04 +0000 (UTC) Received: by obbun3 with SMTP id un3so7783943obb.13 for ; Mon, 06 Aug 2012 09:23:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=HwQ2MPOvpQY10fOLl2YiRyhokQkv7Q67ywcu6yCnLVo=; b=tpU8jXitbeQxf//5y1ux/L0M0oICS4RpnUJb63vvyfMXIiXHe8VO2KltN+T5RBlBfU WSx3KTerDwaUZigGOjyk2BB90sMWqsBpAz9Yl4g2UOpOFK8AjYokw2YMQp/JpNvj7of0 eTYcCAkHGfk/xxU72lVIQrB1kYqb7+WlNow3128I1rgMJk13G71OzeCD/XdACGFuhonR 2EO+V7FXDw8q72Ev0tv02Os2PTvcumWdSPxeSM6NIFRt4gZqsrH7kyNwd7yV1A3IbQSN +BGWVUk4UbPmJSr2/DpO8+l7+hcSVYVNmbgzNkmH5oZP7glqzDpuf6/A+N5nhY3PLWEt w0zg== MIME-Version: 1.0 Received: by 10.182.2.233 with SMTP id 9mr19941357obx.11.1344270184415; Mon, 06 Aug 2012 09:23:04 -0700 (PDT) Received: by 10.76.84.7 with HTTP; Mon, 6 Aug 2012 09:23:04 -0700 (PDT) In-Reply-To: References: <501D52AD.4010105@protected-networks.net> Date: Mon, 6 Aug 2012 09:23:04 -0700 Message-ID: From: Garrett Cooper To: Maksim Yevmenkin Content-Type: text/plain; charset=ISO-8859-1 Cc: stable@freebsd.org, Michael Butler , current@freebsd.org Subject: Re: geom mirror now rebuilding on every 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: Mon, 06 Aug 2012 16:23:05 -0000 On Mon, Aug 6, 2012 at 8:34 AM, Maksim Yevmenkin wrote: > Michael, > >> Something in -current and recently MFC'd to -stable is causing all of my >> gmirror drives to rebuild on reboot :-( >> >> Being remote and these being production machines, I suspect SVN r237929 >> and r237930 in -current and SVN r238500 to -stable but haven't yet been >> able to prove it. >> >> Is anyone else seeing this? > > yes, i've seem something similar only much, much worse. one of our > production systems completely kept loosing its gmirror volumes on > every reboot. it looked like gmirror metadata were completely > corrupted. rebuilding mirrors and reverting back to previous kernel > seemed to work. someone else is tracking it down. Is this is in 9.1 -PRERELEASE, -RELEASE (or whatever the official label is...)? If so, it seems like this would be a ship blocker. Thanks! -Garrett From owner-freebsd-current@FreeBSD.ORG Mon Aug 6 16:26:49 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5944F106566B; Mon, 6 Aug 2012 16:26:49 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 2594B8FC20; Mon, 6 Aug 2012 16:26:48 +0000 (UTC) Received: by pbbrp2 with SMTP id rp2so1537507pbb.13 for ; Mon, 06 Aug 2012 09:26:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=LbpLiFEgCkASnqU1c+FcDKS062O4s9sl9V9ObsrAu7A=; b=QccfO/YOUo338W6wND/wr/raftkHFKw7tEJWtZ7SoO3Ftm/rTtxu+9/2u85Tv1QpHt nPQOFJ9XQ2A7U3onD5NVUb3R0KA7nLiMka7Z7To7X1N8D9ljAT62112OBxKc5m/NTM1c 7pDBe2e89tdeGNvdoots7bgDGBb0WdSNN4Bo1KXyisWigncLWeWXWM5M7J6dztBeOGR9 QhP9Vth5su/tXp4KabXQXVItnHd0dcRIxcUQUTey83yIdmkY4pAiK4b7bXIYmqhB8hmG 3H8keDfuWwGWDPfhJEhp/qIoiH/nT+DcWAevdqusP9DyOgpsm4Lnp8Q+qSqZypc0Apkl r7Yw== MIME-Version: 1.0 Received: by 10.68.125.131 with SMTP id mq3mr18828483pbb.31.1344270408563; Mon, 06 Aug 2012 09:26:48 -0700 (PDT) Received: by 10.68.72.233 with HTTP; Mon, 6 Aug 2012 09:26:48 -0700 (PDT) In-Reply-To: References: <501D52AD.4010105@protected-networks.net> Date: Mon, 6 Aug 2012 09:26:48 -0700 Message-ID: From: Maksim Yevmenkin To: Garrett Cooper Content-Type: text/plain; charset=ISO-8859-1 Cc: stable@freebsd.org, Michael Butler , current@freebsd.org Subject: Re: geom mirror now rebuilding on every 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: Mon, 06 Aug 2012 16:26:49 -0000 On Mon, Aug 6, 2012 at 9:23 AM, Garrett Cooper wrote: > On Mon, Aug 6, 2012 at 8:34 AM, Maksim Yevmenkin > wrote: >> Michael, >> >>> Something in -current and recently MFC'd to -stable is causing all of my >>> gmirror drives to rebuild on reboot :-( >>> >>> Being remote and these being production machines, I suspect SVN r237929 >>> and r237930 in -current and SVN r238500 to -stable but haven't yet been >>> able to prove it. >>> >>> Is anyone else seeing this? >> >> yes, i've seem something similar only much, much worse. one of our >> production systems completely kept loosing its gmirror volumes on >> every reboot. it looked like gmirror metadata were completely >> corrupted. rebuilding mirrors and reverting back to previous kernel >> seemed to work. someone else is tracking it down. > > Is this is in 9.1 -PRERELEASE, -RELEASE (or whatever the official > label is...)? If so, it seems like this would be a ship blocker. sorry. its releng_9/9-stable. gmirrors are on two ssds. we use gpt and gmirror individual partitions, not entire disks. thanks, max From owner-freebsd-current@FreeBSD.ORG Mon Aug 6 16:33:06 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3741D1065673; Mon, 6 Aug 2012 16:33:06 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by mx1.freebsd.org (Postfix) with ESMTP id 949C48FC08; Mon, 6 Aug 2012 16:33:05 +0000 (UTC) Received: by wibhr14 with SMTP id hr14so1511778wib.13 for ; Mon, 06 Aug 2012 09:33:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Xc9KbG+mrDwKFGERKLB27m7x3AhOmsUWAMNb1ESvHIw=; b=PCN2j6DlVk2K7IANrmR0qAUyfUBF4qy+DbKcIl3OYza6kZrNh5fsCtbPVgcnJuDpkZ GT88s01fFqJSW/PPxOBCkQcHM4HylNTcbTK6CRUUrM/I1XysSizW/ZGzJfKY5kG47UZa wI+uJRTmYkRARlFRFKtZR+/CukYqqRHc5t/B7RISkFbcQr8bFaQOwL50wXIhKQRd0PCY KBN7TggmPfTrJYjI2bcMrSgKIXgoREjkejq2i/z9bvtkiSfWL8MrcCJM0YuhI6S9gtKK 2FUjhtEqcl0T0YzfVpWR48YRLRBKitc6ySOGYcnOab9AlYXcoT6go81yD2O5CI3+rf8W m4Dw== MIME-Version: 1.0 Received: by 10.216.4.146 with SMTP id 18mr5517630wej.83.1344270783560; Mon, 06 Aug 2012 09:33:03 -0700 (PDT) Received: by 10.223.60.147 with HTTP; Mon, 6 Aug 2012 09:33:03 -0700 (PDT) In-Reply-To: References: <501D52AD.4010105@protected-networks.net> Date: Mon, 6 Aug 2012 09:33:03 -0700 Message-ID: From: Kevin Oberman To: Maksim Yevmenkin Content-Type: text/plain; charset=UTF-8 Cc: Garrett Cooper , stable@freebsd.org, current@freebsd.org Subject: Re: geom mirror now rebuilding on every 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: Mon, 06 Aug 2012 16:33:06 -0000 On Mon, Aug 6, 2012 at 9:26 AM, Maksim Yevmenkin wrote: > On Mon, Aug 6, 2012 at 9:23 AM, Garrett Cooper wrote: >> On Mon, Aug 6, 2012 at 8:34 AM, Maksim Yevmenkin >> wrote: >>> Michael, >>> >>>> Something in -current and recently MFC'd to -stable is causing all of my >>>> gmirror drives to rebuild on reboot :-( >>>> >>>> Being remote and these being production machines, I suspect SVN r237929 >>>> and r237930 in -current and SVN r238500 to -stable but haven't yet been >>>> able to prove it. >>>> >>>> Is anyone else seeing this? >>> >>> yes, i've seem something similar only much, much worse. one of our >>> production systems completely kept loosing its gmirror volumes on >>> every reboot. it looked like gmirror metadata were completely >>> corrupted. rebuilding mirrors and reverting back to previous kernel >>> seemed to work. someone else is tracking it down. >> >> Is this is in 9.1 -PRERELEASE, -RELEASE (or whatever the official >> label is...)? If so, it seems like this would be a ship blocker. > > sorry. its releng_9/9-stable. gmirrors are on two ssds. we use gpt and > gmirror individual partitions, not entire disks. I may well be confused, but I don't understand how you can use GPT for a single partition. Looks to me like a disk is GPT or legacy. Declaring which is the first command when setting up a new disk. -- R. Kevin Oberman, Network Engineer E-mail: kob6558@gmail.com From owner-freebsd-current@FreeBSD.ORG Mon Aug 6 16:40:44 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 16C5B1065670; Mon, 6 Aug 2012 16:40:44 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id D4FC38FC12; Mon, 6 Aug 2012 16:40:43 +0000 (UTC) Received: by pbbrp2 with SMTP id rp2so1554460pbb.13 for ; Mon, 06 Aug 2012 09:40:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1VlVaZgTS1TGrqIfBPo5N/9zR4oH/zpfqAQntFF3FjQ=; b=RPKg1oOdlKKmbhfyJb3sNC06x5kTRq57CkTXj/agNELV4pZiSguI0xbo9hN1bOE5G5 OyCMv04NkiR5FAP4tnrHjIWTsph0CbQNAJ+4QSjLcc1ypODgRI2qpZ/j8dqzfam9HoXZ iHWh7QhdaNBZ6Yn1X94ojQPlMz5GQVo/ylIakvH/OxpmWLbuCusvjDwPKMwMjzfD3KQz MVhfTuXmuOAnsooFWUDCbpKRUwiGEV58kbFc2LVCjMjeIB4ArcrZfo39pIQsnG7is5lq bXSXJsuVOXbnsC+bGmF/jmZg7XD5v2iiS47lreGmv9MqnbQJ71lsQckPt+z7arY8LaKj 7A5Q== MIME-Version: 1.0 Received: by 10.68.130.9 with SMTP id oa9mr20235207pbb.95.1344271242994; Mon, 06 Aug 2012 09:40:42 -0700 (PDT) Received: by 10.68.72.233 with HTTP; Mon, 6 Aug 2012 09:40:42 -0700 (PDT) In-Reply-To: References: <501D52AD.4010105@protected-networks.net> Date: Mon, 6 Aug 2012 09:40:42 -0700 Message-ID: From: Maksim Yevmenkin To: Kevin Oberman Content-Type: text/plain; charset=ISO-8859-1 Cc: Garrett Cooper , stable@freebsd.org, current@freebsd.org Subject: Re: geom mirror now rebuilding on every 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: Mon, 06 Aug 2012 16:40:44 -0000 On Mon, Aug 6, 2012 at 9:33 AM, Kevin Oberman wrote: > On Mon, Aug 6, 2012 at 9:26 AM, Maksim Yevmenkin > wrote: >> On Mon, Aug 6, 2012 at 9:23 AM, Garrett Cooper wrote: >>> On Mon, Aug 6, 2012 at 8:34 AM, Maksim Yevmenkin >>> wrote: >>>> Michael, >>>> >>>>> Something in -current and recently MFC'd to -stable is causing all of my >>>>> gmirror drives to rebuild on reboot :-( >>>>> >>>>> Being remote and these being production machines, I suspect SVN r237929 >>>>> and r237930 in -current and SVN r238500 to -stable but haven't yet been >>>>> able to prove it. >>>>> >>>>> Is anyone else seeing this? >>>> >>>> yes, i've seem something similar only much, much worse. one of our >>>> production systems completely kept loosing its gmirror volumes on >>>> every reboot. it looked like gmirror metadata were completely >>>> corrupted. rebuilding mirrors and reverting back to previous kernel >>>> seemed to work. someone else is tracking it down. >>> >>> Is this is in 9.1 -PRERELEASE, -RELEASE (or whatever the official >>> label is...)? If so, it seems like this would be a ship blocker. >> >> sorry. its releng_9/9-stable. gmirrors are on two ssds. we use gpt and >> gmirror individual partitions, not entire disks. > > I may well be confused, but I don't understand how you can use GPT for > a single partition. Looks to me like a disk is GPT or legacy. > Declaring which is the first command when setting up a new disk. i'm sorry, to make it (hopefully) clear, we are using gpt partitioning scheme (as opposed to mbr partitioning scheme), and then use gmirror on individual partitions, i.e. we gimirror /dev/ada0p1 and /dev/ada1p1 and not /dev/ada0 and /dev/ada1. thanks max From owner-freebsd-current@FreeBSD.ORG Mon Aug 6 17:13:42 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AAFC7106566C; Mon, 6 Aug 2012 17:13:42 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-gg0-f182.google.com (mail-gg0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 47CCB8FC08; Mon, 6 Aug 2012 17:13:42 +0000 (UTC) Received: by ggnk4 with SMTP id k4so3291627ggn.13 for ; Mon, 06 Aug 2012 10:13:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=eImlt1ij4fIRR7ebKM5BW0jbKkE0v79LKPT/6uorSsA=; b=gib8HcoxTFyVk5NJbrdGaRY1AxxDOmS/niygGyY+ApeeOzMDIem+DJI553ithU2BHs RYkCVoYnRvwNHkL+ZOPG3gx/CciJAyvYQdjqxCwZW7Ni/NYxlO/2x5R9u6VUkOo+yHHK /LAb9+k3+Ir4bfGJKFc9FKvNOp/JlVVvVUZty9RJvkEBs+XDqPmjya90uPRcXlwj5pWJ e3eE1y/pbfGM+bGLTpgRWHvHlX8CQNVtn1Bmua57Mx8hLZ6/ezFEDLY7QVSZxvbd74Zt RHaDDqGmMU2tmcQIGNjM/CTkVrA5mxPdRcK0TO3jLb4D3Qc659CQ1t0W1ukvVbEwx/1H 8ycg== Received: by 10.66.74.3 with SMTP id p3mr19558251pav.49.1344273221230; Mon, 06 Aug 2012 10:13:41 -0700 (PDT) Received: from [10.42.27.125] (mobile-166-147-095-174.mycingular.net. [166.147.95.174]) by mx.google.com with ESMTPS id pv8sm41593pbb.25.2012.08.06.10.13.39 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 06 Aug 2012 10:13:40 -0700 (PDT) References: <501D52AD.4010105@protected-networks.net> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <4A267A1D-8AB4-4B0F-9F99-E04358A40FF5@gmail.com> X-Mailer: iPhone Mail (9B206) From: Garrett Cooper Date: Mon, 6 Aug 2012 10:13:34 -0700 To: Maksim Yevmenkin Cc: "stable@freebsd.org" , "current@freebsd.org" Subject: Re: geom mirror now rebuilding on every 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: Mon, 06 Aug 2012 17:13:42 -0000 On Aug 6, 2012, at 9:40 AM, Maksim Yevmenkin wr= ote: > On Mon, Aug 6, 2012 at 9:33 AM, Kevin Oberman wrote: >> On Mon, Aug 6, 2012 at 9:26 AM, Maksim Yevmenkin >> wrote: >>> On Mon, Aug 6, 2012 at 9:23 AM, Garrett Cooper wrot= e: >>>> On Mon, Aug 6, 2012 at 8:34 AM, Maksim Yevmenkin >>>> wrote: >>>>> Michael, >>>>>=20 >>>>>> Something in -current and recently MFC'd to -stable is causing all of= my >>>>>> gmirror drives to rebuild on reboot :-( >>>>>>=20 >>>>>> Being remote and these being production machines, I suspect SVN r2379= 29 >>>>>> and r237930 in -current and SVN r238500 to -stable but haven't yet be= en >>>>>> able to prove it. >>>>>>=20 >>>>>> Is anyone else seeing this? >>>>>=20 >>>>> yes, i've seem something similar only much, much worse. one of our >>>>> production systems completely kept loosing its gmirror volumes on >>>>> every reboot. it looked like gmirror metadata were completely >>>>> corrupted. rebuilding mirrors and reverting back to previous kernel >>>>> seemed to work. someone else is tracking it down. >>>>=20 >>>> Is this is in 9.1 -PRERELEASE, -RELEASE (or whatever the official >>>> label is...)? If so, it seems like this would be a ship blocker. >>>=20 >>> sorry. its releng_9/9-stable. gmirrors are on two ssds. we use gpt and >>> gmirror individual partitions, not entire disks. >>=20 >> I may well be confused, but I don't understand how you can use GPT for >> a single partition. Looks to me like a disk is GPT or legacy. >> Declaring which is the first command when setting up a new disk. >=20 > i'm sorry, to make it (hopefully) clear, we are using gpt partitioning > scheme (as opposed to mbr partitioning scheme), and then use gmirror > on individual partitions, i.e. we gimirror /dev/ada0p1 and /dev/ada1p1 > and not /dev/ada0 and /dev/ada1. Can you provide more helpful info like svn revisions?= From owner-freebsd-current@FreeBSD.ORG Mon Aug 6 18:06:25 2012 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5992A1065673; Mon, 6 Aug 2012 18:06:25 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.64.117]) by mx1.freebsd.org (Postfix) with ESMTP id CFA838FC0A; Mon, 6 Aug 2012 18:06:24 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.5/8.14.5) with ESMTP id q76I6HqC025724; Mon, 6 Aug 2012 22:06:17 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.5/8.14.5/Submit) id q76I6HXe025723; Mon, 6 Aug 2012 22:06:17 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Mon, 6 Aug 2012 22:06:17 +0400 From: Gleb Smirnoff To: Michael Butler Message-ID: <20120806180617.GJ20560@FreeBSD.org> References: <501D52AD.4010105@protected-networks.net> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <501D52AD.4010105@protected-networks.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: stable@FreeBSD.org, current@FreeBSD.org Subject: Re: geom mirror now rebuilding on every 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: Mon, 06 Aug 2012 18:06:25 -0000 Michael, On Sat, Aug 04, 2012 at 12:49:49PM -0400, Michael Butler wrote: M> Something in -current and recently MFC'd to -stable is causing all of my M> gmirror drives to rebuild on reboot :-( M> M> Being remote and these being production machines, I suspect SVN r237929 M> and r237930 in -current and SVN r238500 to -stable but haven't yet been M> able to prove it. I'd appreciate if you test that and either confirm or disclaim that r238500 introduces such regression. Thanks! -- Totus tuus, Glebius. From owner-freebsd-current@FreeBSD.ORG Mon Aug 6 20:37:57 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8356B106566C; Mon, 6 Aug 2012 20:37:57 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from sarah.protected-networks.net (sarah.protected-networks.net [IPv6:2001:470:1f07:4e1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 475388FC08; Mon, 6 Aug 2012 20:37:57 +0000 (UTC) Received: from mail.auburn.protected-networks.net (mail.auburn.protected-networks.net [202.12.127.83]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail.auburn.protected-networks.net", Issuer "Protected Networks Certificate Authority" (verified OK)) by sarah.protected-networks.net (Postfix) with ESMTPS id 4A265612B; Mon, 6 Aug 2012 16:37:55 -0400 (EDT) Authentication-Results: sarah.protected-networks.net; domainkeys=fail (no signature) (testing) header.from=imb@protected-networks.net Received: from mail.auburn.protected-networks.net (localhost.auburn.protected-networks.net [127.0.0.1]) by mail.auburn.protected-networks.net (Postfix) with ESMTP id BBFDE1CD83; Mon, 6 Aug 2012 16:37:53 -0400 (EDT) Received: from mail.auburn.protected-networks.net ([127.0.0.1]) by mail.auburn.protected-networks.net (mail.auburn.protected-networks.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WRgCd9iU5zKV; Mon, 6 Aug 2012 16:37:51 -0400 (EDT) Received: from Inbox (mb05736d0.tmodns.net [208.54.87.176]) (Authenticated sender: imb@mail.auburn.protected-networks.net) by mail.auburn.protected-networks.net (Postfix) with ESMTPA; Mon, 6 Aug 2012 16:37:49 -0400 (EDT) MIME-Version: 1.0 content-class: From: Michael Butler Date: Mon, 6 Aug 2012 16:37:52 -0400 Importance: normal X-Priority: 3 To: Maksim Yevmenkin , Garrett Cooper Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" Message-Id: <20120806203757.8356B106566C@hub.freebsd.org> Cc: stable@freebsd.org, current@freebsd.org Subject: RE: geom mirror now rebuilding on every 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: Mon, 06 Aug 2012 20:37:57 -0000 Ding, ding - I use the old partitioning scheme but also mirror individual p= artitions rather than whole disks, imb =20 -----Original Message----- From: Maksim Yevmenkin Sent: Monday, 6 August 2012 12:26 To: Garrett Cooper Cc: stable@freebsd.org; Michael Butler ; curren= t@freebsd.org Subject: Re: geom mirror now rebuilding on every reboot? On Mon, Aug 6, 2012 at 9:23 AM, Garrett Cooper wrote: > On Mon, Aug 6, 2012 at 8:34 AM, Maksim Yevmenkin > wrote: >> Michael, >> >>> Something in -current and recently MFC'd to -stable is causing all of m= y >>> gmirror drives to rebuild on reboot :-( >>> >>> Being remote and these being production machines, I suspect SVN r237929 >>> and r237930 in -current and SVN r238500 to -stable but haven't yet been >>> able to prove it. >>> >>> Is anyone else seeing this? >> >> yes, i've seem something similar only much, much worse. one of our >> production systems completely kept loosing its gmirror volumes on >> every reboot. it looked like gmirror metadata were completely >> corrupted. rebuilding mirrors and reverting back to previous kernel >> seemed to work. someone else is tracking it down. > > Is this is in 9.1 -PRERELEASE, -RELEASE (or whatever the official > label is...)? If so, it seems like this would be a ship blocker. sorry. its releng_9/9-stable. gmirrors are on two ssds. we use gpt and gmirror individual partitions, not entire disks. thanks, max _______________________________________________ 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 Aug 6 20:38:04 2012 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 821031065674; Mon, 6 Aug 2012 20:38:04 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from sarah.protected-networks.net (sarah.protected-networks.net [IPv6:2001:470:1f07:4e1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 410138FC12; Mon, 6 Aug 2012 20:38:04 +0000 (UTC) Received: from mail.auburn.protected-networks.net (mail.auburn.protected-networks.net [202.12.127.83]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail.auburn.protected-networks.net", Issuer "Protected Networks Certificate Authority" (verified OK)) by sarah.protected-networks.net (Postfix) with ESMTPS id BC6456171; Mon, 6 Aug 2012 16:38:03 -0400 (EDT) Authentication-Results: sarah.protected-networks.net; domainkeys=fail (no signature) (testing) header.from=imb@protected-networks.net Received: from mail.auburn.protected-networks.net (localhost.auburn.protected-networks.net [127.0.0.1]) by mail.auburn.protected-networks.net (Postfix) with ESMTP id 208601CD86; Mon, 6 Aug 2012 16:38:03 -0400 (EDT) Received: from mail.auburn.protected-networks.net ([127.0.0.1]) by mail.auburn.protected-networks.net (mail.auburn.protected-networks.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BnLQ7FUPWyKx; Mon, 6 Aug 2012 16:38:02 -0400 (EDT) Received: from Inbox (mb05736d0.tmodns.net [208.54.87.176]) (Authenticated sender: imb@mail.auburn.protected-networks.net) by mail.auburn.protected-networks.net (Postfix) with ESMTPA; Mon, 6 Aug 2012 16:37:56 -0400 (EDT) MIME-Version: 1.0 content-class: From: Michael Butler Date: Mon, 6 Aug 2012 16:38:01 -0400 Importance: normal X-Priority: 3 To: Gleb Smirnoff Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="koi8-r" Message-Id: <20120806203804.821031065674@hub.freebsd.org> Cc: stable@FreeBSD.org, current@FreeBSD.org Subject: RE: geom mirror now rebuilding on every 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: Mon, 06 Aug 2012 20:38:04 -0000 Sorry but I'm not going to be able to get to this until next w/e as I'm ~15= 00 miles away from them at present :-( =20 -----Original Message----- From: Gleb Smirnoff Sent: Monday, 6 August 2012 14:06 To: Michael Butler Cc: current@FreeBSD.org; stable@FreeBSD.org Subject: Re: geom mirror now rebuilding on every reboot? Michael, On Sat, Aug 04, 2012 at 12:49:49PM -0400, Michael Butler wrote: M> Something in -current and recently MFC'd to -stable is causing all of my M> gmirror drives to rebuild on reboot :-( M>=20 M> Being remote and these being production machines, I suspect SVN r237929 M> and r237930 in -current and SVN r238500 to -stable but haven't yet been M> able to prove it. I'd appreciate if you test that and either confirm or disclaim that r238500 introduces such regression. Thanks! --=20 Totus tuus, Glebius. From owner-freebsd-current@FreeBSD.ORG Mon Aug 6 21:33:21 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 43C0E1065774; Mon, 6 Aug 2012 21:33:19 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 6BD368FC16; Mon, 6 Aug 2012 21:33:18 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id BFF7CB91A; Mon, 6 Aug 2012 17:33:17 -0400 (EDT) From: John Baldwin To: current@freebsd.org Date: Mon, 6 Aug 2012 17:27:39 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p17; KDE/4.5.5; amd64; ; ) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201208061727.39071.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 06 Aug 2012 17:33:17 -0400 (EDT) Cc: dteske@freebsd.org Subject: [PATCH] Add locking to mlx(4) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Aug 2012 21:33:21 -0000 Continuing with the theme of locking older storage drivers, I have patches to add locking to mlx(4) and mark it MPSAFE. The patches are from HEAD but should apply to 8 or 9. If you test it on 8 or 9 please enable INVARIANTS for at least the initial testing. Thanks. http://www.FreeBSD.org/~jhb/patches/mlx_locking.patch -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Aug 7 00:17:30 2012 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 441E01065670; Tue, 7 Aug 2012 00:17: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 0FF368FC0A; Tue, 7 Aug 2012 00:17:29 +0000 (UTC) Received: from [127.0.0.1] (pooker.samsco.org [168.103.85.57]) (authenticated bits=0) by pooker.samsco.org (8.14.5/8.14.5) with ESMTP id q770HKHN061965; Mon, 6 Aug 2012 18:17:21 -0600 (MDT) (envelope-from scottl@samsco.org) Content-Type: text/plain; charset=koi8-r Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) From: Scott Long In-Reply-To: <20120806180617.GJ20560@FreeBSD.org> Date: Mon, 6 Aug 2012 18:17:20 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <501D52AD.4010105@protected-networks.net> <20120806180617.GJ20560@FreeBSD.org> To: Gleb Smirnoff X-Mailer: Apple Mail (2.1485) X-Spam-Status: No, score=-50.0 required=3.8 tests=ALL_TRUSTED, T_RP_MATCHES_RCVD autolearn=unavailable version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on pooker.samsco.org Cc: stable@FreeBSD.org, Michael Butler , current@FreeBSD.org Subject: Re: geom mirror now rebuilding on every 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: Tue, 07 Aug 2012 00:17:30 -0000 On Aug 6, 2012, at 12:06 PM, Gleb Smirnoff wrote: > Michael, >=20 > On Sat, Aug 04, 2012 at 12:49:49PM -0400, Michael Butler wrote: > M> Something in -current and recently MFC'd to -stable is causing all = of my > M> gmirror drives to rebuild on reboot :-( > M>=20 > M> Being remote and these being production machines, I suspect SVN = r237929 > M> and r237930 in -current and SVN r238500 to -stable but haven't yet = been > M> able to prove it. >=20 > I'd appreciate if you test that and either confirm or disclaim that > r238500 introduces such regression. Thanks! >=20 I'm not sure how r238500 could affect what Max, myself, and presumably = the original poster are seeing. There's one other change in 9-stable, = r235599, but it looks like a benign change as well. Scott From owner-freebsd-current@FreeBSD.ORG Tue Aug 7 00:21:54 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 253EA1065672 for ; Tue, 7 Aug 2012 00:21:54 +0000 (UTC) (envelope-from tom@uffner.com) Received: from eris.uffner.com (eris.uffner.com [71.162.143.94]) by mx1.freebsd.org (Postfix) with ESMTP id CC4EE8FC08 for ; Tue, 7 Aug 2012 00:21:53 +0000 (UTC) Received: from discordia.uffner.com (discordia.uffner.com [10.69.69.61]) (authenticated bits=0) by eris.uffner.com (8.14.5/8.14.5) with ESMTP id q77045aa009402 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=FAIL) for ; Mon, 6 Aug 2012 20:04:16 -0400 (EDT) (envelope-from tom@uffner.com) Message-ID: <50205B66.10701@uffner.com> Date: Mon, 06 Aug 2012 20:03:50 -0400 From: Tom Uffner User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:12.0) Gecko/20120517 Firefox/12.0 SeaMonkey/2.9.1 MIME-Version: 1.0 To: current@freebsd.org References: <20120806203804.821031065674@hub.freebsd.org> In-Reply-To: <20120806203804.821031065674@hub.freebsd.org> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: geom mirror now rebuilding on every 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: Tue, 07 Aug 2012 00:21:54 -0000 not quite the same issue, but i tried to update a system with gmirror from FreeBSD eris.uffner.com 10.0-CURRENT FreeBSD 10.0-CURRENT #210: Thu Mar 15 16:41:18 EDT 2012 tom@eris.uffner.com:/usr/obj/usr/src/sys/ERIS i386 to -current from Aug 4th, and booting now fails into mountroot> with GEOM_RAID: Promise: Array Promise Created GEOM_RAID: Promise: Disk ad4 state changed from NONE to SPARE GEOM_MIRROR: Cannot open consumer ad4 (error=1) GEOM_MIRROR: Cannot add disk ad4 to gm0 (error=1) GEOM_MIRROR: Device gm0 destroyed GEOM_RAID: Promise: Array Promise Created GEOM_RAID: Promise: Disk ad6 state changed from NONE to SPARE GEOM_MIRROR: Cannot open consumer ad6 (error=1) GEOM_MIRROR: Cannot add disk ad6 to gm0 (error=1) GEOM_MIRROR: Device gm0 destroyed nor will it boot from the underlying partitions (ad4s1a, ad6s1a), even if i unplug one of the drives. the partitions & metadata are not corrupt and work just fine if i revert to the previous kernel. i haven't had time yet to track down the commit where this breaks. i was just wondering if anyone knew offhand what is going on & how to fix it. tom From owner-freebsd-current@FreeBSD.ORG Tue Aug 7 01:46:17 2012 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 35F3B106566C; Tue, 7 Aug 2012 01:46:17 +0000 (UTC) (envelope-from frank@undermydesk.org) Received: from amazone.undermydesk.org (amazone.undermydesk.org [213.211.198.100]) by mx1.freebsd.org (Postfix) with ESMTP id DAA4A8FC15; Tue, 7 Aug 2012 01:46:16 +0000 (UTC) Received: from amazone.undermydesk.org (localhost [127.0.0.1]) by amazone.undermydesk.org (Postfix) with ESMTP id 2AA4A286E7B; Tue, 7 Aug 2012 03:46:10 +0200 (CEST) X-Virus-Scanned: amavisd-new at undermydesk.org Received: from amazone.undermydesk.org ([213.211.198.100]) by amazone.undermydesk.org (amazone.undermydesk.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rp7q0obUsUu6; Tue, 7 Aug 2012 03:46:08 +0200 (CEST) Received: from [192.168.0.74] (p54B36834.dip.t-dialin.net [84.179.104.52]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by amazone.undermydesk.org (Postfix) with ESMTPSA id C427B286E7A; Tue, 7 Aug 2012 03:46:08 +0200 (CEST) Message-ID: <5020735C.2000701@undermydesk.org> Date: Tue, 07 Aug 2012 03:46:04 +0200 From: Frank Reppin User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: stable@FreeBSD.org, current@FreeBSD.org References: <501D52AD.4010105@protected-networks.net> <20120806180617.GJ20560@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: geom mirror now rebuilding on every 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: Tue, 07 Aug 2012 01:46:17 -0000 by any chance... ... is this maybe related to my PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=170038 cheers, Frank Reppin -- 43rd Law of Computing: Anything that can go wr fortune: Segmentation violation -- Core dumped From owner-freebsd-current@FreeBSD.ORG Tue Aug 7 09:31:22 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6FF21106568B; Tue, 7 Aug 2012 09:31:22 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id DC0048FC14; Tue, 7 Aug 2012 09:31:21 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1Syg8B-0004U0-5w>; Tue, 07 Aug 2012 11:31:15 +0200 Received: from e178018228.adsl.alicedsl.de ([85.178.18.228] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1Syg8A-0006AB-WF>; Tue, 07 Aug 2012 11:31:15 +0200 Message-ID: <5020E05C.3000704@zedat.fu-berlin.de> Date: Tue, 07 Aug 2012 11:31:08 +0200 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:14.0) Gecko/20120801 Thunderbird/14.0 MIME-Version: 1.0 To: Current FreeBSD , Ports FreeBSD X-Enigmail-Version: 1.4.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig995387F9CB2C294BC65FDE0B" X-Originating-IP: 85.178.18.228 Cc: Subject: pkg and portmaster: Downgrading ports? Why? portmaster messes up ... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 07 Aug 2012 09:31:22 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig995387F9CB2C294BC65FDE0B Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Hello. I tried to switch to the new tool pkg. I'm still installing my ports via sources and compiling, but I appreciate the more stable dependency tracking of pkg(ng). Therefore, I patched, as reuqired and recommended, ports-mgmt/portmaster.= I performed a portmaster --check-depends after I got several warnings and two very confusing (if not scaring) exclsuions and therefore rejectio= ns: graphics/libGL and x11/nvidia-driver (which is in my case 304.32 and works pretty well so far!), x11-server/xorg-server. They all install, so the compalin of pkg/portmaster, files in the very same place. So I'm stuck and I do not know, whether my ports collection is now corrupted by this stubborn behaviour or not. Mor scaring, performing a "portmaster --check-depends" ends up in this: >>> Missing package dependencies were detected. >>> Found 2 issue(s) in total with your package database. The following packages will be installed: Installing pkg-config: 0.25_1 Downgrading pciids: 20120711 -> 20120625 Downgrading libdrm: 2.4.31_1 -> 2.4.17_1 Installing libGL: 7.6.1 Installing perl: 5.14.2_2 Downgrading dbus: 1.4.14_3 -> 1.4.14_2 Downgrading dri: 7.11.2_1,2 -> 7.6.1,2 Downgrading pcre: 8.31 -> 8.30_2 Downgrading python27: 2.7.3_3 -> 2.7.3_2 Installing xorg-server: 1.7.7_5,1 The installation will require 40 MB more space 28 MB to be downloaded Before I made the update towards pkg via pkg2ng, I updated everything with portmaster as it worked in the old-fashion before. I have set properly the knob WITH_NEW_X11 in /etc/make.conf. Now this new toolset tries to donwgrade some of the ports - why? What happens here? ports-mgmt/portmaster installs still the old fashioned style folders of ports in /var/db/pkg. I thought ith the new scheme of pkg, everything is going into a file based SQLite3 DB? With each kernel update, I also need to update x11/nvidia-driver. I do this by /etc/src.conf setting PORTS_MODULES=3D "x11/nvidia-driver" PORTS_MODULES+=3D "emulators/virtualbox-ose-kmod" The nvidia driver now fails. How can I circumvent this nasty problem? Is there a "brute force" knob. Will ports-mgmt/portupgrade-devel heal those problems? My OS is a most recent FBSD 10.0-CURRENT. Regards, Oliver --------------enig995387F9CB2C294BC65FDE0B Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBAgAGBQJQIOBiAAoJEOgBcD7A/5N8ry4H/juVMTagNXwmmKPKadeHxY48 6sjlTjA2kI8emkWXmZ1zLORTu2TacOiea3RHXg3usxzL7C56Qa1utkBJqA8vGWkH EnT4h6Ce4gI+KXhQv6Y//4i8p/hIcbxnuYBlOAqukgKSBS2bgvj4H1KiZ7d92+tC jPKCH20NMGT4KjRygHXCYX0Y9pOZC+Kxl3KnsFoTxGULTKuI0EZknMp/kpIjorR8 lIjLedzCUU3NHRMfpdqanCgCjokc8EuyC0LUQmx/q8HuIS6PLOzkWOtKZWve+VP2 4c/cJQPA07MMub3/3D0DQqQuehwlI7tIArui2QgdmYtHGOGax/AEkU6Y66GBJwU= =kWLV -----END PGP SIGNATURE----- --------------enig995387F9CB2C294BC65FDE0B-- From owner-freebsd-current@FreeBSD.ORG Tue Aug 7 13:37:47 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E13DF106566C for ; Tue, 7 Aug 2012 13:37:46 +0000 (UTC) (envelope-from bryan@shatow.net) Received: from secure.xzibition.com (secure.xzibition.com [173.160.118.92]) by mx1.freebsd.org (Postfix) with ESMTP id 3C6C18FC08 for ; Tue, 7 Aug 2012 13:37:45 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; c=nofws; d=shatow.net; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sweb; b=o88QxG /cwNtCc8plk4gA4TfZTjYtZc6HK4xjwuDCCJLjT0Tj0yzzpR/rCKYfi6Au4IKT/j 9fG9bar+cjrPtW642DV9FPFA2NO1Y6JOnXAKjEgiJFoRm7f12muKD02ASM2RLuMu 2fxouWG49e+dL6aXTZ6/ezRArsUphmgNzIzYU= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=shatow.net; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sweb; bh=tnxy1rYBoj7/ LhLEzIvpU6XvWSzBGWopVe1n35A+OKA=; b=1IlCQNFyL+sKTojtUsVMQAjeXHCR siLcwoxKlcDyiRKiiRLMZdOidXwTNTjmusnbbF+eEEZy2Yi2a8Qi7xnwj1SebNK5 komRRz/d4JPihHSE4Hrw9I/6Kc+NgFiiegbQJSOJyEiwpn3lhNDka3GBTT4VywQ1 SsK9uTI37cVKziQ= Received: (qmail 19138 invoked from network); 7 Aug 2012 08:37:38 -0500 Received: from unknown (HELO ?10.10.0.115?) (bryan@shatow.net@10.10.0.115) by sweb.xzibition.com with ESMTPA; 7 Aug 2012 08:37:38 -0500 Message-ID: <50211A0F.9060600@shatow.net> Date: Tue, 07 Aug 2012 08:37:19 -0500 From: Bryan Drewery User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: "O. Hartmann" References: <5020E05C.3000704@zedat.fu-berlin.de> In-Reply-To: <5020E05C.3000704@zedat.fu-berlin.de> X-Enigmail-Version: 1.4.3 OpenPGP: id=3C9B0CF9; url=http://www.shatow.net/bryan/bryan.asc Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: Current FreeBSD , Ports FreeBSD Subject: Re: pkg and portmaster: Downgrading ports? Why? portmaster messes up ... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 07 Aug 2012 13:37:47 -0000 On 8/7/2012 4:31 AM, O. Hartmann wrote: > Hello. > I tried to switch to the new tool pkg. I'm still installing my ports via > sources and compiling, but I appreciate the more stable dependency > tracking of pkg(ng). > Therefore, I patched, as reuqired and recommended, ports-mgmt/portmaster. > > I performed a portmaster --check-depends after I got several warnings > and two very confusing (if not scaring) exclsuions and therefore rejections: > > graphics/libGL and x11/nvidia-driver (which is in my case 304.32 and > works pretty well so far!), x11-server/xorg-server. They all install, so > the compalin of pkg/portmaster, files in the very same place. So I'm > stuck and I do not know, whether my ports collection is now corrupted by > this stubborn behaviour or not. > > Mor scaring, performing a "portmaster --check-depends" ends up in this: > >>>> Missing package dependencies were detected. >>>> Found 2 issue(s) in total with your package database. > > The following packages will be installed: > > Installing pkg-config: 0.25_1 > Downgrading pciids: 20120711 -> 20120625 > Downgrading libdrm: 2.4.31_1 -> 2.4.17_1 > Installing libGL: 7.6.1 > Installing perl: 5.14.2_2 > Downgrading dbus: 1.4.14_3 -> 1.4.14_2 > Downgrading dri: 7.11.2_1,2 -> 7.6.1,2 > Downgrading pcre: 8.31 -> 8.30_2 > Downgrading python27: 2.7.3_3 -> 2.7.3_2 > Installing xorg-server: 1.7.7_5,1 > > The installation will require 40 MB more space > > 28 MB to be downloaded > > > Before I made the update towards pkg via pkg2ng, I updated everything > with portmaster as it worked in the old-fashion before. I have set > properly the knob WITH_NEW_X11 in /etc/make.conf. Now this new toolset > tries to donwgrade some of the ports - why? What happens here? There's some discrepancy between your installed packages, ports, and possibly a remote repository. portmaster --check-depends must not be properly implemented with pkgng. It's trying to use the remote repository to fix the problems it sees instead of the local PORTS tree. The remote is outdated, so it's also trying to downgrade packages. I would not use --check-depends for now. Just manually portmaster every port that's missing. > > ports-mgmt/portmaster installs still the old fashioned style folders of > ports in /var/db/pkg. I thought ith the new scheme of pkg, everything is > going into a file based SQLite3 DB? The portmaster patch is only storing distfile information. The actual pkg db is only using the SQLite3 pkgng db. > > With each kernel update, I also need to update x11/nvidia-driver. I do > this by /etc/src.conf setting > > PORTS_MODULES= "x11/nvidia-driver" > PORTS_MODULES+= "emulators/virtualbox-ose-kmod" > > The nvidia driver now fails. How can I circumvent this nasty problem? Is > there a "brute force" knob. > > Will ports-mgmt/portupgrade-devel heal those problems? The main problem I see is with --check-depends. This looks to the be equivalent of 'pkgdb -F'. Currently 'pkgdb -F' is not implemented in portupgrade-devel for pkgng support. So it won't help. > > My OS is a most recent FBSD 10.0-CURRENT. > > Regards, > Oliver > -- Regards, Bryan Drewery bdrewery@freenode/EFNet From owner-freebsd-current@FreeBSD.ORG Tue Aug 7 13:39:48 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BE3651065676 for ; Tue, 7 Aug 2012 13:39:48 +0000 (UTC) (envelope-from bryan@shatow.net) Received: from secure.xzibition.com (secure.xzibition.com [173.160.118.92]) by mx1.freebsd.org (Postfix) with ESMTP id 652B38FC0A for ; Tue, 7 Aug 2012 13:39:48 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; c=nofws; d=shatow.net; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sweb; b=PG0x9d HYhmVGEfrE1CViW7hRA4ia54gXo4CZNHWFv5+Jk+DJNPnOanikLRc2tZEmsa3ZgD 5MKiwL4RatURMAgNBfKGv3GaCPItk1sJgAoYrBvW89Wl3FGZriujEBqwn2HPIVsb TgddqhoLwilhx/sY0vX0WFHy0hZ7U8ATPgQhI= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=shatow.net; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sweb; bh=pjN8yHnfUKND mPzNra9GpUgW/gCZSJUZZLV0sPw81Rc=; b=K9/+yZ4PChHTYko4qFyH543bYhVW J4MtFSRZgpwfgV55kIKPKyFL3ThVVCTRmdtpPoPWcuH0T/4VyDXwTyGZVH4MzuG4 suXfOOWD4uxFzizX/mHVaBZ+x/hbD0SkYN5Q5ktC/4b3YUvTsbI0FNCQPRltlg1Y K1Qv5FPR9i3lCRc= Received: (qmail 64184 invoked from network); 7 Aug 2012 08:39:46 -0500 Received: from unknown (HELO ?10.10.0.115?) (bryan@shatow.net@10.10.0.115) by sweb.xzibition.com with ESMTPA; 7 Aug 2012 08:39:46 -0500 Message-ID: <50211A8F.40108@shatow.net> Date: Tue, 07 Aug 2012 08:39:27 -0500 From: Bryan Drewery User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: "O. Hartmann" References: <5020E05C.3000704@zedat.fu-berlin.de> In-Reply-To: <5020E05C.3000704@zedat.fu-berlin.de> X-Enigmail-Version: 1.4.3 OpenPGP: id=3C9B0CF9; url=http://www.shatow.net/bryan/bryan.asc Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: Current FreeBSD , Ports FreeBSD Subject: Re: pkg and portmaster: Downgrading ports? Why? portmaster messes up ... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 07 Aug 2012 13:39:48 -0000 On 8/7/2012 4:31 AM, O. Hartmann wrote: > ports-mgmt/portmaster installs still the old fashioned style folders of > ports in /var/db/pkg. I thought ith the new scheme of pkg, everything is > going into a file based SQLite3 DB? Also ensure WITH_PKGNG=yes is in your /etc/make.conf. My last comment still stands though, portmaster will store distifile information in /var/db/pkg. -- Regards, Bryan Drewery bdrewery@freenode/EFNet From owner-freebsd-current@FreeBSD.ORG Tue Aug 7 14:09:16 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DE6E1106566B; Tue, 7 Aug 2012 14:09:16 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward19.mail.yandex.net (forward19.mail.yandex.net [IPv6:2a02:6b8:0:1402::4]) by mx1.freebsd.org (Postfix) with ESMTP id 4E16D8FC0A; Tue, 7 Aug 2012 14:09:16 +0000 (UTC) Received: from smtp18.mail.yandex.net (smtp18.mail.yandex.net [95.108.252.18]) by forward19.mail.yandex.net (Yandex) with ESMTP id 5BBCE1120D9F; Tue, 7 Aug 2012 18:09:14 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1344348554; bh=Dt9pxhSBRRZT0m/7Zya2EC5ZVRhQmuhZjB62ch9LpTs=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=p5v2yC8PB9jT6g1Emd3r2t8+RRmfUiFIJiMKd7A/qn+b+G58XzJn/O0IhX8jP27r3 Y5RdhqsvRyRjlQKeYYVt6L7pPr0wlPN4kntqXhtPtgg8R8miupEn/an9VQNYaUaSqB mttIwf1PxmgS+oaptqX2OLXwGGaqr1Wgq2DzvHxk= Received: from smtp18.mail.yandex.net (localhost [127.0.0.1]) by smtp18.mail.yandex.net (Yandex) with ESMTP id 29A8B18A01D1; Tue, 7 Aug 2012 18:09:14 +0400 (MSK) Received: from dynamic-178-141-5-132.kirov.comstar-r.ru (dynamic-178-141-5-132.kirov.comstar-r.ru [178.141.5.132]) by smtp18.mail.yandex.net (nwsmtp/Yandex) with ESMTP id 9DJS9p0A-9DJGWAHY; Tue, 7 Aug 2012 18:09:13 +0400 X-Yandex-Rcpt-Suid: tom@uffner.com X-Yandex-Rcpt-Suid: current@freebsd.org X-Yandex-Rcpt-Suid: mav@freebsd.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1344348554; bh=Dt9pxhSBRRZT0m/7Zya2EC5ZVRhQmuhZjB62ch9LpTs=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:X-Enigmail-Version:Content-Type: Content-Transfer-Encoding; b=YFMJShhHCENQDj8QaoqHv6mP8+lMkebULHw0N8AyuKTz5PmSohTlEbGHTyXKZcT20 klliyyElFbIeiGaAQIkwj3YyvjzTvHWvcUzJlxqfrj7OBj9s4Oji1wcepOg02GioxI 6tzEdHymnZJPntgknwrGDpW5kAvrp6BXuIk+0ZSM= Message-ID: <50212188.9000203@yandex.ru> Date: Tue, 07 Aug 2012 18:09:12 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.3) Gecko/20120406 Thunderbird/10.0.3 MIME-Version: 1.0 To: Tom Uffner References: <20120806203804.821031065674@hub.freebsd.org> <50205B66.10701@uffner.com> In-Reply-To: <50205B66.10701@uffner.com> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Cc: Alexander Motin , current@freebsd.org Subject: Re: geom mirror now rebuilding on every 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: Tue, 07 Aug 2012 14:09:17 -0000 On 07.08.2012 04:03, Tom Uffner wrote: > GEOM_RAID: Promise: Array Promise Created > GEOM_RAID: Promise: Disk ad4 state changed from NONE to SPARE > GEOM_MIRROR: Cannot open consumer ad4 (error=1) > GEOM_MIRROR: Cannot add disk ad4 to gm0 (error=1) > wondering if anyone knew offhand what is going on & how to fix it. You can remove "options GEOM_RAID" from your kernel config. -- WBR, Andrey V. Elsukov From owner-freebsd-current@FreeBSD.ORG Tue Aug 7 14:11:08 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 655541065670; Tue, 7 Aug 2012 14:11:08 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1-6.sentex.ca [IPv6:2607:f3e0:0:1::12]) by mx1.freebsd.org (Postfix) with ESMTP id 255E38FC08; Tue, 7 Aug 2012 14:11:08 +0000 (UTC) Received: from [192.168.43.26] (pyroxene.sentex.ca [199.212.134.18]) by smarthost1.sentex.ca (8.14.5/8.14.5) with ESMTP id q77EB7ak021636; Tue, 7 Aug 2012 10:11:07 -0400 (EDT) (envelope-from mike@sentex.net) Message-ID: <502121F5.4020705@sentex.net> Date: Tue, 07 Aug 2012 10:11:01 -0400 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: John Baldwin References: <201208031418.57941.jhb@freebsd.org> <501C37D3.5040704@sentex.net> <9C0F7DB1-E75B-42A9-90A4-22599F99E15E@gmail.com> <201208031726.03652.jhb@freebsd.org> In-Reply-To: <201208031726.03652.jhb@freebsd.org> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.72 on 64.7.153.18 Cc: Garrett Cooper , current@freebsd.org Subject: Re: [PATCH] Add locking to twe(4) so it no longer uses Giant X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 07 Aug 2012 14:11:08 -0000 On 8/3/2012 5:26 PM, John Baldwin wrote: >> If there's a tool for poking at the drives/controller, I would use that, plus camcontrol. Of course you want a data intensive workload > (iometer/iozone/xdd with async and sync mode, random reads and sequential reads, etc), and maybe resort to manual testing like pulling drives > (power, data) if you don't mind creating failures. If you have some failed/failing drives kicking around, that would be a good test as well (see > that all/some of the failure paths are properly stimulated). > > 3dm2 testing would be good for the ioctl handling, but the most critical > tests are basic I/O. > Looks like it breaks 3dm2 and the tw_cli. With the patch, I am not able to see the 8006 controller I added. tw_cli without the patch 0{offsite2}# tw_cli //offsite2> /c0 show Unit UnitType Status %RCmpl %V/I/M Stripe Size(GB) Cache AVrfy ------------------------------------------------------------------------------ u0 RAID-0 OK - - 64K 931.521 ON - Port Status Unit Size Blocks Serial --------------------------------------------------------------- p0 OK u0 465.76 GB 976773168 WD-WCAYUEY18298 p1 OK u0 465.76 GB 976773168 WD-WMAYUL256317 //offsite2> //offsite2> show Ctl Model (V)Ports Drives Units NotOpt RRate VRate BBU ------------------------------------------------------------------------ c0 8006-2LP 2 2 1 0 3 - - c1 9650SE-2LP 2 2 1 0 1 1 - The boot array is c1 (the off twa controller) with the patch (invariants and invariants_support in the kernel) 0{offsite2}# tw_cli //offsite2> show Ctl Model (V)Ports Drives Units NotOpt RRate VRate BBU ------------------------------------------------------------------------ c0 9650SE-2LP 2 2 1 0 1 1 - //offsite2> ---Mike -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From owner-freebsd-current@FreeBSD.ORG Tue Aug 7 15:02:53 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F099C106564A for ; Tue, 7 Aug 2012 15:02:52 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe08.c2i.net [212.247.154.226]) by mx1.freebsd.org (Postfix) with ESMTP id 60EA38FC08 for ; Tue, 7 Aug 2012 15:02:51 +0000 (UTC) X-T2-Spam-Status: No, hits=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 Received: from [176.74.212.201] (account mc467741@c2i.net HELO laptop015.hselasky.homeunix.org) by mailfe08.swip.net (CommuniGate Pro SMTP 5.4.4) with ESMTPA id 306283327; Tue, 07 Aug 2012 17:02:44 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Tue, 7 Aug 2012 17:03:13 +0200 User-Agent: KMail/1.13.7 (FreeBSD/9.0-STABLE; KDE/4.7.4; amd64; ; ) References: <20120801160323.GN2676@deviant.kiev.zoral.com.ua> <201208051033.13486.hselasky@c2i.net> In-Reply-To: <201208051033.13486.hselasky@c2i.net> X-Face: 'mmZ:T{)),Oru^0c+/}w'`gU1$ubmG?lp!=R4Wy\ELYo2)@'UZ24N@d2+AyewRX}mAm; Yp |U[@, _z/([?1bCfM{_"B<.J>mICJCHAzzGHI{y7{%JVz%R~yJHIji`y>Y}k1C4TfysrsUI -%GU9V5]iUZF&nRn9mJ'?&>O MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_x4SIQn2gx+2/oq8" Message-Id: <201208071703.13773.hselasky@c2i.net> Cc: Konstantin Belousov , Ed Schouten Subject: Re: ttydev_cdevsw has no d_purge X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 07 Aug 2012 15:02:53 -0000 --Boundary-00=_x4SIQn2gx+2/oq8 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Sunday 05 August 2012 10:33:13 Hans Petter Selasky wrote: > On Friday 03 August 2012 10:32:47 Ed Schouten wrote: > > 2012/8/1 Hans Petter Selasky : > > > I think the problem is like this, that in order to re-use the unit > > > numbers for USB serial tty devices, the USB stack needs to wait until a > > > TTY is actually freed, right? Else you will have a panic on creating > > > devfs entries having the same name. > > > > Indeed. So the USB code could simply pick a different unit number. > > Hi Ed, > > USB could use a different Unit number. Some questions: > > When can the previous unit number be re-used? Is there a callback for this? > > When can the USB serial code assume that it will not be called again and > that all callbacks are drained? > Hi, Can you try the attached patch and report back? --HPS --Boundary-00=_x4SIQn2gx+2/oq8 Content-Type: text/x-patch; charset="utf-8"; name="ucom_unit_number.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ucom_unit_number.patch" === usb_serial.c ================================================================== --- usb_serial.c (revision 239054) +++ usb_serial.c (local) @@ -179,8 +179,11 @@ MODULE_VERSION(ucom, 1); #define UCOM_UNIT_MAX 128 /* limits size of ucom_bitmap */ +#define UCOM_UNIT_MAX_BYTES ((UCOM_UNIT_MAX + 7) / 8) -static uint8_t ucom_bitmap[(UCOM_UNIT_MAX + 7) / 8]; +static uint8_t ucom_bitmap[UCOM_UNIT_MAX_BYTES]; +static uint8_t ucom_closing[UCOM_UNIT_MAX_BYTES]; +static uint32_t ucom_closing_ref; static struct mtx ucom_bitmap_mtx; MTX_SYSINIT(ucom_bitmap_mtx, &ucom_bitmap_mtx, "ucom bitmap", MTX_DEF); @@ -215,16 +218,34 @@ } /* + * Sync the "ucom_bitmap" and the "ucom_closing" one. + */ +static void +ucom_unit_sync(void) +{ + uint32_t x; + + mtx_lock(&ucom_bitmap_mtx); + if (ucom_closing_ref == 0) { + for (x = 0; x != UCOM_UNIT_MAX_BYTES; x++) { + ucom_bitmap[x] &= ~ucom_closing[x]; + ucom_closing[x] = 0; + } + } + mtx_unlock(&ucom_bitmap_mtx); +} + +/* * Mark the unit number as not in use. */ static void ucom_unit_free(int unit) { mtx_lock(&ucom_bitmap_mtx); + ucom_closing[unit / 8] |= (1 << (unit % 8)); + mtx_unlock(&ucom_bitmap_mtx); - ucom_bitmap[unit / 8] &= ~(1 << (unit % 8)); - - mtx_unlock(&ucom_bitmap_mtx); + ucom_unit_sync(); } /* @@ -356,7 +377,6 @@ sc->sc_tty = tp; DPRINTF("ttycreate: %s\n", buf); - cv_init(&sc->sc_cv, "ucom"); /* Check if this device should be a console */ if ((ucom_cons_softc == NULL) && @@ -408,7 +428,13 @@ sc->sc_flag |= UCOM_FLAG_GONE; sc->sc_flag &= ~(UCOM_FLAG_HL_READY | UCOM_FLAG_LL_READY); mtx_unlock(sc->sc_mtx); + if (tp) { + + mtx_lock(&ucom_bitmap_mtx); + ucom_closing_ref++; + mtx_unlock(&ucom_bitmap_mtx); + tty_lock(tp); ucom_close(tp); /* close, if any */ @@ -416,9 +442,6 @@ tty_rel_gone(tp); mtx_lock(sc->sc_mtx); - /* Wait for the callback after the TTY is torn down */ - while (sc->sc_ttyfreed == 0) - cv_wait(&sc->sc_cv, sc->sc_mtx); /* * make sure that read and write transfers are stopped */ @@ -430,7 +453,6 @@ } mtx_unlock(sc->sc_mtx); } - cv_destroy(&sc->sc_cv); } void @@ -1323,12 +1345,11 @@ static void ucom_free(void *xsc) { - struct ucom_softc *sc = xsc; + mtx_lock(&ucom_bitmap_mtx); + ucom_closing_ref--; + mtx_unlock(&ucom_bitmap_mtx); - mtx_lock(sc->sc_mtx); - sc->sc_ttyfreed = 1; - cv_signal(&sc->sc_cv); - mtx_unlock(sc->sc_mtx); + ucom_unit_sync(); } static cn_probe_t ucom_cnprobe; === usb_serial.h ================================================================== --- usb_serial.h (revision 239054) +++ usb_serial.h (local) @@ -158,7 +158,6 @@ struct ucom_cfg_task sc_line_state_task[2]; struct ucom_cfg_task sc_status_task[2]; struct ucom_param_task sc_param_task[2]; - struct cv sc_cv; /* Used to set "UCOM_FLAG_GP_DATA" flag: */ struct usb_proc_msg *sc_last_start_xfer; const struct ucom_callback *sc_callback; @@ -179,7 +178,6 @@ uint8_t sc_lsr; uint8_t sc_msr; uint8_t sc_mcr; - uint8_t sc_ttyfreed; /* set when TTY has been freed */ /* programmed line state bits */ uint8_t sc_pls_set; /* set bits */ uint8_t sc_pls_clr; /* cleared bits */ --Boundary-00=_x4SIQn2gx+2/oq8-- From owner-freebsd-current@FreeBSD.ORG Tue Aug 7 18:43:36 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B8FB21065675 for ; Tue, 7 Aug 2012 18:43:36 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 724E48FC12 for ; Tue, 7 Aug 2012 18:43:36 +0000 (UTC) Received: by pbbrp2 with SMTP id rp2so79243pbb.13 for ; Tue, 07 Aug 2012 11:43:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=Wx9Pm2a/iz3SKAednpPa+qEOarGAN6sOrnwwQjIfsLw=; b=rYpGAMHZvyOCvZVYulV7/evjJ09HzU5Lgbyba2WlTdkz1Oe1Pp2CxbtP64v4bx42+4 1mtVMLbEr1URjDNlKgS9oLu19wcpenlRHMYHZ7qHSeQwRoUx4UNkXGfDumPvf9OwhULP 7yzMpCWSmVwgKnH4doyG1i8auca2pTT4olAds7+sXggmarS+ylYAzf9LR2fCWLQl+cnl jjmQq09VywWoU8pF4vF94uiZZ2JLtvy81LZPHMMBctJnzo/kBzVxtSIatprob82UgAu8 JYSsBh0bVV8uHX0+GcDkyM0GGxsDnNdmFrBTDId4ZmKZgHSIJ7+tNlqpUIsc6G+5uvPE E3Ew== Received: by 10.68.224.39 with SMTP id qz7mr29802027pbc.127.1344365016130; Tue, 07 Aug 2012 11:43:36 -0700 (PDT) Received: from [10.42.27.125] (mobile-166-147-095-174.mycingular.net. [166.147.95.174]) by mx.google.com with ESMTPS id pt2sm11641822pbb.58.2012.08.07.11.43.34 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 07 Aug 2012 11:43:35 -0700 (PDT) References: <501D52AD.4010105@protected-networks.net> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <94FD01E0-87CC-40DF-ABE8-313BFCE4BCC7@gmail.com> X-Mailer: iPhone Mail (9B206) From: Garrett Cooper Date: Tue, 7 Aug 2012 11:43:30 -0700 To: Ian FREISLICH Cc: "current@freebsd.org" Subject: Re: Speaking of ship blockers for 9.... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 07 Aug 2012 18:43:36 -0000 On Aug 7, 2012, at 11:17 AM, Ian FREISLICH wrote: > Garrett Cooper >> Is this is in 9.1 -PRERELEASE, -RELEASE (or whatever the official >> label is...)? If so, it seems like this would be a ship blocker. >=20 > I have a problem that's been getting progressively worse as the > source progresses. So much so that it's had me searching all the > way from 8.0-RELEASE to 10-CURRENT without luck on both amd64 and > i386. >=20 > pf(4) erroneously mismatches state and then blocks an active flow. > It seems that 8.X does so silently and 9 to -CURRENT do so verbosely. > Whether silent or loud, the effect on traffic makes it impracticle > to use FreeBSD+PF for a firewall in any setting (my use is home, > small office, large office and moderately large datacenter core > router). It appears that this has actually been a forever problem > that just being tickled more now. >=20 > Here's from my home firewall: > Status: Enabled for 7 days 02:57:58 Debug: Urgent >=20 > State Table Total Rate > current entries 1653 =20 > searches 45792251 74.4/s > inserts 428375 0.7/s > removals 426722 0.7/s > ... > state-mismatch 1586 0.0/s >=20 >=20 > Here's from a moderately busy firewall: > Status: Enabled for 0 days 21:40:44 Debug: Urgent >=20 > State Table Total Rate > current entries 122395 =20 > searches 4428641685 56745.4/s > inserts 202644593 2596.5/s > removals 202522198 2595.0/s > ... > state-mismatch 277767 3.6/s >=20 > That's 277767 flows terminated in the last almost 22 hours due to > this pf bug. (!!!) >=20 > 9.1-PRERELEASE logs (as does -CURRENT): > Jul 22 08:54:25 brane kernel: pf: state key linking mismatch! dir=3DOUT, i= f=3Dtun0, stored af=3D2, a0: 10.0.2.220:60985, a1: 192.41.162.30:53, proto=3D= 17, found af=3D2, a0: 41.154.2.53:1701, a1: 41.133.165.161:59051, proto=3D17= . > Jul 22 08:54:25 brane kernel: pf: state key linking mismatch! dir=3DOUT, i= f=3Dtun0, stored af=3D2, a0: 10.0.2.220:52995, a1: 41.154.2.100:53, proto=3D= 17, found af=3D2, a0: 41.154.2.53:1701, a1: 41.133.165.161:59051, proto=3D17= . > Jul 22 08:54:25 brane kernel: pf: state key linking mismatch! dir=3DOUT, i= f=3Dtun0, stored af=3D2, a0: 10.0.2.220:60095, a1: 206.223.136.200:53, proto= =3D17, found af=3D2, a0: 41.154.2.53:1701, a1: 41.133.165.161:59051, proto=3D= 17. > Jul 22 08:54:25 brane kernel: pf: state key linking mismatch! dir=3DOUT, i= f=3Dtun0, stored af=3D2, a0: 10.0.2.220:50463, a1: 206.223.136.200:53, proto= =3D17, found af=3D2, a0: 41.154.2.53:1701, a1: 41.133.165.161:59051, proto=3D= 17. > Jul 22 08:54:25 brane kernel: pf: state key linking mismatch! dir=3DOUT, i= f=3Dtun0, stored af=3D2, a0: 10.0.2.220:56748, a1: 192.41.162.30:53, proto=3D= 17, found af=3D2, a0: 41.154.2.53:1701, a1: 41.133.165.161:59051, proto=3D17= . > Jul 22 08:54:25 brane kernel: pf: state key linking mismatch! dir=3DOUT, i= f=3Dtun0, stored af=3D2, a0: 10.0.2.220:60793, a1: 192.41.162.30:53, proto=3D= 17, found af=3D2, a0: 41.154.2.53:1701, a1: 41.133.165.161:59051, proto=3D17= . Filed a PR yet with packet captures? Thanks, -Garrett= From owner-freebsd-current@FreeBSD.ORG Tue Aug 7 18:51:00 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 72D8510657CA for ; Tue, 7 Aug 2012 18:51:00 +0000 (UTC) (envelope-from ianf@clue.co.za) Received: from brane.freislich.nom.za (brane.freislich.nom.za [41.154.0.9]) by mx1.freebsd.org (Postfix) with ESMTP id E65AF8FC18 for ; Tue, 7 Aug 2012 18:50:59 +0000 (UTC) Received: from [10.0.2.220] (helo=clue.co.za) by brane.freislich.nom.za with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80 (FreeBSD)) (envelope-from ) id 1SyoM2-0002N5-2B; Tue, 07 Aug 2012 20:18:06 +0200 Received: from localhost ([127.0.0.1] helo=clue.co.za) by clue.co.za with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1SyoLs-0000P8-UU; Tue, 07 Aug 2012 20:17:56 +0200 To: current@freebsd.org From: Ian FREISLICH In-Reply-To: References: <501D52AD.4010105@protected-networks.net> X-Attribution: BOFH Date: Tue, 07 Aug 2012 20:17:56 +0200 Message-Id: X-Missing-rDNS: 10.0.2.220 Cc: Garrett Cooper Subject: Speaking of ship blockers for 9.... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 07 Aug 2012 18:51:00 -0000 Garrett Cooper > Is this is in 9.1 -PRERELEASE, -RELEASE (or whatever the official > label is...)? If so, it seems like this would be a ship blocker. I have a problem that's been getting progressively worse as the source progresses. So much so that it's had me searching all the way from 8.0-RELEASE to 10-CURRENT without luck on both amd64 and i386. pf(4) erroneously mismatches state and then blocks an active flow. It seems that 8.X does so silently and 9 to -CURRENT do so verbosely. Whether silent or loud, the effect on traffic makes it impracticle to use FreeBSD+PF for a firewall in any setting (my use is home, small office, large office and moderately large datacenter core router). It appears that this has actually been a forever problem that just being tickled more now. Here's from my home firewall: Status: Enabled for 7 days 02:57:58 Debug: Urgent State Table Total Rate current entries 1653 searches 45792251 74.4/s inserts 428375 0.7/s removals 426722 0.7/s ... state-mismatch 1586 0.0/s Here's from a moderately busy firewall: Status: Enabled for 0 days 21:40:44 Debug: Urgent State Table Total Rate current entries 122395 searches 4428641685 56745.4/s inserts 202644593 2596.5/s removals 202522198 2595.0/s ... state-mismatch 277767 3.6/s That's 277767 flows terminated in the last almost 22 hours due to this pf bug. (!!!) 9.1-PRERELEASE logs (as does -CURRENT): Jul 22 08:54:25 brane kernel: pf: state key linking mismatch! dir=OUT, if=tun0, stored af=2, a0: 10.0.2.220:60985, a1: 192.41.162.30:53, proto=17, found af=2, a0: 41.154.2.53:1701, a1: 41.133.165.161:59051, proto=17. Jul 22 08:54:25 brane kernel: pf: state key linking mismatch! dir=OUT, if=tun0, stored af=2, a0: 10.0.2.220:52995, a1: 41.154.2.100:53, proto=17, found af=2, a0: 41.154.2.53:1701, a1: 41.133.165.161:59051, proto=17. Jul 22 08:54:25 brane kernel: pf: state key linking mismatch! dir=OUT, if=tun0, stored af=2, a0: 10.0.2.220:60095, a1: 206.223.136.200:53, proto=17, found af=2, a0: 41.154.2.53:1701, a1: 41.133.165.161:59051, proto=17. Jul 22 08:54:25 brane kernel: pf: state key linking mismatch! dir=OUT, if=tun0, stored af=2, a0: 10.0.2.220:50463, a1: 206.223.136.200:53, proto=17, found af=2, a0: 41.154.2.53:1701, a1: 41.133.165.161:59051, proto=17. Jul 22 08:54:25 brane kernel: pf: state key linking mismatch! dir=OUT, if=tun0, stored af=2, a0: 10.0.2.220:56748, a1: 192.41.162.30:53, proto=17, found af=2, a0: 41.154.2.53:1701, a1: 41.133.165.161:59051, proto=17. Jul 22 08:54:25 brane kernel: pf: state key linking mismatch! dir=OUT, if=tun0, stored af=2, a0: 10.0.2.220:60793, a1: 192.41.162.30:53, proto=17, found af=2, a0: 41.154.2.53:1701, a1: 41.133.165.161:59051, proto=17. Ian -- Ian Freislich From owner-freebsd-current@FreeBSD.ORG Tue Aug 7 23:42:21 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 34237106566B for ; Tue, 7 Aug 2012 23:42:21 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id 9CA608FC08 for ; Tue, 7 Aug 2012 23:42:20 +0000 (UTC) Received: by lbbgk8 with SMTP id gk8so200290lbb.13 for ; Tue, 07 Aug 2012 16:42:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=M9Dg5eKWuoddXc2X6QPkJgYOYaCXiWJ1d7wR0YSMGKs=; b=Z/YWsd2iHREgDjkJUErZ1g4NEx+FH6z22k0uUDAghu0rH2ZuOTPCl3mxToM4Z9XZek my0WWW1TZqNawTmel1lT0WqUXe81fZgpWhfWSXFBClK8mGNYhEhHbF5MNagtNyaqeOd5 bxO3l6qesVU9F9bd93k6wV75yEec9FabAC+QeBZ5sSSHM2qhnIDYuT0bppwHruw4Pwwe HwZvBWjHgw8gbZdtvCI2V4ebjmv2bNslWdX+EcdRjE9z3gU5/ioQShD2AkeQGCFzJ5hT ie4KUrAna1uT9ptwUeHNNmMmPJ2nLTmhQaxbjEIBlNg0xY7r/ckoD8slQJpfIbizpabi Cnkw== Received: by 10.152.105.132 with SMTP id gm4mr7418135lab.8.1344382939552; Tue, 07 Aug 2012 16:42:19 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (213-227-240-37.static.vega-ua.net. [213.227.240.37]) by mx.google.com with ESMTPS id er3sm4635901lbb.16.2012.08.07.16.42.17 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 07 Aug 2012 16:42:18 -0700 (PDT) Sender: Alexander Motin Message-ID: <5021A7D8.9040305@FreeBSD.org> Date: Wed, 08 Aug 2012 02:42:16 +0300 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120628 Thunderbird/13.0.1 MIME-Version: 1.0 To: "Andrey V. Elsukov" References: <20120806203804.821031065674@hub.freebsd.org> <50205B66.10701@uffner.com> <50212188.9000203@yandex.ru> In-Reply-To: <50212188.9000203@yandex.ru> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: geom mirror now rebuilding on every 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: Tue, 07 Aug 2012 23:42:21 -0000 On 07.08.2012 17:09, Andrey V. Elsukov wrote: > On 07.08.2012 04:03, Tom Uffner wrote: >> GEOM_RAID: Promise: Array Promise Created >> GEOM_RAID: Promise: Disk ad4 state changed from NONE to SPARE >> GEOM_MIRROR: Cannot open consumer ad4 (error=1) >> GEOM_MIRROR: Cannot add disk ad4 to gm0 (error=1) >> wondering if anyone knew offhand what is going on & how to fix it. > > You can remove "options GEOM_RAID" from your kernel config. I think the right answer would be to remove stale Promise format RAID metadata from the disk. You should be able to do it by booting from any source and doing `graid list -a` to see all RAID GEOMs (even broken) and then remove them with `graid remove Promise ad4`. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Wed Aug 8 02:13:15 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CA7EA106564A for ; Wed, 8 Aug 2012 02:13:15 +0000 (UTC) (envelope-from sendtomatt@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 95CDB8FC0C for ; Wed, 8 Aug 2012 02:13:15 +0000 (UTC) Received: by pbbrp2 with SMTP id rp2so654575pbb.13 for ; Tue, 07 Aug 2012 19:13:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=++9ejeYu5DHAXK5ohX6FdLSS+al+JXNsEosnYNq2z4A=; b=Xb3DZ0zJ2kFh1lLaC9ZUtkh5T2BLjy7LgHdNtNSeP99okKdCi8lWMthY3+Rop6bnb9 vvdr6W3rVve2npiXyes77B4/BwalsKKXNgea5lqx2s5j36FWQkc2PqArpJykYksVDzgt HUzFbKmxdW0gMG6bZUr3vJy5YeFFAtY1T8daeY85ugWw1C1TAW/KWJGfCsQG2NTzspOD 7zt6xri4rxtsn+wl68qGyo4CzYyv+zup43fw13P7LuzVu2jblArL50LZgI+KWEr6+6MV ihK5/fzJvCAG1Z5PGIjVfWuQi6ICy+6TSnzkM2irC7icoiyHI3D5Kllxyz5zxyJRL8eO SpuA== Received: by 10.68.241.65 with SMTP id wg1mr32645874pbc.25.1344391994918; Tue, 07 Aug 2012 19:13:14 -0700 (PDT) Received: from flatline.local (70-36-223-239.dsl.dynamic.sonic.net. [70.36.223.239]) by mx.google.com with ESMTPS id pj10sm12296455pbb.46.2012.08.07.19.13.12 (version=SSLv3 cipher=OTHER); Tue, 07 Aug 2012 19:13:13 -0700 (PDT) Message-ID: <5021CB2F.7060905@gmail.com> Date: Tue, 07 Aug 2012 19:13:03 -0700 From: matt User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:14.0) Gecko/20120731 Thunderbird/14.0 MIME-Version: 1.0 To: Garrett Cooper References: <501D52AD.4010105@protected-networks.net> <94FD01E0-87CC-40DF-ABE8-313BFCE4BCC7@gmail.com> In-Reply-To: <94FD01E0-87CC-40DF-ABE8-313BFCE4BCC7@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ian FREISLICH , "current@freebsd.org" Subject: Re: Speaking of ship blockers for 9.... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 08 Aug 2012 02:13:15 -0000 On 08/07/12 11:43, Garrett Cooper wrote: > On Aug 7, 2012, at 11:17 AM, Ian FREISLICH wrote: > >> Garrett Cooper >>> Is this is in 9.1 -PRERELEASE, -RELEASE (or whatever the official >>> label is...)? If so, it seems like this would be a ship blocker. >> I have a problem that's been getting progressively worse as the >> source progresses. So much so that it's had me searching all the >> way from 8.0-RELEASE to 10-CURRENT without luck on both amd64 and >> i386. >> >> pf(4) erroneously mismatches state and then blocks an active flow. >> It seems that 8.X does so silently and 9 to -CURRENT do so verbosely. >> Whether silent or loud, the effect on traffic makes it impracticle >> to use FreeBSD+PF for a firewall in any setting (my use is home, >> small office, large office and moderately large datacenter core >> router). It appears that this has actually been a forever problem >> that just being tickled more now. >> >> Here's from my home firewall: >> Status: Enabled for 7 days 02:57:58 Debug: Urgent >> >> State Table Total Rate >> current entries 1653 >> searches 45792251 74.4/s >> inserts 428375 0.7/s >> removals 426722 0.7/s >> ... >> state-mismatch 1586 0.0/s >> >> >> Here's from a moderately busy firewall: >> Status: Enabled for 0 days 21:40:44 Debug: Urgent >> >> State Table Total Rate >> current entries 122395 >> searches 4428641685 56745.4/s >> inserts 202644593 2596.5/s >> removals 202522198 2595.0/s >> ... >> state-mismatch 277767 3.6/s >> >> That's 277767 flows terminated in the last almost 22 hours due to >> this pf bug. (!!!) >> >> 9.1-PRERELEASE logs (as does -CURRENT): >> Jul 22 08:54:25 brane kernel: pf: state key linking mismatch! dir=OUT, if=tun0, stored af=2, a0: 10.0.2.220:60985, a1: 192.41.162.30:53, proto=17, found af=2, a0: 41.154.2.53:1701, a1: 41.133.165.161:59051, proto=17. >> Jul 22 08:54:25 brane kernel: pf: state key linking mismatch! dir=OUT, if=tun0, stored af=2, a0: 10.0.2.220:52995, a1: 41.154.2.100:53, proto=17, found af=2, a0: 41.154.2.53:1701, a1: 41.133.165.161:59051, proto=17. >> Jul 22 08:54:25 brane kernel: pf: state key linking mismatch! dir=OUT, if=tun0, stored af=2, a0: 10.0.2.220:60095, a1: 206.223.136.200:53, proto=17, found af=2, a0: 41.154.2.53:1701, a1: 41.133.165.161:59051, proto=17. >> Jul 22 08:54:25 brane kernel: pf: state key linking mismatch! dir=OUT, if=tun0, stored af=2, a0: 10.0.2.220:50463, a1: 206.223.136.200:53, proto=17, found af=2, a0: 41.154.2.53:1701, a1: 41.133.165.161:59051, proto=17. >> Jul 22 08:54:25 brane kernel: pf: state key linking mismatch! dir=OUT, if=tun0, stored af=2, a0: 10.0.2.220:56748, a1: 192.41.162.30:53, proto=17, found af=2, a0: 41.154.2.53:1701, a1: 41.133.165.161:59051, proto=17. >> Jul 22 08:54:25 brane kernel: pf: state key linking mismatch! dir=OUT, if=tun0, stored af=2, a0: 10.0.2.220:60793, a1: 192.41.162.30:53, proto=17, found af=2, a0: 41.154.2.53:1701, a1: 41.133.165.161:59051, proto=17. > Filed a PR yet with packet captures? > Thanks, > -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" > I was having this problem on one machine but not another (different pf.confs). Are you using synproxy state or modulate state? Feel OK posting a basic pf.conf that experiences the issue? I feel like there was something with either scrub or synproxy I had to remove to make the hurting stop. Obviously that means something is probably borked, and I will share in the no-pr shame. Matt From owner-freebsd-current@FreeBSD.ORG Wed Aug 8 11:27:48 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D0A671065672 for ; Wed, 8 Aug 2012 11:27:47 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id A5E5D8FC0C for ; Wed, 8 Aug 2012 11:27:47 +0000 (UTC) Received: from ralph.baldwin.cx (c-68-39-198-164.hsd1.de.comcast.net [68.39.198.164]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 00C90B980; Wed, 8 Aug 2012 07:27:47 -0400 (EDT) From: John Baldwin To: Mike Tancsa Date: Wed, 8 Aug 2012 07:27:45 -0400 User-Agent: KMail/1.13.7 (FreeBSD/9.0-STABLE; KDE/4.7.4; amd64; ; ) References: <201208031418.57941.jhb@freebsd.org> <201208031726.03652.jhb@freebsd.org> <502121F5.4020705@sentex.net> In-Reply-To: <502121F5.4020705@sentex.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201208080727.45595.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 08 Aug 2012 07:27:47 -0400 (EDT) Cc: Garrett Cooper , current@freebsd.org Subject: Re: [PATCH] Add locking to twe(4) so it no longer uses Giant X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 08 Aug 2012 11:27:48 -0000 On Tuesday, August 07, 2012 10:11:01 AM Mike Tancsa wrote: > On 8/3/2012 5:26 PM, John Baldwin wrote: > >> If there's a tool for poking at the drives/controller, I would use > >> that, plus camcontrol. Of course you want a data intensive workload > > > > (iometer/iozone/xdd with async and sync mode, random reads and sequential > > reads, etc), and maybe resort to manual testing like pulling drives > > (power, data) if you don't mind creating failures. If you have some > > failed/failing drives kicking around, that would be a good test as well > > (see that all/some of the failure paths are properly stimulated). > > > > 3dm2 testing would be good for the ioctl handling, but the most critical > > tests are basic I/O. > > Looks like it breaks 3dm2 and the tw_cli. With the patch, I am not able > to see the 8006 controller I added. Ugh, ok. A few questions: 1) Does the driver see any attached drives/volumes? 2) If it does, does basic I/O to the drives work? 3) Can you add some debugging printfs to twe_ioctl() to see what, if anything, fails in that routine when tw_cli makes a request? Thanks. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Wed Aug 8 11:31:51 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 22951106566C for ; Wed, 8 Aug 2012 11:31:51 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 7468A8FC16 for ; Wed, 8 Aug 2012 11:31:49 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q78BVktE030601; Wed, 8 Aug 2012 14:31:46 +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.5/8.14.5) with ESMTP id q78BVXBN043673; Wed, 8 Aug 2012 14:31:33 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q78BVXIK043672; Wed, 8 Aug 2012 14:31:33 +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: Wed, 8 Aug 2012 14:31:33 +0300 From: Konstantin Belousov To: Hans Petter Selasky Message-ID: <20120808113133.GO2676@deviant.kiev.zoral.com.ua> References: <20120801160323.GN2676@deviant.kiev.zoral.com.ua> <201208051033.13486.hselasky@c2i.net> <201208071703.13773.hselasky@c2i.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="55kmsllhnyURxeAZ" Content-Disposition: inline In-Reply-To: <201208071703.13773.hselasky@c2i.net> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: Ed Schouten , freebsd-current@freebsd.org Subject: Re: ttydev_cdevsw has no d_purge X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 08 Aug 2012 11:31:51 -0000 --55kmsllhnyURxeAZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 07, 2012 at 05:03:13PM +0200, Hans Petter Selasky wrote: > On Sunday 05 August 2012 10:33:13 Hans Petter Selasky wrote: > > On Friday 03 August 2012 10:32:47 Ed Schouten wrote: > > > 2012/8/1 Hans Petter Selasky : > > > > I think the problem is like this, that in order to re-use the unit > > > > numbers for USB serial tty devices, the USB stack needs to wait unt= il a > > > > TTY is actually freed, right? Else you will have a panic on creating > > > > devfs entries having the same name. > > >=20 > > > Indeed. So the USB code could simply pick a different unit number. > >=20 > > Hi Ed, > >=20 > > USB could use a different Unit number. Some questions: > >=20 > > When can the previous unit number be re-used? Is there a callback for t= his? > >=20 > > When can the USB serial code assume that it will not be called again and > > that all callbacks are drained? > >=20 >=20 > Hi, >=20 > Can you try the attached patch and report back? I applied the patch and reloaded ucom and uplcom. So far there were no power glitches so UPS did not dropped off the bus yet. I have a question regarding the changed fragment of code. Why don't you use unr(9) KPI to manage unit numbers ? --55kmsllhnyURxeAZ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAlAiThUACgkQC3+MBN1Mb4jmVQCfYHZOywd1x0Iaq0d7LckIXVKk yvAAnilWFigHaDUOzbkm4+bpr9Zj4QTl =wEwM -----END PGP SIGNATURE----- --55kmsllhnyURxeAZ-- From owner-freebsd-current@FreeBSD.ORG Wed Aug 8 12:39:44 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0875D1065674 for ; Wed, 8 Aug 2012 12:39:44 +0000 (UTC) (envelope-from alissonfer@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id C47F78FC21 for ; Wed, 8 Aug 2012 12:39:43 +0000 (UTC) Received: by pbbrp2 with SMTP id rp2so1491538pbb.13 for ; Wed, 08 Aug 2012 05:39:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=2FAbc2x81tli8v114+9TTF9xIUKC+eFfr0oph9cPQ/o=; b=Rfqak30wgQqqharxB1BI9FNk7q2Lt6JA/aubGWySZWsuSbFiFQCIHASo8Mcs5Qg8F6 wn/eHNrMmKsTtmrdqccRrCfIVBLvnCe2W5r30p+JEWhSuWh7fQZ3O3wbRg8dgyf0bXPt V0EfYjC8zDOcyeGmhzzf+hH0m/fP7C/MdyEGj0ojY5KjVZJreF6k13TFV6ZWiqGBp3GY Ne+JQZ7YE1BIS9jeq8arwfO9qk5I0eY3dpJ1i/5KtnvUqP44fNt8gxpI6Xg2tbx8lrHB 9PiBv4aZ8uLhL+073bNvlGi9ATtEyAnD/FOAPtENAwWf5S38S9P5MOV/4m9BAI5/6pe9 xXHg== MIME-Version: 1.0 Received: by 10.68.190.102 with SMTP id gp6mr36046473pbc.5.1344429583208; Wed, 08 Aug 2012 05:39:43 -0700 (PDT) Sender: alissonfer@gmail.com Received: by 10.68.138.162 with HTTP; Wed, 8 Aug 2012 05:39:43 -0700 (PDT) Date: Wed, 8 Aug 2012 09:39:43 -0300 X-Google-Sender-Auth: xk6ETcB1rDkBe1PxnAcn114crow Message-ID: From: Alisson To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: ECMP/FreeBSD its a dream? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 08 Aug 2012 12:39:44 -0000 Hi... everybody knows the stability of freebsd... but... and the protocol ECMP? its a dream? to use 2 routes with diferent gateways? to load balance? ECMP its a dream? From owner-freebsd-current@FreeBSD.ORG Wed Aug 8 13:01:59 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 39EDA1065670 for ; Wed, 8 Aug 2012 13:01:59 +0000 (UTC) (envelope-from misho@elwix.org) Received: from x0r.aitnet.org (unknown [IPv6:2a00:e40:deba:1::5]) by mx1.freebsd.org (Postfix) with ESMTP id E1C778FC0A for ; Wed, 8 Aug 2012 13:01:58 +0000 (UTC) Received: from localhost (unknown [127.0.0.1]) by x0r.aitnet.org (Postfix) with ESMTP id 30C193F74B for ; Wed, 8 Aug 2012 16:01:58 +0300 (EEST) X-Virus-Scanned: amavisd-new at aitnet.org Received: from x0r.aitnet.org ([127.0.0.1]) by localhost (x0r.aitnet.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tlKVnKinMO5v for ; Wed, 8 Aug 2012 16:01:57 +0300 (EEST) Received: from pi (unknown [212.116.129.162]) by x0r.aitnet.org (Postfix) with ESMTPSA id B912A3F746 for ; Wed, 8 Aug 2012 16:01:57 +0300 (EEST) Date: Wed, 8 Aug 2012 16:01:57 +0300 From: Michael Pounov To: freebsd-current@freebsd.org Message-Id: <20120808160157.89aa7cd4.misho@elwix.org> In-Reply-To: References: Organization: ELWIX X-Mailer: Sylpheed 3.1.4 (GTK+ 2.24.6; i386-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: ECMP/FreeBSD its a dream? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 08 Aug 2012 13:01:59 -0000 Hi ... You can do that with pf from recent several years :) On Wed, 8 Aug 2012 09:39:43 -0300 Alisson wrote: > Hi... > > everybody knows the stability of freebsd... but... and the protocol ECMP? > its a dream? > > to use 2 routes with diferent gateways? > > to load balance? > > ECMP its a dream? > _______________________________________________ > 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" -- Best Regards, Michael Pounov ELWIX - embedded lightweight unix - WWW: http://www.elwix.org/ EMail: misho@elwix.org Skype: mpunov XMPP: misho@aitnet.org Phone: +359 888 737358; +359 899 737358 From owner-freebsd-current@FreeBSD.ORG Wed Aug 8 13:06:09 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 879A3106566C for ; Wed, 8 Aug 2012 13:06:09 +0000 (UTC) (envelope-from vince@unsane.co.uk) Received: from unsane.co.uk (unsane-pt.tunnel.tserv5.lon1.ipv6.he.net [IPv6:2001:470:1f08:110::2]) by mx1.freebsd.org (Postfix) with ESMTP id 025FC8FC15 for ; Wed, 8 Aug 2012 13:06:08 +0000 (UTC) Received: from badger.unsane.co.uk (badger.unsane.co.uk [85.233.185.165]) (authenticated bits=0) by unsane.co.uk (8.14.5/8.14.5) with ESMTP id q78D66oo061039 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 8 Aug 2012 14:06:07 +0100 (BST) (envelope-from vince@unsane.co.uk) Message-ID: <5022643E.1070606@unsane.co.uk> Date: Wed, 08 Aug 2012 14:06:06 +0100 From: Vincent Hoffman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: In-Reply-To: X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: ECMP/FreeBSD its a dream? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 08 Aug 2012 13:06:09 -0000 On 08/08/2012 13:39, Alisson wrote: > Hi... > > everybody knows the stability of freebsd... but... and the protocol ECMP? > its a dream? I havent tried but google says http://lists.freebsd.org/pipermail/cvs-src/2008-April/089956.html Its in since 2008 Vince > to use 2 routes with diferent gateways? > > to load balance? > > ECMP its a dream? > _______________________________________________ > 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 Aug 8 16:27:32 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0AE34106564A for ; Wed, 8 Aug 2012 16:27:32 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe05.c2i.net [212.247.154.130]) by mx1.freebsd.org (Postfix) with ESMTP id 8298D8FC0C for ; Wed, 8 Aug 2012 16:27:30 +0000 (UTC) X-T2-Spam-Status: No, hits=-1.0 required=5.0 tests=ALL_TRUSTED Received: from [176.74.212.201] (account mc467741@c2i.net HELO laptop015.hselasky.homeunix.org) by mailfe05.swip.net (CommuniGate Pro SMTP 5.4.4) with ESMTPA id 302261321; Wed, 08 Aug 2012 18:27:24 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Wed, 8 Aug 2012 18:27:53 +0200 User-Agent: KMail/1.13.7 (FreeBSD/9.1-PRERELEASE; KDE/4.8.4; amd64; ; ) References: <20120801160323.GN2676@deviant.kiev.zoral.com.ua> <201208071703.13773.hselasky@c2i.net> <20120808113133.GO2676@deviant.kiev.zoral.com.ua> In-Reply-To: <20120808113133.GO2676@deviant.kiev.zoral.com.ua> X-Face: 'mmZ:T{)),Oru^0c+/}w'`gU1$ubmG?lp!=R4Wy\ELYo2)@'UZ24N@d2+AyewRX}mAm; Yp |U[@, _z/([?1bCfM{_"B<.J>mICJCHAzzGHI{y7{%JVz%R~yJHIji`y>Y}k1C4TfysrsUI -%GU9V5]iUZF&nRn9mJ'?&>O MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201208081827.53824.hselasky@c2i.net> Cc: Konstantin Belousov , Ed Schouten Subject: Re: ttydev_cdevsw has no d_purge X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 08 Aug 2012 16:27:32 -0000 On Wednesday 08 August 2012 13:31:33 Konstantin Belousov wrote: > On Tue, Aug 07, 2012 at 05:03:13PM +0200, Hans Petter Selasky wrote: > > On Sunday 05 August 2012 10:33:13 Hans Petter Selasky wrote: > > > On Friday 03 August 2012 10:32:47 Ed Schouten wrote: > > > > 2012/8/1 Hans Petter Selasky : > > > > > I think the problem is like this, that in order to re-use the unit > > > > > numbers for USB serial tty devices, the USB stack needs to wait > > > > > until a TTY is actually freed, right? Else you will have a panic > > > > > on creating devfs entries having the same name. > > > > > > > > Indeed. So the USB code could simply pick a different unit number. > > > > > > Hi Ed, > > > > > > USB could use a different Unit number. Some questions: > > > > > > When can the previous unit number be re-used? Is there a callback for > > > this? > > > > > > When can the USB serial code assume that it will not be called again > > > and that all callbacks are drained? > > > > Hi, > > > > Can you try the attached patch and report back? > > I applied the patch and reloaded ucom and uplcom. So far there were no > power glitches so UPS did not dropped off the bus yet. > > I have a question regarding the changed fragment of code. Why don't you use > unr(9) KPI to manage unit numbers ? Probably I could, but right now the unr interface doesn't support pending unit free which I need for other reasons, see below. Ed: I would really like to see a custom argument for the tsw_free(), because it only needs to know the unit number, and the xsc for UCOM is freed when this is called and cannot be referred. Is it possible to have a separate "void *" for the tsw_free() function? Is this something which you can implement? --HPS From owner-freebsd-current@FreeBSD.ORG Wed Aug 8 17:24:19 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5E2EF1065673 for ; Wed, 8 Aug 2012 17:24:19 +0000 (UTC) (envelope-from edschouten@gmail.com) Received: from mail-gg0-f182.google.com (mail-gg0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 160E88FC25 for ; Wed, 8 Aug 2012 17:24:18 +0000 (UTC) Received: by ggnk4 with SMTP id k4so1241900ggn.13 for ; Wed, 08 Aug 2012 10:24:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=Il9d5dHTy/3WL658g1G6aKWxeUGMl0tw6CYirtc0UIU=; b=B4KyIERUAgEYMBW0kHBkRRQ0D3NZEMIy3nbM3ciObO59gP9qYvk6UUb6Zyt4RG5z86 fajG2NOwrxTap11Pdvnir5zEaDyf6gpteSQZN46qsspkemw9DVMl1qUiN3PqyuBq7oNu FXxPzG5I/oLTuVAAeta5Xzp9eFxZ7g4LFFi6gnZg5AdTzGkbFgNvb0Ly013dZ1a3zDZI zS7U+5pjdl+GFZToeP/RklID+Y7H+cZt5yiAwDGoWQV2k2i89lFD56khS0U69QT7uyrF VM8Taku57cvrLjYHz0EPpJp4/BErBBTWQgcIkmdPJQivi8pkgZlor+b+K340f00zldgz 6c+Q== MIME-Version: 1.0 Received: by 10.60.19.34 with SMTP id b2mr550874oee.41.1344446658239; Wed, 08 Aug 2012 10:24:18 -0700 (PDT) Sender: edschouten@gmail.com Received: by 10.76.153.195 with HTTP; Wed, 8 Aug 2012 10:24:18 -0700 (PDT) In-Reply-To: <201208081827.53824.hselasky@c2i.net> References: <20120801160323.GN2676@deviant.kiev.zoral.com.ua> <201208071703.13773.hselasky@c2i.net> <20120808113133.GO2676@deviant.kiev.zoral.com.ua> <201208081827.53824.hselasky@c2i.net> Date: Wed, 8 Aug 2012 19:24:18 +0200 X-Google-Sender-Auth: 3a8EotZUkdi2d9CUkccFdDe4ieo Message-ID: From: Ed Schouten To: Hans Petter Selasky Content-Type: text/plain; charset=UTF-8 Cc: Konstantin Belousov , freebsd-current@freebsd.org Subject: Re: ttydev_cdevsw has no d_purge X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 08 Aug 2012 17:24:19 -0000 2012/8/8 Hans Petter Selasky : >> I have a question regarding the changed fragment of code. Why don't you use >> unr(9) KPI to manage unit numbers ? > > Probably I could, but right now the unr interface doesn't support pending unit > free which I need for other reasons, see below. What does `pending unit free' mean? I also would prefer it if you used unr(9) -- not just here, but across the entire USB stack. > Ed: I would really like to see a custom argument for the tsw_free(), because > it only needs to know the unit number, and the xsc for UCOM is freed when this > is called and cannot be referred. Is it possible to have a separate "void *" > for the tsw_free() function? Is this something which you can implement? We could extend the TTY code to allow the softc to be changed, e.g. tty_set_softc(). This function could be called right before calling tty_rel_gone(). Still, I would prefer it if these kind of things would not be part of the API. Is there really no way the deallocation of the softc can be delayed until tsw_free() is called? Thanks, -- Ed Schouten From owner-freebsd-current@FreeBSD.ORG Wed Aug 8 17:40:57 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 10FC1106566C for ; Wed, 8 Aug 2012 17:40:57 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe01.c2i.net [212.247.154.2]) by mx1.freebsd.org (Postfix) with ESMTP id 90B408FC14 for ; Wed, 8 Aug 2012 17:40:56 +0000 (UTC) X-T2-Spam-Status: No, hits=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 Received: from [176.74.212.201] (account mc467741@c2i.net HELO laptop015.hselasky.homeunix.org) by mailfe01.swip.net (CommuniGate Pro SMTP 5.4.4) with ESMTPA id 308384168; Wed, 08 Aug 2012 19:40:47 +0200 From: Hans Petter Selasky To: Ed Schouten Date: Wed, 8 Aug 2012 19:41:17 +0200 User-Agent: KMail/1.13.7 (FreeBSD/9.1-PRERELEASE; KDE/4.8.4; amd64; ; ) References: <20120801160323.GN2676@deviant.kiev.zoral.com.ua> <201208081827.53824.hselasky@c2i.net> In-Reply-To: X-Face: 'mmZ:T{)),Oru^0c+/}w'`gU1$ubmG?lp!=R4Wy\ELYo2)@'UZ24N@d2+AyewRX}mAm; Yp |U[@, _z/([?1bCfM{_"B<.J>mICJCHAzzGHI{y7{%JVz%R~yJHIji`y>Y}k1C4TfysrsUI -%GU9V5]iUZF&nRn9mJ'?&>O MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201208081941.17860.hselasky@c2i.net> Cc: Konstantin Belousov , freebsd-current@freebsd.org Subject: Re: ttydev_cdevsw has no d_purge X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 08 Aug 2012 17:40:57 -0000 On Wednesday 08 August 2012 19:24:18 Ed Schouten wrote: > > Ed: I would really like to see a custom argument for the tsw_free(), > > because it only needs to know the unit number, and the xsc for UCOM is > > freed when this is called and cannot be referred. Is it possible to have > > a separate "void *" for the tsw_free() function? Is this something which > > you can implement? > > We could extend the TTY code to allow the softc to be changed, e.g. > tty_set_softc(). This function could be called right before calling > tty_rel_gone(). Still, I would prefer it if these kind of things would Are you sure that the new softc won't be used in any callbacks when tty_rel_gone() is called, except for tsw_free() ? > not be part of the API. Is there really no way the deallocation of the > softc can be delayed until tsw_free() is called? Yes, but that is inconvenient. We use the automatically allocated softc given to the driver by newbus. When detach() returns, the softc is freed. Then we need to block in detach, and that is causing the problem! --HPS From owner-freebsd-current@FreeBSD.ORG Wed Aug 8 17:41:57 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 43DA6106564A for ; Wed, 8 Aug 2012 17:41:57 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe05.c2i.net [212.247.154.130]) by mx1.freebsd.org (Postfix) with ESMTP id B750A8FC26 for ; Wed, 8 Aug 2012 17:41:55 +0000 (UTC) X-T2-Spam-Status: No, hits=-1.0 required=5.0 tests=ALL_TRUSTED Received: from [176.74.212.201] (account mc467741@c2i.net HELO laptop015.hselasky.homeunix.org) by mailfe05.swip.net (CommuniGate Pro SMTP 5.4.4) with ESMTPA id 302278772; Wed, 08 Aug 2012 19:41:54 +0200 From: Hans Petter Selasky To: Ed Schouten Date: Wed, 8 Aug 2012 19:42:24 +0200 User-Agent: KMail/1.13.7 (FreeBSD/9.1-PRERELEASE; KDE/4.8.4; amd64; ; ) References: <20120801160323.GN2676@deviant.kiev.zoral.com.ua> <201208081827.53824.hselasky@c2i.net> In-Reply-To: X-Face: 'mmZ:T{)),Oru^0c+/}w'`gU1$ubmG?lp!=R4Wy\ELYo2)@'UZ24N@d2+AyewRX}mAm; Yp |U[@, _z/([?1bCfM{_"B<.J>mICJCHAzzGHI{y7{%JVz%R~yJHIji`y>Y}k1C4TfysrsUI -%GU9V5]iUZF&nRn9mJ'?&>O MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201208081942.24619.hselasky@c2i.net> Cc: Konstantin Belousov , freebsd-current@freebsd.org Subject: Re: ttydev_cdevsw has no d_purge X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 08 Aug 2012 17:41:57 -0000 On Wednesday 08 August 2012 19:24:18 Ed Schouten wrote: > 2012/8/8 Hans Petter Selasky : > >> I have a question regarding the changed fragment of code. Why don't you > >> use unr(9) KPI to manage unit numbers ? > > > > Probably I could, but right now the unr interface doesn't support pending > > unit free which I need for other reasons, see below. > > What does `pending unit free' mean? I also would prefer it if you used > unr(9) -- not just here, but across the entire USB stack. It is like a drain state, where a unit is collected for free, and then committed to free state when the tsw_free() is called. In the [unlocked] time in between the unit cannot be re-used. --HPS From owner-freebsd-current@FreeBSD.ORG Wed Aug 8 18:39:23 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D8188106566B; Wed, 8 Aug 2012 18:39:23 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1-6.sentex.ca [IPv6:2607:f3e0:0:1::12]) by mx1.freebsd.org (Postfix) with ESMTP id 986908FC0A; Wed, 8 Aug 2012 18:39:23 +0000 (UTC) Received: from [192.168.43.26] (pyroxene.sentex.ca [199.212.134.18]) by smarthost1.sentex.ca (8.14.5/8.14.5) with ESMTP id q78IdMAr042746; Wed, 8 Aug 2012 14:39:22 -0400 (EDT) (envelope-from mike@sentex.net) Message-ID: <5022B252.30606@sentex.net> Date: Wed, 08 Aug 2012 14:39:14 -0400 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: John Baldwin References: <201208031418.57941.jhb@freebsd.org> <201208031726.03652.jhb@freebsd.org> <502121F5.4020705@sentex.net> <201208080727.45595.jhb@freebsd.org> In-Reply-To: <201208080727.45595.jhb@freebsd.org> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.72 on 64.7.153.18 Cc: Garrett Cooper , current@freebsd.org Subject: Re: [PATCH] Add locking to twe(4) so it no longer uses Giant X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 08 Aug 2012 18:39:23 -0000 On 8/8/2012 7:27 AM, John Baldwin wrote: >> Looks like it breaks 3dm2 and the tw_cli. With the patch, I am not able >> to see the 8006 controller I added. > > Ugh, ok. A few questions: > > 1) Does the driver see any attached drives/volumes? Yes > > 2) If it does, does basic I/O to the drives work? yes > > 3) Can you add some debugging printfs to twe_ioctl() to see what, if anything, > fails in that routine when tw_cli makes a request? Yes, for sure. Let me know what you would like me to add. ---Mike -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From owner-freebsd-current@FreeBSD.ORG Wed Aug 8 20:46:28 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C3B741065674 for ; Wed, 8 Aug 2012 20:46:28 +0000 (UTC) (envelope-from edschouten@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 846218FC15 for ; Wed, 8 Aug 2012 20:46:28 +0000 (UTC) Received: by obbun3 with SMTP id un3so2187425obb.13 for ; Wed, 08 Aug 2012 13:46:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=IrkxTZ5wPFaU7mR85bm/O3B5Smjjihta+e+h3K2kt4c=; b=A/6VQrVItxI11y3aCb8J9PUZ0ii0GEOkRfWHM8aiz82ZeswjsazmQHmMriP/v56yv8 OC7/JXrxAxg0DXPcwxeDTXhLm+QYojYuaQOSYwYifyyn4maD7VH2LPXCjq892VBQmfD2 tcIxt9a/U8/fLjYHb/gSrYeJ6/TspHWQ1JkOazKsEU3r4EjyybREGCa2IeJuRTzTbDTV hFFu369pQXqzBYiUp/WC1fJnPBoiZFLMFuF7w305f0QedilT6/m16U8PHIKs6o80vTyc fYT3WzqY02yeJK2Za/RFay8s6zzrjax1WEPRadSeK+l786e0iTjBgkNkYs4jk8lOqdaU DccA== MIME-Version: 1.0 Received: by 10.182.17.42 with SMTP id l10mr1752174obd.52.1344458788085; Wed, 08 Aug 2012 13:46:28 -0700 (PDT) Sender: edschouten@gmail.com Received: by 10.76.153.195 with HTTP; Wed, 8 Aug 2012 13:46:28 -0700 (PDT) In-Reply-To: <201208081941.17860.hselasky@c2i.net> References: <20120801160323.GN2676@deviant.kiev.zoral.com.ua> <201208081827.53824.hselasky@c2i.net> <201208081941.17860.hselasky@c2i.net> Date: Wed, 8 Aug 2012 22:46:28 +0200 X-Google-Sender-Auth: iebfLDvAkTCky4ZawBH1m6WH8sw Message-ID: From: Ed Schouten To: Hans Petter Selasky Content-Type: text/plain; charset=UTF-8 Cc: Konstantin Belousov , freebsd-current@freebsd.org Subject: Re: ttydev_cdevsw has no d_purge X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 08 Aug 2012 20:46:28 -0000 Hi Hans, 2012/8/8 Hans Petter Selasky : > Are you sure that the new softc won't be used in any callbacks when > tty_rel_gone() is called, except for tsw_free() ? Yes. Otherwise you would have already seen a kernel panic. See /sys/sys/ttydevsw.h; it has assertions on the locking. > It is like a drain state, where a unit is collected for free, and then > committed to free state when the tsw_free() is called. In the [unlocked] time > in between the unit cannot be re-used. How is this different from calling alloc/free directly? Why would it need to go through this `drain' state? -- Ed Schouten From owner-freebsd-current@FreeBSD.ORG Wed Aug 8 21:52:05 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1AFF4106564A for ; Wed, 8 Aug 2012 21:52:05 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 6D4858FC17 for ; Wed, 8 Aug 2012 21:52:04 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q78Lq838002726; Thu, 9 Aug 2012 00:52:08 +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.5/8.14.5) with ESMTP id q78Lptaa046604; Thu, 9 Aug 2012 00:51:55 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q78LptAu046603; Thu, 9 Aug 2012 00:51:55 +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, 9 Aug 2012 00:51:55 +0300 From: Konstantin Belousov To: Hans Petter Selasky Message-ID: <20120808215155.GP2676@deviant.kiev.zoral.com.ua> References: <20120801160323.GN2676@deviant.kiev.zoral.com.ua> <201208081827.53824.hselasky@c2i.net> <201208081942.24619.hselasky@c2i.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="YqVjBi0tQ7r7wVWr" Content-Disposition: inline In-Reply-To: <201208081942.24619.hselasky@c2i.net> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: Ed Schouten , freebsd-current@freebsd.org Subject: Re: ttydev_cdevsw has no d_purge X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 08 Aug 2012 21:52:05 -0000 --YqVjBi0tQ7r7wVWr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Aug 08, 2012 at 07:42:24PM +0200, Hans Petter Selasky wrote: > On Wednesday 08 August 2012 19:24:18 Ed Schouten wrote: > > 2012/8/8 Hans Petter Selasky : > > >> I have a question regarding the changed fragment of code. Why don't = you > > >> use unr(9) KPI to manage unit numbers ? > > >=20 > > > Probably I could, but right now the unr interface doesn't support pen= ding > > > unit free which I need for other reasons, see below. > >=20 > > What does `pending unit free' mean? I also would prefer it if you used > > unr(9) -- not just here, but across the entire USB stack. >=20 > It is like a drain state, where a unit is collected for free, and then=20 > committed to free state when the tsw_free() is called. In the [unlocked] = time=20 > in between the unit cannot be re-used. Still, why do you need such intermediate state ? You cannot reuse the unit number while it is in the 'pending free' still, AFAIU. --YqVjBi0tQ7r7wVWr Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAlAi33sACgkQC3+MBN1Mb4gTmQCcDUq4xjyvVPT9BzRykY82XQel kgIAniCXmwuYnq6wMsYzEY/5JzRqLxTa =CTrb -----END PGP SIGNATURE----- --YqVjBi0tQ7r7wVWr-- From owner-freebsd-current@FreeBSD.ORG Thu Aug 9 05:30:22 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 60BD5106566B for ; Thu, 9 Aug 2012 05:30:22 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe07.c2i.net [212.247.154.194]) by mx1.freebsd.org (Postfix) with ESMTP id D82128FC08 for ; Thu, 9 Aug 2012 05:30:21 +0000 (UTC) X-T2-Spam-Status: No, hits=-1.0 required=5.0 tests=ALL_TRUSTED Received: from [176.74.212.201] (account mc467741@c2i.net HELO laptop015.hselasky.homeunix.org) by mailfe07.swip.net (CommuniGate Pro SMTP 5.4.4) with ESMTPA id 305643886; Thu, 09 Aug 2012 07:30:13 +0200 From: Hans Petter Selasky To: Konstantin Belousov Date: Thu, 9 Aug 2012 07:30:43 +0200 User-Agent: KMail/1.13.7 (FreeBSD/9.1-PRERELEASE; KDE/4.8.4; amd64; ; ) References: <20120801160323.GN2676@deviant.kiev.zoral.com.ua> <201208081942.24619.hselasky@c2i.net> <20120808215155.GP2676@deviant.kiev.zoral.com.ua> In-Reply-To: <20120808215155.GP2676@deviant.kiev.zoral.com.ua> X-Face: 'mmZ:T{)),Oru^0c+/}w'`gU1$ubmG?lp!=R4Wy\ELYo2)@'UZ24N@d2+AyewRX}mAm; Yp |U[@, _z/([?1bCfM{_"B<.J>mICJCHAzzGHI{y7{%JVz%R~yJHIji`y>Y}k1C4TfysrsUI -%GU9V5]iUZF&nRn9mJ'?&>O MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201208090730.43919.hselasky@c2i.net> Cc: Ed Schouten , freebsd-current@freebsd.org Subject: Re: ttydev_cdevsw has no d_purge X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Aug 2012 05:30:22 -0000 On Wednesday 08 August 2012 23:51:55 Konstantin Belousov wrote: > On Wed, Aug 08, 2012 at 07:42:24PM +0200, Hans Petter Selasky wrote: > > On Wednesday 08 August 2012 19:24:18 Ed Schouten wrote: > > > 2012/8/8 Hans Petter Selasky : > > > >> I have a question regarding the changed fragment of code. Why don't > > > >> you use unr(9) KPI to manage unit numbers ? > > > > > > > > Probably I could, but right now the unr interface doesn't support > > > > pending unit free which I need for other reasons, see below. > > > > > > What does `pending unit free' mean? I also would prefer it if you used > > > unr(9) -- not just here, but across the entire USB stack. > > > > It is like a drain state, where a unit is collected for free, and then > > committed to free state when the tsw_free() is called. In the [unlocked] > > time in between the unit cannot be re-used. > > Still, why do you need such intermediate state ? You cannot reuse the unit > number while it is in the 'pending free' still, AFAIU. Because of the order in which structures are freed. See other e-mail. --HPS From owner-freebsd-current@FreeBSD.ORG Thu Aug 9 05:36:59 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B80C0106566C for ; Thu, 9 Aug 2012 05:36:59 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe06.c2i.net [212.247.154.162]) by mx1.freebsd.org (Postfix) with ESMTP id 45CA58FC08 for ; Thu, 9 Aug 2012 05:36:59 +0000 (UTC) X-T2-Spam-Status: No, hits=-1.0 required=5.0 tests=ALL_TRUSTED Received: from [176.74.212.201] (account mc467741@c2i.net HELO laptop015.hselasky.homeunix.org) by mailfe06.swip.net (CommuniGate Pro SMTP 5.4.4) with ESMTPA id 304841085; Thu, 09 Aug 2012 07:36:51 +0200 From: Hans Petter Selasky To: Ed Schouten Date: Thu, 9 Aug 2012 07:37:21 +0200 User-Agent: KMail/1.13.7 (FreeBSD/9.1-PRERELEASE; KDE/4.8.4; amd64; ; ) References: <20120801160323.GN2676@deviant.kiev.zoral.com.ua> <201208081941.17860.hselasky@c2i.net> In-Reply-To: X-Face: 'mmZ:T{)),Oru^0c+/}w'`gU1$ubmG?lp!=R4Wy\ELYo2)@'UZ24N@d2+AyewRX}mAm; Yp |U[@, _z/([?1bCfM{_"B<.J>mICJCHAzzGHI{y7{%JVz%R~yJHIji`y>Y}k1C4TfysrsUI -%GU9V5]iUZF&nRn9mJ'?&>O MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201208090737.21547.hselasky@c2i.net> Cc: Konstantin Belousov , freebsd-current@freebsd.org Subject: Re: ttydev_cdevsw has no d_purge X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Aug 2012 05:36:59 -0000 On Wednesday 08 August 2012 22:46:28 Ed Schouten wrote: > Hi Hans, > > 2012/8/8 Hans Petter Selasky : > > Are you sure that the new softc won't be used in any callbacks when > > tty_rel_gone() is called, except for tsw_free() ? > > Yes. Otherwise you would have already seen a kernel panic. See > /sys/sys/ttydevsw.h; it has assertions on the locking. > > > It is like a drain state, where a unit is collected for free, and then > > committed to free state when the tsw_free() is called. In the [unlocked] > > time in between the unit cannot be re-used. > > How is this different from calling alloc/free directly? Why would it > need to go through this `drain' state? Because multiple TTYS can share the same ucom unit, and then stuff gets more complicated. I would then need refcounting and such to figure out when to actually free everything. This is simply not needed. I'll make a patch soonish to extend tty.h with a #define tty_set_softc() if you don't mind. --HPS From owner-freebsd-current@FreeBSD.ORG Thu Aug 9 06:51:29 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 96769106566B for ; Thu, 9 Aug 2012 06:51:29 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe06.c2i.net [212.247.154.162]) by mx1.freebsd.org (Postfix) with ESMTP id F27788FC16 for ; Thu, 9 Aug 2012 06:51:28 +0000 (UTC) X-T2-Spam-Status: No, hits=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 Received: from [176.74.212.201] (account mc467741@c2i.net HELO laptop015.hselasky.homeunix.org) by mailfe06.swip.net (CommuniGate Pro SMTP 5.4.4) with ESMTPA id 304866782; Thu, 09 Aug 2012 08:51:26 +0200 From: Hans Petter Selasky To: Ed Schouten Date: Thu, 9 Aug 2012 08:51:56 +0200 User-Agent: KMail/1.13.7 (FreeBSD/9.1-PRERELEASE; KDE/4.8.4; amd64; ; ) References: <20120801160323.GN2676@deviant.kiev.zoral.com.ua> <201208081941.17860.hselasky@c2i.net> In-Reply-To: X-Face: 'mmZ:T{)),Oru^0c+/}w'`gU1$ubmG?lp!=R4Wy\ELYo2)@'UZ24N@d2+AyewRX}mAm; Yp |U[@, _z/([?1bCfM{_"B<.J>mICJCHAzzGHI{y7{%JVz%R~yJHIji`y>Y}k1C4TfysrsUI -%GU9V5]iUZF&nRn9mJ'?&>O MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_M41IQdlR19hhEdx" Message-Id: <201208090851.56972.hselasky@c2i.net> Cc: Konstantin Belousov , freebsd-current@freebsd.org Subject: Re: ttydev_cdevsw has no d_purge X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Aug 2012 06:51:29 -0000 --Boundary-00=_M41IQdlR19hhEdx Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Hi, I've updated the ucom patch. 1) Use unrhdr. Suggested by ed. 2) Implement tty_set_softc() and use that when dereffing ucom unit numbers. Please test and report back. --HPS --Boundary-00=_M41IQdlR19hhEdx Content-Type: text/x-patch; charset="utf-8"; name="ucom_unit_number_and_tty.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ucom_unit_number_and_tty.patch" === sys/tty.h ================================================================== --- sys/tty.h (revision 239054) +++ sys/tty.h (local) @@ -199,6 +199,7 @@ #define tty_opened(tp) ((tp)->t_flags & TF_OPENED) #define tty_gone(tp) ((tp)->t_flags & TF_GONE) #define tty_softc(tp) ((tp)->t_devswsoftc) +#define tty_set_softc(tp,sc) do { (tp)->t_devswsoftc = (sc); } while (0) #define tty_devname(tp) devtoname((tp)->t_dev) /* Status line printing. */ === dev/usb/serial/usb_serial.c ================================================================== --- dev/usb/serial/usb_serial.c (revision 239054) +++ dev/usb/serial/usb_serial.c (local) @@ -146,7 +146,7 @@ static int ucom_unit_alloc(void); static void ucom_unit_free(int); static int ucom_attach_tty(struct ucom_super_softc *, struct ucom_softc *); -static void ucom_detach_tty(struct ucom_softc *); +static void ucom_detach_tty(struct ucom_super_softc *, struct ucom_softc *); static void ucom_queue_command(struct ucom_softc *, usb_proc_callback_t *, struct termios *pt, struct usb_proc_msg *t0, struct usb_proc_msg *t1); @@ -178,14 +178,33 @@ MODULE_DEPEND(ucom, usb, 1, 1, 1); MODULE_VERSION(ucom, 1); -#define UCOM_UNIT_MAX 128 /* limits size of ucom_bitmap */ +#define UCOM_UNIT_MAX 128 /* maximum number of units */ +#define UCOM_TTY_PREFIX "U" -static uint8_t ucom_bitmap[(UCOM_UNIT_MAX + 7) / 8]; -static struct mtx ucom_bitmap_mtx; -MTX_SYSINIT(ucom_bitmap_mtx, &ucom_bitmap_mtx, "ucom bitmap", MTX_DEF); +static struct unrhdr *ucom_unrhdr; -#define UCOM_TTY_PREFIX "U" +static void +ucom_init(void *arg) +{ + DPRINTF("\n"); + ucom_unrhdr = new_unrhdr(0, UCOM_UNIT_MAX - 1, NULL); +} +SYSINIT(ucom_init, SI_SUB_KLD, SI_ORDER_ANY, ucom_init, NULL); +static void +ucom_uninit(void *arg) +{ + struct unrhdr *hdr; + hdr = ucom_unrhdr; + ucom_unrhdr = NULL; + + DPRINTF("\n"); + + if (hdr != NULL) + delete_unrhdr(hdr); +} +SYSUNINIT(ucom_uninit, SI_SUB_KLD, SI_ORDER_ANY, ucom_uninit, NULL); + /* * Mark a unit number (the X in cuaUX) as in use. * @@ -197,21 +216,14 @@ { int unit; - mtx_lock(&ucom_bitmap_mtx); - - for (unit = 0; unit < UCOM_UNIT_MAX; unit++) { - if ((ucom_bitmap[unit / 8] & (1 << (unit % 8))) == 0) { - ucom_bitmap[unit / 8] |= (1 << (unit % 8)); - break; - } + /* sanity checks */ + if (ucom_unrhdr == NULL) { + DPRINTF("ucom_unrhdr is NULL\n"); + return (-1); } - - mtx_unlock(&ucom_bitmap_mtx); - - if (unit == UCOM_UNIT_MAX) - return -1; - else - return unit; + unit = alloc_unr(ucom_unrhdr); + DPRINTF("unit %d is allocated\n", unit); + return (unit); } /* @@ -220,11 +232,13 @@ static void ucom_unit_free(int unit) { - mtx_lock(&ucom_bitmap_mtx); - - ucom_bitmap[unit / 8] &= ~(1 << (unit % 8)); - - mtx_unlock(&ucom_bitmap_mtx); + /* sanity checks */ + if (unit < 0 || unit >= UCOM_UNIT_MAX || ucom_unrhdr == NULL) { + DPRINTF("cannot free unit number\n"); + return; + } + DPRINTF("unit %d is freed\n", unit); + free_unr(ucom_unrhdr, unit); } /* @@ -248,11 +262,21 @@ return (EINVAL); } + ssc->sc_ref = malloc(sizeof(*ssc->sc_ref), M_USBDEV, + M_WAITOK | M_ZERO); + if (ssc->sc_ref == NULL) + return (ENOMEM); + /* allocate a uniq unit number */ ssc->sc_unit = ucom_unit_alloc(); - if (ssc->sc_unit == -1) + if (ssc->sc_unit == -1) { + free(ssc->sc_ref, M_USBDEV); return (ENOMEM); + } + /* store unit number for later */ + ssc->sc_ref->unit = ssc->sc_unit; + /* generate TTY name string */ snprintf(ssc->sc_ttyname, sizeof(ssc->sc_ttyname), UCOM_TTY_PREFIX "%d", ssc->sc_unit); @@ -260,7 +284,7 @@ /* create USB request handling process */ error = usb_proc_create(&ssc->sc_tq, mtx, "ucom", USB_PRI_MED); if (error) { - ucom_unit_free(ssc->sc_unit); + ucom_free(ssc->sc_ref); return (error); } ssc->sc_subunits = subunits; @@ -277,6 +301,10 @@ ucom_detach(ssc, &sc[0]); return (error); } + /* increment unit reference count */ + ssc->sc_ref->refs++; + + /* set subunit attached */ sc[subunit].sc_flag |= UCOM_FLAG_ATTACHED; } @@ -310,16 +338,19 @@ usb_proc_drain(&ssc->sc_tq); + /* if there are no TTYs we need to free the ref structure */ + if (ssc->sc_ref->refs == 0) + ucom_free(ssc->sc_ref); + for (subunit = 0; subunit < ssc->sc_subunits; subunit++) { if (sc[subunit].sc_flag & UCOM_FLAG_ATTACHED) { - ucom_detach_tty(&sc[subunit]); + ucom_detach_tty(ssc, &sc[subunit]); /* avoid duplicate detach */ sc[subunit].sc_flag &= ~UCOM_FLAG_ATTACHED; } } - ucom_unit_free(ssc->sc_unit); usb_proc_free(&ssc->sc_tq); } @@ -356,7 +387,6 @@ sc->sc_tty = tp; DPRINTF("ttycreate: %s\n", buf); - cv_init(&sc->sc_cv, "ucom"); /* Check if this device should be a console */ if ((ucom_cons_softc == NULL) && @@ -388,7 +418,7 @@ } static void -ucom_detach_tty(struct ucom_softc *sc) +ucom_detach_tty(struct ucom_super_softc *ssc, struct ucom_softc *sc) { struct tty *tp = sc->sc_tty; @@ -408,17 +438,17 @@ sc->sc_flag |= UCOM_FLAG_GONE; sc->sc_flag &= ~(UCOM_FLAG_HL_READY | UCOM_FLAG_LL_READY); mtx_unlock(sc->sc_mtx); + if (tp) { tty_lock(tp); ucom_close(tp); /* close, if any */ + tty_set_softc(tp, ssc->sc_ref); + tty_rel_gone(tp); mtx_lock(sc->sc_mtx); - /* Wait for the callback after the TTY is torn down */ - while (sc->sc_ttyfreed == 0) - cv_wait(&sc->sc_cv, sc->sc_mtx); /* * make sure that read and write transfers are stopped */ @@ -430,7 +460,6 @@ } mtx_unlock(sc->sc_mtx); } - cv_destroy(&sc->sc_cv); } void @@ -1323,12 +1352,14 @@ static void ucom_free(void *xsc) { - struct ucom_softc *sc = xsc; + struct ucom_ref *sc_ref = (struct ucom_ref *)xsc; - mtx_lock(sc->sc_mtx); - sc->sc_ttyfreed = 1; - cv_signal(&sc->sc_cv); - mtx_unlock(sc->sc_mtx); + if (sc_ref->refs <= 1) { + ucom_unit_free(sc_ref->unit); + free(sc_ref, M_USBDEV); + } else { + sc_ref->refs--; + } } static cn_probe_t ucom_cnprobe; === dev/usb/serial/usb_serial.h ================================================================== --- dev/usb/serial/usb_serial.h (revision 239054) +++ dev/usb/serial/usb_serial.h (local) @@ -131,12 +131,18 @@ struct termios termios_copy; }; +struct ucom_ref { + int refs; + int unit; +}; + struct ucom_super_softc { struct usb_process sc_tq; int sc_unit; int sc_subunits; struct sysctl_oid *sc_sysctl_ttyname; struct sysctl_oid *sc_sysctl_ttyports; + struct ucom_ref *sc_ref; char sc_ttyname[16]; }; @@ -158,7 +164,6 @@ struct ucom_cfg_task sc_line_state_task[2]; struct ucom_cfg_task sc_status_task[2]; struct ucom_param_task sc_param_task[2]; - struct cv sc_cv; /* Used to set "UCOM_FLAG_GP_DATA" flag: */ struct usb_proc_msg *sc_last_start_xfer; const struct ucom_callback *sc_callback; @@ -179,7 +184,6 @@ uint8_t sc_lsr; uint8_t sc_msr; uint8_t sc_mcr; - uint8_t sc_ttyfreed; /* set when TTY has been freed */ /* programmed line state bits */ uint8_t sc_pls_set; /* set bits */ uint8_t sc_pls_clr; /* cleared bits */ --Boundary-00=_M41IQdlR19hhEdx-- From owner-freebsd-current@FreeBSD.ORG Thu Aug 9 07:12:04 2012 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 18CFD106564A; Thu, 9 Aug 2012 07:12:04 +0000 (UTC) (envelope-from tom@uffner.com) Received: from eris.uffner.com (eris.uffner.com [71.162.143.94]) by mx1.freebsd.org (Postfix) with ESMTP id B31648FC19; Thu, 9 Aug 2012 07:12:03 +0000 (UTC) Received: from discordia.uffner.com (discordia.uffner.com [10.69.69.61]) (authenticated bits=0) by eris.uffner.com (8.14.5/8.14.5) with ESMTP id q797BmpP002415 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=FAIL); Thu, 9 Aug 2012 03:11:57 -0400 (EDT) (envelope-from tom@uffner.com) Message-ID: <502362B4.2080700@uffner.com> Date: Thu, 09 Aug 2012 03:11:48 -0400 From: Tom Uffner User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:12.0) Gecko/20120517 Firefox/12.0 SeaMonkey/2.9.1 MIME-Version: 1.0 To: Alexander Motin References: <20120806203804.821031065674@hub.freebsd.org> <50205B66.10701@uffner.com> <50212188.9000203@yandex.ru> <5021A7D8.9040305@FreeBSD.org> In-Reply-To: <5021A7D8.9040305@FreeBSD.org> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: current@FreeBSD.org Subject: Re: geom mirror now rebuilding on every 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, 09 Aug 2012 07:12:04 -0000 Alexander Motin wrote: > I think the right answer would be to remove stale Promise format RAID metadata > from the disk. You should be able to do it by booting from any source and > doing `graid list -a` to see all RAID GEOMs (even broken) and then remove them > with `graid remove Promise ad4`. thanks, that fixed it. tom From owner-freebsd-current@FreeBSD.ORG Thu Aug 9 11:41:40 2012 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 957EA10656B4 for ; Thu, 9 Aug 2012 11:41:40 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.64.117]) by mx1.freebsd.org (Postfix) with ESMTP id 000A18FC1A for ; Thu, 9 Aug 2012 11:41:39 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.5/8.14.5) with ESMTP id q79BfUcf050257; Thu, 9 Aug 2012 15:41:30 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.5/8.14.5/Submit) id q79BfUaJ050256; Thu, 9 Aug 2012 15:41:30 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Thu, 9 Aug 2012 15:41:30 +0400 From: Gleb Smirnoff To: Ian FREISLICH Message-ID: <20120809114130.GC20560@FreeBSD.org> References: <501D52AD.4010105@protected-networks.net> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Garrett Cooper , current@FreeBSD.org Subject: Re: Speaking of ship blockers for 9.... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Aug 2012 11:41:40 -0000 Ian, On Tue, Aug 07, 2012 at 08:17:56PM +0200, Ian FREISLICH wrote: I> I have a problem that's been getting progressively worse as the I> source progresses. So much so that it's had me searching all the I> way from 8.0-RELEASE to 10-CURRENT without luck on both amd64 and I> i386. I> I> pf(4) erroneously mismatches state and then blocks an active flow. I> It seems that 8.X does so silently and 9 to -CURRENT do so verbosely. I> Whether silent or loud, the effect on traffic makes it impracticle I> to use FreeBSD+PF for a firewall in any setting (my use is home, I> small office, large office and moderately large datacenter core I> router). It appears that this has actually been a forever problem I> that just being tickled more now. ... I> ... I> state-mismatch 277767 3.6/s I> I> That's 277767 flows terminated in the last almost 22 hours due to I> this pf bug. (!!!) I> I> 9.1-PRERELEASE logs (as does -CURRENT): I> Jul 22 08:54:25 brane kernel: pf: state key linking mismatch! dir=OUT, if=tun0, stored af=2, a0: 10.0.2.220:60985, a1: 192.41.162.30:53, proto=17, found af=2, a0: 41.154.2.53:1701, a1: 41.133.165.161:59051, proto=17. Let me give you link to my branch of pf: http://lists.freebsd.org/pipermail/freebsd-pf/2012-June/006643.html http://lists.freebsd.org/pipermail/freebsd-pf/2012-June/006662.html In that branch the code that puts the "reverse" pointer on state keys, as well as the m_addr_changed() function and the pf_compare_state_keys() had been cut away. So, this exact bug definitely can't be reproduced there. However, others may hide in :) Let me encourage you to try and test my branch (instructions in URLs above). P.S. I plan to merge it to head at the and of August. -- Totus tuus, Glebius. From owner-freebsd-current@FreeBSD.ORG Thu Aug 9 12:15:38 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D876E106566B for ; Thu, 9 Aug 2012 12:15:38 +0000 (UTC) (envelope-from bsam@passap.ru) Received: from forward5h.mail.yandex.net (forward5h.mail.yandex.net [IPv6:2a02:6b8:0:f05::5]) by mx1.freebsd.org (Postfix) with ESMTP id 58D688FC0A for ; Thu, 9 Aug 2012 12:15:38 +0000 (UTC) Received: from smtp4h.mail.yandex.net (smtp4h.mail.yandex.net [84.201.186.21]) by forward5h.mail.yandex.net (Yandex) with ESMTP id 0D32DD02662 for ; Thu, 9 Aug 2012 16:15:36 +0400 (MSK) Received: from smtp4h.mail.yandex.net (localhost [127.0.0.1]) by smtp4h.mail.yandex.net (Yandex) with ESMTP id DFF552C00EA for ; Thu, 9 Aug 2012 16:15:36 +0400 (MSK) Received: from 87.249.28.59.tel.ru (87.249.28.59.tel.ru [87.249.28.59]) by smtp4h.mail.yandex.net (nwsmtp/Yandex) with ESMTP id FaAan0Hx-FaAOZrgn; Thu, 9 Aug 2012 16:15:36 +0400 Message-ID: <5023A9E8.6040503@passap.ru> Date: Thu, 09 Aug 2012 16:15:36 +0400 From: Boris Samorodov User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:14.0) Gecko/20120728 Thunderbird/14.0 MIME-Version: 1.0 To: freebsd-current@FreeBSD.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: [clang] kernel build failure X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Aug 2012 12:15:38 -0000 Hi! The kernel build fails at fresh CURRENT. At first I get a couple of same warnings like: ----- clang -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 -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -nostdinc -I. -I/usr/ src/sys -I/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-aes -mno-avx -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector /usr/src/sys/cam/scsi/scsi_cd.c /usr/src/sys/cam/scsi/scsi_cd.c:571:7: warning: implicit declaration of function 'scsi_extract_sense_ccb' is invalid in C99 [-Wimplicit-function-declaration] scsi_extract_sense_ccb(ccb, ^ ----- And then I get an error: ----- linking kernel.debug cam_periph.o: In function `cam_periph_error': /usr/src/sys/cam/cam_periph.c:1776: undefined reference to `scsi_extract_sense_ccb' scsi_cd.o: In function `cdasync': /usr/src/sys/cam/scsi/scsi_cd.c:571: undefined reference to `scsi_extract_sense_ccb' scsi_da.o: In function `daasync': /usr/src/sys/cam/scsi/scsi_da.c:1394: undefined reference to `scsi_extract_sense_ccb' *** [kernel.debug] Error code 1 ----- The system...: ----- % uname -a FreeBSD bsam.wart.ru 10.0-CURRENT FreeBSD 10.0-CURRENT #21 r238828M: Fri Jul 27 16:26:02 SAMT 2012 bsam@bsam.wart.ru:/usr/obj/usr/src/sys/BBX i386 ----- ...is build with options: ----- WITH_CLANG_IS_CC="YES" WITH_LIBCPLUSPLUS="YES" ----- -- WBR, Boris Samorodov (bsam) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-current@FreeBSD.ORG Thu Aug 9 12:23:04 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A3A121065670; Thu, 9 Aug 2012 12:23:04 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1-6.sentex.ca [IPv6:2607:f3e0:0:1::12]) by mx1.freebsd.org (Postfix) with ESMTP id 5C5E48FC0C; Thu, 9 Aug 2012 12:23:04 +0000 (UTC) Received: from [192.168.43.26] (pyroxene.sentex.ca [199.212.134.18]) by smarthost1.sentex.ca (8.14.5/8.14.5) with ESMTP id q79CN316032755; Thu, 9 Aug 2012 08:23:03 -0400 (EDT) (envelope-from mike@sentex.net) Message-ID: <5023AB9D.5070608@sentex.net> Date: Thu, 09 Aug 2012 08:22:53 -0400 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: John Baldwin References: <201208031418.57941.jhb@freebsd.org> <201208031726.03652.jhb@freebsd.org> <502121F5.4020705@sentex.net> <201208080727.45595.jhb@freebsd.org> <5022B252.30606@sentex.net> In-Reply-To: <5022B252.30606@sentex.net> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.72 on 64.7.153.18 Cc: Garrett Cooper , current@freebsd.org Subject: Re: [PATCH] Add locking to twe(4) so it no longer uses Giant X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Aug 2012 12:23:04 -0000 On 8/8/2012 2:39 PM, Mike Tancsa wrote: > On 8/8/2012 7:27 AM, John Baldwin wrote: >>> Looks like it breaks 3dm2 and the tw_cli. With the patch, I am not able >>> to see the 8006 controller I added. >> >> Ugh, ok. A few questions: >> >> 1) Does the driver see any attached drives/volumes? > > Yes > >> >> 2) If it does, does basic I/O to the drives work? > > yes > >> >> 3) Can you add some debugging printfs to twe_ioctl() to see what, if anything, >> fails in that routine when tw_cli makes a request? > > Yes, for sure. Let me know what you would like me to add. One more data point, /dev/twe0 does not exist with the patch and I think thats why the utils fail outright. ---Mike -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From owner-freebsd-current@FreeBSD.ORG Thu Aug 9 12:26:03 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DE225106566B for ; Thu, 9 Aug 2012 12:26:03 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (m209-73.dsl.rawbw.com [198.144.209.73]) by mx1.freebsd.org (Postfix) with ESMTP id B3B288FC0A for ; Thu, 9 Aug 2012 12:26:03 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.5/8.14.5) with ESMTP id q79CQ2XF046914; Thu, 9 Aug 2012 05:26:02 -0700 (PDT) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.5/8.14.5/Submit) id q79CQ2Mr046913; Thu, 9 Aug 2012 05:26:02 -0700 (PDT) (envelope-from david) Date: Thu, 9 Aug 2012 05:26:02 -0700 From: David Wolfskill To: Boris Samorodov Message-ID: <20120809122602.GU1464@albert.catwhisker.org> References: <5023A9E8.6040503@passap.ru> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7Rldj+JZnTQmDdGi" Content-Disposition: inline In-Reply-To: <5023A9E8.6040503@passap.ru> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@freebsd.org Subject: Re: [clang] kernel build failure X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Aug 2012 12:26:04 -0000 --7Rldj+JZnTQmDdGi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Aug 09, 2012 at 04:15:36PM +0400, Boris Samorodov wrote: > Hi! >=20 > The kernel build fails at fresh CURRENT... > And then I get an error: > ----- > linking kernel.debug > cam_periph.o: In function `cam_periph_error': > /usr/src/sys/cam/cam_periph.c:1776: undefined reference to=20 > `scsi_extract_sense_ccb' > scsi_cd.o: In function `cdasync': > /usr/src/sys/cam/scsi/scsi_cd.c:571: undefined reference to=20 > `scsi_extract_sense_ccb' > scsi_da.o: In function `daasync': > /usr/src/sys/cam/scsi/scsi_da.c:1394: undefined reference to=20 > `scsi_extract_sense_ccb' > *** [kernel.debug] Error code 1 > ----- >=20 > The system...: > ----- > % uname -a > FreeBSD bsam.wart.ru 10.0-CURRENT FreeBSD 10.0-CURRENT #21 r238828M: Fri= =20 > Jul 27 16:26:02 SAMT 2012 bsam@bsam.wart.ru:/usr/obj/usr/src/sys/BBX= =20 > i386 > ----- I had no trouble (just now); was running: FreeBSD g1-227.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT #645 239138= M: Wed Aug 8 04:44:43 PDT 2012 root@g1-227.catwhisker.org:/usr/obj/usr= /src/sys/CANARY i386 now running: FreeBSD g1-227.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT #646 239148= M: Thu Aug 9 05:04:05 PDT 2012 root@g1-227.catwhisker.org:/usr/obj/usr= /src/sys/CANARY i386 Peace, david --=20 David H. Wolfskill david@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --7Rldj+JZnTQmDdGi Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlAjrFoACgkQmprOCmdXAD3FCQCfW73lm1qWBDmwfup9NzrAiAdf mFkAnA5BMuqdxvJMWfQolw15kmq28jtH =eoJu -----END PGP SIGNATURE----- --7Rldj+JZnTQmDdGi-- From owner-freebsd-current@FreeBSD.ORG Thu Aug 9 13:16:20 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C5C9E1065672 for ; Thu, 9 Aug 2012 13:16:20 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 9778A8FC19 for ; Thu, 9 Aug 2012 13:16:20 +0000 (UTC) Received: from John-Baldwins-MacBook-Air.local (d-69-161-105-82.cpe.metrocast.net [69.161.105.82]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id ED5E5B94B; Thu, 9 Aug 2012 09:16:19 -0400 (EDT) Message-ID: <5023B824.40405@FreeBSD.org> Date: Thu, 09 Aug 2012 09:16:20 -0400 From: John Baldwin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Mike Tancsa References: <201208031418.57941.jhb@freebsd.org> <201208031726.03652.jhb@freebsd.org> <502121F5.4020705@sentex.net> <201208080727.45595.jhb@freebsd.org> <5022B252.30606@sentex.net> <5023AB9D.5070608@sentex.net> In-Reply-To: <5023AB9D.5070608@sentex.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 09 Aug 2012 09:16:20 -0400 (EDT) Cc: Garrett Cooper , current@freebsd.org Subject: Re: [PATCH] Add locking to twe(4) so it no longer uses Giant X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Aug 2012 13:16:20 -0000 On 8/9/12 8:22 AM, Mike Tancsa wrote: > On 8/8/2012 2:39 PM, Mike Tancsa wrote: >> On 8/8/2012 7:27 AM, John Baldwin wrote: >>>> Looks like it breaks 3dm2 and the tw_cli. With the patch, I am not able >>>> to see the 8006 controller I added. >>> >>> Ugh, ok. A few questions: >>> >>> 1) Does the driver see any attached drives/volumes? >> >> Yes >> >>> >>> 2) If it does, does basic I/O to the drives work? >> >> yes Ok, so that's good. I didn't break anything fundamental with driver commands. >>> 3) Can you add some debugging printfs to twe_ioctl() to see what, if anything, >>> fails in that routine when tw_cli makes a request? >> >> Yes, for sure. Let me know what you would like me to add. > > One more data point, /dev/twe0 does not exist with the patch and I think > thats why the utils fail outright. Oh, hmm. That's odd. Do you get any error messages on the console when twe0 attaches? Also, you have INVARIANTS enabled, yes? (make_dev() panics when it fails if INVARIANTS is enabled). Maybe try something like this (relative to the patched driver): --- //depot/user/jhb/cleanup/sys/dev/twe/twe_freebsd.c 2012-08-03 18:10:04.000000000 0000 +++ /Users/jhb/work/p4/cleanup/sys/dev/twe/twe_freebsd.c 2012-08-03 18:10:04.000000000 0000 @@ -342,9 +342,12 @@ /* * Create the control device. */ + device_printf(sc->twe_dev, "Calling make_dev()\n"); sc->twe_dev_t = make_dev(&twe_cdevsw, device_get_unit(sc->twe_dev), UID_ROOT, GID_OPERATOR, S_IRUSR | S_IWUSR, "twe%d", device_get_unit(sc->twe_dev)); sc->twe_dev_t->si_drv1 = sc; + device_printf(sc->twe_dev, "make_dev() returned %p (%s)\n", sc->twe_dev_t, + sc->twe_dev_t->si_name); /* * Schedule ourselves to bring the controller up once interrupts are available. * This isn't strictly necessary, since we disable interrupts while probing the -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu Aug 9 13:26:51 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1A38A106564A; Thu, 9 Aug 2012 13:26:51 +0000 (UTC) (envelope-from utisoft@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 631478FC08; Thu, 9 Aug 2012 13:26:50 +0000 (UTC) Received: by bkcje9 with SMTP id je9so190031bkc.13 for ; Thu, 09 Aug 2012 06:26:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=cF1fUmi9scVXYetHhfs3f+kXwm0Qz+OaiLeFfAkhE7k=; b=ZqaFPW54gnevfGYWz+nj+qfGqtoE7W+7ZCFTpJpJLB/VdH6vKGqiq7VhzFtatEzj+f Yw5sWRIJO8BHfP4++nZr+wkXVaFpoa/BvxDDiFZgz3YIRWzeULEZkHVZrUWvbl5C+XDR 9iB1YAFomKqPJhSHsG+txFKaaepWn9RHhC7jqSvxuo7kflDI/DpaTIdIAwKQM1i/G5dZ FybROjMBoviHgYwJfKhG3gtlPFJJRyn3IYu26pyj5wnOj/cMDFS10mPAjvMhbBpmqwGq sH4StmYFQHG/BhcPl3H+87XrpsQmiRYRYS3Cq1PSfsKhppkUYU6QYL6O3Dv+x/TNJrdu D1Yw== MIME-Version: 1.0 Received: by 10.204.148.72 with SMTP id o8mr9190598bkv.103.1344518809200; Thu, 09 Aug 2012 06:26:49 -0700 (PDT) Received: by 10.204.231.7 with HTTP; Thu, 9 Aug 2012 06:26:49 -0700 (PDT) Received: by 10.204.231.7 with HTTP; Thu, 9 Aug 2012 06:26:49 -0700 (PDT) In-Reply-To: <50211CEA.6030108@mail.zedat.fu-berlin.de> References: <5020E05C.3000704@zedat.fu-berlin.de> <50211A8F.40108@shatow.net> <50211CEA.6030108@mail.zedat.fu-berlin.de> Date: Thu, 9 Aug 2012 14:26:49 +0100 Message-ID: From: Chris Rees To: "O. Hartmann" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Current FreeBSD , "O. Hartmann" , FreeBSD Mailing List , Bryan Drewery Subject: Re: pkg and portmaster: Downgrading ports? Why? portmaster messes up ... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Aug 2012 13:26:51 -0000 On 7 Aug 2012 15:50, "O. Hartmann" wrote: > > On 08/07/12 15:39, Bryan Drewery wrote: > > On 8/7/2012 4:31 AM, O. Hartmann wrote: > >> ports-mgmt/portmaster installs still the old fashioned style folders of > >> ports in /var/db/pkg. I thought ith the new scheme of pkg, everything is > >> going into a file based SQLite3 DB? > > > > Also ensure WITH_PKGNG=yes is in your /etc/make.conf. My last comment > > still stands though, portmaster will store distifile information in > > /var/db/pkg. > > > > WITH_PKGNG=yes is set in /etc/make.conf. Also in your portmasterrc? Chris From owner-freebsd-current@FreeBSD.ORG Thu Aug 9 14:12:52 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1A6771065673; Thu, 9 Aug 2012 14:12:52 +0000 (UTC) (envelope-from honestqiao@gmail.com) Received: from mail-qa0-f54.google.com (mail-qa0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id A0B2F8FC0C; Thu, 9 Aug 2012 14:12:51 +0000 (UTC) Received: by qaat11 with SMTP id t11so246826qaa.13 for ; Thu, 09 Aug 2012 07:12:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=/mlbNn2ZG3pKf5inUmnam6i2VrsjQm7ErvFT5G/Mmo4=; b=VohAyMOmqJQgMpi4qaRP/Uh1+brmBX8F8q1LXVdlksALA6cSdeRqmaGJv+kbu21fA8 FjlZBp8BiNRL01vbNDGn9VjXv8ndRfP6DHUezNpaqHZ4vdouHfos6k9ApCij8xpVdzjQ UwoKeLhU1lW4uRXgpkbj7yH1SPlD++5O+3O6G55tVpl/YTCxDiku5JmqlPMUIxwNKUdz c/vJoDURhI2yvqipduCKvPgBkJPLi0hAH/MRf3/wxZhgtCQWGSt95HbchV9jwPTgipBA xdZA3oifnSdXjj6hpqs0tuj2ZfSewFKkj68aifQU5HNszgbeY4inmJBQ65CHvBq30hJQ kYvQ== Received: by 10.224.221.143 with SMTP id ic15mr2888614qab.51.1344521570581; Thu, 09 Aug 2012 07:12:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.68.224 with HTTP; Thu, 9 Aug 2012 07:12:10 -0700 (PDT) In-Reply-To: References: <5020E05C.3000704@zedat.fu-berlin.de> <50211A8F.40108@shatow.net> <50211CEA.6030108@mail.zedat.fu-berlin.de> From: =?UTF-8?B?5LmU5qWa?= Date: Thu, 9 Aug 2012 22:12:10 +0800 Message-ID: To: Chris Rees Content-Type: multipart/mixed; boundary=20cf3074b4f49b7d9b04c6d5d258 Cc: "O. Hartmann" , Current FreeBSD , "O. Hartmann" , FreeBSD Mailing List , Bryan Drewery Subject: Re: pkg and portmaster: Downgrading ports? Why? portmaster messes up ... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Aug 2012 14:12:52 -0000 --20cf3074b4f49b7d9b04c6d5d258 Content-Type: text/plain; charset=ISO-8859-1 2012/8/9 Chris Rees : > On 7 Aug 2012 15:50, "O. Hartmann" wrote: >> >> On 08/07/12 15:39, Bryan Drewery wrote: >> > On 8/7/2012 4:31 AM, O. Hartmann wrote: >> >> ports-mgmt/portmaster installs still the old fashioned style folders of >> >> ports in /var/db/pkg. I thought ith the new scheme of pkg, everything > is >> >> going into a file based SQLite3 DB? >> > >> > Also ensure WITH_PKGNG=yes is in your /etc/make.conf. My last comment >> > still stands though, portmaster will store distifile information in >> > /var/db/pkg. >> > >> >> WITH_PKGNG=yes is set in /etc/make.conf. > > Also in your portmasterrc? > > Chris > _______________________________________________ > 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" You can use this patch. --20cf3074b4f49b7d9b04c6d5d258 Content-Type: application/octet-stream; name="patch-portmaster-pkgng-3.13.13" Content-Disposition: attachment; filename="patch-portmaster-pkgng-3.13.13" Content-Transfer-Encoding: base64 X-Attachment-Id: f_h5nxdqw40 CiRGcmVlQlNEJAoKLS0tIHBvcnRtYXN0ZXIuc2guaW4ub3JpZworKysgcG9ydG1hc3Rlci5zaC5p bgpAQCAtNDcsNyArNDcsNyBAQAogIz09PT09PT09PT09PT09PSBCZWdpbiBmdW5jdGlvbnMgd2Ug YWx3YXlzIHdhbnQgdG8gaGF2ZSA9PT09PT09PT09PT09PT0KIAogdmVyc2lvbiAoKSB7Ci0JZWNo byAnJyA7IGVjaG8gIj09PT4+PiBWZXJzaW9uIDMuMTMuMTMiCisJZWNobyAnJyA7IGVjaG8gIj09 PT4+PiBWZXJzaW9uIDMuMTMuMTMgKHBrZ25nIHBhdGNoIDEuMykiCiAJI3N2bj0nJEZyZWVCU0Q6 IHVzZXIvZG91Z2IvcG9ydG1hc3Rlci9wb3J0bWFzdGVyIDIzODc1NCAyMDEyLTA3LTI0IDIwOjE1 OjQxWiBkb3VnYiAkJwogfQogCkBAIC0xMzQsNiArMTM0LDggQEAKIAkJCWlmIFsgLW4gIiRmaWxl cyIgXTsgdGhlbgogCQkJCXBtX3N2IERlbGV0aW5nIFwnaW5zdGFsbCBjb21wbGV0ZVwnIGZsYWdz CiAJCQkJcG1fZmluZF9zICRwZGIgLXR5cGUgZiAtbmFtZSBQTV9VUEdSQURFX0RPTkVfRkxBRyAt ZGVsZXRlCisJCQkJWyAtbiAiJHVzZV9wa2duZyIgXSAmJgorCQkJCQlwbV9maW5kX3MgJHBkYiAt dHlwZSBkIC1kZXB0aCAxIC1lbXB0eSAhIC1wYXRoIFwqXC56ZnMvXCogLWRlbGV0ZSAyPi9kZXYv bnVsbAogCQkJZmkKIAkJZmkKIAkJaWYgWyAteiAiJEJBQ0tVUCIgLWEgLXogIiROT19CQUNLVVAi IC1hIC1uICIkTkJfREVMRVRFIiBdOyB0aGVuCkBAIC0xODcsOSArMTg5LDE0IEBACiAJCWZpCiAK IAkJOiAke1BBR0VSOj0nbGVzcyAtZSd9Ci0JCSggZm9yIGYgaW4gJERJU1BMQVlfTElTVDsgZG8K LQkJCWVjaG8gIj09PT4+PiBwa2ctbWVzc2FnZSBmb3IgJGYiIDsgY2F0ICRwZGIvJGYvK0RJU1BM QVkgOyBlY2hvICcnCi0JCWRvbmUKKwkJKCBpZiBbIC16ICIkdXNlX3BrZ25nIiBdOyB0aGVuCisJ CQlmb3IgZiBpbiAkRElTUExBWV9MSVNUOyBkbworCQkJCWVjaG8gIj09PT4+PiBwa2ctbWVzc2Fn ZSBmb3IgJGYiCisJCQkJY2F0ICRwZGIvJGYvK0RJU1BMQVkgOyBlY2hvICcnCisJCQlkb25lCisJ CWVsc2UKKwkJCXBrZyBxdWVyeSAiPT09Pj4+IHBrZy1tZXNzYWdlIGZvciAlbi0ldlxuJU0iICRE SVNQTEFZX0xJU1QKKwkJZmkKIAkJZWNobyAiPT09Pj4+IERvbmUgZGlzcGxheWluZyBwa2ctbWVz c2FnZSBmaWxlcyIgOyBlY2hvICcnICkgfCAkUEFHRVIgOzsKIAllc2FjCiAKQEAgLTIzMiwxMCAr MjM5LDE0IEBACiAJaWYgWyAtbiAiJGJ1aWxkX2RlcHNfaWwiIF07IHRoZW4KIAkJZWNobyAiPT09 Pj4+IERlbGV0aW5nIGluc3RhbGxlZCBidWlsZC1vbmx5IGRlcGVuZGVuY2llcyIKIAkJY2QKLQkJ Zm9yIGYgaW4gJGJ1aWxkX2RlcHNfaWw7IGRvCi0JCQlwbV92ICIgICAgICAgJGYiCi0JCQlwbV9w a2dfZGVsZXRlX3MgLWYgJGYKLQkJZG9uZQorCQlpZiBbIC16ICIkdXNlX3BrZ25nIiBdOyB0aGVu CisJCQlmb3IgZiBpbiAkYnVpbGRfZGVwc19pbDsgZG8KKwkJCQlwbV92ICIgICAgICAgJGYiCisJ CQkJcG1fcGtnX2RlbGV0ZV9zIC1mICRmCisJCQlkb25lCisJCWVsc2UKKwkJCXBtX3BrZ19kZWxl dGVfcyAtZiAkYnVpbGRfZGVwc19pbAorCQlmaQogCQllY2hvICcnCiAJZmkKIApAQCAtMzIzLDcg KzMzNCwxMyBAQAogcG1fbWFrZV9zICAgICAgICAgKCkgeyAoIHVuc2V0IC12IENVUl9ERVBTIElO U1RBTExFRF9MSVNUIFBNX0RFUFRIIGJ1aWxkX2wgUE1fVVJCX0xJU1Q7CiAJCQkgJFBNX1NVX0NN RCAvdXNyL2Jpbi9uaWNlIC91c3IvYmluL21ha2UgJFBNX01BS0VfQVJHUyAkKjsgKTsgfQogcG1f bWtkaXJfcyAgICAgICAgKCkgeyAkUE1fU1VfQ01EIC9iaW4vbWtkaXIgLXAgJDE7IH0KLXBtX3Br Z19kZWxldGVfcyAgICgpIHsgJFBNX1NVX0NNRCAvdXNyL3NiaW4vcGtnX2RlbGV0ZSAkKjsgfQor cG1fcGtnX2RlbGV0ZV9zICAgKCkgeworCWlmIFsgLXogIiR1c2VfcGtnbmciIF07IHRoZW4KKwkJ JFBNX1NVX0NNRCAvdXNyL3NiaW4vcGtnX2RlbGV0ZSAkKjsKKwllbHNlCisJCSRQTV9TVV9DTUQg L3Vzci9sb2NhbC9zYmluL3BrZyBkZWxldGUgLXkgJCo7CisJZmkKK30KIHBtX3JtX3MgICAgICAg ICAgICgpIHsgJFBNX1NVX0NNRCAvYmluL3JtICQqOyB9CiBwbV9ybWRpcl9zICAgICAgICAoKSB7 ICRQTV9TVV9DTUQgL2Jpbi9ybWRpciAkKjsgfQogcG1fdW5saW5rX3MgICAgICAgKCkgeyBbIC1l ICIkMSIgXSAmJiAkUE1fU1VfQ01EIC9iaW4vdW5saW5rICQxOyB9CkBAIC0zNzEsNiArMzg4LDEw IEBACiAJWyAteiAiJHBvcnRfZGJkaXIiIF0gJiYKIAkJcG9ydF9kYmRpcj1gcG1fbWFrZV9iIC1m L3Vzci9zaGFyZS9tay9ic2QucG9ydC5tayAtViBQT1JUX0RCRElSIDI+L2Rldi9udWxsYAogCVsg LW4gIiRwb3J0X2RiZGlyIiBdICYmIGV4cG9ydCBwb3J0X2RiZGlyCisKKwkjIERldGVjdCBpZiBw a2duZyBpcyBiZWluZyB1c2VkCisJdXNlX3BrZ25nPSJgcG1fbWFrZV9iIC1WIFdJVEhfUEtHTkdg IgorCVsgLW4gIiR1c2VfcGtnbmciIF0gJiYgZXhwb3J0IHVzZV9wa2duZwogZmkKIAogdXNhZ2Ug KCkgewpAQCAtNTI3LDEyICs1NDgsMTcgQEAKIAogCXBhdHRlcm49YGdsb2JzdHJpcCAkMWAKIAot CWdsb2JfZGlycz1gZmluZCAkcGRiIC1tYXhkZXB0aCAxIC10eXBlIGQgLW5hbWUgJHtwYXR0ZXJu fVwqYAorCWlmIFsgLXogIiR1c2VfcGtnbmciIF07IHRoZW4KKwkJZ2xvYl9kaXJzPWBmaW5kICRw ZGIgLWRlcHRoIDEgLXR5cGUgZCAtbmFtZSAke3BhdHRlcm59XCpgCisJZWxzZQorCQlnbG9iX2Rp cnM9YHBrZyBxdWVyeSAtZyAiJW4tJXYiICR7cGF0dGVybn1cKmAKKwlmaQogCWNhc2UgIiRnbG9i X2RpcnMiIGluCiAJIyBNYXRjaCBhIG5ld2xpbmUgaW4gbXVsdGlwbGUgcmVzcG9uc2VzIGZyb20g ZmluZAogCSonCiAnKikJCXJldHVybiAyIDs7Ci0JJHBkYi8qKQlyZXR1cm4gOzsKKwknJykJOzsK KwkqKQlyZXR1cm4gOzsKIAllc2FjCiAKIAl1bnNldCBnbG9iX2RpcnMKQEAgLTU0MiwyMCArNTY4 LDM1IEBACiBvcmlnaW5fZnJvbV9wZGIgKCkgewogCWxvY2FsIG8KIAotCW89YGdyZXAgLW0xICdA Y29tbWVudCBPUklHSU46JyAkcGRiLyQxLytDT05URU5UUyAyPi9kZXYvbnVsbGAgJiYgewotCQll Y2hvICR7byNAY29tbWVudCBPUklHSU46fTsgcmV0dXJuIDA7IH0KKwlpZiBbIC16ICIkdXNlX3Br Z25nIiBdOyB0aGVuCisJCW89YGdyZXAgLW0xICdAY29tbWVudCBPUklHSU46JyAkcGRiLyQxLytD T05URU5UUyAyPi9kZXYvbnVsbGAgJiYgeworCQkJZWNobyAke28jQGNvbW1lbnQgT1JJR0lOOn07 IHJldHVybiAwOyB9CisJZWxzZQorCQlwa2cgaW5mbyAtcW8gJDEgMj4vZGV2L251bGwgJiYgcmV0 dXJuIDAKKwlmaQogCiAJY2FzZSAiJDEiIGluIGJzZHBhbi0qKSByZXR1cm4gMyA7OyBlc2FjCiAK LQlpZiBbIC1lICIkcGRiLyQxLytJR05PUkVNRSIgXTsgdGhlbgorCWlmIFsgLWUgIiRwZGIvJDEv K0lHTk9SRU1FIiBdICYmICggWyAteiAiJHVzZV9wa2duZyIgXSB8fCBwa2cgaW5mbyAtZSAkMSAp OyB0aGVuCiAJCWlmIFsgLW4gIiRQTV9WRVJCT1NFIiAtbyAtbiAiJExJU1RfT1JJR0lOUyIgXTsg dGhlbgotCQkJZWNobyAiCT09PT4+PiBObyBPUklHSU4gaW4gJHBkYi8kMS8rQ09OVEVOVFMiID4m MgorCQkJaWYgWyAteiAiJHVzZV9wa2duZyIgXTsgdGhlbgorCQkJCWVjaG8gIgk9PT0+Pj4gTm8g T1JJR0lOIGluICRwZGIvJDEvK0NPTlRFTlRTIiA+JjIKKwkJCWVsc2UKKwkJCQkjIEFuIGVycm9y IGFib3ZlIGRvZXNuJ3QgbmVjZXNzYXJpbHkgbWVhbiB0aGVyZSdzCisJCQkJIyBhIHByb2JsZW0g aW4gK01BTklGRVNULCBzbyBkb24ndCBtZW50aW9uIGl0CisJCQkJZWNobyAiCT09PT4+PiBObyBv cmlnaW4gYXZhaWxhYmxlIGZvciAkMSIgPiYyCisJCQlmaQogCQkJZWNobyAiCT09PT4+PiAkcGRi LyQxLytJR05PUkVNRSBleGlzdHMiID4mMgogCQkJZWNobyAnJyA+JjIKIAkJZmkKIAkJcmV0dXJu IDIKIAllbHNlCi0JCWVjaG8gIgk9PT0+Pj4gTm8gT1JJR0lOIGluICRwZGIvJDEvK0NPTlRFTlRT IiA+JjIKKwkJaWYgWyAteiAiJHVzZV9wa2duZyIgXTsgdGhlbgorCQkJZWNobyAiCT09PT4+PiBO byBPUklHSU4gaW4gJHBkYi8kMS8rQ09OVEVOVFMiID4mMgorCQllbHNlCisJCQkjIFNhbWUgYXMg YWJvdmUKKwkJCWVjaG8gIgk9PT0+Pj4gTm8gb3JpZ2luIGF2YWlsYWJsZSBmb3IgJDEiID4mMgor CQlmaQogCQllY2hvICcnID4mMgogCWZpCiAJcmV0dXJuIDEKQEAgLTY5NywxMiArNzM4LDE3IEBA CiAJbykJUkVQTEFDRV9PUklHSU49b29wdCA7OwogCXApCWZhaWwgJ1RoZSAtcCBvcHRpb24gaGFz IGJlZW4gZGVwcmVjYXRlZCcgOzsKIAlyKQlQTV9VUkI9cm9wdAotCQlpZiBbIC1kICIkcGRiLyRP UFRBUkciIF07IHRoZW4KKwkJaWYgWyAtZCAiJHBkYi8kT1BUQVJHIiBdICYmICggWyAteiAiJHVz ZV9wa2duZyIgXSB8fCBwa2cgaW5mbyAtZSAkT1BUQVJHICk7IHRoZW4KIAkJCWdsb2JfZGlycz0k T1BUQVJHCiAJCWVsc2UKKwkJCWNhc2UgIiRPUFRBUkciIGluICovKikgZmFpbCAnVGhlIGFyZ3Vt ZW50IHRvIC1yIG11c3QgYmUgYSBwYWNrYWdlIG5hbWUsIG9yIGEgZ2xvYiBwYXR0ZXJuJyA7OyBl c2FjCiAJCQlmaW5kX2dsb2JfZGlycyAkT1BUQVJHCiAJCQljYXNlICQ/IGluCi0JCQkxKQlmYWls ICIkcGRiLyRPUFRBUkcgZG9lcyBub3QgZXhpc3QiIDs7CisJCQkxKQlpZiBbIC16ICIkdXNlX3Br Z25nIiBdOyB0aGVuCisJCQkJCWZhaWwgIiRwZGIvJE9QVEFSRyBkb2VzIG5vdCBleGlzdCIKKwkJ CQllbHNlCisJCQkJCWZhaWwgIiRPUFRBUkcgaXMgbm90IGluc3RhbGxlZCIKKwkJCQlmaSA7Owog CQkJMikJZmFpbCAnVGhlIGFyZ3VtZW50IHRvIC1yIG11c3QgbWF0Y2ggb25seSBvbmUgcG9ydCcg OzsKIAkJCWVzYWMKIAkJZmkKQEAgLTc4NCw2ICs4MzAsMTIgQEAKIAkgICAgZmFpbCAnVGhlIC1b YXJdIG9wdGlvbnMgYXJlIG5vdCBjb21wYXRpYmxlIHdpdGggb3RoZXIgdXBkYXRlcycKIAogCWlm IFsgLW4gIiRQTV9QQUNLQUdFUyIgLW8gLW4gIiRQTV9QQUNLQUdFU19CVUlMRCIgXTsgdGhlbgor CQlpZiBbIC1uICIkdXNlX3BrZ25nIiBdOyB0aGVuCisJCQl1bnNldCBQTV9QQUNLQUdFUyBQTV9Q QUNLQUdFU19CVUlMRCBQTV9QQUNLQUdFU19MT0NBTCBQTV9QQUNLQUdFU19ORVdFUiBQTV9BTFdB WVNfRkVUQ0ggUE1fREVMRVRFX1BBQ0tBR0VTCisJCQllY2hvICI9PT0+Pj4gUGFja2FnZSBpbnN0 YWxsYXRpb24gc3VwcG9ydCBjYW5ub3QgYmUgdXNlZCB3aXRoIHBrZ25nIHlldCwiCisJCQllY2hv ICIgICAgICAgaXQgd2lsbCBiZSBkaXNhYmxlZCIKKwkJCWVjaG8gJycKKwkJZmkKIAkJWyBgL3Ni aW4vc3lzY3RsIC1uIGtlcm4ub3NyZWxkYXRlIDI+L2Rldi9udWxsYCAtbHQgNjAwNDAwIF0gJiYK IAkJCWZhaWwgUGFja2FnZSBpbnN0YWxsYXRpb24gc3VwcG9ydCByZXF1aXJlcyBGcmVlQlNEIDYu NCBvciBuZXdlcgogCWZpCkBAIC04NTAsNyArOTAyLDEyIEBACiAJCWZpCiAJCXVuc2V0IElOREVY RklMRSBJTkRFWERJUgogCi0JCVBNX0lOREVYX1BPUlRTPWBwa2dfdmVyc2lvbiAtSXZsXDwgJFBN X0lOREVYIHwgY3V0IC1mMSAtZFw8YAorCQlpZiBbIC16ICIkdXNlX3BrZ25nIiBdOyB0aGVuCisJ CQlwa2dfdmVyc2lvbj0icGtnX3ZlcnNpb24iCisJCWVsc2UKKwkJCXBrZ192ZXJzaW9uPSJwa2cg dmVyc2lvbiIKKwkJZmkKKwkJUE1fSU5ERVhfUE9SVFM9YCRwa2dfdmVyc2lvbiAtSXZsXDwgJFBN X0lOREVYIHwgY3V0IC1mMSAtZFw8YAogCQlleHBvcnQgUE1fSU5ERVhfUE9SVFMKIAogCQlpZiBb IC16ICIkcGQiIC1vICIkcGQiICE9IC91c3IvcG9ydHMgXTsgdGhlbgpAQCAtOTA3LDYgKzk2NCwx MCBAQAogaXBvcnRfZnJvbV9vcmlnaW4gKCkgewogCWxvY2FsIHNuIGRpcgogCisJaWYgWyAtbiAi JHVzZV9wa2duZyIgXTsgdGhlbgorCQlwa2cgaW5mbyAtcU8gJHsxfSB8fCByZXR1cm4gMQorCQly ZXR1cm4KKwlmaQogCXNuPSR7MSMqL30gOyBzbj0ke3NuJS0qfSA7IHNuPSR7c24lJVswLTldKn0K IAogCWlmICEgZGlyPWBncmVwIC1sICJAY29tbWVudCBPUklHSU46JHsxfSQiICRwZGIvJHtzbn0q LytDT05URU5UUyAyPi9kZXYvbnVsbGA7IHRoZW4KQEAgLTkzNSw3ICs5OTYsOSBAQAogCWRvbmUK IH0KIAorIyBSZWR1bmRhbnQgd2l0aCBwa2duZwogY2hlY2tfZGVwZW5kZW5jeV9maWxlcyAoKSB7 CisJWyAtbiAiJHVzZV9wa2duZyIgXSAmJiByZXR1cm4KIAkjIEdsb2JhbDogZ3JlcF9kZXBzCiAJ bG9jYWwgb3JpZ2luIGlwb3J0IHJvX29wZAogCkBAIC0xMDE3LDcgKzEwODAsOSBAQAogCWZpCiB9 CiAKKyMgcmVkdW5kYW50IHdpdGggcGtnbmcKIHVwZGF0ZV9jb250ZW50cyAoKSB7CisJWyAtbiAi JHVzZV9wa2duZyIgXSAmJiByZXR1cm4KIAlsb2NhbCBJRlMgZGVsZXRlIGNvbnRlbnRzIG9yaWdp biBuX3BvcnQgb2xkX29yaWdpbiBpcG9ydAogCWxvY2FsIG9fc2VlbiBsaW5lIGRfbWlzc2luZyBk X29yaWdpbiBkX2lwb3J0IHByZXZfbGluZSBhbnN3ZXIKIApAQCAtMTExNyw3ICsxMTgyLDcgQEAK IAlmb3IgbCBpbiBgZ3JlcCAiXiRzZnwiICRwZC9NT1ZFRGA7IGRvCiAJCWNhc2UgIiRsIiBpbgog CQkke3NmfVx8XHwqKSBbIC1uICIkaXBvcnQiIF0gfHwgaXBvcnQ9YGlwb3J0X2Zyb21fb3JpZ2lu ICRzZmAKLQkJCWlmIFsgLWUgIiRwZGIvJGlwb3J0LytJR05PUkVNRSIgXTsgdGhlbgorCQkJaWYg WyAtZSAiJHBkYi8kaXBvcnQvK0lHTk9SRU1FIiBdICYmICggWyAteiAiJHVzZV9wa2duZyIgXSB8 fCBwa2cgaW5mbyAtZSAkaXBvcnQgKTsgdGhlbgogCQkJCWlmIFsgLW4gIiRQTV9WRVJCT1NFIiBd OyB0aGVuCiAJCQkJCWVjaG8gJycKIAkJCQkJZWNobyAiCT09PT4+PiBUaGUgJHNmIHBvcnQgaGFz IGJlZW4gZGVsZXRlZCIKQEAgLTExNTIsMjQgKzEyMTcsMzYgQEAKIAkJZWNobyAnJwogCiAJCVsg LW4gIiRpcG9ydCIgXSB8fCBpcG9ydD1gaXBvcnRfZnJvbV9vcmlnaW4gJHNmYAotCQlbIC1lICIk cGRiLyRpcG9ydC8rSUdOT1JFTUUiIF0gfHwgcmV0dXJuIDEKKwkJWyAtZSAiJHBkYi8kaXBvcnQv K0lHTk9SRU1FIiBdICYmICggWyAteiAiJHVzZV9wa2duZyIgXSB8fCBwa2cgaW5mbyAtZSAkaXBv cnQgKSB8fCByZXR1cm4gMQogCWZpCiAJcmV0dXJuIDAKIH0KIAorYWxsX3BrZ3NfYnlfb3JpZ2lu ICgpIHsKKwlpZiBbIC16ICIkdXNlX3BrZ25nIiBdOyB0aGVuCisJCWxvY2FsIHBrZyBpcG9ydCBv cmlnaW4KKworCQlmb3IgcGtnIGluICR7cGRifS8qIDsgZG8KKwkJCVsgLWQgJHBrZyBdIHx8IGNv bnRpbnVlCisJCQlpcG9ydD0ke3BrZyMkcGRiL30KKworCQkJb3JpZ2luPWBvcmlnaW5fZnJvbV9w ZGIgJGlwb3J0YCB8fCBjb250aW51ZQorCQkJZWNobyAkaXBvcnQgJG9yaWdpbgorCQlkb25lCisJ ZWxzZQorCQlwa2cgcXVlcnkgLWEgIiVuLSV2ICVvIgorCWZpCisJcmV0dXJuCit9CisKIHJlYWRf ZGlzdGluZm9zICgpIHsKLQlsb2NhbCBwa2cgaXBvcnQgb3JpZ2luIGRpc3RpbmZvIHMgZiBkaXNj YXJkCisJbG9jYWwgaXBvcnQgb3JpZ2luIGRpc3RpbmZvIHMgZiBkaXNjYXJkCiAKIAllY2hvICcj IyMjIyMjIyMjIyMnID4gJERJX0ZJTEVTCQkjIE1ha2UgdGhlIGZpbGUgPiAwIGJ5dGVzCiAJZWNo byAiPT09Pj4+IEdhdGhlcmluZyBkaXN0aW5mbyBsaXN0IGZvciBpbnN0YWxsZWQgcG9ydHMiCiAJ ZWNobyAnJwogCi0JZm9yIHBrZyBpbiAke3BkYn0vKjsgZG8KLQkJWyAtZCAkcGtnIF0gfHwgY29u dGludWUKLQkJaXBvcnQ9JHtwa2cjJHBkYi99Ci0KLQkJb3JpZ2luPWBvcmlnaW5fZnJvbV9wZGIg JGlwb3J0YCB8fCBjb250aW51ZQotCisJYWxsX3BrZ3NfYnlfb3JpZ2luIHwgd2hpbGUgcmVhZCBp cG9ydCBvcmlnaW47IGRvCiAJCWlmIFsgISAtZCAiJHBkLyRvcmlnaW4iIF07IHRoZW4KIAkJCWZp bmRfbW92ZWRfcG9ydCAkb3JpZ2luICRpcG9ydCBub25mYXRhbCA+L2Rldi9udWxsCiAJCQlbIC1u ICIkbW92ZWRfbnBkIiBdIHx8IGNvbnRpbnVlCkBAIC0xMjQ1LDI5ICsxMzIyLDQzIEBACiAKIAlw bV92ICI9PT0+Pj4gU29ydGluZyBwb3J0cyBieSBjYXRlZ29yeSIKIAotCW51bV9yb290cz0wOyBu dW1fdHJ1bmtzPTA7IG51bV9icmFuY2hlcz0wOyBudW1fbGVhdmVzPTAKLQlmb3IgcGtnIGluICRw ZGIvKjsgZG8KLQkJaWYgWyAtcyAiJHBrZy8rUkVRVUlSRURfQlkiIF07IHRoZW4KLQkJCWlmIGdy ZXAgLXFsICdeQHBrZ2RlcCAnICRwa2cvK0NPTlRFTlRTIDI+L2Rldi9udWxsOyB0aGVuCi0JCQkJ YnJhbmNoZXM9IiRicmFuY2hlcyAke3BrZyMkcGRiL30iCi0JCQkJbnVtX2JyYW5jaGVzPSQoKCAk bnVtX2JyYW5jaGVzICsgMSApKQotCQkJZWxzZQotCQkJCXRydW5rcz0iJHRydW5rcyAke3BrZyMk cGRiL30iCi0JCQkJbnVtX3RydW5rcz0kKCggJG51bV90cnVua3MgKyAxICkpCi0JCQlmaQotCQll bHNlCi0JCQlpZiBncmVwIC1xbCAnXkBwa2dkZXAgJyAkcGtnLytDT05URU5UUyAyPi9kZXYvbnVs bDsgdGhlbgotCQkJCWxlYXZlcz0iJGxlYXZlcyAke3BrZyMkcGRiL30iCi0JCQkJbnVtX2xlYXZl cz0kKCggJG51bV9sZWF2ZXMgKyAxICkpCisJaWYgWyAteiAiJHVzZV9wa2duZyIgXTsgdGhlbgor CQludW1fcm9vdHM9MDsgbnVtX3RydW5rcz0wOyBudW1fYnJhbmNoZXM9MDsgbnVtX2xlYXZlcz0w CisJCWZvciBwa2cgaW4gJHBkYi8qOyBkbworCQkJaWYgWyAtcyAiJHBrZy8rUkVRVUlSRURfQlki IF07IHRoZW4KKwkJCQlpZiBncmVwIC1xbCAnXkBwa2dkZXAgJyAkcGtnLytDT05URU5UUyAyPi9k ZXYvbnVsbDsgdGhlbgorCQkJCQlicmFuY2hlcz0iJGJyYW5jaGVzICR7cGtnIyRwZGIvfSIKKwkJ CQkJbnVtX2JyYW5jaGVzPSQoKCAkbnVtX2JyYW5jaGVzICsgMSApKQorCQkJCWVsc2UKKwkJCQkJ dHJ1bmtzPSIkdHJ1bmtzICR7cGtnIyRwZGIvfSIKKwkJCQkJbnVtX3RydW5rcz0kKCggJG51bV90 cnVua3MgKyAxICkpCisJCQkJZmkKIAkJCWVsc2UKLQkJCQlbIC1kICIkcGtnIiBdIHx8IGNvbnRp bnVlCi0JCQkJcm9vdHM9IiRyb290cyAke3BrZyMkcGRiL30iCi0JCQkJbnVtX3Jvb3RzPSQoKCAk bnVtX3Jvb3RzICsgMSApKQorCQkJCWlmIGdyZXAgLXFsICdeQHBrZ2RlcCAnICRwa2cvK0NPTlRF TlRTIDI+L2Rldi9udWxsOyB0aGVuCisJCQkJCWxlYXZlcz0iJGxlYXZlcyAke3BrZyMkcGRiL30i CisJCQkJCW51bV9sZWF2ZXM9JCgoICRudW1fbGVhdmVzICsgMSApKQorCQkJCWVsc2UKKwkJCQkJ WyAtZCAiJHBrZyIgXSB8fCBjb250aW51ZQorCQkJCQlyb290cz0iJHJvb3RzICR7cGtnIyRwZGIv fSIKKwkJCQkJbnVtX3Jvb3RzPSQoKCAkbnVtX3Jvb3RzICsgMSApKQorCQkJCWZpCiAJCQlmaQot CQlmaQotCWRvbmUKKwkJZG9uZQogCi0JbnVtX3BvcnRzPSQoKCAkbnVtX3Jvb3RzICsgJG51bV90 cnVua3MgKyAkbnVtX2JyYW5jaGVzICsgJG51bV9sZWF2ZXMgKSkKKwkJbnVtX3BvcnRzPSQoKCAk bnVtX3Jvb3RzICsgJG51bV90cnVua3MgKyAkbnVtX2JyYW5jaGVzICsgJG51bV9sZWF2ZXMgKSkK KwllbHNlCisJCXJvb3RzPWAgICBwa2cgcXVlcnkgLWUgIiUjZCA9IDAgJiYgJSNyID0gMCIgIiVu LSV2ImAKKwkJdHJ1bmtzPWAgIHBrZyBxdWVyeSAtZSAiJSNkID0gMCAmJiAlI3IgPiAwIiAiJW4t JXYiYAorCQlicmFuY2hlcz1gcGtnIHF1ZXJ5IC1lICIlI2QgPiAwICYmICUjciA+IDAiICIlbi0l diJgCisJCWxlYXZlcz1gICBwa2cgcXVlcnkgLWUgIiUjZCA+IDAgJiYgJSNyID0gMCIgIiVuLSV2 ImAKKworCQludW1fcm9vdHM9JChlY2hvICAgICQoZWNobyAkcm9vdHMgICAgfCB3YyAtdykpCisJ CW51bV90cnVua3M9JChlY2hvICAgJChlY2hvICR0cnVua3MgICB8IHdjIC13KSkKKwkJbnVtX2Jy YW5jaGVzPSQoZWNobyAkKGVjaG8gJGJyYW5jaGVzIHwgd2MgLXcpKQorCQludW1fbGVhdmVzPSQo ZWNobyAgICQoZWNobyAkbGVhdmVzICAgfCB3YyAtdykpCisKKwkJbnVtX3BvcnRzPSQoZWNobyAk KHBrZyBxdWVyeSAtYSAiJW4tJXYiIHwgd2MgLXcpKQorCWZpCiB9CiAKIGRlbGV0ZV9lbXB0eV9k aXN0X3N1YmRpcnMgKCkgewpAQCAtMTMxNSw3ICsxNDA2LDkgQEAKIAllc2FjCiB9CiAKKyMgUmVk dW5kYW50IHdpdGggcGtnbmcKIHVwZGF0ZV9yZXF1aXJlZF9ieSAoKSB7CisJWyAtbiAiJHVzZV9w a2duZyIgXSAmJiAvYmluL3VubGluayAkZ3JlcF9kZXBzICYmIHVuc2V0IGdyZXBfZGVwcyAmJiBy ZXR1cm4KIAkjIEdsb2JhbDogbmVlZHdzCiAJbG9jYWwgZG9fdXBkYXRlCiAKQEAgLTEzMjUsNyAr MTQxOCw3IEBACiAJZWxzZQogCQlkb191cGRhdGU9ZG9fdXBkYXRlMgogCWZpCi0JaWYgWyAtbiAi JGRvX3VwZGF0ZSIgXTsgdGhlbgorIAlpZiBbIC1uICIkZG9fdXBkYXRlIiBdOyB0aGVuCiAJCXBt X3YgIgk9PT0+Pj4gVXBkYXRpbmcgJDEvK1JFUVVJUkVEX0JZIgogCQluZWVkd3M9bmVlZHdzX3Vy YgogCQlwbV9pbnN0YWxsX3MgJGdyZXBfZGVwcyAkcGRiLyQxLytSRVFVSVJFRF9CWQpAQCAtMTM3 MSwxMSArMTQ2NCwxNSBAQAogCiAJZWNobyAiPT09Pj4+IENoZWNraW5nIGZvciBzdGFsZSBwYWNr YWdlcyIKIAlmb3IgcGFja2FnZSBpbiBgZmluZCAkUEFDS0FHRVMgLXR5cGUgZiB8IHNvcnRgOyBk bwotCQlwa2dfZGlyPSR7cGFja2FnZSMjKi99IDsgcGtnX2Rpcj0ke3BrZ19kaXIlXC50Ynp9IDsg ZWNobyAnJworCQlwa2dfZGlyPSR7cGFja2FnZSMjKi99IDsgcGtnX2Rpcj0ke3BrZ19kaXIlXC4q fSA7IGVjaG8gJycKIAotCQlvcmlnaW49YHRhciAtTyAtenh2ZiAkcGFja2FnZSAnK0NPTlRFTlRT JyAyPi9kZXYvbnVsbCB8IGdyZXAgJ0Bjb21tZW50IE9SSUdJTjonYCB8fAotCQkJZmFpbCBFbXB0 eSBvcmlnaW4gaW4gJHBhY2thZ2UKKwkJWyAtbiAiJHVzZV9wa2duZyIgXSAmJgorCQkJb3JpZ2lu PWBwa2cgcXVlcnkgLUYgJHBhY2thZ2UgIiVvIiAyPi9kZXYvbnVsbGAgfHwKKwkJCW9yaWdpbj1g dGFyIC1PIC16eHZmICRwYWNrYWdlICcrQ09OVEVOVFMnIDI+L2Rldi9udWxsIHwgZ3JlcCAnQGNv bW1lbnQgT1JJR0lOOidgIHx8CisJCQlvcmlnaW49YHRhciAtTyAtenh2ZiAkcGFja2FnZSAnK01B TklGRVNUJyAyPi9kZXYvbnVsbCB8IGdyZXAgJ15vcmlnaW46J2AgfHwKKwkJCWZhaWwgIkVtcHR5 IG9yaWdpbiBpbiAkcGFja2FnZSIKIAkJb3JpZ2luPSR7b3JpZ2luI0Bjb21tZW50IE9SSUdJTjp9 CisJCW9yaWdpbj0ke29yaWdpbiNvcmlnaW46IH0KIAogCQlpZiBbIC16ICIkUE1fSU5ERVgiIF07 IHRoZW4KIAkJCWlmIFsgLWQgIiRwZC8kb3JpZ2luIiBdOyB0aGVuCkBAIC0xMzkxLDE2ICsxNDg4 LDI4IEBACiAJCWZpCiAKIAkJaWYgWyAtbiAiJHBvcnRfdmVyIiBdOyB0aGVuCi0JCQlpZiBbICIk e3BvcnRfdmVyfS50YnoiID0gIiR7cGFja2FnZSMjKi99IiBdOyB0aGVuCisJCQlpZiBbICIkcG9y dF92ZXIiID0gIiRwa2dfZGlyIiBdOyB0aGVuCiAJCQkJZWNobyAiPT09Pj4+ICR7cGFja2FnZSMj Ki99IGlzIHVwIHRvIGRhdGUiCi0JCQkJaWYgWyAhIC1kICIke3BkYn0vJHtwa2dfZGlyfSIgXTsg dGhlbgotCQkJCQllY2hvICIJPT09Pj4+ICRwa2dfZGlyIGlzIG5vdCBpbnN0YWxsZWQiCi0JCQkJ CWVjaG8gIgk9PT0+Pj4gUGF0aDogJHtwYWNrYWdlfSIKLQkJCQkJZ2V0X2Fuc3dlcl95biB5ICJc blx0PT09Pj4+IERlbGV0ZSBzdGFsZSBwYWNrYWdlOiAke3BhY2thZ2UjIyovfSIKLQkJCQkJY2Fz ZSAiJD8iIGluCi0JCQkJCTApCWVjaG8gIgk9PT0+Pj4gRGVsZXRpbmcgJHBhY2thZ2UiCi0JCQkJ CQlwbV91bmxpbmtfcyAkcGFja2FnZSA7OwotCQkJCQllc2FjCisJCQkJaWYgWyAteiAiJHVzZV9w a2duZyIgXTsgdGhlbgorCQkJCQlpZiBbICEgLWQgIiR7cGRifS8ke3BrZ19kaXJ9IiBdOyB0aGVu CisJCQkJCQllY2hvICIJPT09Pj4+ICRwa2dfZGlyIGlzIG5vdCBpbnN0YWxsZWQiCisJCQkJCQll Y2hvICIJPT09Pj4+IFBhdGg6ICR7cGFja2FnZX0iCisJCQkJCQlnZXRfYW5zd2VyX3luIHkgIlxu XHQ9PT0+Pj4gRGVsZXRlIHN0YWxlIHBhY2thZ2U6ICR7cGFja2FnZSMjKi99IgorCQkJCQkJY2Fz ZSAiJD8iIGluCisJCQkJCQkwKQllY2hvICIJPT09Pj4+IERlbGV0aW5nICRwYWNrYWdlIgorCQkJ CQkJCXBtX3VubGlua19zICRwYWNrYWdlIDs7CisJCQkJCQllc2FjCisJCQkJCWZpCisJCQkJZWxz ZQorCQkJCQlpZiAhIHBrZyBpbmZvIC1lICRwa2dfZGlyOyB0aGVuCisJCQkJCQllY2hvICIJPT09 Pj4+ICRwa2dfZGlyIGlzIG5vdCBpbnN0YWxsZWQiCisJCQkJCQllY2hvICIJPT09Pj4+IFBhdGg6 ICR7cGFja2FnZX0iCisJCQkJCQlnZXRfYW5zd2VyX3luIHkgIlxuXHQ9PT0+Pj4gRGVsZXRlIHN0 YWxlIHBhY2thZ2U6ICR7cGFja2FnZSMjKi99IgorCQkJCQkJY2FzZSAiJD8iIGluCisJCQkJCQkw KQllY2hvICIJPT09Pj4+IERlbGV0aW5nICRwYWNrYWdlIgorCQkJCQkJCXBtX3VubGlua19zICRw YWNrYWdlIDs7CisJCQkJCQllc2FjCisJCQkJCWZpCiAJCQkJZmkKIAkJCQl1bnNldCBwb3J0X3Zl cgogCQkJCWNvbnRpbnVlCkBAIC0xNDExLDEwICsxNTIwLDE4IEBACiAKIAkJCXVuc2V0IHBvcnRf dmVyCiAKLQkJCWlmIFsgLWQgIiR7cGRifS8ke3BrZ19kaXJ9IiBdOyB0aGVuCi0JCQkJZWNobyAi CT09PT4+PiAke3BhY2thZ2UjIyovfSBtYXRjaGVzIHRoZSBpbnN0YWxsZWQgdmVyc2lvbiIKKwkJ CWlmIFsgLXogIiR1c2VfcGtnbmciIF07IHRoZW4KKwkJCQlpZiBbIC1kICIke3BkYn0vJHtwa2df ZGlyfSIgXTsgdGhlbgorCQkJCQllY2hvICIJPT09Pj4+ICR7cGFja2FnZSMjKi99IG1hdGNoZXMg dGhlIGluc3RhbGxlZCB2ZXJzaW9uIgorCQkJCWVsc2UKKwkJCQkJZWNobyAiCT09PT4+PiAke3Bh Y2thZ2UjIyovfSBpcyBub3QgaW5zdGFsbGVkIgorCQkJCWZpCiAJCQllbHNlCi0JCQkJZWNobyAi CT09PT4+PiAke3BhY2thZ2UjIyovfSBpcyBub3QgaW5zdGFsbGVkIgorCQkJCWlmIHBrZyBpbmZv IC1lICRwa2dfZGlyOyB0aGVuCisJCQkJCWVjaG8gIgk9PT0+Pj4gJHtwYWNrYWdlIyMqL30gbWF0 Y2hlcyB0aGUgaW5zdGFsbGVkIHZlcnNpb24iCisJCQkJZWxzZQorCQkJCQllY2hvICIJPT09Pj4+ ICR7cGFja2FnZSMjKi99IGlzIG5vdCBpbnN0YWxsZWQiCisJCQkJZmkKIAkJCWZpCiAJCWZpCiAK QEAgLTE0NTMsNiArMTU3MCwxMCBAQAogZmkJIyBbIC1uICIkQ0xFQU5fUEFDS0FHRVMiIF0KIAog aWYgWyAtbiAiJENIRUNLX0RFUEVORFMiIF07IHRoZW4KKwlpZiBbIC1uICIkdXNlX3BrZ25nIiBd OyB0aGVuCisJCXBrZyBjaGVjayAtYWR2CisJCWV4aXQKKwlmaQogCVBNX1ZFUkJPU0U9cG12X2No ZWNrX2RlcGVuZHMKIElGUz0nCiAnCkBAIC0xNDk5LDI0ICsxNjIwLDQyIEBACiAJdW5pcXVlX2xp c3Q9JzonCiAKIAllY2hvICI9PT0+Pj4gQnVpbGRpbmcgbGlzdCBvZiBpbnN0YWxsZWQgcG9ydCBu YW1lcyI7IGVjaG8gJycKLQlmb3IgcGtnIGluICRwZGIvKjsgZG8KLQkJWyAtZCAkcGtnIF0gfHwg Y29udGludWUKKwlpZiBbIC16ICIkdXNlX3BrZ25nIiBdOyB0aGVuCisJCWZvciBwa2cgaW4gJHBk Yi8qOyBkbworCQkJWyAtZCAkcGtnIF0gfHwgY29udGludWUKIAotCQlpcG9ydD0ke3BrZyMkcGRi L30KLQkJb3JpZ2luPWBvcmlnaW5fZnJvbV9wZGIgJGlwb3J0YCB8fCBjb250aW51ZQorCQkJaXBv cnQ9JHtwa2cjJHBkYi99CisJCQlvcmlnaW49YG9yaWdpbl9mcm9tX3BkYiAkaXBvcnRgIHx8IGNv bnRpbnVlCiAKLQkJaWYgWyAhIC1kICIkcGQvJG9yaWdpbiIgXTsgdGhlbgotCQkJZmluZF9tb3Zl ZF9wb3J0ICRvcmlnaW4gJGlwb3J0IG5vbmZhdGFsID4vZGV2L251bGwKLQkJCVsgLW4gIiRtb3Zl ZF9ucGQiIF0gfHwgY29udGludWUKLQkJCW9yaWdpbj0kbW92ZWRfbnBkCi0JCWZpCisJCQlpZiBb ICEgLWQgIiRwZC8kb3JpZ2luIiBdOyB0aGVuCisJCQkJZmluZF9tb3ZlZF9wb3J0ICRvcmlnaW4g JGlwb3J0IG5vbmZhdGFsID4vZGV2L251bGwKKwkJCQlbIC1uICIkbW92ZWRfbnBkIiBdIHx8IGNv bnRpbnVlCisJCQkJb3JpZ2luPSRtb3ZlZF9ucGQKKwkJCWZpCiAKLQkJaWYgISBwbV9jZCAkcGQv JG9yaWdpbjsgdGhlbgotCQkJZWNobyAiCT09PT4+PiAkcGQvJG9yaWdpbiBkb2VzIG5vdCBleGlz dCBmb3IgJHBrZyIKLQkJCWNvbnRpbnVlCi0JCWZpCi0JCXVuaXF1ZV9saXN0PSIke3VuaXF1ZV9s aXN0fWBtYWtlIC1WIFVOSVFVRU5BTUVgOiIKLQlkb25lCisJCQlpZiAhIHBtX2NkICRwZC8kb3Jp Z2luOyB0aGVuCisJCQkJZWNobyAiCT09PT4+PiAkcGQvJG9yaWdpbiBkb2VzIG5vdCBleGlzdCBm b3IgJHBrZyIKKwkJCQljb250aW51ZQorCQkJZmkKKwkJCXVuaXF1ZV9saXN0PSIke3VuaXF1ZV9s aXN0fWBtYWtlIC1WIFVOSVFVRU5BTUVgOiIKKwkJZG9uZQorCWVsc2UKKwkJd2hpbGUgcmVhZCBw a2cgb3JpZ2luOyBkbworCQkJaWYgWyAhIC1kICIkcGQvJG9yaWdpbiIgXTsgdGhlbgorCQkJCWZp bmRfbW92ZWRfcG9ydCAkb3JpZ2luICRwa2cgbm9uZmF0YWwgPi9kZXYvbnVsbAorCQkJCVsgLW4g IiRtb3ZlZF9ucGQiIF0gfHwgY29udGludWUKKwkJCQlvcmlnaW49JG1vdmVkX25wZAorCQkJZmkK KworCQkJaWYgISBwbV9jZCAkcGQvJG9yaWdpbjsgdGhlbgorCQkJCWVjaG8gIgk9PT0+Pj4gJHBk LyRvcmlnaW4gZG9lcyBub3QgZXhpc3QgZm9yICRwa2ciCisJCQkJY29udGludWUKKwkJCWZpCisJ CQl1bmlxdWVfbGlzdD0iJHt1bmlxdWVfbGlzdH1gbWFrZSAtViBVTklRVUVOQU1FYDoiCisJCWRv bmUgPDwgRU9GCitgcGtnIHF1ZXJ5IC1hICIlbi0ldiAlbyJgCitFT0YKKwlmaQogCiAJZWNobyAi PT09Pj4+IENoZWNraW5nICRwb3J0X2RiZGlyIgogCkBAIC0xNjE3LDcgKzE3NTYsNyBAQAogCiAJ aWYgWyAteiAiJGRvX3VwZGF0ZSIgLWEgLXogIiRza2lwIiAtYSAteiAiJFBNX0lOREVYX09OTFki IF0gJiYgWyAtZCAiJHBkLyRvcmlnaW4iIF07IHRoZW4KIAkJaWYgISBwbV9jZCAkcGQvJG9yaWdp bjsgdGhlbgotCQkJaWYgWyAtZSAiJHBkYi8kaXBvcnQvK0lHTk9SRU1FIiBdOyB0aGVuCisJCQlp ZiBbIC1lICIkcGRiLyRpcG9ydC8rSUdOT1JFTUUiIF0gJiYgKCBbIC16ICIkdXNlX3BrZ25nIiBd IHx8IHBrZyBpbmZvIC1lICRpcG9ydCApOyB0aGVuCiAJCQkJZWNobyAiCT09PT4+PiBXYXJuaW5n OiBVbmFibGUgdG8gY2QgdG8gJHBkLyRvcmlnaW4iCiAJCQkJZWNobyAiCT09PT4+PiBDb250aW51 aW5nIGR1ZSB0byAkcGRiLyRpcG9ydC8rSUdOT1JFTUUiCiAJCQkJZWNobyAnJwpAQCAtMTYzNCwx MyArMTc3MywxMyBAQAogCiAJCSMgSWYgdGhlIHBvcnQgaGFzIG1vdmVkIGFuZCBubyArSUdOT1JF TUUsIHdlIGhhdmUgdG8gdXBkYXRlIGl0CiAJCWlmIFsgLW4gIiRtb3ZlZF9ucGQiIF07IHRoZW4K LQkJCWlmIFsgISAtZSAiJHBkYi8kaXBvcnQvK0lHTk9SRU1FIiBdOyB0aGVuCi0JCQkJZG9fdXBk YXRlPWRvX3VwZGF0ZV9tb3ZlZAotCQkJZWxzZQorCQkJaWYgWyAtZSAiJHBkYi8kaXBvcnQvK0lH Tk9SRU1FIiBdICYmICggWyAteiAiJHVzZV9wa2duZyIgXSB8fCBwa2cgaW5mbyAtZSAkaXBvcnQg KTsgdGhlbgogCQkJCWVjaG8gIgk9PT0+Pj4gQ29udGludWluZyBkdWUgdG8gJHBkYi8kaXBvcnQv K0lHTk9SRU1FIgogCQkJCWVjaG8gJycKIAkJCQlDVVJfREVQUz0iJHtDVVJfREVQU30ke2lwb3J0 fToke29yaWdpbn06IgogCQkJCXJldHVybiAwCisJCQllbHNlCisJCQkJZG9fdXBkYXRlPWRvX3Vw ZGF0ZV9tb3ZlZAogCQkJZmkKIAkJZmkKIAlmaQpAQCAtMTY1NywxNCArMTc5NiwyMCBAQAogCQkJ CXVuc2V0IHBvcnRfdmVyCiAJCQlmaQogCQllbHNlCi0JCQljYXNlIGBwa2dfdmVyc2lvbiAtdCAk aXBvcnQgJHBvcnRfdmVyYCBpbgorCQkJbG9jYWwgcGtnX3ZlcnNpb24KKwkJCWlmIFsgLXogIiR1 c2VfcGtnbmciIF07IHRoZW4KKwkJCQlwa2dfdmVyc2lvbj0icGtnX3ZlcnNpb24iCisJCQllbHNl CisJCQkJcGtnX3ZlcnNpb249InBrZyB2ZXJzaW9uIgorCQkJZmkKKwkJCWNhc2UgYCRwa2dfdmVy c2lvbiAtdCAkaXBvcnQgJHBvcnRfdmVyYCBpbgogCQkJXDwpCWRvX3VwZGF0ZT11cGRfbHQgOzsK IAkJCT0pCTs7CSMgQ2FuIGJlIHJlYWNoZWQgaWYgc2FtZSB2ZXJzaW9uIHdpdGggZGlmZmVyZW50 IG9wdGlvbnMKIAkJCVw+KQlpZiBbIC1uICIkUE1fVkVSQk9TRSIgXTsgdGhlbgogCQkJCQllY2hv ICIJPT09Pj4+IFBvcnQgdmVyc2lvbiAkcG9ydF92ZXIgZG9lcyBub3QiCiAJCQkJCWVjaG8gIgk9 PT0+Pj4gc2VlbSBuZXdlciB0aGFuIGluc3RhbGxlZCAkaXBvcnQiCiAJCQkJZmkgOzsKLQkJCSop CWZhaWwgInBrZ192ZXJzaW9uIC10ICRpcG9ydCAkcG9ydF92ZXIgZ2F2ZSBhbiB1bmV4cGVjdGVk IHJlc3VsdCIKKwkJCSopCWZhaWwgIiRwa2dfdmVyc2lvbiAtdCAkaXBvcnQgJHBvcnRfdmVyIGdh dmUgYW4gdW5leHBlY3RlZCByZXN1bHQiCiAJCQllc2FjCiAKIAkJCVsgLXogIiRkb191cGRhdGUi IF0gJiYgewpAQCAtMTY4MCw4ICsxODI1LDkgQEAKIAlpZiBbIC1uICIkTElTVF9QTFVTIiBdOyB0 aGVuCiAJCWlmIFsgLXogIiRtb3ZlZF9ucGQiIF07IHRoZW4KIAkJCWVjaG8gIgk9PT0+Pj4gTmV3 IHZlcnNpb24gYXZhaWxhYmxlOiAkcG9ydF92ZXIiCi0JCQlbIC1lICIkcGRiLyRpcG9ydC8rSUdO T1JFTUUiIF0gJiYKKwkJCWlmIFsgLWUgIiRwZGIvJGlwb3J0LytJR05PUkVNRSIgXSAmJiAoIFsg LXogIiR1c2VfcGtnbmciIF0gfHwgcGtnIGluZm8gLWUgJGlwb3J0ICk7IHRoZW4KIAkJCQllY2hv ICIJPT09Pj4+ICtJR05PUkVNRSBmaWxlIGlzIHByZXNlbnQgZm9yICQxIgorCQkJZmkKIAkJCXBt X2NkX3BkICRvcmlnaW4gJiYgY2hlY2tfc3RhdGUKIAkJCW51bV91cGRhdGVzPSQoKCAkbnVtX3Vw ZGF0ZXMgKyAxICkpCiAJCWVsc2UKQEAgLTE3MzYsNyArMTg4MiwxMyBAQAogCWZpCiAKIAlwbV9j ZCAkcGtnZGlyIHx8IGZhaWwgIkNhbm5vdCBjZCBpbnRvICRwa2dkaXIgdG8gY3JlYXRlIGEgcGFj a2FnZSIKLQlpZiAkUE1fU1VfQ01EIHBrZ19jcmVhdGUgLWIgJDI7IHRoZW4KKwlsb2NhbCBwa2df Y3JlYXRlCisJaWYgWyAteiAiJHVzZV9wa2duZyIgXTsgdGhlbgorCQlwa2dfY3JlYXRlPSJwa2df Y3JlYXRlIC1iIgorCWVsc2UKKwkJcGtnX2NyZWF0ZT0icGtnIGNyZWF0ZSAiCisJZmkKKwlpZiAk UE1fU1VfQ01EICRwa2dfY3JlYXRlICQyOyB0aGVuCiAJCWlmIFsgIiQxIiA9ICIkcGJ1IiBdOyB0 aGVuCiAJCQlpZiBbIC1uICIkQkFDS1VQIiBdOyB0aGVuCiAJCQkJZWNobyAiCT09PT4+PiBQYWNr YWdlIHNhdmVkIHRvICQxIiA7IGVjaG8gJycKQEAgLTIwODUsMTAgKzIyMzcsMTQgQEAKIGZpCiAK IGlmIFsgLW4gIiRFWFBVTkdFIiBdOyB0aGVuCi0JaWYgWyAhIC1kICIkcGRiLyRFWFBVTkdFIiBd OyB0aGVuCisJaWYgWyAhIC1kICIkcGRiLyRFWFBVTkdFIiBdIHx8ICggWyAtbiAiJHVzZV9wa2du ZyIgXSAmJiAhIHBrZyBpbmZvIC1lICRFWFBVTkdFICk7IHRoZW4KIAkJZmluZF9nbG9iX2RpcnMg JEVYUFVOR0UKIAkJY2FzZSAkPyBpbgotCQkxKQlmYWlsICJObyBzdWNoIGRpcmVjdG9yeS9wb3J0 OiAkcGRiLyRFWFBVTkdFIiA7OworCQkxKQlpZiBbIC16ICIkdXNlX3BrZ25nIiBdOyB0aGVuCisJ CQkJZmFpbCAiTm8gc3VjaCBkaXJlY3RvcnkvcG9ydDogJHBkYi8kRVhQVU5HRSIKKwkJCWVsc2UK KwkJCQlmYWlsICJObyBzdWNoIHBvcnQ6ICRFWFBVTkdFIgorCQkJZmkgOzsKIAkJMikJZWNobyAi PT09Pj4+ICRFWFBVTkdFIG1hdGNoZWQgbXVsdGlwbGUgcG9ydHMiCiAJCQlmYWlsICJUaGUgLWUg b3B0aW9uIHdvcmtzIHdpdGggb25seSBvbmUgcG9ydCBhdCBhIHRpbWUiIDs7CiAJCTApCUVYUFVO R0U9JHtnbG9iX2RpcnMjJHBkYi99CkBAIC0yMDk3LDE1ICsyMjUzLDI0IEBACiAJZmkKIAogCW9y aWdpbj1gb3JpZ2luX2Zyb21fcGRiICRFWFBVTkdFYAotCWRlcGxpc3Q9YGdyZXAgLWwgREVQT1JJ R0lOOiRvcmlnaW4kICRwZGIvKi8rQ09OVEVOVFNgCisJaWYgWyAteiAiJHVzZV9wa2duZyIgXTsg dGhlbgorCQlkZXBsaXN0PWBncmVwIC1sIERFUE9SSUdJTjokb3JpZ2luJCAkcGRiLyovK0NPTlRF TlRTYAorCWVsc2UKKwkJZGVwbGlzdD1gcGtnIHF1ZXJ5ICIlcm4tJXJ2IiAkb3JpZ2luYAorCWZp CiAJaWYgWyAtbiAiJGRlcGxpc3QiIF07IHRoZW4KIAkJZWNobyAiPT09Pj4+IFdhcm5pbmc6IFBv cnRzIHdpdGggZGVwZW5kZW5jaWVzIG9uICR7RVhQVU5HRX06IgotCQlmb3IgZGVwIGluICRkZXBs aXN0OyBkbwotCQkJZGVwPSR7ZGVwJS8rQ09OKn0gOyBlY2hvICIJJHtkZXAjIyovfSIKLQkJZG9u ZQorCQlpZiBbIC16ICIkdXNlX3BrZ25nIiBdOyB0aGVuCisJCQlmb3IgZGVwIGluICRkZXBsaXN0 OyBkbworCQkJCWRlcD0ke2RlcCUvK0NPTip9IDsgZWNobyAiCSR7ZGVwIyMqL30iCisJCQlkb25l CisJCWVsc2UKKwkJCWVjaG8gIiRkZXBsaXN0IiB8IHNlZCAncy9eLwkvJworCQlmaQogCQlnZXRf YW5zd2VyX3luIG4gIlxuXHQ9PT0+Pj4gRGVsZXRlIHRoaXMgZGVwZW5kZW5jeSBkYXRhIgogCQlj YXNlICIkPyIgaW4KLQkJMCkJZm9yIGYgaW4gJGRlcGxpc3Q7IGRvCisJCTApCVsgLW4gIiR1c2Vf cGtnbmciIF0gJiYgZXhpdCAxICNUT0RPCisJCQlmb3IgZiBpbiAkZGVwbGlzdDsgZG8KIAkJCQl1 cGRhdGVfY29udGVudHMgZGVsZXRlICRmICRvcmlnaW4KIAkJCWRvbmUgOzsKIAkJKikJZXhpdCAx IDs7CkBAIC0yMTE1LDggKzIyODAsMTMgQEAKIAlbIC1uICIkQkFDS1VQIiBdICYmIHsgaW5pdF9w YWNrYWdlcyA7IHBtX3BrZ19jcmVhdGUgJHBidSAkRVhQVU5HRTsgfQogCVsgLXogIiRET05UX1ND UlVCX0RJU1RGSUxFUyIgXSAmJiBkZWxldGVfYWxsX2Rpc3RmaWxlcyAkb3JpZ2luCiAKLQllY2hv ICI9PT0+Pj4gUnVubmluZyBwa2dfZGVsZXRlIC1mICRFWFBVTkdFIgotCXBtX3BrZ19kZWxldGVf cyAtZiAkRVhQVU5HRSB8fCBmYWlsICdwa2dfZGVsZXRlIGZhaWxlZCcKKwlpZiBbIC16ICIkdXNl X3BrZ25nIiBdOyB0aGVuCisJCXBrZ19kZWxldGU9InBrZ19kZWxldGUiCisJZWxzZQorCQlwa2df ZGVsZXRlPSJwa2cgZGVsZXRlIgorCWZpCisJZWNobyAiPT09Pj4+IFJ1bm5pbmcgJHBrZ19kZWxl dGUgLWYgJEVYUFVOR0UiCisJcG1fcGtnX2RlbGV0ZV9zIC1mICRFWFBVTkdFIHx8IGZhaWwgIiRw a2dfZGVsZXRlIGZhaWxlZCIKIAogCWVjaG8gJycgOyBlY2hvICI9PT0+Pj4gUnVubmluZyAkezAj IyovfSAtcyAkQVJHUyIKIAlleGVjICQwIC1zICRBUkdTCkBAIC0yMTI2LDEzICsyMjk2LDIxIEBA CiBpZiBbIC1uICIkQ0xFQU5fU1RBTEUiIF07IHRoZW4KIAlbIC16ICIkbm9fZGVsX2xpc3QiIF0g JiYgZXhwb3J0IG5vX2RlbF9saXN0PSc6JwogCi0JZm9yIGZpbGUgaW4gYGZpbmQgJHBkYiAtdHlw ZSBmIC1uYW1lIFwrUkVRVUlSRURfQlkgLWVtcHR5YCA7IGRvCisJaWYgWyAteiAiJHVzZV9wa2du ZyIgXTsgdGhlbgorCQlmaW5kX3N0YWxlX3BvcnRzPSJmaW5kICRwZGIgLXR5cGUgZiAtbmFtZSBc K1JFUVVJUkVEX0JZIC1lbXB0eSIKKwllbHNlCisJCWZpbmRfc3RhbGVfcG9ydHM9InBrZyBxdWVy eSAtYSBcIiU/ciAlbi0ldlwiIHwgYXdrICcvXjAvIHsgcHJpbnQgXCQyIH0nIgorCWZpCisJZm9y IGZpbGUgaW4gYGV2YWwgJGZpbmRfc3RhbGVfcG9ydHNgIDsgZG8KIAkJaXBvcnQ9IiR7ZmlsZSUv K1JFUVVJUkVEX0JZfSIgOyBpcG9ydD0ke2lwb3J0IyRwZGIvfQogCiAJCWNhc2UgIiRub19kZWxf bGlzdCIgaW4gKjoke2lwb3J0fToqKSBjb250aW51ZSA7OyBlc2FjCiAKIAkJb3JpZ2luPWBvcmln aW5fZnJvbV9wZGIgJGlwb3J0YAotCQlkZXBsaXN0PWBncmVwIC1sIERFUE9SSUdJTjokb3JpZ2lu JCAkcGRiLyovK0NPTlRFTlRTYAorCQlkZXBsaXN0PSIiCisJCWlmIFsgLXogIiR1c2VfcGtnbmci IF07IHRoZW4KKwkJCWRlcGxpc3Q9YGdyZXAgLWwgREVQT1JJR0lOOiRvcmlnaW4kICRwZGIvKi8r Q09OVEVOVFNgCisJCWZpCiAJCWlmIFsgLW4gIiRkZXBsaXN0IiBdOyB0aGVuCiAJCQllY2hvICcn CiAJCQllY2hvICI9PT0+Pj4gV2FybmluZzogVW5yZWNvcmRlZCBkZXBlbmRlbmNpZXMgb24gJHtp cG9ydH06IgpAQCAtMjE0NSwyMiArMjMyMywzMiBAQAogCQkJY29udGludWUKIAkJZmkKIAotCQll Y2hvICcnIDsgcGtnX2luZm8gJGlwb3J0CisJCWlmIFsgLXogIiR1c2VfcGtnbmciIF07IHRoZW4K KwkJCWVjaG8gJycgOyBwa2dfaW5mbyAkaXBvcnQKKwkJCXBrZ19kZWxldGU9InBrZ19kZWxldGUi CisJCWVsc2UKKwkJCWVjaG8gJycgOyBwa2cgaW5mbyAtZiAkaXBvcnQKKwkJCXBrZ19kZWxldGU9 InBrZyBkZWxldGUiCisJCWZpCiAKIAkJZ2V0X2Fuc3dlcl95biBuICJcdD09PT4+PiAke2lwb3J0 fSBpcyBubyBsb25nZXIgZGVwZW5kZWQgb24sIGRlbGV0ZSIKIAkJY2FzZSAiJD8iIGluCiAJCTAp CVsgLW4gIiRCQUNLVVAiIF0gJiYgeyBpbml0X3BhY2thZ2VzIDsgcG1fcGtnX2NyZWF0ZSAkcGJ1 ICRpcG9ydDsgfQogCQkJWyAteiAiJERPTlRfU0NSVUJfRElTVEZJTEVTIiBdICYmIGRlbGV0ZV9h bGxfZGlzdGZpbGVzICRvcmlnaW4KIAotCQkJZWNobyAiPT09Pj4+IFJ1bm5pbmcgcGtnX2RlbGV0 ZSAtZiAkaXBvcnQiCi0JCQlwbV9wa2dfZGVsZXRlX3MgLWYgJGlwb3J0IHx8IGZhaWwgJ3BrZ19k ZWxldGUgZmFpbGVkJworCQkJZWNobyAiPT09Pj4+IFJ1bm5pbmcgJHBrZ19kZWxldGUgLWYgJGlw b3J0IgorCQkJcG1fcGtnX2RlbGV0ZV9zIC1mICRpcG9ydCB8fCBmYWlsICIkcGtnX2RlbGV0ZSBm YWlsZWQiCiAKIAkJCWV4ZWMgJDAgLXMgJEFSR1MgOzsKLQkJKikJZ2V0X2Fuc3dlcl95biBuICJc dD09PT4+PiBEZWxldGUgdGhpcyBkZXBlbmRlbmN5IGRhdGEiCi0JCQljYXNlICIkPyIgaW4KLQkJ CTApCXBtX3VubGlua19zICRmaWxlIDs7Ci0JCQkqKQlub19kZWxfbGlzdD0iJHtub19kZWxfbGlz dH0ke2lwb3J0fToiIDs7Ci0JCQllc2FjIDs7CisJCSopCWlmIFsgLXogIiR1c2VfcGtnbmciIF07 IHRoZW4KKwkJCQlnZXRfYW5zd2VyX3luIG4gIlx0PT09Pj4+IERlbGV0ZSB0aGlzIGRlcGVuZGVu Y3kgZGF0YSIKKwkJCQljYXNlICIkPyIgaW4KKwkJCQkwKQlwbV91bmxpbmtfcyAkZmlsZSA7Owor CQkJCSopCW5vX2RlbF9saXN0PSIke25vX2RlbF9saXN0fSR7aXBvcnR9OiIgOzsKKwkJCQllc2Fj CisJCQllbHNlCisJCQkJbm9fZGVsX2xpc3Q9IiR7bm9fZGVsX2xpc3R9JHtpcG9ydH06IgorCQkJ ZmkgOzsKIAkJZXNhYwogCWRvbmUKIAlleGl0IDAKQEAgLTIxODMsNyArMjM3MSw3IEBACiAJIyB0 byBnbyBvdXQgdG8gdGhlIGRpc2sgaWYgd2UgZG9uJ3QgaGF2ZSB0by4KIAlbIC16ICIkUkVTVEFS VCIgXSAmJiByZXR1cm4gMQogCi0JaWYgWyAhIC1lICIkcGRiLyR7MX0vUE1fVVBHUkFERV9ET05F X0ZMQUciIF07IHRoZW4KKwlpZiBbICEgLWUgIiRwZGIvJHsxfS9QTV9VUEdSQURFX0RPTkVfRkxB RyIgXSB8fCAoIFsgLW4gIiR1c2VfcGtnbmciIF0gJiYgISBwa2cgaW5mbyAtZSAkMSApOyB0aGVu CiAJCXJldHVybiAxCiAJZWxzZQogCQlhbHJlYWR5X2RvbmUgJDEKQEAgLTIyMDAsNyArMjM4OCw3 IEBACiAJY2FzZSAiJElOVEVSQUNUSVZFX1lFUyIgaW4gKjokezF9OiopIHJldHVybiAwIDs7IGVz YWMKIAljYXNlICIkSU5URVJBQ1RJVkVfTk8iIGluICo6JHsxfToqKSByZXR1cm4gMSA7OyBlc2Fj CiAKLQlpZiBbIC1lICIkcGRiLyQxLytJR05PUkVNRSIgXTsgdGhlbgorCWlmIFsgLWUgIiRwZGIv JDEvK0lHTk9SRU1FIiBdICYmICggWyAteiAiJHVzZV9wa2duZyIgXSB8fCBwa2cgaW5mbyAtZSAk MSApOyB0aGVuCiAJCWVjaG8gJycKIAkJZWNobyAiPT09Pj4+ICtJR05PUkVNRSBmaWxlIGlzIHBy ZXNlbnQgZm9yICQxIgogCQllY2hvICcnCkBAIC0yMzEyLDcgKzI1MDAsMTMgQEAKIAkJCWZhaWwg Ik5vIGVudHJ5IGZvciAkb3JpZ2luIGluICRQTV9JTkRFWCIKIAlmaQogCi0JY2FzZSBgcGtnX3Zl cnNpb24gLXQgJGlwb3J0ICRuZXdfcG9ydCAyPi9kZXYvbnVsbGAgaW4KKwlsb2NhbCBwa2dfdmVy c2lvbgorCWlmIFsgLXogIiR1c2VfcGtnbmciIF07IHRoZW4KKwkJcGtnX3ZlcnNpb249InBrZ192 ZXJzaW9uIgorCWVsc2UKKwkJcGtnX3ZlcnNpb249InBrZyB2ZXJzaW9uIgorCWZpCisJY2FzZSBg JHBrZ192ZXJzaW9uIC10ICRpcG9ydCAkbmV3X3BvcnQgMj4vZGV2L251bGxgIGluCiAJXDwpCWJ1 aWxkX2w9IiR7YnVpbGRfbH1cdFVwZ3JhZGUgJGlwb3J0IHRvICRuZXdfcG9ydFxuIiA7OwogCT0p CWJ1aWxkX2w9IiR7YnVpbGRfbH1cdFJlLWluc3RhbGwgJGlwb3J0XG4iIDs7CiAJXD4pCWJ1aWxk X2w9IiR7YnVpbGRfbH1cdERvd25ncmFkZSAkaXBvcnQgdG8gJG5ld19wb3J0XG4iIDs7CkBAIC0y NDYzLDYgKzI2NTcsMTggQEAKIAkJcnVuZGVwcz1gZ2VuX2RlcF9saXN0IHJ1bi1kZXBlbmRzLWxp c3RgCiAKIAkJZm9yIGRlcCBpbiAkZF9wb3J0X2xpc3Q7IGRvCisJCQkjIElmIHRoZSBwb3J0IGlz IGFscmVhZHkgaW5zdGFsbGVkLCBkbyBub3QgbWFyaworCQkJIyBpdCBhcyBhIGJ1aWxkLW9ubHkg ZGVwZW5kZW5jeSwgb3IgaXQgd2lsbCBiZQorCQkJIyBpbnN0YWxsZWQgYnkgcGFja2FnZSBhbmQv b3IgcmVtb3ZlZAorCQkJaWYgWyAteiAiJHVzZV9wa2duZyIgXTsgdGhlbgorCQkJCWlwb3J0X2Zy b21fb3JpZ2luICR7ZGVwIyRwZC99ID4vZGV2L251bGwgJiYKKwkJCQkJcnVuX2RsPSIkcnVuX2Rs ICRkZXAiICYmCisJCQkJCWNvbnRpbnVlCisJCQllbHNlCisJCQkJcGtnIGluZm8gLWUgJHtkZXAj JHBkL30gJiYKKwkJCQkJcnVuX2RsPSIkcnVuX2RsICRkZXAiICYmCisJCQkJCWNvbnRpbnVlCisJ CQlmaQogCQkJY2FzZSAiJHJ1bmRlcHMiIGluCiAJCQkqIiAke2RlcH0gIip8KiR7ZGVwfSopCiAJ CQkJdmFybmFtZT1gZWNobyAke2RlcCMkcGQvfSB8IHNlZCAncyNbLSsvXC5dI18jZydgCkBAIC0y NTMyLDcgKzI3MzgsMTEgQEAKIAkJCQlmYWlsICJDYW5ub3QgY2QgdG8gJGRfcG9ydCIKIAkJCWZp CiAJCQlmb3IgZ2xvYiBpbiAkY29uZmxpY3RzOyBkbwotCQkJCWNvbmZsX3A9YHBrZ19pbmZvIC1J ICRnbG9iIDI+L2Rldi9udWxsYAorCQkJCWlmIFsgLXogIiR1c2VfcGtnbmciIF07IHRoZW4KKwkJ CQkJY29uZmxfcD1gcGtnX2luZm8gLUkgJGdsb2IgMj4vZGV2L251bGxgCisJCQkJZWxzZQorCQkJ CQljb25mbF9wPWBwa2cgcXVlcnkgLWcgIiVuLSV2IiAkZ2xvYiAyPi9kZXYvbnVsbGAKKwkJCQlm aQogCQkJCWlmIFsgLW4gIiRjb25mbF9wIiBdOyB0aGVuCiAJCQkJCWNvbmZsX3A9JHtjb25mbF9w JSUgKn0KIAkJCQkJZF9wb3J0PSIkcGQvYG9yaWdpbl9mcm9tX3BkYiAkY29uZmxfcGAiCkBAIC0y NjcyLDcgKzI4ODIsMTEgQEAKIAkJZG9uZQogCiAJCWZvciBkZXAgaW4gJGJ1aWxkX29ubHlfZGxf ZzsgZG8KLQkJCWdyZXAgLXEgIkBjb21tZW50IERFUE9SSUdJTjoke2RlcCMkcGQvfSQiICRwZGIv Ki8rQ09OVEVOVFMgJiYgY29udGludWUKKwkJCWlmIFsgLXogIiR1c2VfcGtnbmciIF07IHRoZW4K KwkJCQlncmVwIC1xICJAY29tbWVudCBERVBPUklHSU46JHtkZXAjJHBkL30kIiAkcGRiLyovK0NP TlRFTlRTICYmIGNvbnRpbnVlCisJCQllbHNlCisJCQkJWyAiYHBrZyBxdWVyeSAiJT9yIiAke2Rl cCMkcGQvfWAiID0gIjEiIF0gJiYgY29udGludWUKKwkJCWZpCiAJCQlbIC1uICIkUE1fREVMX0JV SUxEX09OTFkiIF0gJiYKIAkJCQlpcG9ydF9mcm9tX29yaWdpbiAke2RlcCMkcGQvfSA+L2Rldi9u dWxsICYmIGNvbnRpbnVlCiAJCQl0ZW1wX2JvZGxnPSIkdGVtcF9ib2RsZyAkZGVwIgpAQCAtMjY5 OSw3ICsyOTEzLDcgQEAKIAogdXJiX3VwZGF0ZSAoKSB7CiAJIyBHbG9iYWw6IFBNX1VSQl9VUAot CWxvY2FsIHZlcmIgb3JpZ2luIHJlcV9ieQorCWxvY2FsIHZlcmIgb3JpZ2luIHJlcV9ieSByZXFf YnlfbwogCiAJdmVyYj1jaGVja2luZyA7IFsgLW4gIiQxIiBdICYmIHZlcmI9dXBkYXRpbmcKIApA QCAtMjcwOSwxNSArMjkyMywyNSBAQAogCWVjaG8gJycKIAogCWZvciBvcmlnaW4gaW4gJFBNX1VS Ql9PUklHSU5TOyBkbwotCQlmb3IgcmVxX2J5IGluIGBncmVwIC1sIERFUE9SSUdJTjoke29yaWdp bn0kICRwZGIvKi8rQ09OVEVOVFNgOyBkbwotCQkJcmVxX2J5PSIke3JlcV9ieSUvK0NPTlRFTlRT fSIKLQkJCXJlcV9ieT0iJHtyZXFfYnkjIyovfSIKKwkJaWYgWyAteiAiJHVzZV9wa2duZyIgXTsg dGhlbgorCQkJZm9yIHJlcV9ieSBpbiBgZ3JlcCAtbCBERVBPUklHSU46JHtvcmlnaW59JCAkcGRi LyovK0NPTlRFTlRTYDsgZG8KKwkJCQlyZXFfYnk9IiR7cmVxX2J5JS8rQ09OVEVOVFN9IgorCQkJ CXJlcV9ieT0iJHtyZXFfYnkjIyovfSIKIAotCQkJY2FzZSAiICRQTV9VUkJfSVBPUlRTIiBpbiAq IiAkcmVxX2J5ICIqKSBjb250aW51ZSA7OyBlc2FjCi0JCQljYXNlICIgJFBNX1VSQl9PUklHSU5T IiBpbiAqIiBgb3JpZ2luX2Zyb21fcGRiICRyZXFfYnlgICIqKSBjb250aW51ZSA7OyBlc2FjCisJ CQkJY2FzZSAiICRQTV9VUkJfSVBPUlRTIiBpbiAqIiAkcmVxX2J5ICIqKSBjb250aW51ZSA7OyBl c2FjCisJCQkJY2FzZSAiICRQTV9VUkJfT1JJR0lOUyIgaW4gKiIgYG9yaWdpbl9mcm9tX3BkYiAk cmVxX2J5YCAiKikgY29udGludWUgOzsgZXNhYwogCi0JCQlQTV9VUkJfTElTVD0iJHtQTV9VUkJf TElTVH0gJHtyZXFfYnl9IgotCQlkb25lCisJCQkJUE1fVVJCX0xJU1Q9IiR7UE1fVVJCX0xJU1R9 ICR7cmVxX2J5fSIKKwkJCWRvbmUKKwkJZWxzZQorCQkJd2hpbGUgcmVhZCByZXFfYnkgcmVxX2J5 X287IGRvCisJCQkJY2FzZSAiICRQTV9VUkJfSVBPUlRTIiBpbiAqIiAkcmVxX2J5ICIqKSBjb250 aW51ZSA7OyBlc2FjCisJCQkJY2FzZSAiICRQTV9VUkJfT1JJR0lOUyIgaW4gKiIgJHJlcV9ieV9v ICIqKSBjb250aW51ZSA7OyBlc2FjCisJCQkJUE1fVVJCX0xJU1Q9IiR7UE1fVVJCX0xJU1R9ICR7 cmVxX2J5fSIKKwkJCWRvbmUgPDwgRU9GCitgcGtnIHF1ZXJ5ICIlcm4tJXJ2ICVybyIgJHtvcmln aW59YAorRU9GCisJCWZpCiAJZG9uZQogCiAJaWYgWyAtbiAiJFBNX1VSQl9MSVNUIiBdOyB0aGVu CkBAIC0yNzI5LDcgKzI5NTMsMTEgQEAKIAogCWZvciByZXFfYnkgaW4gJFBNX1VSQl9MSVNUOyBk bwogCQkjIFByb2JhYmx5IG5vdCBuZWVkZWQsIGJ1dCBKSUMKLQkJWyAtZCAiJHBkYi8kcmVxX2J5 IiBdIHx8IGNvbnRpbnVlCisJCWlmIFsgLXogIiR1c2VfcGtnbmciIF07IHRoZW4KKwkJCVsgLWQg IiRwZGIvJHJlcV9ieSIgXSB8fCBjb250aW51ZQorCQllbHNlCisJCQlwa2cgaW5mbyAtZSAkcmVx X2J5IHx8IGNvbnRpbnVlCisJCWZpCiAKIAkJcG1fdiAiPT09Pj4+ICRyZXFfYnkgZGVwZW5kcyBv biAkUE1fVVJCX0lQT1JUUyIKIApAQCAtMjc3MCwxMiArMjk5OCwxNiBAQAogCQkJZWxzZQogCQkJ CWZhaWwgIiRwZC8ke3BvcnR9IGRvZXMgbm90IGV4aXN0IgogCQkJZmkgOzsKLQkJKikJaWYgWyAt ZCAiJHBkYi8kcG9ydCIgXTsgdGhlbgorCQkqKQlpZiBbIC1kICIkcGRiLyRwb3J0IiBdICYmICgg WyAteiAiJHVzZV9wa2duZyIgXSB8fCBwa2cgaW5mbyAtZSAkcG9ydCApOyB0aGVuCiAJCQkJd29y a2xpc3RfdGVtcD0iJHdvcmtsaXN0X3RlbXAgJHBvcnQiCiAJCQllbHNlCiAJCQkJZmluZF9nbG9i X2RpcnMgJHBvcnQKIAkJCQljYXNlICQ/IGluCi0JCQkJMSkJZmFpbCAiJHBkYi8kcG9ydCBkb2Vz IG5vdCBleGlzdCIgOzsKKwkJCQkxKQlpZiBbIC16ICIkdXNlX3BrZ25nIiBdOyB0aGVuCisJCQkJ CQlmYWlsICIkcGRiLyRwb3J0IGRvZXMgbm90IGV4aXN0IgorCQkJCQllbHNlCisJCQkJCQlmYWls ICIkcG9ydCBpcyBub3QgaW5zdGFsbGVkIgorCQkJCQlmaSA7OwogCQkJCSopCWxvY2FsIGRpcgog CQkJCQlmb3IgZGlyIGluICRnbG9iX2RpcnM7IGRvCiAJCQkJCXdvcmtsaXN0X3RlbXA9IiR3b3Jr bGlzdF90ZW1wICR7ZGlyIyRwZGIvfSIKQEAgLTI4ODcsOSArMzExOSwxNiBAQAogCQkqLyopCW9y aWdpbj0kcG9ydCA7OwogCQkqKQkjIElmIGFuIGluc3RhbGxlZCB2ZXJzaW9uIGRvZXMgbm90IGV4 aXN0IGF0IHRoaXMKIAkJCSMgcG9pbnQgaXQgcHJvYmFibHkgZ290IHVwZGF0ZWQgYXMgYSBkZXBl bmRlbmN5Ci0JCQlpZiBbICEgLWQgIiRwZGIvJHBvcnQiIF07IHRoZW4KLQkJCQludW1wb3J0cz0k KCggJG51bXBvcnRzIC0gMSApKQotCQkJCWNvbnRpbnVlCisJCQlpZiBbIC16ICIkdXNlX3BrZ25n IiBdOyB0aGVuCisJCQkJaWYgWyAhIC1kICIkcGRiLyRwb3J0IiBdOyB0aGVuCisJCQkJCW51bXBv cnRzPSQoKCAkbnVtcG9ydHMgLSAxICkpCisJCQkJCWNvbnRpbnVlCisJCQkJZmkKKwkJCWVsc2UK KwkJCQlpZiAhIHBrZyBpbmZvIC1lICRwb3J0OyB0aGVuCisJCQkJCW51bXBvcnRzPSQoKCAkbnVt cG9ydHMgLSAxICkpCisJCQkJCWNvbnRpbnVlCisJCQkJZmkKIAkJCWZpCiAJCQlvcmlnaW49YG9y aWdpbl9mcm9tX3BkYiAkcG9ydGAgOzsKIAkJZXNhYwpAQCAtMzExMiwxNyArMzM1MSwyMiBAQAog ICAgY2FzZSAiJGFyZ3YiIGluCiAgICAkcGQvKikgIHBvcnRkaXI9JHthcmd2IyRwZC99IDs7Ci0g ICAkcGRiLyopIHVwZ19wb3J0PSR7YXJndiMkcGRiL30gOzsKKyAgICRwZGIvKikgaWYgWyAteiAi JHVzZV9wa2duZyIgXTsgdGhlbgorICAgICAgICAgICB1cGdfcG9ydD0ke2FyZ3YjJHBkYi99Cisg ICAgICAgZWxzZQorICAgICAgICAgICBlY2hvICcnIDsgbm9fdmFsaWRfcG9ydAorICAgICAgIGZp IDs7ICAgIAogICAgLyopIGVjaG8gJycgOyBub192YWxpZF9wb3J0IDs7CiAgICAqLyopICAgIHBv cnRkaXI9JGFyZ3YgOzsKICAgIFwufCcnKSAgcG9ydGRpcj0iJFBXRCIKICAgICAgICB3aGlsZSA6 IDsgZG8KICAgICAgICAgICAgY2FzZSAiJHBvcnRkaXIiIGluCiAgICAgICAgICAgICovKi8qKSAg cG9ydGRpcj0iJHtwb3J0ZGlyIyovfSIgOzsKICAgICAgICAgICAgKi8qKSAgICBicmVhayA7Owog ICAgICAgICAgICAqKSAgZWNobyAnJyA7IG5vX3ZhbGlkX3BvcnQgOzsKICAgICAgICAgICAgZXNh YwogICAgICAgIGRvbmUgOzsKLSAgICopICBbIC1kICIkcGRiLyRhcmd2IiBdICYmIHVwZ19wb3J0 PSRhcmd2IDs7CisgICAqKSAgWyAtZCAiJHBkYi8kYXJndiIgXSAmJiAoIFsgLXogIiR1c2VfcGtn bmciIF0gfHwgcGtnIGluZm8gLWUgJGFyZ3YgKSAmJgorICAgICAgIHVwZ19wb3J0PSRhcmd2IDs7 ICAgIAogICAgZXNhYwoKICAgIGlmIFsgLXogIiRwb3J0ZGlyIiAtYSAteiAiJHVwZ19wb3J0IiBd OyB0aGVuCkBAIC0zMTQ5LDcgKzMzOTMsNyBAQAogCiAJY2FzZSAiJGFyZzIiIGluCiAJKi8qKQly b19vcGQ9JGFyZzIgOyByb191cGdfcG9ydD1gaXBvcnRfZnJvbV9vcmlnaW4gJHJvX29wZGAgOzsK LQkqKQlpZiBbIC1kICIkcGRiLyRhcmcyIiBdOyB0aGVuCisJKikJaWYgWyAtZCAiJHBkYi8kYXJn MiIgXSAmJiAoIFsgLXogIiR1c2VfcGtnbmciIF0gfHwgcGtnIGluZm8gLWUgJGFyZzIgKTsgdGhl bgogCQkJcm9fdXBnX3BvcnQ9JGFyZzIKIAkJZWxzZQogCQkJZmluZF9nbG9iX2RpcnMgJGFyZzIg JiYgcm9fdXBnX3BvcnQ9JHtnbG9iX2RpcnMjJHBkYi99CkBAIC0zMTY0LDEyICszNDA4LDIxIEBA CiAJdW5zZXQgYXJnMgogCiAJaWYgWyAteiAiJHJvX3VwZ19wb3J0IiBdOyB0aGVuCi0JCWlmICEg Z3JlcCAtcWwgIkRFUE9SSUdJTjokcm9fb3BkJCIgJHBkYi8qLytDT05URU5UUzsgdGhlbgorCQlp ZiBbIC16ICIkdXNlX3BrZ25nIiBdOyB0aGVuCisJCQlncmVwIC1xbCAiREVQT1JJR0lOOiRyb19v cGQkIiAkcGRiLyovK0NPTlRFTlRTCisJCWVsc2UKKwkJCXBrZyBxdWVyeSAtYSAiJWRvIiB8IGdy ZXAgLXEgIl4kcm9fb3BkJCIKKwkJZmkKKwkJaWYgWyAiJD8iIC1lcSAxIF07IHRoZW4KIAkJCWVj aG8gJycKLQkJCWVjaG8gIj09PT4+PiBUaGUgc2Vjb25kIGFyZ3VtZW50IHRvIC1vIGNhbiBiZSBh IHBvcnQgaW4gJHBkYiwiCisJCQlpZiBbIC16ICIkdXNlX3BrZ25nIiBdOyB0aGVuCisJCQkJZWNo byAiPT09Pj4+IFRoZSBzZWNvbmQgYXJndW1lbnQgdG8gLW8gY2FuIGJlIGEgcG9ydCBpbiAkcGRi LCIKKwkJCWVsc2UKKwkJCQllY2hvICI9PT0+Pj4gVGhlIHNlY29uZCBhcmd1bWVudCB0byAtbyBj YW4gYmUgYSBwYWNrYWdlIG5hbWUsIgorCQkJZmkKIAkJCWVjaG8gIiAgICAgICBvciBhIHBvcnQg ZGlyZWN0b3J5IGZyb20gJHBkIgogCQkJZWNobyAnJwotCQkJZWNobyAiICAgICAgICRyb19vcGQg ZG9lcyBub3Qgc2VlbSB0byBiZSBpbnN0YWxsZWQsIgorCQkJZWNobyAiICAgICAgICRhcmcyIGRv ZXMgbm90IHNlZW0gdG8gYmUgaW5zdGFsbGVkLCIKIAkJCWVjaG8gJyAgICAgICBvciBsaXN0ZWQg YXMgYSBkZXBlbmRlbmN5JwogCQkJZWNobyAnJyA7IG5vX3ZhbGlkX3BvcnQKIAkJZmkKQEAgLTMy MDEsNyArMzQ1NCw3IEBACiBmaQogWyAteiAiJHVwZ19wb3J0IiAtYSAteiAiJFJFUExBQ0VfT1JJ R0lOIiBdICYmIHVwZ19wb3J0PWBpcG9ydF9mcm9tX29yaWdpbiAke3BvcnRkaXJ9YAogCi1pZiBb IC1lICIkcGRiLyR1cGdfcG9ydC8rSUdOT1JFTUUiIF07IHRoZW4KK2lmIFsgLWUgIiRwZGIvJHVw Z19wb3J0LytJR05PUkVNRSIgXSAmJiAoIFsgLXogIiR1c2VfcGtnbmciIF0gfHwgcGtnIGluZm8g LWUgJHVwZ19wb3J0ICk7IHRoZW4KIAkjIEFkZGluZyB0byBDVVJfREVQUyBtZWFucyB3ZSB3aWxs IG5vdCBnZXQgaGVyZSBpbiB0aGUgYnVpbGQKIAlpZiBbIC16ICIkUE1fQlVJTERJTkciIF07IHRo ZW4KIAkJIyBPbmx5IG5lZWQgdG8gcHJvbXB0IGZvciB0aGlzIG9uY2UgaWYgLWFpCkBAIC0zNTk5 LDcgKzM4NTIsMTIgQEAKIAkJcG1fdiAiPT09Pj4+IEF2YWlsYWJsZSBwYWNrYWdlICgkbGF0ZXN0 X3B2KSBtYXRjaGVzIHRoZSBjdXJyZW50IHZlcnNpb24iCiAJZWxpZiBbIC1uICIkbGF0ZXN0X3B2 IiAtYSAtbiAiJFBNX1BBQ0tBR0VTX05FV0VSIiBdOyB0aGVuCiAJCWlmIFsgLW4gIiR1cGdfcG9y dCIgXTsgdGhlbgotCQkJY2FzZSBgcGtnX3ZlcnNpb24gLXQgJHVwZ19wb3J0ICRsYXRlc3RfcHZg IGluCisJCQlpZiBbIC16ICIkdXNlX3BrZ25nIiBdOyB0aGVuCisJCQkJcGtnX3ZlcnNpb249InBr Z192ZXJzaW9uIgorCQkJZWxzZQorCQkJCXBrZ192ZXJzaW9uPSJwa2cgdmVyc2lvbiIKKwkJCWZp CisJCQljYXNlIGAkcGtnX3ZlcnNpb24gLXQgJHVwZ19wb3J0ICRsYXRlc3RfcHZgIGluCiAJCQlc PCkJdXNlX3BhY2thZ2U9dXBfbmV3ZXIKIAkJCQlwbV92ICI9PT0+Pj4gQXZhaWxhYmxlIHBhY2th Z2UgKCRsYXRlc3RfcHYpIgogCQkJCXBtX3YgIiAgICAgICBpcyBuZXdlciB0aGFuIGluc3RhbGxl ZCAoJHVwZ19wb3J0KSIgOzsKQEAgLTM2MTUsNyArMzg3MywxMiBAQAogCQkJcG1fdiAiPT09Pj4+ IFRoZXJlIGlzIGEgcGFja2FnZSBhdmFpbGFibGUgKCRsYXRlc3RfcHYpIgogCQlmaQogCWVsaWYg WyAtbiAiJGxhdGVzdF9wdiIgXTsgdGhlbgotCQljYXNlIGBwa2dfdmVyc2lvbiAtdCAkbmV3X3Bv cnQgJGxhdGVzdF9wdmAgaW4KKwkJaWYgWyAteiAiJHVzZV9wa2duZyIgXTsgdGhlbgorCQkJcGtn X3ZlcnNpb249InBrZ192ZXJzaW9uIgorCQllbHNlCisJCQlwa2dfdmVyc2lvbj0icGtnIHZlcnNp b24iCisJCWZpCisJCWNhc2UgYCRwa2dfdmVyc2lvbiAtdCAkbmV3X3BvcnQgJGxhdGVzdF9wdmAg aW4KIAkJXDwpCSMgQ291bGQgaGFwcGVuIGlmIHBvcnRzIHRyZWUgaXMgb3V0IG9mIGRhdGUKIAkJ CXVzZV9wYWNrYWdlPXVwX29sZF90cmVlCiAJCQlwbV92ICI9PT0+Pj4gQXZhaWxhYmxlIHBhY2th Z2UgKCRsYXRlc3RfcHYpIgpAQCAtMzcxNSw3ICszOTc4LDEyIEBACiAJCSAgICBncmVwIC12IF4k TE9DQUxCQVNFX0NPTVBBVCA+ICRwbV9ta3RlbXBfZmlsZQogCiAJCXVuc2V0IHRlbXAKLQkJZm9y IGZpbGUgaW4gYHBrZ19pbmZvIC1xIC1MICRVUEdSQURFX1BPUlQgfAorCQlpZiBbIC16ICIkdXNl X3BrZ25nIiBdOyB0aGVuCisJCQlwa2dsaXN0PSJwa2dfaW5mbyAtcSAtTCIKKwkJZWxzZQorCQkJ cGtnbGlzdD0icGtnIHF1ZXJ5ICVGcCIKKwkJZmkKKwkJZm9yIGZpbGUgaW4gYCRwa2dsaXN0ICRV UEdSQURFX1BPUlQgfAogCQkgICAgc29ydCAtICRwbV9ta3RlbXBfZmlsZSB8IHVuaXEgLWRgOyBk bwogCQkJdGVtcD0iJHt0ZW1wfSRmaWxlICIKIAkJZG9uZQpAQCAtMzczOCw2ICs0MDA2LDcgQEAK IAogCWlmIFsgLW4gIiRSRVBMQUNFX09SSUdJTiIgLWEgLW4gIiRyb191cGdfcG9ydCIgXTsgdGhl bgogCQkjIERlbGV0ZSBhbnkgZXhpc3RpbmcgdmVyc2lvbnMgb2YgdGhlIG9sZCBwb3J0CisJCW5w X29ycGhhbj1gcGtnIHF1ZXJ5ICIlYSIgJHJvX3VwZ19wb3J0YAogCQlwbV9zdiAiUnVubmluZyBw a2dfZGVsZXRlIGZvciAkcm9fdXBnX3BvcnQiCiAJCXBtX3BrZ19kZWxldGVfcyAtZiAkcm9fdXBn X3BvcnQKIAlmaQpAQCAtMzc1Nyw2ICs0MDI2LDggQEAKIAkJCXVuc2V0IHByZXNlcnZlX3BvcnQg ZmlsZXMKIAkJZXNhYwogCisJCSMgT3JwaGFuIHN0YXRlIG9mICRyb191cGdfcG9ydCBoYXMgcHJl Y2VkZW5jZQorCQk6ICR7bnBfb3JwaGFuOj1gcGtnIHF1ZXJ5ICIlYSIgJHVwZ19wb3J0YH0KIAkJ cG1fc3YgIlJ1bm5pbmcgcGtnX2RlbGV0ZSBmb3IgJHVwZ19wb3J0IgogCQlwbV9wa2dfZGVsZXRl X3MgLWYgJHVwZ19wb3J0CiAJZmkKQEAgLTM4MDMsNiArNDA3NCwxOCBAQAogCQl1bnNldCBwb3J0 X2xvZ19hcmdzCiAJZmkKIAorCWlmIFsgLXogIiRVUERBVEVfQUxMIiAtYSAteiAiJFJFUExBQ0Vf T1JJR0lOIiAtYSAteiAiJFBNX1VSQiIgLWEgIiR7bnBfb3JwaGFuOi0xfSIgLWVxIDEgXTsgdGhl bgorCQlpZiBbIC1uICIkUE1fTVVMVElfUE9SVFMiIF07IHRoZW4KKwkJCWNhc2UgIiRQTV9NVUxU SV9QT1JUUyIgaW4KKwkJCSo6JHt1cGdfcG9ydDotTk9ORX06KikJbnBfb3JwaGFuPTAgOzsKKwkJ CSo6JHtwb3J0ZGlyfToqKQkJbnBfb3JwaGFuPTAgOzsKKwkJCWVzYWMKKwkJZWxzZQorCQkJWyAi JCQiIC1lcSAiJFBNX1BBUkVOVF9QSUQiIF0gJiYgbnBfb3JwaGFuPTAKKwkJZmkKKwlmaQorCVsg IiR7bnBfb3JwaGFuOi0xfSIgLWVxIDEgXSAmJiBQTV9NQUtFX0FSR1M9IiR7UE1fTUFLRV9BUkdT fSAtRElOU1RBTExTX0RFUEVORFMiCisJdW5zZXQgbnBfb3JwaGFuCiAJIyBEZWZpbmluZyBOT19E RVBFTkRTIGVuc3VyZXMgdGhhdCB3ZSB3aWxsIGNvbnRyb2wgdGhlIGluc3RhbGxhdGlvbgogCSMg b2YgdGhlIGRlcGVuZHMsIG5vdCBic2QucG9ydC5tay4KIAlldmFsIHBtX21ha2VfcyAtRE5PX0RF UEVORFMgaW5zdGFsbCAkcG9ydF9sb2dfYXJncyB8fCBpbnN0YWxsX2ZhaWxlZCAkbmV3X3BvcnQK QEAgLTM4MjAsMjkgKzQxMDMsMzEgQEAKIAlmaQogZmkKIAotZm9yIGZpbGUgaW4gJHByZXNlcnZl X3BvcnRfZmlsZXM7IGRvCi0JbXYgJGZpbGUgJHtmaWxlfS1uZXcKLQltdiAke3ByZXNlcnZlX2Rp cn0vJHtmaWxlIyMqL30gJGZpbGUKLQlvbGRtZDU9Ik1ENTpgbWQ1IC1xICRmaWxlYCIKLQotCXBt X21rdGVtcCBjb250ZW50cwotCXdoaWxlIHJlYWQgbGVmdCByaWdodDsgZG8KLQkJY2FzZSAiJGxl ZnQiIGluCi0JCUBjd2QpCQlzaG9ydF9maWxlPSIke2ZpbGUjJHtyaWdodH0vfSIgOzsKLQkJJHNo b3J0X2ZpbGUpCWZvdW5kX2l0PWZvdW5kX2l0IDsgY29udGludWU7OwotCQlAY29tbWVudCkJaWYg WyAtbiAiJGZvdW5kX2l0IiBdOyB0aGVuCi0JCQkJCWVjaG8gLWUgIiR7c2hvcnRfZmlsZX0tbmV3 XG4kbGVmdCAkcmlnaHQiCi0JCQkJCWVjaG8gLWUgIiRzaG9ydF9maWxlXG5AY29tbWVudCAkb2xk bWQ1IgotCQkJCQl1bnNldCBmb3VuZF9pdAotCQkJCQljb250aW51ZQotCQkJCWZpIDs7Ci0JCWVz YWMKLQkJZWNobyAiJGxlZnQgJHJpZ2h0IgotCWRvbmUgPCAkcGRiLyRuZXdfcG9ydC8rQ09OVEVO VFMgPiAkcG1fbWt0ZW1wX2ZpbGUKLQlwbV9pbnN0YWxsX3MgJHBtX21rdGVtcF9maWxlICRjb250 ZW50cwotCXBtX3VubGluayAkcG1fbWt0ZW1wX2ZpbGUKLQl1bnNldCBmaWxlIG9sZG1kNSBwbV9t a3RlbXBfZmlsZSBsZWZ0IHJpZ2h0IHNob3J0X2ZpbGUKLWRvbmUKK2lmIFsgLXogIiR1c2VfcGtn bmciIF07IHRoZW4KKwlmb3IgZmlsZSBpbiAkcHJlc2VydmVfcG9ydF9maWxlczsgZG8KKwkJbXYg JGZpbGUgJHtmaWxlfS1uZXcKKwkJbXYgJHtwcmVzZXJ2ZV9kaXJ9LyR7ZmlsZSMjKi99ICRmaWxl CisJCW9sZG1kNT0iTUQ1OmBtZDUgLXEgJGZpbGVgIgorCQorCQlwbV9ta3RlbXAgY29udGVudHMK KwkJd2hpbGUgcmVhZCBsZWZ0IHJpZ2h0OyBkbworCQkJY2FzZSAiJGxlZnQiIGluCisJCQlAY3dk KQkJc2hvcnRfZmlsZT0iJHtmaWxlIyR7cmlnaHR9L30iIDs7CisJCQkkc2hvcnRfZmlsZSkJZm91 bmRfaXQ9Zm91bmRfaXQgOyBjb250aW51ZTs7CisJCQlAY29tbWVudCkJaWYgWyAtbiAiJGZvdW5k X2l0IiBdOyB0aGVuCisJCQkJCQllY2hvIC1lICIke3Nob3J0X2ZpbGV9LW5ld1xuJGxlZnQgJHJp Z2h0IgorCQkJCQkJZWNobyAtZSAiJHNob3J0X2ZpbGVcbkBjb21tZW50ICRvbGRtZDUiCisJCQkJ CQl1bnNldCBmb3VuZF9pdAorCQkJCQkJY29udGludWUKKwkJCQkJZmkgOzsKKwkJCWVzYWMKKwkJ CWVjaG8gIiRsZWZ0ICRyaWdodCIKKwkJZG9uZSA8ICRwZGIvJG5ld19wb3J0LytDT05URU5UUyA+ ICRwbV9ta3RlbXBfZmlsZQorCQlwbV9pbnN0YWxsX3MgJHBtX21rdGVtcF9maWxlICRjb250ZW50 cworCQlwbV91bmxpbmsgJHBtX21rdGVtcF9maWxlCisJCXVuc2V0IGZpbGUgb2xkbWQ1IHBtX21r dGVtcF9maWxlIGxlZnQgcmlnaHQgc2hvcnRfZmlsZQorCWRvbmUKK2ZpCiBpZiBbIC1uICIkcHJl c2VydmVfZGlyIiBdOyB0aGVuCiAJcm1kaXIgJHByZXNlcnZlX2RpciAyPi9kZXYvbnVsbAogCXVu c2V0IHByZXNlcnZlX2RpciBwcmVzZXJ2ZV9wb3J0X2ZpbGVzCkBAIC0zODU4LDE0ICs0MTQzLDE5 IEBACiB0ZW1wPWBmaW5kICRMT0NBTEJBU0VfQ09NUEFUIC10eXBlIGQgLWVtcHR5IDI+L2Rldi9u dWxsYAogaWYgWyAteiAiJHRlbXAiIF0gJiYgWyAtZCAiJExPQ0FMQkFTRV9DT01QQVQiIF07IHRo ZW4KIAl1bnNldCBmaWxlcwotCWZvciBmaWxlIGluIGBwa2dfaW5mbyAtcSAtTCAkbmV3X3BvcnRg OyBkbworCWlmIFsgLXogIiR1c2VfcGtnbmciIF07IHRoZW4KKwkJcGtnbGlzdD0icGtnX2luZm8g LXEgLUwiCisJZWxzZQorCQlwa2dsaXN0PSJwa2cgcXVlcnkgJUZwIgorCWZpCisJZm9yIGZpbGUg aW4gYCRwa2dsaXN0ICRuZXdfcG9ydGA7IGRvCiAJCVsgLWYgIiR7TE9DQUxCQVNFX0NPTVBBVH0v JHtmaWxlIyMqL30iIF0gJiYKIAkJCWZpbGVzPSIke2ZpbGVzfSR7TE9DQUxCQVNFX0NPTVBBVH0v JHtmaWxlIyMqL30gIgogCWRvbmUKIAogCWlmIFsgLW4gIiRmaWxlcyIgXTsgdGhlbgogCQlwbV9z diBSZW1vdmluZyBvbGQgc2hhcmVkIGxpYnJhcmllcywgYW5kIHJ1bm5pbmcgbGRjb25maWcKLQkJ cG1fcm1fcyAkZmlsZXMKKwkJcG1fcm1fcyBgbWFrZSAtViBGSUxFUzpPOnUgRklMRVM9IiRmaWxl cyJgCiAJCSRQTV9TVV9DTUQgL2V0Yy9yYy5kL2xkY29uZmlnIHN0YXJ0ID4gL2Rldi9udWxsCiAJ ZmkKIAl1bnNldCB0ZW1wIGZpbGUgZmlsZXMKQEAgLTM5MTcsMTEgKzQyMDcsMTMgQEAKIAlkb25l CiAKIAlwbV9zdiAiSW5zdGFsbGluZyAkZGlzdF9saXN0XG4iCisJcG1fbWtkaXJfcyAke2Rpc3Rf bGlzdCUvKn0KIAlwbV9pbnN0YWxsX3MgJHBtX21rdGVtcF9maWxlICRkaXN0X2xpc3QKIAkvYmlu L3VubGluayAkcG1fbWt0ZW1wX2ZpbGUgOyB1bnNldCBkaXN0aW5mbyBwbV9ta3RlbXBfZmlsZSBm aWxlIGxpbmUKIGZpCiAKLWlmIFsgLW4gIiR1c2VfcGFja2FnZSIgXTsgdGhlbgorIyBwa2duZyBk b2VzIG5vdCBuZWVkIHRoaXMKK2lmIFsgLXogIiR1c2VfcGtnbmciIC1hIC1uICIkdXNlX3BhY2th Z2UiIF07IHRoZW4KIAlpZiBncmVwIC1xIERFUE9SSUdJTiAkcGRiLyRuZXdfcG9ydC8rQ09OVEVO VFM7IHRoZW4KIAkJZWNobyAtZSAiPT09Pj4+IFVwZGF0aW5nIGRlcGVuZGVuY2llcyBmb3IgJG5l d19wb3J0IHRvIG1hdGNoIGluc3RhbGxlZCB2ZXJzaW9uc1xuIgogCQl1cGRhdGVfY29udGVudHMg JHBkYi8kbmV3X3BvcnQvK0NPTlRFTlRTIDsgcG1fdgpAQCAtMzk0Myw3ICs0MjM1LDcgQEAKIGlm IFsgLW4gIiRNQUtFX1BBQ0tBR0UiIF07IHRoZW4KIAlpZiBbIC16ICIkdXNlX3BhY2thZ2UiIF07 IHRoZW4KIAkJZWNobyAiPT09Pj4+IENyZWF0aW5nIGEgcGFja2FnZSBmb3IgbmV3IHZlcnNpb24g JG5ld19wb3J0IgotCQlwbV9tYWtlX3MgcGFja2FnZSA+L2Rldi9udWxsIHx8IGZhaWwgIlBhY2th Z2UgY3JlYXRpb24gb2YgJG5ld19wb3J0IGZhaWxlZCIKKwkJcG1fbWFrZV9zIC1EX09QVElPTlNf T0sgcGFja2FnZSA+L2Rldi9udWxsIHx8IGZhaWwgIlBhY2thZ2UgY3JlYXRpb24gb2YgJG5ld19w b3J0IGZhaWxlZCIKIAkJZWNobyAiCT09PT4+PiBQYWNrYWdlIHNhdmVkIHRvICRQQUNLQUdFUy9B bGwiIDsgZWNobyAnJwogCWVsc2UKIAkJcG1fcGtnX2NyZWF0ZSAkUEFDS0FHRVMgJG5ld19wb3J0 CkBAIC0zOTU2LDI5ICs0MjQ4LDM3IEBACiAJcG1fdgogZmkKIAotY2hlY2tfZGVwZW5kZW5jeV9m aWxlcyAkcG9ydGRpciAkbmV3X3BvcnQKLWlmIFsgLXMgIiRncmVwX2RlcHMiIF07IHRoZW4KLQll Y2hvIC1lICI9PT0+Pj4gVXBkYXRpbmcgZGVwZW5kZW5jeSBlbnRyeSBmb3IgJG5ld19wb3J0IGlu IGVhY2ggZGVwZW5kZW50IHBvcnRcbiIKLQl3aGlsZSByZWFkIGRfcG9ydDsgZG8KLQkJcG1fdiAi PT09Pj4+ICRkX3BvcnQiCi0JCWRwX2NvbnQ9JHBkYi8kZF9wb3J0LytDT05URU5UUwotCQlbIC1l ICIkZHBfY29udCIgXSB8fCBjb250aW51ZQotCi0JCWlmIFsgLW4gIiRyb19vcGQiIF0gJiYgZ3Jl cCAtcWwgIkRFUE9SSUdJTjokcm9fb3BkJCIgJGRwX2NvbnQ7IHRoZW4KLQkJCXVwZGF0ZV9jb250 ZW50cyAkZHBfY29udCAkcG9ydGRpciAkbmV3X3BvcnQgJHJvX29wZAotCQlmaQotCQkjIERvIHRo aXMgb25lIGxhc3Qgc28gaXQgY2FuIGdldCBkZWxldGVkIGFzIGEgZHVwbGljYXRlCi0JCSMgaWYg cm9fb3BkIGlzIHByZXNlbnQuCi0JCWlmIGdyZXAgLXFsICJERVBPUklHSU46JHBvcnRkaXIkIiAk ZHBfY29udDsgdGhlbgotCQkJdXBkYXRlX2NvbnRlbnRzICRkcF9jb250ICRwb3J0ZGlyICRuZXdf cG9ydAotCQlmaQotCWRvbmUgPCAkZ3JlcF9kZXBzCi0JdW5zZXQgZF9wb3J0IGRwX2NvbnQgOyBw bV92Ci0KLQl1cGRhdGVfcmVxdWlyZWRfYnkgJG5ld19wb3J0Ci0JWyAtbiAiJG5lZWR3cyIgXSAm JiB7IHBtX3Y7IHVuc2V0IG5lZWR3czsgfQoraWYgWyAteiAiJHVzZV9wa2duZyIgXTsgdGhlbgor CWNoZWNrX2RlcGVuZGVuY3lfZmlsZXMgJHBvcnRkaXIgJG5ld19wb3J0CisJaWYgWyAtcyAiJGdy ZXBfZGVwcyIgXTsgdGhlbgorCQllY2hvIC1lICI9PT0+Pj4gVXBkYXRpbmcgZGVwZW5kZW5jeSBl bnRyeSBmb3IgJG5ld19wb3J0IGluIGVhY2ggZGVwZW5kZW50IHBvcnRcbiIKKwkJd2hpbGUgcmVh ZCBkX3BvcnQ7IGRvCisJCQlwbV92ICI9PT0+Pj4gJGRfcG9ydCIKKwkJCWRwX2NvbnQ9JHBkYi8k ZF9wb3J0LytDT05URU5UUworCQkJWyAtZSAiJGRwX2NvbnQiIF0gfHwgY29udGludWUKKwkKKwkJ CWlmIFsgLW4gIiRyb19vcGQiIF0gJiYgZ3JlcCAtcWwgIkRFUE9SSUdJTjokcm9fb3BkJCIgJGRw X2NvbnQ7IHRoZW4KKwkJCQl1cGRhdGVfY29udGVudHMgJGRwX2NvbnQgJHBvcnRkaXIgJG5ld19w b3J0ICRyb19vcGQKKwkJCWZpCisJCQkjIERvIHRoaXMgb25lIGxhc3Qgc28gaXQgY2FuIGdldCBk ZWxldGVkIGFzIGEgZHVwbGljYXRlCisJCQkjIGlmIHJvX29wZCBpcyBwcmVzZW50LgorCQkJaWYg Z3JlcCAtcWwgIkRFUE9SSUdJTjokcG9ydGRpciQiICRkcF9jb250OyB0aGVuCisJCQkJdXBkYXRl X2NvbnRlbnRzICRkcF9jb250ICRwb3J0ZGlyICRuZXdfcG9ydAorCQkJZmkKKwkJZG9uZSA8ICRn cmVwX2RlcHMKKwkJdW5zZXQgZF9wb3J0IGRwX2NvbnQgOyBwbV92CisJCisJCXVwZGF0ZV9yZXF1 aXJlZF9ieSAkbmV3X3BvcnQKKwkJWyAtbiAiJG5lZWR3cyIgXSAmJiB7IHBtX3Y7IHVuc2V0IG5l ZWR3czsgfQorCWZpCitlbHNlCisJaWYgWyAtbiAiJHJvX29wZCIgXTsgdGhlbgorCQllY2hvICI9 PT0+Pj4gVXBkYXRpbmcgZGVwZW5kZW5jeSBlbnRyeSBmb3IgJG5ld19wb3J0IGluIGVhY2ggZGVw ZW5kZW50IHBvcnQiCisJCXBrZyBzZXQgLXlvICRyb19vcGQ6JHBvcnRkaXIKKwlmaQogZmkKIAor CiBpZiBbIC1uICIkdXBnX3BvcnQiIF07IHRoZW4KIAlpZiBbICEgIiR1cGdfcG9ydCIgPSAiJG5l d19wb3J0IiBdOyB0aGVuCiAJCWlsaXN0PSJVcGdyYWRlIG9mICR1cGdfcG9ydCB0byAkbmV3X3Bv cnQiCkBAIC0zOTk0LDEzICs0Mjk0LDE1IEBACiBmaQogCiBJTlNUQUxMRURfTElTVD0iJHtJTlNU QUxMRURfTElTVH1cdCR7aWxpc3R9XG4iCi1bIC1lICIkcGRiLyRuZXdfcG9ydC8rRElTUExBWSIg XSAmJiBESVNQTEFZX0xJU1Q9IiR7RElTUExBWV9MSVNUfSRuZXdfcG9ydCAiCitbIC16ICIkdXNl X3BrZ25nIiAtYSAtZSAiJHBkYi8kbmV3X3BvcnQvK0RJU1BMQVkiIC1vIC1uICIkdXNlX3BrZ25n IiAtYSAtbiAiYHBrZyBxdWVyeSAiJU0iICRuZXdfcG9ydGAiIF0gJiYKKwlESVNQTEFZX0xJU1Q9 IiR7RElTUExBWV9MSVNUfSRuZXdfcG9ydCAiCiBDVVJfREVQUz0iJHtDVVJfREVQU30ke25ld19w b3J0fToke3BvcnRkaXJ9OiIKIAogWyAtbiAiJEhJREVfQlVJTEQiIC1hIC1uICIkcG9ydF9sb2ci IF0gJiYgcG1fdW5saW5rICRwb3J0X2xvZwogCiBbIC1uICIkUE1fVVJCIiAtbyAtbiAiJFBNX1VS Ql9VUCIgXSAmJiBQTV9VUkJfRE9ORT0iJHtQTV9VUkJfRE9ORX0ke25ld19wb3J0fToiCiBbIC1u ICIkUE1fVVJCIiAtbyAtbiAiJFBNX1VSQl9VUCIgLW8gLW4gIiRQTV9GT1JDRSIgXSAmJgorCXBt X21rZGlyX3MgJHBkYi8kbmV3X3BvcnQgJiYKIAkkUE1fU1VfQ01EIHRvdWNoICRwZGIvJG5ld19w b3J0L1BNX1VQR1JBREVfRE9ORV9GTEFHCiAKIGlmIFsgLXogIiRET05UX1NDUlVCX0RJU1RGSUxF UyIgXTsgdGhlbgo= --20cf3074b4f49b7d9b04c6d5d258-- From owner-freebsd-current@FreeBSD.ORG Thu Aug 9 14:31:13 2012 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4A405106564A; Thu, 9 Aug 2012 14:31:13 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1-6.sentex.ca [IPv6:2607:f3e0:0:1::12]) by mx1.freebsd.org (Postfix) with ESMTP id 09B358FC0C; Thu, 9 Aug 2012 14:31:12 +0000 (UTC) Received: from [192.168.43.26] (pyroxene.sentex.ca [199.212.134.18]) by smarthost1.sentex.ca (8.14.5/8.14.5) with ESMTP id q79EVCA3055740; Thu, 9 Aug 2012 10:31:12 -0400 (EDT) (envelope-from mike@sentex.net) Message-ID: <5023C9A6.9070502@sentex.net> Date: Thu, 09 Aug 2012 10:31:02 -0400 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: John Baldwin References: <201208031418.57941.jhb@freebsd.org> <201208031726.03652.jhb@freebsd.org> <502121F5.4020705@sentex.net> <201208080727.45595.jhb@freebsd.org> <5022B252.30606@sentex.net> <5023AB9D.5070608@sentex.net> <5023B824.40405@FreeBSD.org> In-Reply-To: <5023B824.40405@FreeBSD.org> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.72 on 64.7.153.18 Cc: Garrett Cooper , current@FreeBSD.org Subject: Re: [PATCH] Add locking to twe(4) so it no longer uses Giant X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Aug 2012 14:31:13 -0000 On 8/9/2012 9:16 AM, John Baldwin wrote: >> One more data point, /dev/twe0 does not exist with the patch and I think >> thats why the utils fail outright. > > Oh, hmm. That's odd. Do you get any error messages on the console > when twe0 attaches? Also, you have INVARIANTS enabled, yes? > (make_dev() panics when it fails if INVARIANTS is enabled). I have INVARIANTS in the kernel, sorry, do I need to do something to make it active ? 0{offsite2}# sysctl -a | grep -i invar kern.features.invariant_support: 1 options INVARIANT_SUPPORT options INVARIANTS kern.timecounter.invariant_tsc: 1 TSC: P-state invariant, performance statistics TSC: P-state invariant, performance statistics TSC: P-state invariant, performance statistics TSC: P-state invariant, performance statistics 0{offsite2}# Nothing odd in dmesg ZFS filesystem version 5 ZFS storage pool version 28 Timecounters tick every 1.000 msec twed0 on twe0 twed0: 953878MB (1953542144 sectors) usbus0: 480Mbps High Speed USB v2.0 usbus1: 480Mbps High Speed USB v2.0 pci6: on pcib6 twe0: <3ware Storage Controller. Driver version 1.50.01.002> port 0x2000-0x200f mem 0xe2810000-0xe281000f,0xe2000000-0xe 27fffff at device 0.0 on pci6 twe0: 2 ports, Firmware FE8S 1.05.00.068, BIOS BE7X 1.08.00.048 isab0: at device 31.0 on pci0 Patch below is causing a panic now on boot. Just going to add debugging to the serial console to see what it is.... and 0{offsite2}# kldload twe twe0: <3ware Storage Controller. Driver version 1.50.01.002> port 0x2000-0x200f mem 0xe2810000-0xe281000f,0xe2000000-0xe27fffff at device 0.0 on pci6 twe0: [GIANT-LOCKED] Fatal trap 12: page fault while in kernel mode cpuid = 4; apic id = 04 fault virtual address = 0x3 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff81813eb3 stack pointer = 0x28:0xffffff84529d33f0 frame pointer = 0x28:0xffffff84529d3430 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 1324 (kldload) [ thread pid 1324 tid 100146 ] Stopped at twe_setup+0x153: movzbl 0x3(%rdx),%eax db> > > Maybe try something like this (relative to the patched driver): > > --- //depot/user/jhb/cleanup/sys/dev/twe/twe_freebsd.c 2012-08-03 > 18:10:04.000000000 0000 > +++ /Users/jhb/work/p4/cleanup/sys/dev/twe/twe_freebsd.c 2012-08-03 > 18:10:04.000000000 0000 > @@ -342,9 +342,12 @@ > /* > * Create the control device. > */ > + device_printf(sc->twe_dev, "Calling make_dev()\n"); > sc->twe_dev_t = make_dev(&twe_cdevsw, device_get_unit(sc->twe_dev), > UID_ROOT, GID_OPERATOR, > S_IRUSR | S_IWUSR, "twe%d", device_get_unit(sc->twe_dev)); > sc->twe_dev_t->si_drv1 = sc; > + device_printf(sc->twe_dev, "make_dev() returned %p (%s)\n", > sc->twe_dev_t, > + sc->twe_dev_t->si_name); > /* > * Schedule ourselves to bring the controller up once interrupts > are available. > * This isn't strictly necessary, since we disable interrupts while > probing the > > -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From owner-freebsd-current@FreeBSD.ORG Thu Aug 9 16:05:52 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D77611065672 for ; Thu, 9 Aug 2012 16:05:52 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-gg0-f182.google.com (mail-gg0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 894858FC16 for ; Thu, 9 Aug 2012 16:05:52 +0000 (UTC) Received: by ggnk4 with SMTP id k4so744180ggn.13 for ; Thu, 09 Aug 2012 09:05:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=Dp0C+QrDeuCNXHQ9RK9mtt21pDKtmMza4rom/Y7XyRQ=; b=LiCL4ymeOBtS+UIAp5Bv2kQiAMX1aHJbI3TKjVrEwFgSjm7uMFBMJOT0ntJcBWKFBd jjSddDcUlNkYlndUU7cVRFjgc/tweouX7GXFV3x0GxFoXoIfw9Qwf9cdnslRMZxLDcAs Vv9+x0Sp9KSmpEkO6ePzqyfGiXQ1ee2D3wv4f6q4ZcW1OHdFCQFkUiCTLAHFBiwh0V9Q 1PrGq6wmBoHqchJE03eGBJIOhpOxyABJlOpnijpw+6KplNTYEgXVrLTh6byY2u4a3kf+ mjv8XEtmCcL2bXg1N6HAqZZaCUGUaixyhrTuqSi2puloHnfYiGtgpTZ0igyUQpP11Wtf 53XQ== Received: by 10.60.10.6 with SMTP id e6mr36396795oeb.45.1344528351446; Thu, 09 Aug 2012 09:05:51 -0700 (PDT) Received: from [10.30.101.53] ([209.117.142.2]) by mx.google.com with ESMTPS id g8sm1143019obz.16.2012.08.09.09.05.49 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 09 Aug 2012 09:05:50 -0700 (PDT) Sender: Warner Losh Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <201208081941.17860.hselasky@c2i.net> Date: Thu, 9 Aug 2012 10:05:47 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120801160323.GN2676@deviant.kiev.zoral.com.ua> <201208081827.53824.hselasky@c2i.net> <201208081941.17860.hselasky@c2i.net> To: Hans Petter Selasky X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQlsFRh+pJsZRb8/ROMshVkW+Fm88JmVR+/+sympYW1ENHCx/QzI1fUlgFPbpWnhMOv4Ep02 Cc: Konstantin Belousov , Ed Schouten , freebsd-current@freebsd.org Subject: Re: ttydev_cdevsw has no d_purge X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Aug 2012 16:05:52 -0000 On Aug 8, 2012, at 11:41 AM, Hans Petter Selasky wrote: > On Wednesday 08 August 2012 19:24:18 Ed Schouten wrote: >>> Ed: I would really like to see a custom argument for the tsw_free(), >>> because it only needs to know the unit number, and the xsc for UCOM = is >>> freed when this is called and cannot be referred. Is it possible to = have >>> a separate "void *" for the tsw_free() function? Is this something = which >>> you can implement? >>=20 >> We could extend the TTY code to allow the softc to be changed, e.g. >> tty_set_softc(). This function could be called right before calling >> tty_rel_gone(). Still, I would prefer it if these kind of things = would >=20 > Are you sure that the new softc won't be used in any callbacks when=20 > tty_rel_gone() is called, except for tsw_free() ? >=20 >> not be part of the API. Is there really no way the deallocation of = the >> softc can be delayed until tsw_free() is called? >=20 > Yes, but that is inconvenient. We use the automatically allocated = softc given=20 > to the driver by newbus. When detach() returns, the softc is freed. = Then we=20 > need to block in detach, and that is causing the problem! I thought the detach protocol was such that you shouldn't return from = detach until all dangling references were gone. you could use tsw_free = to wake up the detach sleeper, no? Warner From owner-freebsd-current@FreeBSD.ORG Thu Aug 9 17:21:30 2012 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 81656106566C for ; Thu, 9 Aug 2012 17:21:30 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 5305C8FC08 for ; Thu, 9 Aug 2012 17:21:30 +0000 (UTC) Received: from John-Baldwins-MacBook-Air.local (d-69-161-105-82.cpe.metrocast.net [69.161.105.82]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 8FBCAB94A; Thu, 9 Aug 2012 13:21:29 -0400 (EDT) Message-ID: <5023F199.1090201@FreeBSD.org> Date: Thu, 09 Aug 2012 13:21:29 -0400 From: John Baldwin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Mike Tancsa References: <201208031418.57941.jhb@freebsd.org> <201208031726.03652.jhb@freebsd.org> <502121F5.4020705@sentex.net> <201208080727.45595.jhb@freebsd.org> <5022B252.30606@sentex.net> <5023AB9D.5070608@sentex.net> <5023B824.40405@FreeBSD.org> <5023C9A6.9070502@sentex.net> In-Reply-To: <5023C9A6.9070502@sentex.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 09 Aug 2012 13:21:29 -0400 (EDT) Cc: Garrett Cooper , current@FreeBSD.org Subject: Re: [PATCH] Add locking to twe(4) so it no longer uses Giant X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Aug 2012 17:21:30 -0000 On 8/9/12 10:31 AM, Mike Tancsa wrote: > On 8/9/2012 9:16 AM, John Baldwin wrote: >>> One more data point, /dev/twe0 does not exist with the patch and I think >>> thats why the utils fail outright. >> >> Oh, hmm. That's odd. Do you get any error messages on the console >> when twe0 attaches? Also, you have INVARIANTS enabled, yes? >> (make_dev() panics when it fails if INVARIANTS is enabled). > > I have INVARIANTS in the kernel, sorry, do I need to do something to > make it active ? > > 0{offsite2}# sysctl -a | grep -i invar > kern.features.invariant_support: 1 > options INVARIANT_SUPPORT > options INVARIANTS > kern.timecounter.invariant_tsc: 1 > TSC: P-state invariant, performance statistics > TSC: P-state invariant, performance statistics > TSC: P-state invariant, performance statistics > TSC: P-state invariant, performance statistics > 0{offsite2}# > > Nothing odd in dmesg > > ZFS filesystem version 5 > ZFS storage pool version 28 > Timecounters tick every 1.000 msec > twed0 on twe0 > twed0: 953878MB (1953542144 sectors) > usbus0: 480Mbps High Speed USB v2.0 > usbus1: 480Mbps High Speed USB v2.0 > > > pci6: on pcib6 > twe0: <3ware Storage Controller. Driver version 1.50.01.002> port > 0x2000-0x200f mem 0xe2810000-0xe281000f,0xe2000000-0xe > 27fffff at device 0.0 on pci6 > twe0: 2 ports, Firmware FE8S 1.05.00.068, BIOS BE7X 1.08.00.048 > isab0: at device 31.0 on pci0 > > > Patch below is causing a panic now on boot. Just going to add debugging > to the serial console to see what it is.... and > > 0{offsite2}# kldload twe > twe0: <3ware Storage Controller. Driver version 1.50.01.002> port > 0x2000-0x200f mem 0xe2810000-0xe281000f,0xe2000000-0xe27fffff at device > 0.0 on pci6 > twe0: [GIANT-LOCKED] Odd, the patched driver shouldn't be triggering this message. > Fatal trap 12: page fault while in kernel mode > cpuid = 4; apic id = 04 > fault virtual address = 0x3 > fault code = supervisor read data, page not present > instruction pointer = 0x20:0xffffffff81813eb3 > stack pointer = 0x28:0xffffff84529d33f0 > frame pointer = 0x28:0xffffff84529d3430 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 1324 (kldload) > [ thread pid 1324 tid 100146 ] > Stopped at twe_setup+0x153: movzbl 0x3(%rdx),%eax > db> Humm, I wonder if this module has a mix of old and new .o files somehow? Perhaps try rebuilding twe.ko from scratch after doing a 'make clean'? -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu Aug 9 19:28:42 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CB74F106564A; Thu, 9 Aug 2012 19:28:42 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1-6.sentex.ca [IPv6:2607:f3e0:0:1::12]) by mx1.freebsd.org (Postfix) with ESMTP id 8B67B8FC0A; Thu, 9 Aug 2012 19:28:42 +0000 (UTC) Received: from [192.168.43.26] (pyroxene.sentex.ca [199.212.134.18]) by smarthost1.sentex.ca (8.14.5/8.14.5) with ESMTP id q79JSfhF011065; Thu, 9 Aug 2012 15:28:41 -0400 (EDT) (envelope-from mike@sentex.net) Message-ID: <50240F5F.6000702@sentex.net> Date: Thu, 09 Aug 2012 15:28:31 -0400 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: John Baldwin References: <201208031418.57941.jhb@freebsd.org> <201208031726.03652.jhb@freebsd.org> <502121F5.4020705@sentex.net> <201208080727.45595.jhb@freebsd.org> <5022B252.30606@sentex.net> <5023AB9D.5070608@sentex.net> <5023B824.40405@FreeBSD.org> <5023C9A6.9070502@sentex.net> <5023F199.1090201@FreeBSD.org> In-Reply-To: <5023F199.1090201@FreeBSD.org> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.72 on 64.7.153.18 Cc: Garrett Cooper , current@freebsd.org Subject: Re: [PATCH] Add locking to twe(4) so it no longer uses Giant X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Aug 2012 19:28:42 -0000 On 8/9/2012 1:21 PM, John Baldwin wrote: > > Humm, I wonder if this module has a mix of old and new .o files somehow? > Perhaps try rebuilding twe.ko from scratch after doing a 'make clean'? I think you are right. I nuked all the kernel files and recompiled again, and it no longer panics and I see the entry in /dev now!? 0{offsite2}# kldload twe twe0: <3ware Storage Controller. Driver version 1.50.01.002> port 0x2000-0x200f mem 0xe2810000-0xe281000f,0xe2000000-0xe27fffff at device 0.0 on pci6 twe0: [GIANT-LOCKED] twe0: 2 ports, Firmware FE8S 1.05.00.068, BIOS BE7X 1.08.00.048 twe0: Calling make_dev() twe0: make_dev() returned 0xfffffe0122105200 (twe0) twed0 on twe0 twed0: 953878MB (1953542144 sectors) 0{offsite2}# ---Mike -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From owner-freebsd-current@FreeBSD.ORG Thu Aug 9 21:04:12 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id ADDA6106564A; Thu, 9 Aug 2012 21:04:12 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1-6.sentex.ca [IPv6:2607:f3e0:0:1::12]) by mx1.freebsd.org (Postfix) with ESMTP id 6C7F68FC18; Thu, 9 Aug 2012 21:04:12 +0000 (UTC) Received: from [192.168.43.26] (pyroxene.sentex.ca [199.212.134.18]) by smarthost1.sentex.ca (8.14.5/8.14.5) with ESMTP id q79L4BXb027834; Thu, 9 Aug 2012 17:04:11 -0400 (EDT) (envelope-from mike@sentex.net) Message-ID: <502425C0.5070303@sentex.net> Date: Thu, 09 Aug 2012 17:04:00 -0400 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: John Baldwin References: <201208031418.57941.jhb@freebsd.org> <201208031726.03652.jhb@freebsd.org> <502121F5.4020705@sentex.net> <201208080727.45595.jhb@freebsd.org> <5022B252.30606@sentex.net> <5023AB9D.5070608@sentex.net> <5023B824.40405@FreeBSD.org> <5023C9A6.9070502@sentex.net> <5023F199.1090201@FreeBSD.org> <50240F5F.6000702@sentex.net> In-Reply-To: <50240F5F.6000702@sentex.net> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.72 on 64.7.153.18 Cc: Garrett Cooper , current@freebsd.org Subject: Re: [PATCH] Add locking to twe(4) so it no longer uses Giant X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Aug 2012 21:04:12 -0000 On 8/9/2012 3:28 PM, Mike Tancsa wrote: > On 8/9/2012 1:21 PM, John Baldwin wrote: >> >> Humm, I wonder if this module has a mix of old and new .o files somehow? >> Perhaps try rebuilding twe.ko from scratch after doing a 'make clean'? > > I think you are right. I nuked all the kernel files and recompiled > again, and it no longer panics and I see the entry in /dev now!? > > 0{offsite2}# kldload twe > twe0: <3ware Storage Controller. Driver version 1.50.01.002> port > 0x2000-0x200f mem 0xe2810000-0xe281000f,0xe2000000-0xe27fffff at device > 0.0 on pci6 > twe0: [GIANT-LOCKED] > twe0: 2 ports, Firmware FE8S 1.05.00.068, BIOS BE7X 1.08.00.048 > twe0: Calling make_dev() > twe0: make_dev() returned 0xfffffe0122105200 (twe0) > twed0 on twe0 > twed0: 953878MB (1953542144 sectors) > 0{offsite2}# OK, some more mystery. If I load it as a kld, I see the device. (Note, I added MDT into the version string) 0{offsite2}# twe0: <3ware Storage Controller. Driver version 1.50.01.002MDT> port 0x2000-0x200f mem 0xe2810000-0xe281000f,0xe2000000-0xe27fffff at device 0.0 on pci6 twe0: 2 ports, Firmware FE8S 1.05.00.068, BIOS BE7X 1.08.00.048 twe0: Calling make_dev() twe0: make_dev() returned 0xfffffe0026581a00 (twe0) twed0 on twe0 twed0: 953878MB (1953542144 sectors) 0{offsite2}# ls -l /dev/tw* crw------- 1 root operator - 0, 37 Aug 9 16:58 /dev/twa0 crw------- 1 root operator - 0, 173 Aug 9 17:00 /dev/twe0 crw-r----- 1 root operator - 0, 174 Aug 9 17:00 /dev/twed0 Start up the tw_cli client 0{offsite2}# tw_cli //offsite2> show Ctl Model (V)Ports Drives Units NotOpt RRate VRate BBU ------------------------------------------------------------------------ c0 9650SE-2LP 2 2 1 0 1 1 - //offsite2> exit 0{offsite2}# ls -l /dev/tw* crw------- 1 root operator - 0, 37 Aug 9 16:58 /dev/twa0 crw-r----- 1 root operator - 0, 174 Aug 9 17:00 /dev/twed0 0{offsite2}# It then disappears ?! ---Mike -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From owner-freebsd-current@FreeBSD.ORG Fri Aug 10 13:31:53 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 229B3106567F for ; Fri, 10 Aug 2012 13:31:53 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 7DE2F8FC1F for ; Fri, 10 Aug 2012 13:31:50 +0000 (UTC) Received: from John-Baldwins-MacBook-Air.local (d-69-161-105-82.cpe.metrocast.net [69.161.105.82]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 866EBB941; Fri, 10 Aug 2012 09:31:49 -0400 (EDT) Message-ID: <50250D48.6020101@FreeBSD.org> Date: Fri, 10 Aug 2012 09:31:52 -0400 From: John Baldwin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Mike Tancsa References: <201208031418.57941.jhb@freebsd.org> <201208031726.03652.jhb@freebsd.org> <502121F5.4020705@sentex.net> <201208080727.45595.jhb@freebsd.org> <5022B252.30606@sentex.net> <5023AB9D.5070608@sentex.net> <5023B824.40405@FreeBSD.org> <5023C9A6.9070502@sentex.net> <5023F199.1090201@FreeBSD.org> <50240F5F.6000702@sentex.net> <502425C0.5070303@sentex.net> In-Reply-To: <502425C0.5070303@sentex.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 10 Aug 2012 09:31:50 -0400 (EDT) Cc: Garrett Cooper , current@freebsd.org Subject: Re: [PATCH] Add locking to twe(4) so it no longer uses Giant X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Aug 2012 13:31:53 -0000 On 8/9/12 5:04 PM, Mike Tancsa wrote: > Start up the tw_cli client > > 0{offsite2}# tw_cli > //offsite2> show > > Ctl Model (V)Ports Drives Units NotOpt RRate VRate BBU > ------------------------------------------------------------------------ > c0 9650SE-2LP 2 2 1 0 1 1 - > > > //offsite2> exit > 0{offsite2}# ls -l /dev/tw* > crw------- 1 root operator - 0, 37 Aug 9 16:58 /dev/twa0 > crw-r----- 1 root operator - 0, 174 Aug 9 17:00 /dev/twed0 > 0{offsite2}# > > > It then disappears ?! Bizarre, it seems to disappear while tw_cli is running? I'm curious if 'rm -W /dev/twe0' brings it back? If so, it might be interesting to see a ktrace of tw_cli. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Aug 10 13:36:30 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CAC03106564A for ; Fri, 10 Aug 2012 13:36:30 +0000 (UTC) (envelope-from bsam@passap.ru) Received: from forward5h.mail.yandex.net (forward5h.mail.yandex.net [IPv6:2a02:6b8:0:f05::5]) by mx1.freebsd.org (Postfix) with ESMTP id 495F78FC18 for ; Fri, 10 Aug 2012 13:36:30 +0000 (UTC) Received: from smtp4h.mail.yandex.net (smtp4h.mail.yandex.net [84.201.186.21]) by forward5h.mail.yandex.net (Yandex) with ESMTP id 108B3D00D24; Fri, 10 Aug 2012 17:36:27 +0400 (MSK) Received: from smtp4h.mail.yandex.net (localhost [127.0.0.1]) by smtp4h.mail.yandex.net (Yandex) with ESMTP id CE62F2C0169; Fri, 10 Aug 2012 17:36:27 +0400 (MSK) Received: from 87.249.28.59.tel.ru (87.249.28.59.tel.ru [87.249.28.59]) by smtp4h.mail.yandex.net (nwsmtp/Yandex) with ESMTP id aRAag9MM-aRAm1ieZ; Fri, 10 Aug 2012 17:36:27 +0400 Message-ID: <50250E5B.6060505@passap.ru> Date: Fri, 10 Aug 2012 17:36:27 +0400 From: Boris Samorodov User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:14.0) Gecko/20120728 Thunderbird/14.0 MIME-Version: 1.0 To: David Wolfskill References: <5023A9E8.6040503@passap.ru> <20120809122602.GU1464@albert.catwhisker.org> In-Reply-To: <20120809122602.GU1464@albert.catwhisker.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-current@freebsd.org Subject: Re: [clang] kernel build failure X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Aug 2012 13:36:30 -0000 09.08.2012 16:26, David Wolfskill пишет: > On Thu, Aug 09, 2012 at 04:15:36PM +0400, Boris Samorodov wrote: >> Hi! >> >> The kernel build fails at fresh CURRENT... >> And then I get an error: >> ----- >> linking kernel.debug >> cam_periph.o: In function `cam_periph_error': >> /usr/src/sys/cam/cam_periph.c:1776: undefined reference to >> `scsi_extract_sense_ccb' >> scsi_cd.o: In function `cdasync': >> /usr/src/sys/cam/scsi/scsi_cd.c:571: undefined reference to >> `scsi_extract_sense_ccb' >> scsi_da.o: In function `daasync': >> /usr/src/sys/cam/scsi/scsi_da.c:1394: undefined reference to >> `scsi_extract_sense_ccb' >> *** [kernel.debug] Error code 1 >> ----- >> >> The system...: >> ----- >> % uname -a >> FreeBSD bsam.wart.ru 10.0-CURRENT FreeBSD 10.0-CURRENT #21 r238828M: Fri >> Jul 27 16:26:02 SAMT 2012 bsam@bsam.wart.ru:/usr/obj/usr/src/sys/BBX >> i386 >> ----- > > I had no trouble (just now); was running: > > FreeBSD g1-227.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT #645 239138M: Wed Aug 8 04:44:43 PDT 2012 root@g1-227.catwhisker.org:/usr/obj/usr/src/sys/CANARY i386 > > now running: > > FreeBSD g1-227.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT #646 239148M: Thu Aug 9 05:04:05 PDT 2012 root@g1-227.catwhisker.org:/usr/obj/usr/src/sys/CANARY i386 I appeared to have some stale patches: ----- % svn st /usr/src M /usr/src/sys/cam/cam_periph.c M /usr/src/sys/cam/scsi/scsi_all.c M /usr/src/sys/cam/scsi/scsi_all.h M /usr/src/sys/cam/scsi/scsi_cd.c M /usr/src/sys/cam/scsi/scsi_da.c ----- Reverting helped here. Thanks for your cooperation! -- WBR, Boris Samorodov (bsam) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-current@FreeBSD.ORG Fri Aug 10 13:39:16 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D943010656D1 for ; Fri, 10 Aug 2012 13:39:16 +0000 (UTC) (envelope-from edschouten@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 9AF988FC18 for ; Fri, 10 Aug 2012 13:39:16 +0000 (UTC) Received: by mail-ob0-f182.google.com with SMTP id un3so3021567obb.13 for ; Fri, 10 Aug 2012 06:39:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=+1/84s4MVMa8dsP5fhpcmJjIrxY47Y4ypezZKIxu1WA=; b=UkAIY5S0d+3EMExlCE/rwU+DGGlLOT3zzzybWTkpqU490J3ZhU3yIKHdwY/IBDJnI6 F60UJuMY8s82UfaH8ALE2d+gaGmkcQWLtxaT/O8IaxTMfi0fzUGEYRi5OknMkczAn57U +kL2ln8/XiWKWIFF1285JxWCT2vYaiTDwF312JGMRjPbFMPx9hs2P0vqJUsju7S2ygKQ OxpiH8pNt5+kgsKVXX4q+IrPspb1Mvo3KzsAJGscbpmfbd1iax7rHdlfPg2Y7AteBG9l 9qF6lIdQ3sdGLKalq03gqZ8PJUUQ15gL/PZZwRKbOABv06fNzxnD1wMfQ1btzlqGioIi 40UQ== MIME-Version: 1.0 Received: by 10.60.19.34 with SMTP id b2mr4144132oee.41.1344605956473; Fri, 10 Aug 2012 06:39:16 -0700 (PDT) Sender: edschouten@gmail.com Received: by 10.76.173.197 with HTTP; Fri, 10 Aug 2012 06:39:16 -0700 (PDT) In-Reply-To: <201208090851.56972.hselasky@c2i.net> References: <20120801160323.GN2676@deviant.kiev.zoral.com.ua> <201208081941.17860.hselasky@c2i.net> <201208090851.56972.hselasky@c2i.net> Date: Fri, 10 Aug 2012 15:39:16 +0200 X-Google-Sender-Auth: ZNZmWTgPfcBjqt7O_afJJ0lqyx4 Message-ID: From: Ed Schouten To: Hans Petter Selasky Content-Type: text/plain; charset=UTF-8 Cc: Konstantin Belousov , freebsd-current@freebsd.org Subject: Re: ttydev_cdevsw has no d_purge X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Aug 2012 13:39:17 -0000 Hi Hans, 2012/8/9 Hans Petter Selasky : > 1) Use unrhdr. Suggested by ed. Thanks! > 2) Implement tty_set_softc() and use that when dereffing ucom unit numbers. We're getting there. Now that I think of it, if we want to go in this direction, we might as well do the following: - Simply call tty_alloc() -- not tty_alloc_mutex(). I'd rather get rid of this functionality altogether, if possible. - Use the TTY mutex to lock down the state of the ucom driver, e.g. #define ucom_lock(sc) tty_lock(sc->sc_mtx). Any thoughts? -- Ed Schouten From owner-freebsd-current@FreeBSD.ORG Fri Aug 10 13:52:51 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B1DA0106566B; Fri, 10 Aug 2012 13:52:51 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1-6.sentex.ca [IPv6:2607:f3e0:0:1::12]) by mx1.freebsd.org (Postfix) with ESMTP id 6C9558FC15; Fri, 10 Aug 2012 13:52:51 +0000 (UTC) Received: from [192.168.43.26] (pyroxene.sentex.ca [199.212.134.18]) by smarthost1.sentex.ca (8.14.5/8.14.5) with ESMTP id q7ADqoNf002082; Fri, 10 Aug 2012 09:52:50 -0400 (EDT) (envelope-from mike@sentex.net) Message-ID: <50251226.8020805@sentex.net> Date: Fri, 10 Aug 2012 09:52:38 -0400 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: John Baldwin References: <201208031418.57941.jhb@freebsd.org> <201208031726.03652.jhb@freebsd.org> <502121F5.4020705@sentex.net> <201208080727.45595.jhb@freebsd.org> <5022B252.30606@sentex.net> <5023AB9D.5070608@sentex.net> <5023B824.40405@FreeBSD.org> <5023C9A6.9070502@sentex.net> <5023F199.1090201@FreeBSD.org> <50240F5F.6000702@sentex.net> <502425C0.5070303@sentex.net> <50250D48.6020101@FreeBSD.org> In-Reply-To: <50250D48.6020101@FreeBSD.org> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.72 on 64.7.153.18 Cc: Garrett Cooper , current@freebsd.org Subject: Re: [PATCH] Add locking to twe(4) so it no longer uses Giant X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Aug 2012 13:52:51 -0000 On 8/10/2012 9:31 AM, John Baldwin wrote: > On 8/9/12 5:04 PM, Mike Tancsa wrote: >> Start up the tw_cli client >> >> 0{offsite2}# tw_cli >> //offsite2> show >> >> Ctl Model (V)Ports Drives Units NotOpt RRate VRate BBU >> ------------------------------------------------------------------------ >> c0 9650SE-2LP 2 2 1 0 1 1 - >> >> >> //offsite2> exit >> 0{offsite2}# ls -l /dev/tw* >> crw------- 1 root operator - 0, 37 Aug 9 16:58 /dev/twa0 >> crw-r----- 1 root operator - 0, 174 Aug 9 17:00 /dev/twed0 >> 0{offsite2}# >> >> >> It then disappears ?! > > Bizarre, it seems to disappear while tw_cli is running? I'm curious if > 'rm -W /dev/twe0' brings it back? nada 0{offsite2}# rm -W /dev/twe0 rm: /dev/twe0: No such file or directory 1{offsite2}# rm -W /dev/twe0 rm: /dev/twe0: No such file or directory 1{offsite2}# ls -l /dev/twe* crw-r----- 1 root operator - 0, 174 Aug 9 17:00 /dev/twed0 0{offsite2}# > > If so, it might be interesting to see a ktrace of tw_cli. > I just ran ktrace tw_cli File is available at http://www.tancsa.com/misc/ktrace.out and http://www.tancsa.com/misc/ktrace.txt ---Mike -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From owner-freebsd-current@FreeBSD.ORG Fri Aug 10 14:05:33 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9B70D106566C for ; Fri, 10 Aug 2012 14:05:33 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 694568FC0C for ; Fri, 10 Aug 2012 14:05:33 +0000 (UTC) Received: from John-Baldwins-MacBook-Air.local (d-69-161-105-82.cpe.metrocast.net [69.161.105.82]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 814C7B946; Fri, 10 Aug 2012 10:05:32 -0400 (EDT) Message-ID: <50251530.2060502@FreeBSD.org> Date: Fri, 10 Aug 2012 10:05:36 -0400 From: John Baldwin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Mike Tancsa References: <201208031418.57941.jhb@freebsd.org> <201208031726.03652.jhb@freebsd.org> <502121F5.4020705@sentex.net> <201208080727.45595.jhb@freebsd.org> <5022B252.30606@sentex.net> <5023AB9D.5070608@sentex.net> <5023B824.40405@FreeBSD.org> <5023C9A6.9070502@sentex.net> <5023F199.1090201@FreeBSD.org> <50240F5F.6000702@sentex.net> <502425C0.5070303@sentex.net> <50250D48.6020101@FreeBSD.org> <50251226.8020805@sentex.net> In-Reply-To: <50251226.8020805@sentex.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 10 Aug 2012 10:05:33 -0400 (EDT) Cc: Garrett Cooper , current@freebsd.org Subject: Re: [PATCH] Add locking to twe(4) so it no longer uses Giant X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Aug 2012 14:05:33 -0000 On 8/10/12 9:52 AM, Mike Tancsa wrote: > On 8/10/2012 9:31 AM, John Baldwin wrote: >> On 8/9/12 5:04 PM, Mike Tancsa wrote: >>> Start up the tw_cli client >>> >>> 0{offsite2}# tw_cli >>> //offsite2> show >>> >>> Ctl Model (V)Ports Drives Units NotOpt RRate VRate BBU >>> ------------------------------------------------------------------------ >>> c0 9650SE-2LP 2 2 1 0 1 1 - >>> >>> >>> //offsite2> exit >>> 0{offsite2}# ls -l /dev/tw* >>> crw------- 1 root operator - 0, 37 Aug 9 16:58 /dev/twa0 >>> crw-r----- 1 root operator - 0, 174 Aug 9 17:00 /dev/twed0 >>> 0{offsite2}# >>> >>> >>> It then disappears ?! >> >> Bizarre, it seems to disappear while tw_cli is running? I'm curious if >> 'rm -W /dev/twe0' brings it back? > > nada > 0{offsite2}# rm -W /dev/twe0 > rm: /dev/twe0: No such file or directory > 1{offsite2}# rm -W /dev/twe0 > rm: /dev/twe0: No such file or directory > 1{offsite2}# ls -l /dev/twe* > crw-r----- 1 root operator - 0, 174 Aug 9 17:00 /dev/twed0 > 0{offsite2}# > >> >> If so, it might be interesting to see a ktrace of tw_cli. >> > > I just ran ktrace tw_cli > File is available at > > http://www.tancsa.com/misc/ktrace.out > and > http://www.tancsa.com/misc/ktrace.txt 5972 tw_cli CALL __sysctl(0x7fffffffd798,0x2,0x7fffffffd7a0,0x7fffffffd790,0x7fffffffd960,0x16) 5972 tw_cli SCTL "sysctl.name2oid" 5972 tw_cli RET __sysctl -1 errno 2 No such file or directory 5972 tw_cli CALL unlink(0x7fffffffd9d0) 5972 tw_cli NAMI "/dev/twe0" 5972 tw_cli RET unlink 0 ... Oh! I moved the sysctl's for twe out of hw and under the device node. That seem to have broken tw_cli. I will revert that and generate an updated patch. Try http://www.FreeBSD.org/~jhb/patches/twe_locking2.patch -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Aug 10 14:39:10 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 28383106566C for ; Fri, 10 Aug 2012 14:39:10 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe07.c2i.net [212.247.154.194]) by mx1.freebsd.org (Postfix) with ESMTP id A3C828FC16 for ; Fri, 10 Aug 2012 14:39:08 +0000 (UTC) X-T2-Spam-Status: No, hits=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 Received: from [176.74.212.201] (account mc467741@c2i.net HELO laptop015.hselasky.homeunix.org) by mailfe07.swip.net (CommuniGate Pro SMTP 5.4.4) with ESMTPA id 306293988; Fri, 10 Aug 2012 16:39:02 +0200 From: Hans Petter Selasky To: Ed Schouten Date: Fri, 10 Aug 2012 16:39:34 +0200 User-Agent: KMail/1.13.7 (FreeBSD/9.1-PRERELEASE; KDE/4.8.4; amd64; ; ) References: <20120801160323.GN2676@deviant.kiev.zoral.com.ua> <201208090851.56972.hselasky@c2i.net> In-Reply-To: X-Face: 'mmZ:T{)),Oru^0c+/}w'`gU1$ubmG?lp!=R4Wy\ELYo2)@'UZ24N@d2+AyewRX}mAm; Yp |U[@, _z/([?1bCfM{_"B<.J>mICJCHAzzGHI{y7{%JVz%R~yJHIji`y>Y}k1C4TfysrsUI -%GU9V5]iUZF&nRn9mJ'?&>O MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201208101639.34082.hselasky@c2i.net> Cc: Konstantin Belousov , freebsd-current@freebsd.org Subject: Re: ttydev_cdevsw has no d_purge X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Aug 2012 14:39:10 -0000 On Friday 10 August 2012 15:39:16 Ed Schouten wrote: > Hi Hans, > > 2012/8/9 Hans Petter Selasky : > > 1) Use unrhdr. Suggested by ed. > > Thanks! > > > 2) Implement tty_set_softc() and use that when dereffing ucom unit > > numbers. > > We're getting there. Now that I think of it, if we want to go in this > direction, we might as well do the following: > > - Simply call tty_alloc() -- not tty_alloc_mutex(). I'd rather get rid > of this functionality altogether, if possible. > - Use the TTY mutex to lock down the state of the ucom driver, e.g. > #define ucom_lock(sc) tty_lock(sc->sc_mtx). > > Any thoughts? Hi, Not possible :-( It will cause a hell inside ucom when multiple tty's are present having each their lock sharing the same USB device and possibly also an ethernet interface on the same softc. KISS: One lock per softc. No more no less. You're simply pushing a problem into ucom, that ucom has do do refcounting which should be generic for all TTY clients. BTW: I've changed by solutions a little bit to be more generic. I will commit it shortly. There are more problems like kldunload() and how you need to block kldunload() from completing when a softc is pending for tsw_free(). --HPS From owner-freebsd-current@FreeBSD.ORG Fri Aug 10 16:06:25 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E4A79106566B for ; Fri, 10 Aug 2012 16:06:25 +0000 (UTC) (envelope-from pfg@freebsd.org) Received: from nm30-vm4.bullet.mail.ne1.yahoo.com (nm30-vm4.bullet.mail.ne1.yahoo.com [98.138.91.190]) by mx1.freebsd.org (Postfix) with ESMTP id 8B8828FC15 for ; Fri, 10 Aug 2012 16:06:25 +0000 (UTC) Received: from [98.138.90.52] by nm30.bullet.mail.ne1.yahoo.com with NNFMP; 10 Aug 2012 16:06:19 -0000 Received: from [98.138.89.171] by tm5.bullet.mail.ne1.yahoo.com with NNFMP; 10 Aug 2012 16:06:19 -0000 Received: from [127.0.0.1] by omp1027.mail.ne1.yahoo.com with NNFMP; 10 Aug 2012 16:06:19 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 687628.31140.bm@omp1027.mail.ne1.yahoo.com Received: (qmail 9612 invoked by uid 60001); 10 Aug 2012 16:06:18 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1344614778; bh=pCjjYrYDtz8aF6PECWV9SO9NdjBdXNo7/5OpGlt2ED0=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=fNAGZLC8G9h5cDiz4o2YFpaV6ambFfsFAy7lvPXsIgfMdrWKre90YsydV5X4PjMi4NElkTiqc9ZcYZGIZZXRp1xFrYQ6jamqNIXJO4qg6fybqhWB7mcjIBgrfHClX1xrir3rh4yU1iX/rBvgIQnC3qTR6ulN9/mXeFdY9BfER+I= X-YMail-OSG: NtEL5JUVM1mwxl5JKjW.5bi9DNopbCCYIdWelgrUVo2ocgh AkGpoEYTav_ZitTQVgGQoLWjc6WmsUzRJWAs7pU_XjI4FCXYGIXIxdvrRuOG ExKQbLfWKj3V5tCP4B5I4L7EFZFkeacYPdJuXDHLhSp_bsf8D6ZexR7qIuVo R761LYdfXMF9DqE2c3kTSedi.abOtEK9ICxqytxKIQkkoo_RhZVlXI3mJXHm 6_p4JnRRFakT25MNp4WK33NBYdhpsddDCjuUz0SBmUSqPhHK2KEuX7Ni.1vz x087PKN0b6tR4R.7gTPtKwVuEbaLf9pmHncsXUn4GMdjTMEAy2IuaXiVoW0z IAQRdYhM7DQ_5EyQ_lgtgXk6QIxSVwDF_UUT7zmYZw6pcIF35nv8ru6S.Xj2 Gg1R4Dcy4yHFvVuugerk9PYTrfsHPmn.H8t.OYfxAJYwGCoEKpF6qG5Zuiza Nll9rgJN2D1TpO.t4wYz7brDnErdImRHONaQL1cjfcq6LJNuvt09B6WzvNXE sNLyH7m14CFKY5Ei2f_OcN9JXStV7NitcKK4o4nU8YDnFiwEebJ9ulvTbVxI 9Jk528pRH2V0YvlcO52cXtsxFyACE6QwwJxfFfAsXxOTE_gosHxNuKKFQPwy KQpdQueXzA_1LPi.ljRb8DT7nY1ST_X0- Received: from [200.118.157.7] by web113519.mail.gq1.yahoo.com via HTTP; Fri, 10 Aug 2012 09:06:18 PDT X-RocketYMMF: giffunip X-Mailer: YahooMailWebService/0.8.120.356233 Message-ID: <1344614778.3922.YahooMailNeo@web113519.mail.gq1.yahoo.com> Date: Fri, 10 Aug 2012 09:06:18 -0700 (PDT) From: Pedro Giffuni To: Free BSD Current MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: MS Hyper-v for FreeBSD announced X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Pedro Giffuni List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 16:06:26 -0000 Hi guys,=0A=0AYesterday, per chance, I had the idea of looking up what the = status=0Aof the Hyper-V drivers was and I found the announcement:=0A=0Ahttp= ://blogs.technet.com/b/openness/archive/2012/08/09/available-today-freebsd-= support-for-windows-server-hyper-v.aspx=A0=0A=0A=0AThe announcement is much= easier to find through Bing than=0Athrough Google :).=0A=0AKudos to everyo= ne involved and hope we see it soon in -current.=0A=0APedro.=0A From owner-freebsd-current@FreeBSD.ORG Fri Aug 10 16:06:40 2012 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 510EA106571F; Fri, 10 Aug 2012 16:06:40 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1-6.sentex.ca [IPv6:2607:f3e0:0:1::12]) by mx1.freebsd.org (Postfix) with ESMTP id DAE5A8FC17; Fri, 10 Aug 2012 16:06:39 +0000 (UTC) Received: from [192.168.43.26] (pyroxene.sentex.ca [199.212.134.18]) by smarthost1.sentex.ca (8.14.5/8.14.5) with ESMTP id q7AG6cpG025997; Fri, 10 Aug 2012 12:06:38 -0400 (EDT) (envelope-from mike@sentex.net) Message-ID: <50253182.4030702@sentex.net> Date: Fri, 10 Aug 2012 12:06:26 -0400 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: John Baldwin References: <201208031418.57941.jhb@freebsd.org> <201208031726.03652.jhb@freebsd.org> <502121F5.4020705@sentex.net> <201208080727.45595.jhb@freebsd.org> <5022B252.30606@sentex.net> <5023AB9D.5070608@sentex.net> <5023B824.40405@FreeBSD.org> <5023C9A6.9070502@sentex.net> <5023F199.1090201@FreeBSD.org> <50240F5F.6000702@sentex.net> <502425C0.5070303@sentex.net> <50250D48.6020101@FreeBSD.org> <50251226.8020805@sentex.net> <50251530.2060502@FreeBSD.org> In-Reply-To: <50251530.2060502@FreeBSD.org> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.72 on 64.7.153.18 Cc: Garrett Cooper , current@FreeBSD.org Subject: Re: [PATCH] Add locking to twe(4) so it no longer uses Giant X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Aug 2012 16:06:40 -0000 On 8/10/2012 10:05 AM, John Baldwin wrote: > > 5972 tw_cli CALL > __sysctl(0x7fffffffd798,0x2,0x7fffffffd7a0,0x7fffffffd790,0x7fffffffd960,0x16) > 5972 tw_cli SCTL "sysctl.name2oid" > 5972 tw_cli RET __sysctl -1 errno 2 No such file or directory > 5972 tw_cli CALL unlink(0x7fffffffd9d0) > 5972 tw_cli NAMI "/dev/twe0" > 5972 tw_cli RET unlink 0 > ... > > Oh! I moved the sysctl's for twe out of hw and under the device node. > That seem to have broken tw_cli. I will revert that and generate an > updated patch. > > Try http://www.FreeBSD.org/~jhb/patches/twe_locking2.patch > Looks good! Both the tw_cli and 3dm2 web interface work now. Doing some simple disk tests show everything to be pretty well the same. new driver 0{offsite2}# dd if=/dev/zero of=/mnt/test bs=1024k count=1000 1000+0 records in 1000+0 records out 1048576000 bytes transferred in 14.677410 secs (71441488 bytes/sec) 0{offsite2}# dd if=/mnt/test of=/dev/null bs=1024 1024000+0 records in 1024000+0 records out 1048576000 bytes transferred in 10.325622 secs (101550879 bytes/sec) 0{offsite2}# umount /mnt ; mount /dev/twed0 /mnt 0{offsite2}# dd if=/mnt/test of=/dev/null bs=2048 512000+0 records in 512000+0 records out 1048576000 bytes transferred in 10.347670 secs (101334503 bytes/sec) 0{offsite2}# old driver 0{offsite2}# dd if=/dev/zero of=/mnt/test bs=1024k count=1000 1000+0 records in 1000+0 records out 1048576000 bytes transferred in 14.695589 secs (71353111 bytes/sec) 0{offsite2}# umount /mnt ; mount /dev/twed0 /mnt 0{offsite2}# dd if=/mnt/test of=/dev/null bs=2048 512000+0 records in 512000+0 records out 1048576000 bytes transferred in 10.305835 secs (101745856 bytes/sec) 0{offsite2}# I will do some more stress tests through the day 0{offsite2}# patch -p9 < twe_locking2.patch Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |--- //depot/vendor/freebsd/src/sys/dev/twe/twe.c 2009-12-25 17:35:14.000000000 0000 |+++ //depot/user/jhb/cleanup/sys/dev/twe/twe.c 2012-08-03 04:00:49.000000000 0000 -------------------------- Patching file twe.c using Plan A... Hunk #1 succeeded at 151. Hunk #2 succeeded at 167. Hunk #3 succeeded at 189. Hunk #4 succeeded at 208. Hunk #5 succeeded at 226. Hunk #6 succeeded at 234. Hunk #7 succeeded at 271. Hunk #8 succeeded at 288. Hunk #9 succeeded at 310. Hunk #10 succeeded at 337. Hunk #11 succeeded at 349. Hunk #12 succeeded at 405. Hunk #13 succeeded at 521. Hunk #14 succeeded at 557. Hunk #15 succeeded at 580. Hunk #16 succeeded at 595. Hunk #17 succeeded at 608. Hunk #18 succeeded at 646. Hunk #19 succeeded at 769. Hunk #20 succeeded at 863. Hunk #21 succeeded at 921. Hunk #22 succeeded at 952. Hunk #23 succeeded at 1038. Hunk #24 succeeded at 1051. Hunk #25 succeeded at 1082. Hunk #26 succeeded at 1104. Hunk #27 succeeded at 1140. Hunk #28 succeeded at 1151. Hunk #29 succeeded at 1177. Hunk #30 succeeded at 1206. Hunk #31 succeeded at 1309. Hunk #32 succeeded at 1447. Hunk #33 succeeded at 1469. Hunk #34 succeeded at 1499. Hunk #35 succeeded at 1513. Hunk #36 succeeded at 1531. Hunk #37 succeeded at 1554. Hunk #38 succeeded at 1589. Hunk #39 succeeded at 1618. Hunk #40 succeeded at 1644. Hunk #41 succeeded at 1696. Hunk #42 succeeded at 1778. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |--- //depot/vendor/freebsd/src/sys/dev/twe/twe_compat.h 2005-05-29 04:45:51.000000000 0000 |+++ //depot/user/jhb/cleanup/sys/dev/twe/twe_compat.h 2012-08-03 03:58:12.000000000 0000 -------------------------- Patching file twe_compat.h using Plan A... Hunk #1 succeeded at 43. Hunk #2 succeeded at 68. Hunk #3 succeeded at 82. Hunk #4 succeeded at 92. Hunk #5 succeeded at 108. Hunk #6 succeeded at 128. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |--- //depot/vendor/freebsd/src/sys/dev/twe/twe_freebsd.c 2012-03-12 08:05:24.000000000 0000 |+++ //depot/user/jhb/cleanup/sys/dev/twe/twe_freebsd.c 2012-08-10 14:04:10.000000000 0000 -------------------------- Patching file twe_freebsd.c using Plan A... Hunk #1 succeeded at 69. Hunk #2 succeeded at 83. Hunk #3 succeeded at 101. Hunk #4 succeeded at 179. Hunk #5 succeeded at 189. Hunk #6 succeeded at 218. Hunk #7 succeeded at 248. Hunk #8 succeeded at 299. Hunk #9 succeeded at 421. Hunk #10 succeeded at 432. Hunk #11 succeeded at 468. Hunk #12 succeeded at 503. Hunk #13 succeeded at 525. Hunk #14 succeeded at 540. Hunk #15 succeeded at 573. Hunk #16 succeeded at 592. Hunk #17 succeeded at 611. Hunk #18 succeeded at 687. Hunk #19 succeeded at 736. Hunk #20 succeeded at 841. Hunk #21 succeeded at 864. Hunk #22 succeeded at 883. Hunk #23 succeeded at 1045. Hunk #24 succeeded at 1104. Hunk #25 succeeded at 1158. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |--- //depot/vendor/freebsd/src/sys/dev/twe/twevar.h 2009-12-25 17:35:14.000000000 0000 |+++ //depot/user/jhb/cleanup/sys/dev/twe/twevar.h 2012-08-03 04:00:49.000000000 0000 -------------------------- Patching file twevar.h using Plan A... Hunk #1 succeeded at 134. Hunk #2 succeeded at 210. Hunk #3 succeeded at 255. done 0{offsite2}# Looks good! //offsite2> show Ctl Model (V)Ports Drives Units NotOpt RRate VRate BBU ------------------------------------------------------------------------ c0 8006-2LP 2 2 1 0 3 - - c1 9650SE-2LP 2 2 1 0 1 1 - //offsite2> /c0 show Unit UnitType Status %RCmpl %V/I/M Stripe Size(GB) Cache AVrfy ------------------------------------------------------------------------------ u0 RAID-0 OK - - 64K 931.521 ON - Port Status Unit Size Blocks Serial --------------------------------------------------------------- p0 OK u0 465.76 GB 976773168 WD-WCAYUEY18298 p1 OK u0 465.76 GB 976773168 WD-WMAYUL256317 //offsite2> /c1 show Unit UnitType Status %RCmpl %V/I/M Stripe Size(GB) Cache AVrfy ------------------------------------------------------------------------------ u0 RAID-1 OK - - - 465.651 RiW ON VPort Status Unit Size Type Phy Encl-Slot Model ------------------------------------------------------------------------------ p0 OK u0 465.76 GB SATA 0 - WDC WD5002AALX-00J3 p1 OK u0 465.76 GB SATA 1 - WDC WD5002AALX-00J3 //offsite2> -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From owner-freebsd-current@FreeBSD.ORG Fri Aug 10 17:19:22 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B1A1E106564A for ; Fri, 10 Aug 2012 17:19:22 +0000 (UTC) (envelope-from bryan@shatow.net) Received: from secure.xzibition.com (secure.xzibition.com [173.160.118.92]) by mx1.freebsd.org (Postfix) with ESMTP id 536F38FC0A for ; Fri, 10 Aug 2012 17:19:22 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; c=nofws; d=shatow.net; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sweb; b=z9UN8M BC3kt9Jqa47U9ghF2OSpZ+8J5UITi7mOcyrsAs2DV2k1pSH+YDhXi2Y3hHzChkHl dXU5DRJJ5FhI2HLYfOKe2ZSmz2Nmv6QBlxEo5X16Z1yqDrbaz4tPymlUyFyqNe1M /dgqUIVYVgO1HYuu9yBlD8eNvwAYXOGO8yxbU= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=shatow.net; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sweb; bh=kBTkVojXZH46 2s19UicH/HFux2gXX1hje7+AymaWMbQ=; b=0JnxdpcoPTNC+5IElMQ10bwys4jy 5qUNWP3fvL4Z1J6zuGs/6LlQE11SJj1bBlxgcbhwoq7fmtJXSeYfIz8CO6qOpWnl j8UQYlsUUsyBtdUm9DWseGxBCvrqOozIktwcBjO41fSl9tK/JSepEt/qSvD0bCTq RLu51RDbyvFwaAo= Received: (qmail 79227 invoked from network); 10 Aug 2012 12:19:15 -0500 Received: from unknown (HELO ?192.168.0.74?) (bryan@shatow.net@74.94.87.209) by sweb.xzibition.com with ESMTPA; 10 Aug 2012 12:19:15 -0500 Message-ID: <502542A9.4040801@shatow.net> Date: Fri, 10 Aug 2012 12:19:37 -0500 From: Bryan Drewery User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: FreeBSD Mailing List References: <5020E05C.3000704@zedat.fu-berlin.de> <50211A8F.40108@shatow.net> <50211CEA.6030108@mail.zedat.fu-berlin.de> In-Reply-To: X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Current FreeBSD Subject: Re: pkg and portmaster: Downgrading ports? Why? portmaster messes up ... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Aug 2012 17:19:22 -0000 On 8/9/2012 8:26 AM, Chris Rees wrote: > On 7 Aug 2012 15:50, "O. Hartmann" wrote: >> >> On 08/07/12 15:39, Bryan Drewery wrote: >>> On 8/7/2012 4:31 AM, O. Hartmann wrote: >>>> ports-mgmt/portmaster installs still the old fashioned style folders of >>>> ports in /var/db/pkg. I thought ith the new scheme of pkg, everything > is >>>> going into a file based SQLite3 DB? >>> >>> Also ensure WITH_PKGNG=yes is in your /etc/make.conf. My last comment >>> still stands though, portmaster will store distifile information in >>> /var/db/pkg. >>> >> >> WITH_PKGNG=yes is set in /etc/make.conf. > > Also in your portmasterrc? > > Chris use_pkgng should not be needed in the portmasterrc anymore if using the newer patches. Just WITH_PKGNG=yes in /etc/make.conf should suffice. For reference: https://github.com/pkgng/pkgng/commit/8a1bffdbab0c01c0c5c349066a7f10df8eff070b Bryan From owner-freebsd-current@FreeBSD.ORG Fri Aug 10 17:51:17 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 814BE106566B for ; Fri, 10 Aug 2012 17:51:17 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe02.c2i.net [212.247.154.34]) by mx1.freebsd.org (Postfix) with ESMTP id 048918FC17 for ; Fri, 10 Aug 2012 17:51:16 +0000 (UTC) X-T2-Spam-Status: No, hits=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 Received: from [176.74.212.201] (account mc467741@c2i.net HELO laptop015.hselasky.homeunix.org) by mailfe02.swip.net (CommuniGate Pro SMTP 5.4.4) with ESMTPA id 307409700; Fri, 10 Aug 2012 19:51:09 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Fri, 10 Aug 2012 19:51:42 +0200 User-Agent: KMail/1.13.7 (FreeBSD/9.1-PRERELEASE; KDE/4.8.4; amd64; ; ) References: <20120801160323.GN2676@deviant.kiev.zoral.com.ua> <201208101639.34082.hselasky@c2i.net> In-Reply-To: <201208101639.34082.hselasky@c2i.net> X-Face: 'mmZ:T{)),Oru^0c+/}w'`gU1$ubmG?lp!=R4Wy\ELYo2)@'UZ24N@d2+AyewRX}mAm; Yp |U[@, _z/([?1bCfM{_"B<.J>mICJCHAzzGHI{y7{%JVz%R~yJHIji`y>Y}k1C4TfysrsUI -%GU9V5]iUZF&nRn9mJ'?&>O MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201208101951.42116.hselasky@c2i.net> Cc: Konstantin Belousov , Ed Schouten Subject: Re: ttydev_cdevsw has no d_purge X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Aug 2012 17:51:17 -0000 Hi, Please see the following patches for a solution of the problem given by the subject of this thread: http://svn.freebsd.org/changeset/base/239178 http://svn.freebsd.org/changeset/base/239179 http://svn.freebsd.org/changeset/base/239180 --HPS From owner-freebsd-current@FreeBSD.ORG Sat Aug 11 10:02:55 2012 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AB6B2106564A; Sat, 11 Aug 2012 10:02:55 +0000 (UTC) (envelope-from ianf@clue.co.za) Received: from zcs03.jnb1.cloudseed.co.za (zcs03.jnb1.cloudseed.co.za [41.154.0.139]) by mx1.freebsd.org (Postfix) with ESMTP id 34C088FC15; Sat, 11 Aug 2012 10:02:54 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zcs03.jnb1.cloudseed.co.za (Postfix) with ESMTP id 87E6C2B42A53; Sat, 11 Aug 2012 11:56:05 +0200 (SAST) X-Virus-Scanned: amavisd-new at zcs03.jnb1.cloudseed.co.za Received: from zcs03.jnb1.cloudseed.co.za ([127.0.0.1]) by localhost (zcs03.jnb1.cloudseed.co.za [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L3vjnksXhhWm; Sat, 11 Aug 2012 11:56:05 +0200 (SAST) Received: from clue.co.za (unknown [41.154.88.19]) by zcs03.jnb1.cloudseed.co.za (Postfix) with ESMTPSA id D42612B42A52; Sat, 11 Aug 2012 11:56:04 +0200 (SAST) Received: from localhost ([127.0.0.1] helo=clue.co.za) by clue.co.za with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1T08QN-0000S9-H1; Sat, 11 Aug 2012 11:56:03 +0200 To: Gleb Smirnoff From: Ian FREISLICH In-Reply-To: <20120809114130.GC20560@FreeBSD.org> References: <20120809114130.GC20560@FreeBSD.org> <501D52AD.4010105@protected-networks.net> X-Attribution: BOFH Date: Sat, 11 Aug 2012 11:56:03 +0200 Message-Id: Cc: Garrett Cooper , current@FreeBSD.org Subject: Re: Speaking of ship blockers for 9.... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Aug 2012 10:02:55 -0000 Gleb Smirnoff wrote: > Let me give you link to my branch of pf: > > http://lists.freebsd.org/pipermail/freebsd-pf/2012-June/006643.html > http://lists.freebsd.org/pipermail/freebsd-pf/2012-June/006662.html > > In that branch the code that puts the "reverse" pointer on state keys, > as well as the m_addr_changed() function and the pf_compare_state_keys() > had been cut away. > > So, this exact bug definitely can't be reproduced there. However, others > may hide in :) Thanks. I'll be able to work on this next week. My system is pretty similar to yours - 16 cores, full BGP RIB, 20+ VLANs + CARP on 4*bce(4), PF+Sync, 400k+ states, NAT, tables, anchors etc. The complication is that the production system is on 8 and the pfsync is incompatible with 9 and CURRENT. And, 9/CURRENT is unuseable for me as a backup without this fix because of the state mismatch rate. Ian -- Ian Freislich From owner-freebsd-current@FreeBSD.ORG Sat Aug 11 16:17:00 2012 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 054DC1065672; Sat, 11 Aug 2012 16:17:00 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from sarah.protected-networks.net (sarah.protected-networks.net [202.12.127.65]) by mx1.freebsd.org (Postfix) with ESMTP id C09ED8FC0A; Sat, 11 Aug 2012 16:16:59 +0000 (UTC) Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [IPv6:2001:470:1f07:4e1::4]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "Iain Butler", Issuer "RSA Class 2 Personal CA v2" (verified OK)) (Authenticated sender: imb@protected-networks.net) by sarah.protected-networks.net (Postfix) with ESMTPSA id 1143060E4; Sat, 11 Aug 2012 12:16:52 -0400 (EDT) DomainKey-Signature: a=rsa-sha1; s=200509; d=protected-networks.net; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=HjALqQYt7uh6tARkPyOknxmW/AY4/gEGZqHD+rqMkC2/KjRVKusx4d7LOHkNNBslS F0Q6UW5RpdQcInTkQpD2AW2G35QK7r8YtNlmuYXgitzuucWM1Gd/d2zNZbzVxqc Message-ID: <50268572.7030204@protected-networks.net> Date: Sat, 11 Aug 2012 12:16:50 -0400 From: Michael Butler User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:14.0) Gecko/20120727 Thunderbird/14.0 MIME-Version: 1.0 To: Gleb Smirnoff References: <501D52AD.4010105@protected-networks.net> <20120806180617.GJ20560@FreeBSD.org> In-Reply-To: <20120806180617.GJ20560@FreeBSD.org> X-Enigmail-Version: 1.4.2 OpenPGP: id=0442D492 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Cc: stable@FreeBSD.org, current@FreeBSD.org Subject: Re: geom mirror now rebuilding on every 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: Sat, 11 Aug 2012 16:17:00 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/06/12 14:06, Gleb Smirnoff wrote: > Michael, > > On Sat, Aug 04, 2012 at 12:49:49PM -0400, Michael Butler wrote: > M> Something in -current and recently MFC'd to -stable is causing all of my > M> gmirror drives to rebuild on reboot :-( > M> > M> Being remote and these being production machines, I suspect SVN r237929 > M> and r237930 in -current and SVN r238500 to -stable but haven't yet been > M> able to prove it. > > I'd appreciate if you test that and either confirm or disclaim that > r238500 introduces such regression. Thanks! I'm only home for a few hours this weekend (enough to do the laundry before hitting the road again :-() but I did prove that disabling SUJ and moving back to SU mitigates the problem, imb -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAlAmhXIACgkQQv9rrgRC1JLqCQCghWIHeG9m3q6qY2o4vuTqXAx1 PSkAoIKgsEfiDxJJAqni/bL2CqRBG4+D =3fLJ -----END PGP SIGNATURE-----