From owner-freebsd-current@FreeBSD.ORG Sun Feb 3 02:30:47 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B020A1D0; Sun, 3 Feb 2013 02:30:47 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 26CE3FB5; Sun, 3 Feb 2013 02:30:46 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAEAOvIDVGDaFvO/2dsb2JhbAA9CIZIuQBzgh8BAQEEAQEBIAQnIAsbDgoCAg0ZAikBCSYGCAcEARwEh3AMry2RaYEjjAMEgxWBEwOIZosHgjKBHYg4hnyDGoFRNQ X-IronPort-AV: E=Sophos;i="4.84,591,1355115600"; d="scan'208";a="14817928" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 02 Feb 2013 21:30:39 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id E1B72B3F4B; Sat, 2 Feb 2013 21:30:39 -0500 (EST) Date: Sat, 2 Feb 2013 21:30:39 -0500 (EST) From: Rick Macklem To: Andriy Gapon Message-ID: <1423598176.2627168.1359858639862.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <510A73A0.9000607@FreeBSD.org> Subject: Re: panic: LK_RETRY set with incompatible flags MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.203] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: FreeBSD Current , Kostik Belousov , Sergey Kandaurov X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 03 Feb 2013 02:30:47 -0000 Andriy Gapon wrote: > on 31/01/2013 15:29 Sergey Kandaurov said the following: > > Hi. > > > > Got this assertion on idle NFS server while `ls -la /.zfs/shares/' > > issued on NFS client. > > kern/vfs_vnops.c:_vn_lock() > > KASSERT((flags & LK_RETRY) == 0 || error == 0, > > ("LK_RETRY set with incompatible flags (0x%x) or > > an error occured (%d)", > > > > panic: LK_RETRY set with incompatible flags (0x200400) or an error > > occured (11) > > > > What does that mean and how is it possible? As you can see, both > > parts > > of assertion failed. > > 11 is EDEADLK > > 0x200400: LK_RETRY & LK_UPGRADE > > LK_SHARED, not LK_UPGRADE. > Apparently the thread already holds an exlusive lock on the vnode, > which you > confirm below. > > > > Tracing pid 2943 tid 101532 td 0xfffffe004f5b7000 > > kdb_enter() at kdb_enter+0x3e/frame 0xffffff848e45ef50 > > vpanic() at vpanic+0x147/frame 0xffffff848e45ef90 > > kassert_panic() at kassert_panic+0x136/frame 0xffffff848e45f000 > > _vn_lock() at _vn_lock+0x70/frame 0xffffff848e45f070 > > zfs_lookup() at zfs_lookup+0x392/frame 0xffffff848e45f100 > > zfs_freebsd_lookup() at zfs_freebsd_lookup+0x6d/frame > > 0xffffff848e45f240 > > VOP_CACHEDLOOKUP_APV() at VOP_CACHEDLOOKUP_APV+0xc2/frame > > 0xffffff848e45f260 > > vfs_cache_lookup() at vfs_cache_lookup+0xcf/frame 0xffffff848e45f2b0 > > VOP_LOOKUP_APV() at VOP_LOOKUP_APV+0xc2/frame 0xffffff848e45f2d0 > > lookup() at lookup+0x548/frame 0xffffff848e45f350 > > nfsvno_namei() at nfsvno_namei+0x1a5/frame 0xffffff848e45f400 > > nfsrvd_lookup() at nfsrvd_lookup+0x13a/frame 0xffffff848e45f6b0 > > nfsrvd_dorpc() at nfsrvd_dorpc+0xca5/frame 0xffffff848e45f8a0 > > nfssvc_program() at nfssvc_program+0x482/frame 0xffffff848e45fa00 > > svc_run_internal() at svc_run_internal+0x1e9/frame > > 0xffffff848e45fba0 > > svc_thread_start() at svc_thread_start+0xb/frame 0xffffff848e45fbb0 > > fork_exit() at fork_exit+0x84/frame 0xffffff848e45fbf0 > > fork_trampoline() at fork_trampoline+0xe/frame 0xffffff848e45fbf0 > > --- trap 0xc, rip = 0x800883e9a, rsp = 0x7fffffffd488, rbp = > > 0x7fffffffd730 --- > > > > db> show lockedvnods > > Locked vnodes > > > > 0xfffffe02e21b11d8: tag zfs, type VDIR > > usecount 4, writecount 0, refcount 4 mountedhere 0 > > flags (VI_ACTIVE) > > v_object 0xfffffe02d9f2eb40 ref 0 pages 0 > > lock type zfs: EXCL by thread 0xfffffe004f5b7000 (pid 2943, > > nfsd, > > tid 101532) > > > > > > I just took a look at zfs_vnops.c and I am probably missing something, but I can't see how this ever worked for a lookup of ".." when at the root (unless ZFS doesn't do the ".." is the current directory when at the root). Here's the code snippet: 1442 if (error == 0 && (nm[0] != '.' || nm[1] != '\0')) { 1443 int ltype = 0; 1444 1445 if (cnp->cn_flags & ISDOTDOT) { 1446 ltype = VOP_ISLOCKED(dvp); 1447 VOP_UNLOCK(dvp, 0); 1448 } 1449 ZFS_EXIT(zfsvfs); 1450 error = zfs_vnode_lock(*vpp, cnp->cn_lkflags); 1451 if (cnp->cn_flags & ISDOTDOT) 1452 vn_lock(dvp, ltype | LK_RETRY); 1453 if (error != 0) { 1454 VN_RELE(*vpp); 1455 *vpp = NULL; 1456 return (error); 1457 } Maybe line# 1451 should be changed to: if ((cnp->cn_flags & ISDOTDOT) && *vpp != dvp) I'm not at all familiar with ZFS, so I've probably way off the mark on this, rick ps: I hope kib and jhb don't mind being added as cc's, since they are familiar with this stuff, although maybe not ZFS specifics. > > > -- > Andriy Gapon > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Sun Feb 3 05:46:43 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 88560BAB for ; Sun, 3 Feb 2013 05:46:43 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id 48694802 for ; Sun, 3 Feb 2013 05:46:42 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r135kfuw072027 for freebsd-current@freebsd.org; Sun, 3 Feb 2013 05:46:41 GMT (envelope-from kientzle@freebsd.org) Received: from [192.168.2.143] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id 3fi8yqvvnpxyx2qaxgsbc6yjqa; for freebsd-current@freebsd.org; Sun, 03 Feb 2013 05:46:41 +0000 (UTC) (envelope-from kientzle@freebsd.org) From: Tim Kientzle Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Better pkg bootstrapping instructions? Date: Sat, 2 Feb 2013 21:46:41 -0800 Message-Id: <6E30CAD7-182D-48BA-BFF2-E56547989902@freebsd.org> To: freebsd-current Current Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 03 Feb 2013 05:46:43 -0000 Especially on -CURRENT, it's not going to be uncommon to see things like this: The package management tool is not yet installed on your system. Do you want to fetch and install it now? [y/N]: y Bootstrapping pkg please wait _http._tcp.pkg.FreeBSD.org pkg: Error fetching = http://pkg.FreeBSD.org/freebsd:10:arm:32:el:oabi:softfp/latest/Latest/pkg.= txz: Not Found It would be nice if the next line said: "A pre-built version of pkg could not be found for your system." "Please install it from source using the ports-mgmt/pkg port." From owner-freebsd-current@FreeBSD.ORG Sun Feb 3 10:02:36 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 536AD5D4; Sun, 3 Feb 2013 10:02:36 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: from mail-ea0-f174.google.com (mail-ea0-f174.google.com [209.85.215.174]) by mx1.freebsd.org (Postfix) with ESMTP id A5665FB2; Sun, 3 Feb 2013 10:02:35 +0000 (UTC) Received: by mail-ea0-f174.google.com with SMTP id 1so2287334eaa.5 for ; Sun, 03 Feb 2013 02:02:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=J4LIyCfYplLzmxg7emGB83B5AUesfbWBS2mVC+YBF7w=; b=YlBP4HvvI+sWC2tv2lwzbxR34EWl9eO7kWbpXjzgAyyAM0akZWkVohvpCFV4lyNJ+e gAvEs5Obkgrfk/N7b6j4v70UZ2je05iJPQMghMDB5T+N9WPAjj4eoId2W/oPNHpj7Qrx clImwltHcw+zfBecwWX1D4as86tWTkctaQXsU27yjLgTilOwjk0YYhBgW6VuUn0q4fHy uFWm6N6KzISiceFhu/DoFK98U+zg/pb0UntruaNb7tzCXbisqj/uoVYFZ8BqT2krqvwM 82nGx6kfhM7A0NgMBkXmuHPeYBguCzivc9q++RpIxAw7WsdyPWVjTzYACNIcD0NzKebf cuPA== X-Received: by 10.14.203.3 with SMTP id e3mr59455489eeo.9.1359885754603; Sun, 03 Feb 2013 02:02:34 -0800 (PST) Received: from ithaqua.etoilebsd.net (ithaqua.etoilebsd.net. [37.59.37.188]) by mx.google.com with ESMTPS id 46sm21613019eeg.4.2013.02.03.02.02.33 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 03 Feb 2013 02:02:33 -0800 (PST) Sender: Baptiste Daroussin Date: Sun, 3 Feb 2013 11:02:31 +0100 From: Baptiste Daroussin To: Tim Kientzle Subject: Re: Better pkg bootstrapping instructions? Message-ID: <20130203100231.GA44720@ithaqua.etoilebsd.net> References: <6E30CAD7-182D-48BA-BFF2-E56547989902@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="EVF5PPMfhYS0aIcm" Content-Disposition: inline In-Reply-To: <6E30CAD7-182D-48BA-BFF2-E56547989902@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 03 Feb 2013 10:02:36 -0000 --EVF5PPMfhYS0aIcm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Feb 02, 2013 at 09:46:41PM -0800, Tim Kientzle wrote: > Especially on -CURRENT, it's not going to be uncommon > to see things like this: >=20 > The package management tool is not yet installed on your system. > Do you want to fetch and install it now? [y/N]: y > Bootstrapping pkg please wait > _http._tcp.pkg.FreeBSD.org > pkg: Error fetching http://pkg.FreeBSD.org/freebsd:10:arm:32:el:oabi:soft= fp/latest/Latest/pkg.txz: Not Found >=20 > It would be nice if the next line said: > "A pre-built version of pkg could not be found for your system." > "Please install it from source using the ports-mgmt/pkg port." >=20 Sure, I will improve it as soon as I can regards, Bapt --EVF5PPMfhYS0aIcm Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlEONbcACgkQ8kTtMUmk6EzGPQCffdfnljy+ZwEcBQkeMZEo0jiB nNcAoK6Y/cWThO0qbkihAIb93OUUzHNm =x9XH -----END PGP SIGNATURE----- --EVF5PPMfhYS0aIcm-- From owner-freebsd-current@FreeBSD.ORG Sun Feb 3 10:33:03 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 49039DED; Sun, 3 Feb 2013 10:33:03 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 62577124; Sun, 3 Feb 2013 10:33:01 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id MAA07161; Sun, 03 Feb 2013 12:33:00 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1U1wsd-0006DZ-NI; Sun, 03 Feb 2013 12:32:59 +0200 Message-ID: <510E3CDB.2070803@FreeBSD.org> Date: Sun, 03 Feb 2013 12:32:59 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130121 Thunderbird/17.0.2 MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: scheduler->swapper, SI_SUB_RUN_SCHEDULER->SI_SUB_LAST References: <510CFD90.9000304@FreeBSD.org> <20130202145013.GV2522@kib.kiev.ua> In-Reply-To: <20130202145013.GV2522@kib.kiev.ua> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org, freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 03 Feb 2013 10:33:03 -0000 on 02/02/2013 16:50 Konstantin Belousov said the following: > On Sat, Feb 02, 2013 at 01:50:40PM +0200, Andriy Gapon wrote: >> >> I would like to propose the following mostly cosmetic change: >> http://people.freebsd.org/~avg/scheduler-swapper.diff >> >> This is something that bit me early in my FreeBSD days, so I am kind of obsessed >> with it. >> The current naming is confusing/misleading indeed. >> And magic properties of SI_SUB_RUN_SCHEDULER:SI_ORDER_LAST is a "hidden gem". > > You may remove the Giant unlock from the scheduler()/swapper() as well > then, doing it before the swapper() call in the mi_startup(). > > Note that the wait chain for the idle swapper is still called "sched". Thank you for the review. I am fixing both issues. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Sun Feb 3 11:08:05 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 15ADE45F; Sun, 3 Feb 2013 11:08:05 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 7F2C1229; Sun, 3 Feb 2013 11:08:04 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r13B7x88009350; Sun, 3 Feb 2013 13:07:59 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.4 kib.kiev.ua r13B7x88009350 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r13B7xjk009349; Sun, 3 Feb 2013 13:07:59 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 3 Feb 2013 13:07:59 +0200 From: Konstantin Belousov To: Rick Macklem Subject: Re: panic: LK_RETRY set with incompatible flags Message-ID: <20130203110759.GM2522@kib.kiev.ua> References: <510A73A0.9000607@FreeBSD.org> <1423598176.2627168.1359858639862.JavaMail.root@erie.cs.uoguelph.ca> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="yHpupmvcyB3InP4W" Content-Disposition: inline In-Reply-To: <1423598176.2627168.1359858639862.JavaMail.root@erie.cs.uoguelph.ca> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: FreeBSD Current , Sergey Kandaurov , Andriy Gapon X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 03 Feb 2013 11:08:05 -0000 --yHpupmvcyB3InP4W Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Feb 02, 2013 at 09:30:39PM -0500, Rick Macklem wrote: > Andriy Gapon wrote: > > on 31/01/2013 15:29 Sergey Kandaurov said the following: > > > Hi. > > > > > > Got this assertion on idle NFS server while `ls -la /.zfs/shares/' > > > issued on NFS client. > > > kern/vfs_vnops.c:_vn_lock() > > > KASSERT((flags & LK_RETRY) =3D=3D 0 || error =3D=3D 0, > > > ("LK_RETRY set with incompatible flags (0x%x) or > > > an error occured (%d)", > > > > > > panic: LK_RETRY set with incompatible flags (0x200400) or an error > > > occured (11) > > > > > > What does that mean and how is it possible? As you can see, both > > > parts > > > of assertion failed. > > > 11 is EDEADLK > > > 0x200400: LK_RETRY & LK_UPGRADE > >=20 > > LK_SHARED, not LK_UPGRADE. > > Apparently the thread already holds an exlusive lock on the vnode, > > which you > > confirm below. > >=20 > >=20 > > > Tracing pid 2943 tid 101532 td 0xfffffe004f5b7000 > > > kdb_enter() at kdb_enter+0x3e/frame 0xffffff848e45ef50 > > > vpanic() at vpanic+0x147/frame 0xffffff848e45ef90 > > > kassert_panic() at kassert_panic+0x136/frame 0xffffff848e45f000 > > > _vn_lock() at _vn_lock+0x70/frame 0xffffff848e45f070 > > > zfs_lookup() at zfs_lookup+0x392/frame 0xffffff848e45f100 > > > zfs_freebsd_lookup() at zfs_freebsd_lookup+0x6d/frame > > > 0xffffff848e45f240 > > > VOP_CACHEDLOOKUP_APV() at VOP_CACHEDLOOKUP_APV+0xc2/frame > > > 0xffffff848e45f260 > > > vfs_cache_lookup() at vfs_cache_lookup+0xcf/frame 0xffffff848e45f2b0 > > > VOP_LOOKUP_APV() at VOP_LOOKUP_APV+0xc2/frame 0xffffff848e45f2d0 > > > lookup() at lookup+0x548/frame 0xffffff848e45f350 > > > nfsvno_namei() at nfsvno_namei+0x1a5/frame 0xffffff848e45f400 > > > nfsrvd_lookup() at nfsrvd_lookup+0x13a/frame 0xffffff848e45f6b0 > > > nfsrvd_dorpc() at nfsrvd_dorpc+0xca5/frame 0xffffff848e45f8a0 > > > nfssvc_program() at nfssvc_program+0x482/frame 0xffffff848e45fa00 > > > svc_run_internal() at svc_run_internal+0x1e9/frame > > > 0xffffff848e45fba0 > > > svc_thread_start() at svc_thread_start+0xb/frame 0xffffff848e45fbb0 > > > fork_exit() at fork_exit+0x84/frame 0xffffff848e45fbf0 > > > fork_trampoline() at fork_trampoline+0xe/frame 0xffffff848e45fbf0 > > > --- trap 0xc, rip =3D 0x800883e9a, rsp =3D 0x7fffffffd488, rbp =3D > > > 0x7fffffffd730 --- > > > > > > db> show lockedvnods > > > Locked vnodes > > > > > > 0xfffffe02e21b11d8: tag zfs, type VDIR > > > usecount 4, writecount 0, refcount 4 mountedhere 0 > > > flags (VI_ACTIVE) > > > v_object 0xfffffe02d9f2eb40 ref 0 pages 0 > > > lock type zfs: EXCL by thread 0xfffffe004f5b7000 (pid 2943, > > > nfsd, > > > tid 101532) > > > > > > > > > > I just took a look at zfs_vnops.c and I am probably missing something, > but I can't see how this ever worked for a lookup of ".." when at the > root (unless ZFS doesn't do the ".." is the current directory when at > the root). >=20 > Here's the code snippet: > 1442 if (error =3D=3D 0 && (nm[0] !=3D '.' || nm[1] !=3D '\0')) { > 1443 int ltype =3D 0; > 1444 =09 > 1445 if (cnp->cn_flags & ISDOTDOT) { > 1446 ltype =3D VOP_ISLOCKED(dvp); > 1447 VOP_UNLOCK(dvp, 0); > 1448 } > 1449 ZFS_EXIT(zfsvfs); > 1450 error =3D zfs_vnode_lock(*vpp, cnp->cn_lkflags); > 1451 if (cnp->cn_flags & ISDOTDOT) > 1452 vn_lock(dvp, ltype | LK_RETRY); > 1453 if (error !=3D 0) { > 1454 VN_RELE(*vpp); > 1455 *vpp =3D NULL; > 1456 return (error); > 1457 }=20 >=20 > Maybe line# 1451 should be changed to: > if ((cnp->cn_flags & ISDOTDOT) && *vpp !=3D dvp) >=20 > I'm not at all familiar with ZFS, so I've probably way > off the mark on this, rick > ps: I hope kib and jhb don't mind being added as cc's, since > they are familiar with this stuff, although maybe not ZFS > specifics. VFS (should) never call VOP_LOOKUP for the dotdot and root vnode. The logic in the lookup() prevents it. Might it be a missing check in the nfs server code ? (I did not looked yet). --yHpupmvcyB3InP4W Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRDkUPAAoJEJDCuSvBvK1BaRsP/jK3Y+hIYByw8IwzsWlm1wzo OXzYznH6HOjp5D4zijl4efx1UiPUYw8FnxLEwUol2hHH8Nkplj7lv1DkaAIHekoC bRJ/G8+lyJXKZlY9cKMPrZrzGFAwUtxMwZbXTIbfOIjemji1GgtxDmQVSQu0xotW wU+ae2fNmCdS6+/9rRyKQId1w/M02oZOO3cleoaoFmGI8kVYgYpZ6jHtg0twK3K8 fFLq486TLx/MFX8iUzVrbe5T1h4q+tOENtcDz4xxO4b7P7S34Tb1Z3ZDKl7CEpxy vjIuu9/4tXuivuyBiJgXQx8Tv5nfOxF7+jPzpbizj56Ggg4xSSdmr68oh3mWoESG JzeupNk6B/WfBfTA26jKi82lFVGuhm+kIj/KNxHGbOHSIApKHKTvWAt9Vy4vj+fo E3f0EP3qXpsF856ux9hAeVyQuUMprFcN/XkCNANyiqdeq0H0/rSgFaqoO3JE7Pfw aC+4l7uwhNplK4rW4MHFL/26AbAEVzNKZcp9zuwAWSv45hakH0EdAyJaPpXCc41a bYvnmL57oln95d/TjdbI6WW9nbJRKZNEr1r4A4+eKZiOS85AZL277e5dxo34dj+D SHJHt/GTDpH3YM00uZuQj6yI6EHu/DVD8spgUDIpvaLwRrxY/1HZgMJcD/dmrwRs nOuhTGDNKp0/WNOPtQX/ =9ruN -----END PGP SIGNATURE----- --yHpupmvcyB3InP4W-- From owner-freebsd-current@FreeBSD.ORG Sun Feb 3 14:00:56 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9F92FAB5; Sun, 3 Feb 2013 14:00:56 +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 48D068CB; Sun, 3 Feb 2013 14:00:55 +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 <1U207l-002M2u-67>; Sun, 03 Feb 2013 15:00:49 +0100 Received: from e178034007.adsl.alicedsl.de ([85.178.34.7] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1U207l-002E9m-2I>; Sun, 03 Feb 2013 15:00:49 +0100 Message-ID: <510E6D89.2090502@zedat.fu-berlin.de> Date: Sun, 03 Feb 2013 15:00:41 +0100 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130131 Thunderbird/17.0.2 MIME-Version: 1.0 To: David Chisnall Subject: Re: r246057: buildworld fails with: /usr/obj/usr/src/tmp/usr/lib/libc++.so: undefined reference to `std::bad_alloc::~bad_alloc()' References: <51079F0A.20309@zedat.fu-berlin.de> <20130129163554.GW1804@albert.catwhisker.org> <5109F527.2030702@zedat.fu-berlin.de> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig29682A5889120A3F8E9FE2CA" X-Originating-IP: 85.178.34.7 Cc: Current FreeBSD , Dimitry Andric , "jesse@glx.me >> Jesse" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 03 Feb 2013 14:00:56 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig29682A5889120A3F8E9FE2CA Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Am 01/31/13 10:10, schrieb David Chisnall: > On 31 Jan 2013, at 04:37, O. Hartmann wrote: >=20 >> First, I suspected the c++ option "-std=3Dc++11" I issued in /etc/src.= conf >> when building the sources - I did this before without any problems. >> Then, leaving the build without "-std=3Dc++11" option, I get the follo= wing >> error below and compilation stops. >> >> Maybe this reveals the real issue. >> >> The revision of the OS I compile on and where it fails is FreeBSD >> 10.0-CURRENT #2 r245995: Sun Jan 27 19:56:47 CET 2013. This is maybe o= f >> any help. >=20 > If you are going to compile with -stdlib=3Dlibc++ and not -std=3Dc++11,= then you probably need to add -Wno-c++11-extensions. Some C++11isms hav= e crept into the libc++ headers. I think some have been fixed upstream, = so I'll do a new import soon and see. >=20 > David >=20 Since world can not be build anymore at the moment with the use of -stdlib=3Dlibc++, wouldn't it be well-advised to make a note in UPDATING?= I was wondering that so few CURRENT users are going to use the new libc++ for building world. If it is an official advise NOT to use libc++ at the moment and I simply didn't get the message, please consider my complain without a subject anymore. Regards, Oliver --------------enig29682A5889120A3F8E9FE2CA 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) iQEcBAEBAgAGBQJRDm2QAAoJEOgBcD7A/5N8tlAH/3HVJFpGp29KJHWdWz0k36k1 46vfqAOSnJ/5w4meCN2eSnR2Kjf5s7Oi1Dn6Clf9DopeRD5olGaMXIpv5fMNLQXn WgBYidKdI4z7BnL535GDUc1QFt8NvIp0c74W6LJi5uZI1/W0ScvuAzA1PhTFnv4h h9WG2XgLaZ3ntZ0oLoM5/Dc41XEoV4tYCn1/Xn3UoqmRRbuORaiCHJ9LlsvURJDH dVM0g57QAusguBsIbFDVTe0P1sRvv8EOdoMrtb10eSQDDZIQzBAhzsJNaxhDelW4 HM0EH7i2xbJEsfeeRgIXmYw83GTSCvbOtzvf3w6grCODa4YnFa6B7YN26ugQGkc= =FV1r -----END PGP SIGNATURE----- --------------enig29682A5889120A3F8E9FE2CA-- From owner-freebsd-current@FreeBSD.ORG Sun Feb 3 15:57:21 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id BB57B35D; Sun, 3 Feb 2013 15:57:21 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id 4704ED9A; Sun, 3 Feb 2013 15:57:20 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.5/8.14.5/ALCHEMY.FRANKEN.DE) with ESMTP id r13FvIAr006234; Sun, 3 Feb 2013 16:57:18 +0100 (CET) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.5/8.14.5/Submit) id r13FvIvL006233; Sun, 3 Feb 2013 16:57:18 +0100 (CET) (envelope-from marius) Date: Sun, 3 Feb 2013 16:57:18 +0100 From: Marius Strobl To: Konstantin Belousov Subject: Re: Physbio changes final call for tests and reviews Message-ID: <20130203155718.GA6204@alchemy.franken.de> References: <20130202163322.GA2522@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130202163322.GA2522@kib.kiev.ua> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: powerpc@freebsd.org, mips@freebsd.org, current@freebsd.org, ia64@freebsd.org, arch@freebsd.org, sparc64@freebsd.org, arm@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 03 Feb 2013 15:57:21 -0000 On Sat, Feb 02, 2013 at 06:33:22PM +0200, Konstantin Belousov wrote: > Hi, > I finished the last (insignificant) missed bits in the Jeff' physbio > work. Now I am asking for the last round of testing and review, esp. for > the !x86 architectures. Another testing focus are the SCSI HBAs and RAID > controllers which drivers are changed by the patchset. Please do test > this before the patchset is committed into HEAD ! > > The plan is to commit the patch somewhere in two weeks from this moment. > The patch is required for the finalizing of the unmapped I/O work for UFS > I did in parallel, which I hope to finish shortly after the commit. > > Patch is available at http://people.freebsd.org/~kib/misc/physbio.5.diff > Once you bring in said UFS changes, will the use of bus_dmamap_load_ccb(9) be a requirement for disk controller drivers? Marius From owner-freebsd-current@FreeBSD.ORG Sun Feb 3 16:11:56 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 94E856BB; Sun, 3 Feb 2013 16:11:56 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 0CB75E0A; Sun, 3 Feb 2013 16:11:55 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r13GBjmC051486; Sun, 3 Feb 2013 18:11:45 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.4 kib.kiev.ua r13GBjmC051486 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r13GBjRR051485; Sun, 3 Feb 2013 18:11:45 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 3 Feb 2013 18:11:45 +0200 From: Konstantin Belousov To: Marius Strobl Subject: Re: Physbio changes final call for tests and reviews Message-ID: <20130203161145.GQ2522@kib.kiev.ua> References: <20130202163322.GA2522@kib.kiev.ua> <20130203155718.GA6204@alchemy.franken.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mi2hulEOATkNQ14l" Content-Disposition: inline In-Reply-To: <20130203155718.GA6204@alchemy.franken.de> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: arch@freebsd.org, current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 03 Feb 2013 16:11:56 -0000 --mi2hulEOATkNQ14l Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Feb 03, 2013 at 04:57:18PM +0100, Marius Strobl wrote: > On Sat, Feb 02, 2013 at 06:33:22PM +0200, Konstantin Belousov wrote: > > Hi, > > I finished the last (insignificant) missed bits in the Jeff' physbio > > work. Now I am asking for the last round of testing and review, esp. for > > the !x86 architectures. Another testing focus are the SCSI HBAs and RAID > > controllers which drivers are changed by the patchset. Please do test > > this before the patchset is committed into HEAD ! > >=20 > > The plan is to commit the patch somewhere in two weeks from this moment. > > The patch is required for the finalizing of the unmapped I/O work for U= FS > > I did in parallel, which I hope to finish shortly after the commit. > >=20 > > Patch is available at http://people.freebsd.org/~kib/misc/physbio.5.diff > >=20 >=20 > Once you bring in said UFS changes, will the use of bus_dmamap_load_ccb(9) > be a requirement for disk controller drivers? Generally speaking, no. I plan to do the gradual migration of the drivers, definitely not forcing the unmapped bios down to the drivers which are not tested yet. In the patch, driver indicates the support for unmapped bios by a DISKFLAG. If flag is set, driver could receive both mapped and unmapped bios, and use of the bus_dmamap_load_ccb(), while formally is only convenience, is essentially the requirement. If driver does not set the flag, it receives the same i/o requests as it does now. Geom performs transient compat mapping for the unmapped requests on its own for such drivers. As result, driver does not need a change. My plan is to convert ahci(4) and then some often used high-profile drivers like mfi(4) and mps(4). I can also hope for isci(4) help. Everything else, IMO, could be done on the best efforts basis, when both developers time and testing facilities are available. Jeff wanted to do all driver conversion in one pass, but IMO this is unrealistic. Still, I started write some helpers which should provide the transient one-page mappings for PIO modes. You can look at some previous version of the unmapped patch at http://people.freebsd.org/~kib/misc/unmapped.8.patch. It only contain a hack for ahci(4), which should be fixed properly after physbio is committed. --mi2hulEOATkNQ14l Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRDoxBAAoJEJDCuSvBvK1BqJQP/RpIphfsDzjo53QLX3+xnClm OB8WWZvZpxc3qOXPd5pKeOYggeE/6hkrUIL7AMlmg0qNKU7RXQmVJkcX+Yiuke5h oL1LSyIEBFuz8j7ks04H8ZOTjZpQQDeXYJPTrkNXcHqKWWZMMfsCZU1YNmzc0Shi m2ot3p7sL5gqUFaodC0qRejP5OOiMkdplwuSmyi3atoobrdMjqeadpDYCj6Ia9RU QBmWtr22Pj3AmVczK6L5jLk+uq7Al+ezwGEN4Bt5oT5B6pQMc8la6PyPNHVNdflA pW4qG0Pw4l6Gn/9ccpC001T8XJYq18j7U6yJIp1azoongTMmS1PFUssohSBtCwl0 q1xu3FTsh5U+M8z2HuxOyLiL1Eduf2uqFxnqPFuX0q0m9Wb3mCVauRd2sKkL8kvi WmW2x+PTuYiiFxU9MvtABZPWa8UVSpLJl30u2ptDheNb9vWmPBhfXps3bO8J0nN1 hIsdPJ+A0yevdqeLIDy6mdB7fUuEogHdCL9u9KtoOptpUPeiXpmUK7PsSyTz6G89 4Oz7jbSfmYGUY0rqiR+gfFZDa+4L8jYFYpxuneyGpTY77FvjCFrZ3efrJbbFj2r5 siu7GASJna3KgjQpj1G3UAU7j3dTuybRvBGd6/tKCbARSBGOcq2nYic3DpLVwJq9 kLGLoOEyKX9j+oJlWRtl =idda -----END PGP SIGNATURE----- --mi2hulEOATkNQ14l-- From owner-freebsd-current@FreeBSD.ORG Sun Feb 3 16:23:55 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E7A5A581; Sun, 3 Feb 2013 16:23:55 +0000 (UTC) (envelope-from jbeich@tormail.org) Received: from outgoing.tormail.org (outgoing.tormail.org [82.221.96.22]) by mx1.freebsd.org (Postfix) with ESMTP id A9550EA7; Sun, 3 Feb 2013 16:23:55 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=internal.tormail.org) by outgoing.tormail.org with esmtp (Exim 4.72) (envelope-from ) id 1U22MD-0008W8-0k; Sun, 03 Feb 2013 19:23:54 +0300 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tormail.org; s=tm; h=Message-Id:X-TorMail-User:Content-Type:MIME-Version:References:Date:Subject:Cc:To:From; bh=AXRFgV6lROc05rDEzWqk0GyUnXjO6ArhCEUfWNqKM4A=; b=m6xzcPODAzPhStmk07dp1nnkdBwmeQN8tQJoe5V+mvANvqG2mb7j/BU0h8iCbEd5vJLsp0T1CLxz3NzoPdwsV2R9IKx/IM8Ba7jUjbX36pPr3xSOiDrI9ZBKCBNWtlPSbs0EPvo2xQWvyeUm63H0cirSpYSPatno6XzgJz+yG+Q=; Received: from jbeich by internal.tormail.org with local (Exim 4.63) (envelope-from ) id 1U22K1-000F0W-OJ; Sun, 03 Feb 2013 16:21:39 +0000 From: Jan Beich To: Ed Maste Subject: DEBUG_FLAGS broken with -jX (Was: svn commit: r244236 - head/share/mk) Date: Sun, 03 Feb 2013 15:21:52 -0100 References: <201212150003.qBF03Zr0085865@svn.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain X-TorMail-User: jbeich Message-Id: <1U22K1-000F0W-OJ@internal.tormail.org> Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 03 Feb 2013 16:23:56 -0000 Ed Maste writes: > Author: emaste > Date: Sat Dec 15 00:03:35 2012 > New Revision: 244236 > URL: http://svnweb.freebsd.org/changeset/base/244236 > > Log: > Put shared library debug info into separate .symbols file > > Sponsored by: ADARA Networks Does this work with -jX ? $ echo DEBUG_FLAGS=-g >/etc/make.conf $ make -vj2 [...] --- Version.map --- cat /usr/src/lib/librpcsec_gss/Symbol.map | cpp - - | awk -v vfile=/usr/src/lib/librpcsec_gss/../libc/Versions.def -f /usr/src/share/mk/version_gen.awk > Version.map --- librpcsec_gss.a --- building static rpcsec_gss library ranlib librpcsec_gss.a --- librpcsec_gss.so.1.debug --- building shared library librpcsec_gss.so.1 /usr/obj/usr/src/tmp/usr/bin/ld:Version.map:1: syntax error in VERSION script cc: error: linker command failed with exit code 1 (use -v to see invocation) *** [librpcsec_gss.so.1.debug] Error code 1 1 error From owner-freebsd-current@FreeBSD.ORG Sun Feb 3 16:26:56 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C04606A8 for ; Sun, 3 Feb 2013 16:26:56 +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 6B385EC7 for ; Sun, 3 Feb 2013 16:26:56 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) for freebsd-current@FreeBSD.org with esmtp (envelope-from ) id <1U22P9-002lGL-ID>; Sun, 03 Feb 2013 17:26:55 +0100 Received: from e178003221.adsl.alicedsl.de ([85.178.3.221] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) for freebsd-current@FreeBSD.org with esmtpsa (envelope-from ) id <1U22P9-002Lub-EM>; Sun, 03 Feb 2013 17:26:55 +0100 Message-ID: <510E8FCD.1040701@zedat.fu-berlin.de> Date: Sun, 03 Feb 2013 17:26:53 +0100 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130131 Thunderbird/17.0.2 MIME-Version: 1.0 To: Current FreeBSD Subject: CURRENT: Broken on > r246222? X-Enigmail-Version: 1.4.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig9DB518347DBFCB2F4CD8889C" X-Originating-IP: 85.178.3.221 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 03 Feb 2013 16:26:56 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig9DB518347DBFCB2F4CD8889C Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable CURRENT, as of recent Revision 246285 (see below) fails and crashes/reboots on an Ivy-Bridge platform (see below). Since the box does not have debugging switched on (not yet, will do eventually Monday), Last thing I see on screen is p4tcc3: on cpu3 then the system run dark and reboots without any notice (kernel doesn't have debugging switched on so far, will do this after Monday). The box is running quite well with FreeBSD 10.0-CURRENT #1 r246222: Fri Feb 1 23:13:28 CET 2013 (amd64) but sources at: root@gate [src] svn info Path: . Working Copy Root Path: /usr/src URL: svn://svn.freebsd.org/base/head Repository Root: svn://svn.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 246285 Node Kind: directory Schedule: normal Last Changed Author: hrs Last Changed Rev: 246283 Last Changed Date: 2013-02-03 11:26:24 +0100 (Sun, 03 Feb 2013) fail. Is there a known issue with hardware like shown below? I have a bunch of more modern Sandy- and Ivy-Bridge Intel driven boxes I'd like to update next week (they run CURRENT as well) and I'm not sure by now to do so. The crash occurs with a GENERIC kernel as well as with the custom kernel (working output is the custom kernel). dmesg: CPU: Intel(R) Core(TM) i3-3220 CPU @ 3.30GHz (3300.09-MHz K8-class CPU) Origin =3D "GenuineIntel" Id =3D 0x306a9 Family =3D 0x6 Model =3D 0x= 3a Stepping =3D 9 Features=3D0xbfebfbff Features2=3D0x3d9ae3bf AMD Features=3D0x28100800 AMD Features2=3D0x1 Standard Extended Features=3D0x281 TSC: P-state invariant, performance statistics real memory =3D 17179869184 (16384 MB) avail memory =3D 16221089792 (15469 MB) Event timer "LAPIC" quality 600 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) x 2 SMT threads cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 netmap: loaded module ctl: CAM Target Layer loaded smbios0: at iomem 0xf04c0-0xf04de on motherboard= smbios0: Version: 2.7, BCD Revision: 2.7 cryptosoft0: on motherboard aesni0: No AESNI support. --------------enig9DB518347DBFCB2F4CD8889C 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) iQEcBAEBAgAGBQJRDo/PAAoJEOgBcD7A/5N8imcH/jzwV1P0Y4n2KlTM6epsfZk0 rQtQZAKEsGbpUeV/KpDMuC30sEV+oNwl7hwjZlt8vO7M6YjiXaLYYZPSuYsMx+b6 b3fRwJKMfx8mDRNS0nHmnaBYp2vBYgJxjIuDLuwz4kZ9RtGJF4XM8tOwZdg36wg/ +boVQHNeDasKzhfiQ5p6XttLnAFWX7RDkc4BDpMevJ/8BKmxDW2jCwONldaw3Jfi MnaO3qBSdZk7YX9Y1Qu2QHS5i9u/fecxE+baBDtpgd9QXYTOZkcI3taZLO9w0eYG +8FNhUQy8a95/iGM/U4Af7nDcuapR0p/t6EF1Map335QsWEsrMFXu+l2yEPeCNg= =1aHL -----END PGP SIGNATURE----- --------------enig9DB518347DBFCB2F4CD8889C-- From owner-freebsd-current@FreeBSD.ORG Sun Feb 3 16:37:02 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 76EB38C9; Sun, 3 Feb 2013 16:37:02 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.net.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 0B622F0F; Sun, 3 Feb 2013 16:37:01 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAEALGQDlGDaFvO/2dsb2JhbAA8CIZItQ+DcnOCHwEBBSMEUhsOCgICDRkCWQaIJK00kUmBI4wDgxmBEwOIZo05iVWGfIMaggY X-IronPort-AV: E=Sophos;i="4.84,593,1355115600"; d="scan'208";a="12208733" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu.net.uoguelph.ca with ESMTP; 03 Feb 2013 11:36:54 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id A0199B40A0; Sun, 3 Feb 2013 11:36:54 -0500 (EST) Date: Sun, 3 Feb 2013 11:36:54 -0500 (EST) From: Rick Macklem To: Konstantin Belousov Message-ID: <74133619.2630890.1359909414548.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <20130203110759.GM2522@kib.kiev.ua> Subject: Re: panic: LK_RETRY set with incompatible flags MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.201] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: FreeBSD Current , Sergey Kandaurov , Andriy Gapon X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 03 Feb 2013 16:37:02 -0000 Konstantin Belousov wrote: > On Sat, Feb 02, 2013 at 09:30:39PM -0500, Rick Macklem wrote: > > Andriy Gapon wrote: > > > on 31/01/2013 15:29 Sergey Kandaurov said the following: > > > > Hi. > > > > > > > > Got this assertion on idle NFS server while `ls -la > > > > /.zfs/shares/' > > > > issued on NFS client. > > > > kern/vfs_vnops.c:_vn_lock() > > > > KASSERT((flags & LK_RETRY) == 0 || error == 0, > > > > ("LK_RETRY set with incompatible flags > > > > (0x%x) or > > > > an error occured (%d)", > > > > > > > > panic: LK_RETRY set with incompatible flags (0x200400) or an > > > > error > > > > occured (11) > > > > > > > > What does that mean and how is it possible? As you can see, both > > > > parts > > > > of assertion failed. > > > > 11 is EDEADLK > > > > 0x200400: LK_RETRY & LK_UPGRADE > > > > > > LK_SHARED, not LK_UPGRADE. > > > Apparently the thread already holds an exlusive lock on the vnode, > > > which you > > > confirm below. > > > > > > > > > > Tracing pid 2943 tid 101532 td 0xfffffe004f5b7000 > > > > kdb_enter() at kdb_enter+0x3e/frame 0xffffff848e45ef50 > > > > vpanic() at vpanic+0x147/frame 0xffffff848e45ef90 > > > > kassert_panic() at kassert_panic+0x136/frame 0xffffff848e45f000 > > > > _vn_lock() at _vn_lock+0x70/frame 0xffffff848e45f070 > > > > zfs_lookup() at zfs_lookup+0x392/frame 0xffffff848e45f100 > > > > zfs_freebsd_lookup() at zfs_freebsd_lookup+0x6d/frame > > > > 0xffffff848e45f240 > > > > VOP_CACHEDLOOKUP_APV() at VOP_CACHEDLOOKUP_APV+0xc2/frame > > > > 0xffffff848e45f260 > > > > vfs_cache_lookup() at vfs_cache_lookup+0xcf/frame > > > > 0xffffff848e45f2b0 > > > > VOP_LOOKUP_APV() at VOP_LOOKUP_APV+0xc2/frame 0xffffff848e45f2d0 > > > > lookup() at lookup+0x548/frame 0xffffff848e45f350 > > > > nfsvno_namei() at nfsvno_namei+0x1a5/frame 0xffffff848e45f400 > > > > nfsrvd_lookup() at nfsrvd_lookup+0x13a/frame 0xffffff848e45f6b0 > > > > nfsrvd_dorpc() at nfsrvd_dorpc+0xca5/frame 0xffffff848e45f8a0 > > > > nfssvc_program() at nfssvc_program+0x482/frame > > > > 0xffffff848e45fa00 > > > > svc_run_internal() at svc_run_internal+0x1e9/frame > > > > 0xffffff848e45fba0 > > > > svc_thread_start() at svc_thread_start+0xb/frame > > > > 0xffffff848e45fbb0 > > > > fork_exit() at fork_exit+0x84/frame 0xffffff848e45fbf0 > > > > fork_trampoline() at fork_trampoline+0xe/frame > > > > 0xffffff848e45fbf0 > > > > --- trap 0xc, rip = 0x800883e9a, rsp = 0x7fffffffd488, rbp = > > > > 0x7fffffffd730 --- > > > > > > > > db> show lockedvnods > > > > Locked vnodes > > > > > > > > 0xfffffe02e21b11d8: tag zfs, type VDIR > > > > usecount 4, writecount 0, refcount 4 mountedhere 0 > > > > flags (VI_ACTIVE) > > > > v_object 0xfffffe02d9f2eb40 ref 0 pages 0 > > > > lock type zfs: EXCL by thread 0xfffffe004f5b7000 (pid 2943, > > > > nfsd, > > > > tid 101532) > > > > > > > > > > > > > > I just took a look at zfs_vnops.c and I am probably missing > > something, > > but I can't see how this ever worked for a lookup of ".." when at > > the > > root (unless ZFS doesn't do the ".." is the current directory when > > at > > the root). > > > > Here's the code snippet: > > 1442 if (error == 0 && (nm[0] != '.' || nm[1] != '\0')) { > > 1443 int ltype = 0; > > 1444 > > 1445 if (cnp->cn_flags & ISDOTDOT) { > > 1446 ltype = VOP_ISLOCKED(dvp); > > 1447 VOP_UNLOCK(dvp, 0); > > 1448 } > > 1449 ZFS_EXIT(zfsvfs); > > 1450 error = zfs_vnode_lock(*vpp, cnp->cn_lkflags); > > 1451 if (cnp->cn_flags & ISDOTDOT) > > 1452 vn_lock(dvp, ltype | LK_RETRY); > > 1453 if (error != 0) { > > 1454 VN_RELE(*vpp); > > 1455 *vpp = NULL; > > 1456 return (error); > > 1457 } > > > > Maybe line# 1451 should be changed to: > > if ((cnp->cn_flags & ISDOTDOT) && *vpp != dvp) > > > > I'm not at all familiar with ZFS, so I've probably way > > off the mark on this, rick > > ps: I hope kib and jhb don't mind being added as cc's, since > > they are familiar with this stuff, although maybe not ZFS > > specifics. > > VFS (should) never call VOP_LOOKUP for the dotdot and root vnode. > The logic in the lookup() prevents it. > > Might it be a missing check in the nfs server code ? (I did not looked > yet). The server code (at least the new one) just calls lookup() and I see the check in there. I can think of two possibilities: 1 - ZFS isn't setting VV_ROOT on the root vnode under some condition. or 2 - The vnode was left locked from some previous operation that happened to be done by this thread. Doesn't seem likely, but??? Maybe Sergey could try the change to line#1451 and see if the panic still happens. If not, that would suggest possibility #1, I think. Thanks yet again for your help, rick. ps: I'll take a closer look at zfs_lookup() and see if I can spot another explanation. From owner-freebsd-current@FreeBSD.ORG Sun Feb 3 16:46:26 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 75935D90; Sun, 3 Feb 2013 16:46:26 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id E129CFBB; Sun, 3 Feb 2013 16:46:25 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.5/8.14.5/ALCHEMY.FRANKEN.DE) with ESMTP id r13GkOjY006468; Sun, 3 Feb 2013 17:46:24 +0100 (CET) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.5/8.14.5/Submit) id r13GkOFw006467; Sun, 3 Feb 2013 17:46:24 +0100 (CET) (envelope-from marius) Date: Sun, 3 Feb 2013 17:46:24 +0100 From: Marius Strobl To: Konstantin Belousov Subject: Re: Physbio changes final call for tests and reviews Message-ID: <20130203164624.GL80850@alchemy.franken.de> References: <20130202163322.GA2522@kib.kiev.ua> <20130203155718.GA6204@alchemy.franken.de> <20130203161145.GQ2522@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130203161145.GQ2522@kib.kiev.ua> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: arch@freebsd.org, current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 03 Feb 2013 16:46:26 -0000 On Sun, Feb 03, 2013 at 06:11:45PM +0200, Konstantin Belousov wrote: > On Sun, Feb 03, 2013 at 04:57:18PM +0100, Marius Strobl wrote: > > On Sat, Feb 02, 2013 at 06:33:22PM +0200, Konstantin Belousov wrote: > > > Hi, > > > I finished the last (insignificant) missed bits in the Jeff' physbio > > > work. Now I am asking for the last round of testing and review, esp. for > > > the !x86 architectures. Another testing focus are the SCSI HBAs and RAID > > > controllers which drivers are changed by the patchset. Please do test > > > this before the patchset is committed into HEAD ! > > > > > > The plan is to commit the patch somewhere in two weeks from this moment. > > > The patch is required for the finalizing of the unmapped I/O work for UFS > > > I did in parallel, which I hope to finish shortly after the commit. > > > > > > Patch is available at http://people.freebsd.org/~kib/misc/physbio.5.diff > > > > > > > Once you bring in said UFS changes, will the use of bus_dmamap_load_ccb(9) > > be a requirement for disk controller drivers? > > Generally speaking, no. I plan to do the gradual migration of the drivers, > definitely not forcing the unmapped bios down to the drivers which are > not tested yet. In the patch, driver indicates the support for unmapped > bios by a DISKFLAG. If flag is set, driver could receive both mapped > and unmapped bios, and use of the bus_dmamap_load_ccb(), while formally > is only convenience, is essentially the requirement. > > If driver does not set the flag, it receives the same i/o requests as > it does now. Geom performs transient compat mapping for the unmapped > requests on its own for such drivers. As result, driver does not need > a change. > > My plan is to convert ahci(4) and then some often used high-profile drivers > like mfi(4) and mps(4). I can also hope for isci(4) help. > > Everything else, IMO, could be done on the best efforts basis, when both > developers time and testing facilities are available. Jeff wanted to do > all driver conversion in one pass, but IMO this is unrealistic. Still, I > started write some helpers which should provide the transient one-page > mappings for PIO modes. Okay > > You can look at some previous version of the unmapped patch at > http://people.freebsd.org/~kib/misc/unmapped.8.patch. It only contain a > hack for ahci(4), which should be fixed properly after physbio is committed. Hrm, the changes to the sparc64 pmap code in the latter patch might need some more attention as some of the functions used for copying pages there IIRC have constraints on the aligment of source and destination as well as on the count. Can you say something about these properties when pmap_copy_page_offs() is called via pmap_copy_pages()? Marius From owner-freebsd-current@FreeBSD.ORG Sun Feb 3 17:03:57 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B8295530; Sun, 3 Feb 2013 17:03:57 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id CEDAE117; Sun, 3 Feb 2013 17:03:56 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id TAA09315; Sun, 03 Feb 2013 19:03:52 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1U22yu-0006ko-C9; Sun, 03 Feb 2013 19:03:52 +0200 Message-ID: <510E9877.5000701@FreeBSD.org> Date: Sun, 03 Feb 2013 19:03:51 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130121 Thunderbird/17.0.2 MIME-Version: 1.0 To: Rick Macklem , Sergey Kandaurov Subject: Re: panic: LK_RETRY set with incompatible flags References: <74133619.2630890.1359909414548.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <74133619.2630890.1359909414548.JavaMail.root@erie.cs.uoguelph.ca> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Konstantin Belousov , FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 03 Feb 2013 17:03:57 -0000 on 03/02/2013 18:36 Rick Macklem said the following: > I can think of two possibilities: > 1 - ZFS isn't setting VV_ROOT on the root vnode under some condition. > or > 2 - The vnode was left locked from some previous operation that happened > to be done by this thread. Doesn't seem likely, but??? > > Maybe Sergey could try the change to line#1451 and see if the panic > still happens. If not, that would suggest possibility #1, I think. If the kernel is configured with witness, then it should be easy to check where the exclusive lock was taken (file and line number). -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Sun Feb 3 17:17:59 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 25E009F6; Sun, 3 Feb 2013 17:17:59 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 863CA1A4; Sun, 3 Feb 2013 17:17:58 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r13HHhjL058355; Sun, 3 Feb 2013 19:17:43 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.4 kib.kiev.ua r13HHhjL058355 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r13HHh0O058354; Sun, 3 Feb 2013 19:17:43 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 3 Feb 2013 19:17:43 +0200 From: Konstantin Belousov To: Marius Strobl Subject: Re: Physbio changes final call for tests and reviews Message-ID: <20130203171743.GS2522@kib.kiev.ua> References: <20130202163322.GA2522@kib.kiev.ua> <20130203155718.GA6204@alchemy.franken.de> <20130203161145.GQ2522@kib.kiev.ua> <20130203164624.GL80850@alchemy.franken.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="YyxSosoRaUW6PdRh" Content-Disposition: inline In-Reply-To: <20130203164624.GL80850@alchemy.franken.de> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: arch@freebsd.org, current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 03 Feb 2013 17:17:59 -0000 --YyxSosoRaUW6PdRh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Feb 03, 2013 at 05:46:24PM +0100, Marius Strobl wrote: > On Sun, Feb 03, 2013 at 06:11:45PM +0200, Konstantin Belousov wrote: > > On Sun, Feb 03, 2013 at 04:57:18PM +0100, Marius Strobl wrote: > > > On Sat, Feb 02, 2013 at 06:33:22PM +0200, Konstantin Belousov wrote: > > > > Hi, > > > > I finished the last (insignificant) missed bits in the Jeff' physbio > > > > work. Now I am asking for the last round of testing and review, esp= =2E for > > > > the !x86 architectures. Another testing focus are the SCSI HBAs and= RAID > > > > controllers which drivers are changed by the patchset. Please do te= st > > > > this before the patchset is committed into HEAD ! > > > >=20 > > > > The plan is to commit the patch somewhere in two weeks from this mo= ment. > > > > The patch is required for the finalizing of the unmapped I/O work f= or UFS > > > > I did in parallel, which I hope to finish shortly after the commit. > > > >=20 > > > > Patch is available at http://people.freebsd.org/~kib/misc/physbio.5= =2Ediff > > > >=20 > > >=20 > > > Once you bring in said UFS changes, will the use of bus_dmamap_load_c= cb(9) > > > be a requirement for disk controller drivers? > >=20 > > Generally speaking, no. I plan to do the gradual migration of the drive= rs, > > definitely not forcing the unmapped bios down to the drivers which are > > not tested yet. In the patch, driver indicates the support for unmapped > > bios by a DISKFLAG. If flag is set, driver could receive both mapped > > and unmapped bios, and use of the bus_dmamap_load_ccb(), while formally > > is only convenience, is essentially the requirement. > >=20 > > If driver does not set the flag, it receives the same i/o requests as > > it does now. Geom performs transient compat mapping for the unmapped > > requests on its own for such drivers. As result, driver does not need > > a change. > >=20 > > My plan is to convert ahci(4) and then some often used high-profile dri= vers > > like mfi(4) and mps(4). I can also hope for isci(4) help. > >=20 > > Everything else, IMO, could be done on the best efforts basis, when both > > developers time and testing facilities are available. Jeff wanted to do > > all driver conversion in one pass, but IMO this is unrealistic. Still, I > > started write some helpers which should provide the transient one-page > > mappings for PIO modes. >=20 > Okay >=20 > >=20 > > You can look at some previous version of the unmapped patch at > > http://people.freebsd.org/~kib/misc/unmapped.8.patch. It only contain a > > hack for ahci(4), which should be fixed properly after physbio is commi= tted. >=20 > Hrm, the changes to the sparc64 pmap code in the latter patch might > need some more attention as some of the functions used for copying > pages there IIRC have constraints on the aligment of source and > destination as well as on the count. Can you say something about > these properties when pmap_copy_page_offs() is called via > pmap_copy_pages()? There is no constraints on the offsets or length for the pmap_copy_pages() itself. As a consequence, the only (obvious) constraint is that cnt <=3D PAGE_SIZE for sparc64 pmap_copy_page_offs(). I will be glad to obtain the help, both as advise and patch, for any !x86 architecture. For x86 too. Yes, pmap_copy_pages() is the corner-stone of the data moves needed when operating on the unmapped buffers. Our current i/o path already converts user buffers into the page list, but it was enough to use uiomove_fromphys() so far, because buffers were always mapped. Now, unmapped buffers provide the other side of the copy with the page list, so I need operation like pmap_copy_pages(). --YyxSosoRaUW6PdRh Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRDpu2AAoJEJDCuSvBvK1By24P/Rp+VIMl++pMjg6C7/A5ed0I AIZ70QQEPIekITd3AOj1UekTLUsYdGCoHT4ruSpJ3PNXIGyUqzUzVnsjR5sMHVzV 4PlHDEW6TFwm9MLs7mLio5hgQ7V0vj1yJMxhPyMhAD8lPk3sr40wUKIJM5VbT7B2 tli+sFag/J9Gq3kJ2LAROKaoYYD8dBczvP65xZgdQR/B2tWzdaUHQevaowGd8QNS WfuafBivVMKy5PR6zRDzWJF8EuDedlwFNfnbQvCns/7OH65zJuEFql1P2P6Iir8U vHWQRgo/Av8aIgTRIfptxQwCLDtlOzJKxKvgaYAQMDVF75oQhhoKRk5Zm4kfvZvR bHszvl8qIx9jilKdmxdwK86kBSjxpg6Yr5DfeXklYvLL5kycrs60mYWvXwY/OK8A HAXoXi1hwH8hka4G0lfHpCSKrHg7Q47fISwCUTkBa+sWpsnXk9VUipuSJb9tWpzd +5h95ffeil4F56gKAHk1CC+rykN1kNuSbvoZpVRQCe/E467YjqXDJWV29c8IPoMs dUY/p62IBSs8sZu3M62O0582CYzP2gto+zdQYgA9516YeJZYSku7DXbO15NmdlCG wWzOIZ6nsIdUOt50/nmXgWKuqj0V3wh+tjNR8wz7P1uG0Kldrfy1QjFBdmGE+n2P na1lt2H31/EYW8JmRgMy =9bnf -----END PGP SIGNATURE----- --YyxSosoRaUW6PdRh-- From owner-freebsd-current@FreeBSD.ORG Sun Feb 3 17:45:03 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 72507619; Sun, 3 Feb 2013 17:45:03 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 72E3F2C6; Sun, 3 Feb 2013 17:45:02 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id TAA09560; Sun, 03 Feb 2013 19:44:58 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1U23cg-0006ph-81; Sun, 03 Feb 2013 19:44:58 +0200 Message-ID: <510EA219.2090504@FreeBSD.org> Date: Sun, 03 Feb 2013 19:44:57 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130121 Thunderbird/17.0.2 MIME-Version: 1.0 To: freebsd-current@FreeBSD.org Subject: detect mwait capabilities and extensions X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=X-VIET-VPS Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 03 Feb 2013 17:45:03 -0000 Guys, could you please the following change? It is amd64-centric now, but obviously I plan equivalent changes for i386. I am mostly concerned about proper header files for various definitions and proper names for them. Especially I am not sure where to put STATE_RUNNING, STATE_MWAIT, STATE_SLEEPING... Thank you. diff --git a/sys/amd64/amd64/identcpu.c b/sys/amd64/amd64/identcpu.c index 2517498..d831f95 100644 --- a/sys/amd64/amd64/identcpu.c +++ b/sys/amd64/amd64/identcpu.c @@ -513,6 +513,13 @@ identify_cpu(void) } } + if (cpu_high >= 5 && (cpu_feature2 & CPUID2_MON) != 0) { + do_cpuid(5, regs); + cpu_mon_mwait_flags = regs[2]; + cpu_mon_min_size = regs[0] & CPUID5_MON_MIN_SIZE; + cpu_mon_max_size = regs[1] & CPUID5_MON_MAX_SIZE; + } + if (cpu_high >= 7) { cpuid_count(7, 0, regs); cpu_stdext_feature = regs[1]; diff --git a/sys/amd64/amd64/initcpu.c b/sys/amd64/amd64/initcpu.c index 4abed4c..f7574b1 100644 --- a/sys/amd64/amd64/initcpu.c +++ b/sys/amd64/amd64/initcpu.c @@ -75,6 +75,9 @@ u_int cpu_mxcsr_mask; /* Valid bits in mxcsr */ u_int cpu_clflush_line_size = 32; u_int cpu_stdext_feature; u_int cpu_max_ext_state_size; +u_int cpu_mon_mwait_flags; /* MONITOR/MWAIT flags (CPUID.05H.ECX) */ +u_int cpu_mon_min_size; /* MONITOR minimum range size, bytes */ +u_int cpu_mon_max_size; /* MONITOR minimum range size, bytes */ SYSCTL_UINT(_hw, OID_AUTO, via_feature_rng, CTLFLAG_RD, &via_feature_rng, 0, "VIA RNG feature available in CPU"); diff --git a/sys/amd64/include/md_var.h b/sys/amd64/include/md_var.h index 5d7cb74..ddc5b9f 100644 --- a/sys/amd64/include/md_var.h +++ b/sys/amd64/include/md_var.h @@ -58,6 +58,9 @@ extern u_int cpu_procinfo; extern u_int cpu_procinfo2; extern char cpu_vendor[]; extern u_int cpu_vendor_id; +extern u_int cpu_mon_mwait_flags; +extern u_int cpu_mon_min_size; +extern u_int cpu_mon_max_size; extern char ctx_switch_xsave[]; extern char kstack[]; extern char sigcode[]; diff --git a/sys/x86/include/specialreg.h b/sys/x86/include/specialreg.h index dbf9ba0..af64c1b 100644 --- a/sys/x86/include/specialreg.h +++ b/sys/x86/include/specialreg.h @@ -240,6 +240,29 @@ #define CPUID_LOCAL_APIC_ID 0xff000000 /* + * CPUID instruction 5 info + */ +#define CPUID5_MON_MIN_SIZE 0x0000ffff /* eax */ +#define CPUID5_MON_MAX_SIZE 0x0000ffff /* ebx */ +#define CPUID5_MON_MWAIT_EXT 0x00000001 /* ecx */ +#define CPUID5_MWAIT_INTRBREAK 0x00000002 /* ecx */ + +/* + * MWAIT cpu power states. Lower 4 bits are sub-states. + */ +#define MWAIT_C0 0xf0 +#define MWAIT_C1 0x00 +#define MWAIT_C2 0x10 +#define MWAIT_C3 0x20 +#define MWAIT_C4 0x30 + +/* + * MWAIT extensions. + */ +/* Interrupt breaks MWAIT even when masked. */ +#define MWAIT_INTRBREAK 0x00000001 + +/* * CPUID instruction 6 ecx info */ #define CPUID_PERF_STAT 0x00000001 --- a/sys/amd64/amd64/machdep.c +++ b/sys/amd64/amd64/machdep.c @@ -665,10 +665,6 @@ TUNABLE_INT("machdep.idle_mwait", &idle_mwait); SYSCTL_INT(_machdep, OID_AUTO, idle_mwait, CTLFLAG_RW, &idle_mwait, 0, "Use MONITOR/MWAIT for short idle"); -#define STATE_RUNNING 0x0 -#define STATE_MWAIT 0x1 -#define STATE_SLEEPING 0x2 - static void cpu_idle_acpi(int busy) { diff --git a/sys/amd64/include/cpu.h b/sys/amd64/include/cpu.h index 1c2871f..dc29a37 100644 --- a/sys/amd64/include/cpu.h +++ b/sys/amd64/include/cpu.h @@ -43,8 +43,14 @@ #include #include +/* + * CPU states for the purpose of communication using MONITOR+MWAIT. */ +#define STATE_RUNNING 0x0 +#define STATE_MWAIT 0x1 +#define STATE_SLEEPING 0x2 + #define cpu_exec(p) /* nothing */ #define cpu_swapin(p) /* nothing */ #define cpu_getstack(td) ((td)->td_frame->tf_rsp) #define cpu_setstack(td, ap) ((td)->td_frame->tf_rsp = (ap)) #define cpu_spinwait() ia32_pause() -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Sun Feb 3 20:06:51 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3C494A67 for ; Sun, 3 Feb 2013 20:06:51 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id 1AEF687B for ; Sun, 3 Feb 2013 20:06:50 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r13K6iss075010 for freebsd-current@freebsd.org; Sun, 3 Feb 2013 20:06:44 GMT (envelope-from kientzle@freebsd.org) Received: from [192.168.2.143] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id 24py59izzhwq25nhazkwbznuja; for freebsd-current@freebsd.org; Sun, 03 Feb 2013 20:06:44 +0000 (UTC) (envelope-from kientzle@freebsd.org) From: Tim Kientzle Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: gpart resize vs. cache? Date: Sun, 3 Feb 2013 12:06:41 -0800 Message-Id: <3D812191-2D6E-43B2-B9C1-F00FFA44C5F8@freebsd.org> To: freebsd-current Current Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 03 Feb 2013 20:06:51 -0000 I'm tinkering with a disk image that automatically fills whatever media you put it onto. But I'm having trouble with gpart resize failing. Disk layout: MBR with two slices mmcsd0s1 and mmcsd0s2 bsdlabel with one partition mmcsd0s2a Before I can use growfs, I have two gpart resize operations: 1) gpart resize -i 2 mmcsd0 2) gpart resize -i 1 mmcsd0s2 Step 1 resizes mmcsd0s2 and always succeeds. Step 2 resizes mmcsd0s2a and always fails with "No space on device." BUT if I reboot between these steps, step #2 always succeeds. I suspect that step #1 is updating the partition information on disk but that step #2 is somehow reading the old size of mmcsd0s2 and thus finding that there is no available space to grow the partition. gpart(1) doesn't say anything about caching of disk partiition info and "gpart list" does show the updated information after step #1. Is there some trick that will force the partition information in memory to be updated (short of a reboot or unmount/remount the root filesystem)? Tim From owner-freebsd-current@FreeBSD.ORG Sun Feb 3 20:48:44 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A5860DBE for ; Sun, 3 Feb 2013 20:48:44 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [IPv6:2001:7b8:3a7:1:2d0:b7ff:fea0:8c26]) by mx1.freebsd.org (Postfix) with ESMTP id 5F8C59C1 for ; Sun, 3 Feb 2013 20:48:44 +0000 (UTC) Received: from [192.168.0.6] (spaceball.home.andric.com [192.168.0.6]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 092C65C5A; Sun, 3 Feb 2013 21:48:43 +0100 (CET) Message-ID: <510ECD2A.5000104@FreeBSD.org> Date: Sun, 03 Feb 2013 21:48:42 +0100 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/20130117 Thunderbird/19.0 MIME-Version: 1.0 To: "O. Hartmann" , Current FreeBSD Subject: Re: r246057: buildworld fails with: /usr/obj/usr/src/tmp/usr/lib/libc++.so: undefined reference to `std::bad_alloc::~bad_alloc()' References: <51079F0A.20309@zedat.fu-berlin.de> In-Reply-To: <51079F0A.20309@zedat.fu-berlin.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 03 Feb 2013 20:48:44 -0000 On 2013-01-29 11:06, O. Hartmann wrote: > I receive this error since yesterday building world and it is still > sticky on most recent sources (r246057) and I was wondering why the > tinderboxes do not pick this up on the 10.0-CURRENT builds ... just for > a notice for the development folks ... ... > /usr/obj/usr/src/tmp/usr/lib/libc++.so: undefined reference to > `std::bad_alloc::~bad_alloc()' I have committed a fix for libcxxrt's symbol version map in r246297. Please update to that revision, clean out /usr/obj, and try buildworld again. -Dimitry From owner-freebsd-current@FreeBSD.ORG Sun Feb 3 21:09:04 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 293263DD; Sun, 3 Feb 2013 21:09:04 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id 02EABA69; Sun, 3 Feb 2013 21:09:03 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.6/8.14.6) with ESMTP id r13L8uGp072257; Sun, 3 Feb 2013 14:08:56 -0700 (MST) (envelope-from ian@FreeBSD.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r13L8XP5028661; Sun, 3 Feb 2013 14:08:33 -0700 (MST) (envelope-from ian@FreeBSD.org) Subject: Re: gpart resize vs. cache? From: Ian Lepore To: Tim Kientzle In-Reply-To: <3D812191-2D6E-43B2-B9C1-F00FFA44C5F8@freebsd.org> References: <3D812191-2D6E-43B2-B9C1-F00FFA44C5F8@freebsd.org> Content-Type: text/plain; charset="us-ascii" Date: Sun, 03 Feb 2013 14:08:33 -0700 Message-ID: <1359925713.93359.440.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-current Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 03 Feb 2013 21:09:04 -0000 On Sun, 2013-02-03 at 12:06 -0800, Tim Kientzle wrote: > I'm tinkering with a disk image that automatically > fills whatever media you put it onto. But I'm having > trouble with gpart resize failing. > > Disk layout: > MBR with two slices mmcsd0s1 and mmcsd0s2 > bsdlabel with one partition mmcsd0s2a > > Before I can use growfs, I have two gpart resize operations: > > 1) gpart resize -i 2 mmcsd0 > > 2) gpart resize -i 1 mmcsd0s2 > > Step 1 resizes mmcsd0s2 and always succeeds. > > Step 2 resizes mmcsd0s2a and always fails > with "No space on device." > > BUT if I reboot between these steps, step #2 > always succeeds. > > I suspect that step #1 is updating the partition > information on disk but that step #2 is somehow > reading the old size of mmcsd0s2 and thus finding > that there is no available space to grow the partition. > > gpart(1) doesn't say anything about caching of > disk partiition info and "gpart list" does show the > updated information after step #1. > > Is there some trick that will force the partition > information in memory to be updated (short of > a reboot or unmount/remount the root filesystem)? This sounds like one of those situations where the "force re-taste" incantation may work... just open/close the parent geom for write. From script, it's as easy as : >/dev/mmcsd0s2 If that doesn't work, try /dev/mmcsd0. The re-taste trick is usually only needed on things like a usb sdcard reader where it can't tell you changed media and tries to use the in-memory info from the prior card. Since you're using a geom-aware tool to make a geom change, I wonder why it doesn't do the re-taste automatically? -- Ian From owner-freebsd-current@FreeBSD.ORG Sun Feb 3 23:50:26 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A1C13A23; Sun, 3 Feb 2013 23:50:26 +0000 (UTC) (envelope-from erichsfreebsdlist@alogt.com) Received: from alogt.com (alogt.com [69.36.191.58]) by mx1.freebsd.org (Postfix) with ESMTP id 125FAF98; Sun, 3 Feb 2013 23:50:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alogt.com; s=default; h=Content-Transfer-Encoding:Content-Type:Mime-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=6oAjsAWpZ8zEzzsQ+hk8anLpNl7J4qqLoVzgRwAp2Ag=; b=pbEntI4NOpMf7HTmmUk2Lvvo1nuoGXawCsJQa0pSqRCZNK7vfgejD4Rz+yUGzfYrFxSECE5tCecm3Yc/E+jLGY9xig7iLMzqr5ZlWtBHaEkbrWk5TxVLzctiwEn52lYG; Received: from [122.129.203.50] (port=47993 helo=X220.ovitrap.com) by sl-508-2.slc.westdc.net with esmtpsa (SSLv3:DHE-RSA-AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1U28vX-001FmK-Hf; Sun, 03 Feb 2013 16:24:48 -0700 Date: Mon, 4 Feb 2013 06:24:43 +0700 From: Erich Dollansky To: Tim Kientzle Subject: Re: gpart resize vs. cache? Message-ID: <20130204062443.485cff60@X220.ovitrap.com> In-Reply-To: <3D812191-2D6E-43B2-B9C1-F00FFA44C5F8@freebsd.org> References: <3D812191-2D6E-43B2-B9C1-F00FFA44C5F8@freebsd.org> X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.6; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sl-508-2.slc.westdc.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - alogt.com X-Get-Message-Sender-Via: sl-508-2.slc.westdc.net: authenticated_id: erichsfreebsdlist@alogt.com X-Source: X-Source-Args: X-Source-Dir: Cc: freebsd-current Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 03 Feb 2013 23:50:26 -0000 Hi, On Sun, 3 Feb 2013 12:06:41 -0800 Tim Kientzle wrote: > I'm tinkering with a disk image that automatically > fills whatever media you put it onto. But I'm having > trouble with gpart resize failing. > > Disk layout: > MBR with two slices mmcsd0s1 and mmcsd0s2 > bsdlabel with one partition mmcsd0s2a > > Before I can use growfs, I have two gpart resize operations: > > 1) gpart resize -i 2 mmcsd0 > > 2) gpart resize -i 1 mmcsd0s2 > > Step 1 resizes mmcsd0s2 and always succeeds. > > Step 2 resizes mmcsd0s2a and always fails > with "No space on device." > I used a gpart show between in a different situation. The script did not work without it. When I entered the same commands from the command line, they all worked. So, things could be related to cache or delayed writes. Erich From owner-freebsd-current@FreeBSD.ORG Mon Feb 4 00:27:40 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 7A3FB405; Mon, 4 Feb 2013 00:27:40 +0000 (UTC) (envelope-from kientzle@FreeBSD.org) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id 4325111D; Mon, 4 Feb 2013 00:27:39 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r140RadB076000; Mon, 4 Feb 2013 00:27:36 GMT (envelope-from kientzle@FreeBSD.org) Received: from [192.168.2.143] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id n3i7sjeja8zz6b82xwnea392ji; Mon, 04 Feb 2013 00:27:36 +0000 (UTC) (envelope-from kientzle@FreeBSD.org) Subject: Re: gpart resize vs. cache? Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Tim Kientzle In-Reply-To: <1359925713.93359.440.camel@revolution.hippie.lan> Date: Sun, 3 Feb 2013 16:27:33 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3D812191-2D6E-43B2-B9C1-F00FFA44C5F8@freebsd.org> <1359925713.93359.440.camel@revolution.hippie.lan> To: Ian Lepore , Erich Dollansky X-Mailer: Apple Mail (2.1283) Cc: freebsd-current Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 04 Feb 2013 00:27:40 -0000 On Feb 3, 2013, at 1:08 PM, Ian Lepore wrote: > On Sun, 2013-02-03 at 12:06 -0800, Tim Kientzle wrote: >> I'm tinkering with a disk image that automatically >> fills whatever media you put it onto. But I'm having >> trouble with gpart resize failing. >>=20 >> Disk layout: >> MBR with two slices mmcsd0s1 and mmcsd0s2 >> bsdlabel with one partition mmcsd0s2a >>=20 >> Before I can use growfs, I have two gpart resize operations: >>=20 >> 1) gpart resize -i 2 mmcsd0 >>=20 >> 2) gpart resize -i 1 mmcsd0s2 >>=20 >> Step 1 resizes mmcsd0s2 and always succeeds. >>=20 >> Step 2 resizes mmcsd0s2a and always fails >> with "No space on device." >>=20 >> BUT if I reboot between these steps, step #2 >> always succeeds. >>=20 >> I suspect that step #1 is updating the partition >> information on disk but that step #2 is somehow >> reading the old size of mmcsd0s2 and thus finding >> that there is no available space to grow the partition. BTW, I've added some debug messages to gpart and the second resize is failing because the new computed size is a little smaller than the old size (maybe because of a different alignment?). But it's certainly not sizing to the new container size. >> gpart(1) doesn't say anything about caching of >> disk partiition info and "gpart list" does show the >> updated information after step #1. >>=20 >> Is there some trick that will force the partition >> information in memory to be updated (short of >> a reboot or unmount/remount the root filesystem)? >=20 > This sounds like one of those situations where the "force re-taste" > incantation may work... just open/close the parent geom for write. = From > script, it's as easy as >=20 > : >/dev/mmcsd0s2 >=20 > If that doesn't work, try /dev/mmcsd0. >=20 > The re-taste trick is usually only needed on things like a usb sdcard > reader where it can't tell you changed media and tries to use the > in-memory info from the prior card. Since you're using a geom-aware > tool to make a geom change, I wonder why it doesn't do the re-taste > automatically? That certainly changes things, but not in a good way. Here's the key part of the script now: gpart resize -i 2 mmcsd0 :> /dev/mmcsd0 gpart resize -i 1 mmcsd0s2 :> /dev/mmcsd0s2 growfs -y /dev/mmcsd0s2a And here's the result: mmcsd0s2 resized mmcsd0s2a resized eval: growfs: Device not configured =85 lots more "Device not configured", ultimately leading to=85 vm_fault: pager read error, pid 1 (init) vnode_pager_getpages: I/O read error vm_fault: pager read error, pid 1 (init) vnode_pager_getpages: I/O read error =85 which keeps scrolling until I pull power. Apparently this hosed the root mount (I've tried every combination of one or both force retastes above with the same effect). It does not appear that the disk is hosed as I can reboot single user and everything is okay, but every time this code runs the same errors occur. I also tried Erich Dollansky's suggestion of adding a "gpart show" between the resize requests but that seems to make no difference at all. Tim From owner-freebsd-current@FreeBSD.ORG Mon Feb 4 01:07:47 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 79348328; Mon, 4 Feb 2013 01:07:47 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 0EA5B29C; Mon, 4 Feb 2013 01:07:46 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAEAJ0ID1GDaFvO/2dsb2JhbAA8CIZItQ+DdHOCHwEBBSNWGw4KAgINGQJZBogkrSeRVIEjjAODGYETA4hmjTmJVYZ8gxqCBg X-IronPort-AV: E=Sophos;i="4.84,596,1355115600"; d="scan'208";a="14893958" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 03 Feb 2013 20:07:45 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id CD66FB3F44; Sun, 3 Feb 2013 20:07:45 -0500 (EST) Date: Sun, 3 Feb 2013 20:07:45 -0500 (EST) From: Rick Macklem To: Andriy Gapon Message-ID: <1515954355.2640466.1359940065810.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <510E9877.5000701@FreeBSD.org> Subject: Re: panic: LK_RETRY set with incompatible flags MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.203] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: Konstantin Belousov , FreeBSD Current , Sergey Kandaurov X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 04 Feb 2013 01:07:47 -0000 Andriy Gapon wrote: > on 03/02/2013 18:36 Rick Macklem said the following: > > I can think of two possibilities: > > 1 - ZFS isn't setting VV_ROOT on the root vnode under some > > condition. > > or > > 2 - The vnode was left locked from some previous operation that > > happened > > to be done by this thread. Doesn't seem likely, but??? > > > > Maybe Sergey could try the change to line#1451 and see if the panic > > still happens. If not, that would suggest possibility #1, I think. > > If the kernel is configured with witness, then it should be easy to > check where > the exclusive lock was taken (file and line number). > Yep. If Sergey can reproduce this using a kernel with witness, doing "show witness" to see where the lock on the directory vnode was acquired, could be helpful. rick > -- > Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Mon Feb 4 01:50:18 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E90ACC7; Mon, 4 Feb 2013 01:50:18 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 316A5658; Mon, 4 Feb 2013 01:50:17 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAEAEQTD1GDaFvO/2dsb2JhbAA4BAiGSLUPg3Vzgh8BAQQBHQYEUgUWDgoCAg0ZAlkGEYgNBq0skVaBI4tyAQQMgxmBEwOIZo05iVWGfIMaIYEwNQ X-IronPort-AV: E=Sophos;i="4.84,596,1355115600"; d="scan'208";a="14897909" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 03 Feb 2013 20:50:17 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 33857B3F26; Sun, 3 Feb 2013 20:50:17 -0500 (EST) Date: Sun, 3 Feb 2013 20:50:17 -0500 (EST) From: Rick Macklem To: Konstantin Belousov Message-ID: <1982774587.2641177.1359942617191.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <20130203110759.GM2522@kib.kiev.ua> Subject: Re: panic: LK_RETRY set with incompatible flags MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.202] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: FreeBSD Current , Sergey Kandaurov , Andriy Gapon X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 04 Feb 2013 01:50:19 -0000 Konstantin Belousov wrote: > On Sat, Feb 02, 2013 at 09:30:39PM -0500, Rick Macklem wrote: > > Andriy Gapon wrote: > > > on 31/01/2013 15:29 Sergey Kandaurov said the following: > > > > Hi. > > > > > > > > Got this assertion on idle NFS server while `ls -la > > > > /.zfs/shares/' > > > > issued on NFS client. > > > > kern/vfs_vnops.c:_vn_lock() > > > > KASSERT((flags & LK_RETRY) == 0 || error == 0, > > > > ("LK_RETRY set with incompatible flags > > > > (0x%x) or > > > > an error occured (%d)", > > > > > > > > panic: LK_RETRY set with incompatible flags (0x200400) or an > > > > error > > > > occured (11) > > > > > > > > What does that mean and how is it possible? As you can see, both > > > > parts > > > > of assertion failed. > > > > 11 is EDEADLK > > > > 0x200400: LK_RETRY & LK_UPGRADE > > > > > > LK_SHARED, not LK_UPGRADE. > > > Apparently the thread already holds an exlusive lock on the vnode, > > > which you > > > confirm below. > > > > > > > > > > Tracing pid 2943 tid 101532 td 0xfffffe004f5b7000 > > > > kdb_enter() at kdb_enter+0x3e/frame 0xffffff848e45ef50 > > > > vpanic() at vpanic+0x147/frame 0xffffff848e45ef90 > > > > kassert_panic() at kassert_panic+0x136/frame 0xffffff848e45f000 > > > > _vn_lock() at _vn_lock+0x70/frame 0xffffff848e45f070 > > > > zfs_lookup() at zfs_lookup+0x392/frame 0xffffff848e45f100 > > > > zfs_freebsd_lookup() at zfs_freebsd_lookup+0x6d/frame > > > > 0xffffff848e45f240 > > > > VOP_CACHEDLOOKUP_APV() at VOP_CACHEDLOOKUP_APV+0xc2/frame > > > > 0xffffff848e45f260 > > > > vfs_cache_lookup() at vfs_cache_lookup+0xcf/frame > > > > 0xffffff848e45f2b0 > > > > VOP_LOOKUP_APV() at VOP_LOOKUP_APV+0xc2/frame 0xffffff848e45f2d0 > > > > lookup() at lookup+0x548/frame 0xffffff848e45f350 > > > > nfsvno_namei() at nfsvno_namei+0x1a5/frame 0xffffff848e45f400 > > > > nfsrvd_lookup() at nfsrvd_lookup+0x13a/frame 0xffffff848e45f6b0 > > > > nfsrvd_dorpc() at nfsrvd_dorpc+0xca5/frame 0xffffff848e45f8a0 > > > > nfssvc_program() at nfssvc_program+0x482/frame > > > > 0xffffff848e45fa00 > > > > svc_run_internal() at svc_run_internal+0x1e9/frame > > > > 0xffffff848e45fba0 > > > > svc_thread_start() at svc_thread_start+0xb/frame > > > > 0xffffff848e45fbb0 > > > > fork_exit() at fork_exit+0x84/frame 0xffffff848e45fbf0 > > > > fork_trampoline() at fork_trampoline+0xe/frame > > > > 0xffffff848e45fbf0 > > > > --- trap 0xc, rip = 0x800883e9a, rsp = 0x7fffffffd488, rbp = > > > > 0x7fffffffd730 --- > > > > > > > > db> show lockedvnods > > > > Locked vnodes > > > > > > > > 0xfffffe02e21b11d8: tag zfs, type VDIR > > > > usecount 4, writecount 0, refcount 4 mountedhere 0 > > > > flags (VI_ACTIVE) > > > > v_object 0xfffffe02d9f2eb40 ref 0 pages 0 > > > > lock type zfs: EXCL by thread 0xfffffe004f5b7000 (pid 2943, > > > > nfsd, > > > > tid 101532) > > > > > > > > > > > > > > I just took a look at zfs_vnops.c and I am probably missing > > something, > > but I can't see how this ever worked for a lookup of ".." when at > > the > > root (unless ZFS doesn't do the ".." is the current directory when > > at > > the root). > > > > Here's the code snippet: > > 1442 if (error == 0 && (nm[0] != '.' || nm[1] != '\0')) { > > 1443 int ltype = 0; > > 1444 > > 1445 if (cnp->cn_flags & ISDOTDOT) { > > 1446 ltype = VOP_ISLOCKED(dvp); > > 1447 VOP_UNLOCK(dvp, 0); > > 1448 } > > 1449 ZFS_EXIT(zfsvfs); > > 1450 error = zfs_vnode_lock(*vpp, cnp->cn_lkflags); > > 1451 if (cnp->cn_flags & ISDOTDOT) > > 1452 vn_lock(dvp, ltype | LK_RETRY); > > 1453 if (error != 0) { > > 1454 VN_RELE(*vpp); > > 1455 *vpp = NULL; > > 1456 return (error); > > 1457 } > > > > Maybe line# 1451 should be changed to: > > if ((cnp->cn_flags & ISDOTDOT) && *vpp != dvp) > > > > I'm not at all familiar with ZFS, so I've probably way > > off the mark on this, rick > > ps: I hope kib and jhb don't mind being added as cc's, since > > they are familiar with this stuff, although maybe not ZFS > > specifics. > > VFS (should) never call VOP_LOOKUP for the dotdot and root vnode. > The logic in the lookup() prevents it. > Correcting my previous posts, like usual. If you look at the above snippet of code, it seems that zfs_lock_vnode() must lock the same vnode as *dvp. Notice that vn_lock() is only called when ISDOTDOT is set and the code does a VOP_UNLOCK(dvp, 0); for this case, just before the zfs_vnode_lock(). This assumes that the vn_lock() call at #1452 causes the panic. This is the only vn_lock() call in zfs_lookup(), so unless the compiler has done something weird, it seems the case. Sergey, do you have this kernel handy? If so, maybe you could check the line# for zfs_lookup+0x392. (If you haven't done this before, just email and I'll give you the steps. You just need the kernel.symbols file for the kernel that panic'd.) I'll take a look at zfs_dirlookup() to see if I can spot any case where it will return the same vnode as the dvp argument. rick > Might it be a missing check in the nfs server code ? (I did not looked > yet). From owner-freebsd-current@FreeBSD.ORG Mon Feb 4 02:32:21 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 9917B7C8; Mon, 4 Feb 2013 02:32:21 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.net.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 024497F7; Mon, 4 Feb 2013 02:32:20 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAEAGAcD1GDaFvO/2dsb2JhbAA8CIZItRCDdnOCHwEBBSMEUhsOCgICDRkCWQaIJK0jkVqBI4wDgxmBEwOIZo05iVWGfIMaggY X-IronPort-AV: E=Sophos;i="4.84,596,1355115600"; d="scan'208";a="12255687" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu.net.uoguelph.ca with ESMTP; 03 Feb 2013 21:32:19 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 6AEBEB3EEA; Sun, 3 Feb 2013 21:32:19 -0500 (EST) Date: Sun, 3 Feb 2013 21:32:19 -0500 (EST) From: Rick Macklem To: Konstantin Belousov Message-ID: <2051134267.2641928.1359945139386.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <20130203110759.GM2522@kib.kiev.ua> Subject: Re: panic: LK_RETRY set with incompatible flags MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.203] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: FreeBSD Current , Sergey Kandaurov , Andriy Gapon X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 04 Feb 2013 02:32:21 -0000 Konstantin Belousov wrote: > On Sat, Feb 02, 2013 at 09:30:39PM -0500, Rick Macklem wrote: > > Andriy Gapon wrote: > > > on 31/01/2013 15:29 Sergey Kandaurov said the following: > > > > Hi. > > > > > > > > Got this assertion on idle NFS server while `ls -la > > > > /.zfs/shares/' > > > > issued on NFS client. Ok, here's a snippet of zfs_dirlook() from zfs_dir.c: 388 } else if (name[0] == '.' && name[1] == '.' && name[2] == 0) { 389 zfsvfs_t *zfsvfs = dzp->z_zfsvfs; 390 391 /* 392 * If we are a snapshot mounted under .zfs, return 393 * the vp for the snapshot directory. 394 */ 395 if ((error = sa_lookup(dzp->z_sa_hdl, 396 SA_ZPL_PARENT(zfsvfs), &parent, sizeof (parent))) != 0) 397 return (error); 398 if (parent == dzp->z_id && zfsvfs->z_parent != zfsvfs) { 399 error = zfsctl_root_lookup(zfsvfs->z_parent->z_ctldir, 400 "snapshot", vpp, NULL, 0, NULL, kcred, 401 NULL, NULL, NULL); 402 return (error); 403 } Just reading the comment, I don't know what it is referring to by "snapshot directory". Would that be "shares" for Sergey's case? It seems too obvious, but maybe the lookup of ".." is returning the vnode for /.zfs/shares for this case? I don't know why this wouldn't have shown up before, but maybe it usually replies from its cache (I think zfs_lookup() calls it a "fast path"). It might still be interesting to replace zfs_vnops.c line# 1451 with: if ((cnp->cn_flags & ISDOTDOT) && *vpp != dvp) and see what happens? rick > > > > kern/vfs_vnops.c:_vn_lock() > > > > KASSERT((flags & LK_RETRY) == 0 || error == 0, > > > > ("LK_RETRY set with incompatible flags > > > > (0x%x) or > > > > an error occured (%d)", > > > > > > > > panic: LK_RETRY set with incompatible flags (0x200400) or an > > > > error > > > > occured (11) > > > > > > > > What does that mean and how is it possible? As you can see, both > > > > parts > > > > of assertion failed. > > > > 11 is EDEADLK > > > > 0x200400: LK_RETRY & LK_UPGRADE > > > > > > LK_SHARED, not LK_UPGRADE. > > > Apparently the thread already holds an exlusive lock on the vnode, > > > which you > > > confirm below. > > > > > > > > > > Tracing pid 2943 tid 101532 td 0xfffffe004f5b7000 > > > > kdb_enter() at kdb_enter+0x3e/frame 0xffffff848e45ef50 > > > > vpanic() at vpanic+0x147/frame 0xffffff848e45ef90 > > > > kassert_panic() at kassert_panic+0x136/frame 0xffffff848e45f000 > > > > _vn_lock() at _vn_lock+0x70/frame 0xffffff848e45f070 > > > > zfs_lookup() at zfs_lookup+0x392/frame 0xffffff848e45f100 > > > > zfs_freebsd_lookup() at zfs_freebsd_lookup+0x6d/frame > > > > 0xffffff848e45f240 > > > > VOP_CACHEDLOOKUP_APV() at VOP_CACHEDLOOKUP_APV+0xc2/frame > > > > 0xffffff848e45f260 > > > > vfs_cache_lookup() at vfs_cache_lookup+0xcf/frame > > > > 0xffffff848e45f2b0 > > > > VOP_LOOKUP_APV() at VOP_LOOKUP_APV+0xc2/frame 0xffffff848e45f2d0 > > > > lookup() at lookup+0x548/frame 0xffffff848e45f350 > > > > nfsvno_namei() at nfsvno_namei+0x1a5/frame 0xffffff848e45f400 > > > > nfsrvd_lookup() at nfsrvd_lookup+0x13a/frame 0xffffff848e45f6b0 > > > > nfsrvd_dorpc() at nfsrvd_dorpc+0xca5/frame 0xffffff848e45f8a0 > > > > nfssvc_program() at nfssvc_program+0x482/frame > > > > 0xffffff848e45fa00 > > > > svc_run_internal() at svc_run_internal+0x1e9/frame > > > > 0xffffff848e45fba0 > > > > svc_thread_start() at svc_thread_start+0xb/frame > > > > 0xffffff848e45fbb0 > > > > fork_exit() at fork_exit+0x84/frame 0xffffff848e45fbf0 > > > > fork_trampoline() at fork_trampoline+0xe/frame > > > > 0xffffff848e45fbf0 > > > > --- trap 0xc, rip = 0x800883e9a, rsp = 0x7fffffffd488, rbp = > > > > 0x7fffffffd730 --- > > > > > > > > db> show lockedvnods > > > > Locked vnodes > > > > > > > > 0xfffffe02e21b11d8: tag zfs, type VDIR > > > > usecount 4, writecount 0, refcount 4 mountedhere 0 > > > > flags (VI_ACTIVE) > > > > v_object 0xfffffe02d9f2eb40 ref 0 pages 0 > > > > lock type zfs: EXCL by thread 0xfffffe004f5b7000 (pid 2943, > > > > nfsd, > > > > tid 101532) > > > > > > > > > > > > > > I just took a look at zfs_vnops.c and I am probably missing > > something, > > but I can't see how this ever worked for a lookup of ".." when at > > the > > root (unless ZFS doesn't do the ".." is the current directory when > > at > > the root). > > > > Here's the code snippet: > > 1442 if (error == 0 && (nm[0] != '.' || nm[1] != '\0')) { > > 1443 int ltype = 0; > > 1444 > > 1445 if (cnp->cn_flags & ISDOTDOT) { > > 1446 ltype = VOP_ISLOCKED(dvp); > > 1447 VOP_UNLOCK(dvp, 0); > > 1448 } > > 1449 ZFS_EXIT(zfsvfs); > > 1450 error = zfs_vnode_lock(*vpp, cnp->cn_lkflags); > > 1451 if (cnp->cn_flags & ISDOTDOT) > > 1452 vn_lock(dvp, ltype | LK_RETRY); > > 1453 if (error != 0) { > > 1454 VN_RELE(*vpp); > > 1455 *vpp = NULL; > > 1456 return (error); > > 1457 } > > > > Maybe line# 1451 should be changed to: > > if ((cnp->cn_flags & ISDOTDOT) && *vpp != dvp) > > > > I'm not at all familiar with ZFS, so I've probably way > > off the mark on this, rick > > ps: I hope kib and jhb don't mind being added as cc's, since > > they are familiar with this stuff, although maybe not ZFS > > specifics. > > VFS (should) never call VOP_LOOKUP for the dotdot and root vnode. > The logic in the lookup() prevents it. > > Might it be a missing check in the nfs server code ? (I did not looked > yet). From owner-freebsd-current@FreeBSD.ORG Mon Feb 4 05:14:38 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 19D4842D; Mon, 4 Feb 2013 05:14:38 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) by mx1.freebsd.org (Postfix) with ESMTP id B2772D84; Mon, 4 Feb 2013 05:14:37 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.6/8.14.6) with ESMTP id r145ETTK009207; Sun, 3 Feb 2013 22:14:29 -0700 (MST) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.6/8.14.6/Submit) with ESMTP id r145ERVZ009204; Sun, 3 Feb 2013 22:14:27 -0700 (MST) (envelope-from wblock@wonkity.com) Date: Sun, 3 Feb 2013 22:14:27 -0700 (MST) From: Warren Block To: Tim Kientzle Subject: Re: gpart resize vs. cache? In-Reply-To: Message-ID: References: <3D812191-2D6E-43B2-B9C1-F00FFA44C5F8@freebsd.org> <1359925713.93359.440.camel@revolution.hippie.lan> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (wonkity.com [127.0.0.1]); Sun, 03 Feb 2013 22:14:29 -0700 (MST) Cc: Erich Dollansky , freebsd-current Current , Ian Lepore X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 04 Feb 2013 05:14:38 -0000 On Sun, 3 Feb 2013, Tim Kientzle wrote: > On Feb 3, 2013, at 1:08 PM, Ian Lepore wrote: > >> On Sun, 2013-02-03 at 12:06 -0800, Tim Kientzle wrote: >>> I'm tinkering with a disk image that automatically >>> fills whatever media you put it onto. But I'm having >>> trouble with gpart resize failing. >>> >>> Disk layout: >>> MBR with two slices mmcsd0s1 and mmcsd0s2 >>> bsdlabel with one partition mmcsd0s2a >>> >>> Before I can use growfs, I have two gpart resize operations: >>> >>> 1) gpart resize -i 2 mmcsd0 >>> >>> 2) gpart resize -i 1 mmcsd0s2 >>> >>> Step 1 resizes mmcsd0s2 and always succeeds. >>> >>> Step 2 resizes mmcsd0s2a and always fails >>> with "No space on device." >>> >>> BUT if I reboot between these steps, step #2 >>> always succeeds. >>> >>> I suspect that step #1 is updating the partition >>> information on disk but that step #2 is somehow >>> reading the old size of mmcsd0s2 and thus finding >>> that there is no available space to grow the partition. > > BTW, I've added some debug messages to gpart > and the second resize is failing because the new > computed size is a little smaller than the old size > (maybe because of a different alignment?). But > it's certainly not sizing to the new container size. MBR always forces alignment to imaginary CHS tracks, as if you used -a63 in gpart. But it's not gpart, it's the kernel being really strict about standards. As far as I've been able to tell, there is no way around that short of possibly dd-ing a preconstructed MBR partition table into place. From owner-freebsd-current@FreeBSD.ORG Mon Feb 4 11:49:10 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D8CB624A; Mon, 4 Feb 2013 11:49:10 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-qe0-f52.google.com (mail-qe0-f52.google.com [209.85.128.52]) by mx1.freebsd.org (Postfix) with ESMTP id 741BD158D; Mon, 4 Feb 2013 11:49:10 +0000 (UTC) Received: by mail-qe0-f52.google.com with SMTP id 6so2800944qeb.11 for ; Mon, 04 Feb 2013 03:49:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=izt/zTOkfZHDuORKhIcEFh6yo/6yJq7UMicsT/8mAsI=; b=RgqI2xWnsoVPPxfqpgzBxyzI/wRUAGzF7ej+iHgrub3+c/Hsglib/oDS0EhL7ds0hk hn7eiQmJg3n3q2WFLf1ot7PqyyEJdeuA1IpDKYjcTMJtwwUhkzaiR9OhlM9P3dwq975+ AIQosOSAArBiKboNwW5hPQnjPFCiTh9N+wiqJTIyEd3i6B1SEHAWZYUtafy8j/RvO7Je ts2JOV9ifRPaOjpVE2CI4xTb/obb9fV9CDo0CUyHLggP48yoLyO60hFlvSKMd1oZxms8 47UUUM9Q0epVsPqwjBG+C/iMI0DmGaFpbhy4ztsbtEkdTeEylAg+J6MMFM4zVXXc/NrJ vjAg== MIME-Version: 1.0 X-Received: by 10.49.74.10 with SMTP id p10mr20727104qev.35.1359978544400; Mon, 04 Feb 2013 03:49:04 -0800 (PST) Received: by 10.229.105.201 with HTTP; Mon, 4 Feb 2013 03:49:04 -0800 (PST) In-Reply-To: <1515954355.2640466.1359940065810.JavaMail.root@erie.cs.uoguelph.ca> References: <510E9877.5000701@FreeBSD.org> <1515954355.2640466.1359940065810.JavaMail.root@erie.cs.uoguelph.ca> Date: Mon, 4 Feb 2013 14:49:04 +0300 Message-ID: Subject: Re: panic: LK_RETRY set with incompatible flags From: Sergey Kandaurov To: Rick Macklem Content-Type: text/plain; charset=ISO-8859-1 Cc: Konstantin Belousov , FreeBSD Current , Andriy Gapon X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 04 Feb 2013 11:49:10 -0000 On 4 February 2013 05:07, Rick Macklem wrote: > Andriy Gapon wrote: >> on 03/02/2013 18:36 Rick Macklem said the following: >> > I can think of two possibilities: >> > 1 - ZFS isn't setting VV_ROOT on the root vnode under some >> > condition. >> > or >> > 2 - The vnode was left locked from some previous operation that >> > happened >> > to be done by this thread. Doesn't seem likely, but??? >> > >> > Maybe Sergey could try the change to line#1451 and see if the panic >> > still happens. If not, that would suggest possibility #1, I think. >> >> If the kernel is configured with witness, then it should be easy to >> check where >> the exclusive lock was taken (file and line number). >> > Yep. If Sergey can reproduce this using a kernel with witness, > doing "show witness" to see where the lock on the directory vnode > was acquired, could be helpful. Hi, Rick! Here is the requested info regarding witness, and a bit more. The triggered KASSERT is now different though. Full witness is at http://people.freebsd.org/~pluknet/witness-zfs-20130204.txt shared lock of (lockmgr) zfs @ /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:1452 while exclusively locked from /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c:1747 panic: share->excl cpuid = 2 KDB: enter: panic [ thread pid 812 tid 100884 ] Stopped at kdb_enter+0x3e: movq $0,kdb_why The 1st line is at zfs_lookup(): if (error == 0 && (nm[0] != '.' || nm[1] != '\0')) { int ltype = 0; if (cnp->cn_flags & ISDOTDOT) { ltype = VOP_ISLOCKED(dvp); VOP_UNLOCK(dvp, 0); } ZFS_EXIT(zfsvfs); error = zfs_vnode_lock(*vpp, cnp->cn_lkflags); if (cnp->cn_flags & ISDOTDOT) ==> vn_lock(dvp, ltype | LK_RETRY); if (error != 0) { VN_RELE(*vpp); *vpp = NULL; return (error); } } else { ZFS_EXIT(zfsvfs); } The 2nd line is at zfs_vnode_lock(): int zfs_vnode_lock(vnode_t *vp, int flags) { int error; ASSERT(vp != NULL); error = vn_lock(vp, flags); return (error); } db> show locks exclusive lockmgr zfs (zfs) r = 0 (0xfffffe00a1b44240) locked @ /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c:1747 db> show alllocks Process 812 (nfsd) thread 0xfffffe00a1198000 (100884) exclusive lockmgr zfs (zfs) r = 0 (0xfffffe00a1b44240) locked @ /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c:1747 Process 750 (syslogd) thread 0xfffffe0015a4c480 (100706) exclusive lockmgr ufs (ufs) r = 0 (0xfffffe00a1962d50) locked @ /usr/src/sys/kern/vfs_syscalls.c:3433 Process 12 (intr) thread 0xfffffe0006813000 (100033) exclusive sleep mutex AAC I/O lock (AAC I/O lock) r = 0 (0xffffff8001bfb210) locked @ /usr/src/sys/dev/aac/aac.c:827 db> show lock 0xfffffe00a1b44240 class: lockmgr name: zfs state: XLOCK: 0xfffffe00a1198000 (tid 100884, pid 812, "nfsd") waiters: none spinners: none As KASSERT is different: db> bt Tracing pid 812 tid 100884 td 0xfffffe00a1198000 kdb_enter() at kdb_enter+0x3e/frame 0xffffff848e6bfd60 vpanic() at vpanic+0x147/frame 0xffffff848e6bfda0 kassert_panic() at kassert_panic+0x136/frame 0xffffff848e6bfe10 witness_checkorder() at witness_checkorder+0x289/frame 0xffffff848e6bfe90 __lockmgr_args() at __lockmgr_args+0x43e/frame 0xffffff848e6bffc0 vop_stdlock() at vop_stdlock+0x3c/frame 0xffffff848e6bffe0 VOP_LOCK1_APV() at VOP_LOCK1_APV+0xd0/frame 0xffffff848e6c0000 _vn_lock() at _vn_lock+0xab/frame 0xffffff848e6c0070 zfs_lookup() at zfs_lookup+0x392/frame 0xffffff848e6c0100 zfs_freebsd_lookup() at zfs_freebsd_lookup+0x6d/frame 0xffffff848e6c0240 VOP_CACHEDLOOKUP_APV() at VOP_CACHEDLOOKUP_APV+0xc2/frame 0xffffff848e6c0260 vfs_cache_lookup() at vfs_cache_lookup+0xcf/frame 0xffffff848e6c02b0 VOP_LOOKUP_APV() at VOP_LOOKUP_APV+0xc2/frame 0xffffff848e6c02d0 lookup() at lookup+0x548/frame 0xffffff848e6c0350 nfsvno_namei() at nfsvno_namei+0x1a5/frame 0xffffff848e6c0400 nfsrvd_lookup() at nfsrvd_lookup+0x13a/frame 0xffffff848e6c06b0 nfsrvd_dorpc() at nfsrvd_dorpc+0xca5/frame 0xffffff848e6c08a0 nfssvc_program() at nfssvc_program+0x482/frame 0xffffff848e6c0a00 svc_run_internal() at svc_run_internal+0x1e9/frame 0xffffff848e6c0ba0 svc_thread_start() at svc_thread_start+0xb/frame 0xffffff848e6c0bb0 fork_exit() at fork_exit+0x84/frame 0xffffff848e6c0bf0 fork_trampoline() at fork_trampoline+0xe/frame 0xffffff848e6c0bf0 --- trap 0xc, rip = 0x800883b7a, rsp = 0x7fffffffd6c8, rbp = 0x7fffffffd970 --- -- wbr, pluknet From owner-freebsd-current@FreeBSD.ORG Mon Feb 4 12:06:38 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 26C648EF; Mon, 4 Feb 2013 12:06:38 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 492BF16DD; Mon, 4 Feb 2013 12:06:36 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id OAA19592; Mon, 04 Feb 2013 14:06:32 +0200 (EET) (envelope-from avg@FreeBSD.org) Message-ID: <510FA448.8020204@FreeBSD.org> Date: Mon, 04 Feb 2013 14:06:32 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130113 Thunderbird/17.0.2 MIME-Version: 1.0 To: Sergey Kandaurov Subject: Re: panic: LK_RETRY set with incompatible flags References: <510E9877.5000701@FreeBSD.org> <1515954355.2640466.1359940065810.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Konstantin Belousov , Rick Macklem , FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 04 Feb 2013 12:06:38 -0000 on 04/02/2013 13:49 Sergey Kandaurov said the following: > Hi, Rick! Here is the requested info regarding witness, and a bit more. > The triggered KASSERT is now different though. It's exactly the same problem though :-) Do you have a crashdump? If yes, please print **vpp. > Full witness is at http://people.freebsd.org/~pluknet/witness-zfs-20130204.txt > > shared lock of (lockmgr) zfs @ > /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:1452 > while exclusively locked from > /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c:1747 > panic: share->excl > cpuid = 2 > KDB: enter: panic > [ thread pid 812 tid 100884 ] > Stopped at kdb_enter+0x3e: movq $0,kdb_why > > The 1st line is at zfs_lookup(): > if (error == 0 && (nm[0] != '.' || nm[1] != '\0')) { > int ltype = 0; > > if (cnp->cn_flags & ISDOTDOT) { > ltype = VOP_ISLOCKED(dvp); > VOP_UNLOCK(dvp, 0); > } > ZFS_EXIT(zfsvfs); > error = zfs_vnode_lock(*vpp, cnp->cn_lkflags); > if (cnp->cn_flags & ISDOTDOT) > ==> vn_lock(dvp, ltype | LK_RETRY); > if (error != 0) { > VN_RELE(*vpp); > *vpp = NULL; > return (error); > } > } else { > ZFS_EXIT(zfsvfs); > } > > The 2nd line is at zfs_vnode_lock(): > int > zfs_vnode_lock(vnode_t *vp, int flags) > { > int error; > > ASSERT(vp != NULL); > > error = vn_lock(vp, flags); > return (error); > } > > db> show locks > exclusive lockmgr zfs (zfs) r = 0 (0xfffffe00a1b44240) locked @ > /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c:1747 > db> show alllocks > Process 812 (nfsd) thread 0xfffffe00a1198000 (100884) > exclusive lockmgr zfs (zfs) r = 0 (0xfffffe00a1b44240) locked @ > /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c:1747 > Process 750 (syslogd) thread 0xfffffe0015a4c480 (100706) > exclusive lockmgr ufs (ufs) r = 0 (0xfffffe00a1962d50) locked @ > /usr/src/sys/kern/vfs_syscalls.c:3433 > Process 12 (intr) thread 0xfffffe0006813000 (100033) > exclusive sleep mutex AAC I/O lock (AAC I/O lock) r = 0 > (0xffffff8001bfb210) locked @ /usr/src/sys/dev/aac/aac.c:827 > > db> show lock 0xfffffe00a1b44240 > class: lockmgr > name: zfs > state: XLOCK: 0xfffffe00a1198000 (tid 100884, pid 812, "nfsd") > waiters: none > spinners: none > > As KASSERT is different: > > db> bt > Tracing pid 812 tid 100884 td 0xfffffe00a1198000 > kdb_enter() at kdb_enter+0x3e/frame 0xffffff848e6bfd60 > vpanic() at vpanic+0x147/frame 0xffffff848e6bfda0 > kassert_panic() at kassert_panic+0x136/frame 0xffffff848e6bfe10 > witness_checkorder() at witness_checkorder+0x289/frame 0xffffff848e6bfe90 > __lockmgr_args() at __lockmgr_args+0x43e/frame 0xffffff848e6bffc0 > vop_stdlock() at vop_stdlock+0x3c/frame 0xffffff848e6bffe0 > VOP_LOCK1_APV() at VOP_LOCK1_APV+0xd0/frame 0xffffff848e6c0000 > _vn_lock() at _vn_lock+0xab/frame 0xffffff848e6c0070 > zfs_lookup() at zfs_lookup+0x392/frame 0xffffff848e6c0100 > zfs_freebsd_lookup() at zfs_freebsd_lookup+0x6d/frame 0xffffff848e6c0240 > VOP_CACHEDLOOKUP_APV() at VOP_CACHEDLOOKUP_APV+0xc2/frame 0xffffff848e6c0260 > vfs_cache_lookup() at vfs_cache_lookup+0xcf/frame 0xffffff848e6c02b0 > VOP_LOOKUP_APV() at VOP_LOOKUP_APV+0xc2/frame 0xffffff848e6c02d0 > lookup() at lookup+0x548/frame 0xffffff848e6c0350 > nfsvno_namei() at nfsvno_namei+0x1a5/frame 0xffffff848e6c0400 > nfsrvd_lookup() at nfsrvd_lookup+0x13a/frame 0xffffff848e6c06b0 > nfsrvd_dorpc() at nfsrvd_dorpc+0xca5/frame 0xffffff848e6c08a0 > nfssvc_program() at nfssvc_program+0x482/frame 0xffffff848e6c0a00 > svc_run_internal() at svc_run_internal+0x1e9/frame 0xffffff848e6c0ba0 > svc_thread_start() at svc_thread_start+0xb/frame 0xffffff848e6c0bb0 > fork_exit() at fork_exit+0x84/frame 0xffffff848e6c0bf0 > fork_trampoline() at fork_trampoline+0xe/frame 0xffffff848e6c0bf0 > --- trap 0xc, rip = 0x800883b7a, rsp = 0x7fffffffd6c8, rbp = 0x7fffffffd970 --- > -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Mon Feb 4 12:11:51 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 56848A8B; Mon, 4 Feb 2013 12:11:51 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-qe0-f48.google.com (mail-qe0-f48.google.com [209.85.128.48]) by mx1.freebsd.org (Postfix) with ESMTP id DC5F31733; Mon, 4 Feb 2013 12:11:50 +0000 (UTC) Received: by mail-qe0-f48.google.com with SMTP id 3so2749030qea.21 for ; Mon, 04 Feb 2013 04:11:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=g0yF8AhO0/zzWP9jM/TLA4ViA7pflKtVnz8IcQosn0o=; b=Hpk0ushgfshW6Z0NgqUeNqLjEYed1fESdUojkMXUYMn6fiCod75sZ+rhQrSxiuk7A8 WLlZ7tycliNEIrmLQXq2y8L/W7XYZfN4hATKTaCfDCnQwS1KMTahkz1ODRR88xE/QrUZ fgrq/v/GL8qsCI/orw4eh5M4/zCpAusMBUUFzJlSKufen5h+LZLWr9o3wvvsBWp3NRnL bKIJRczgaCbKX7Gh4wQ7la4UgjrMhlhA2c3OUmn/7gKymwY9XnpXbdURF0TjHLS4p2p3 V+ErO6ch/ktiQ7vF0BDCaSbM6CqEeZUnmtlmxdbJZGqLPc6+mU4Kj+G+sgsCvRhWkDRA YHBA== MIME-Version: 1.0 X-Received: by 10.49.74.10 with SMTP id p10mr20756028qev.35.1359979910100; Mon, 04 Feb 2013 04:11:50 -0800 (PST) Received: by 10.229.105.201 with HTTP; Mon, 4 Feb 2013 04:11:49 -0800 (PST) In-Reply-To: <1982774587.2641177.1359942617191.JavaMail.root@erie.cs.uoguelph.ca> References: <20130203110759.GM2522@kib.kiev.ua> <1982774587.2641177.1359942617191.JavaMail.root@erie.cs.uoguelph.ca> Date: Mon, 4 Feb 2013 15:11:49 +0300 Message-ID: Subject: Re: panic: LK_RETRY set with incompatible flags From: Sergey Kandaurov To: Rick Macklem Content-Type: text/plain; charset=ISO-8859-1 Cc: Konstantin Belousov , FreeBSD Current , Andriy Gapon X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 04 Feb 2013 12:11:51 -0000 On 4 February 2013 05:50, Rick Macklem wrote: > Konstantin Belousov wrote: >> On Sat, Feb 02, 2013 at 09:30:39PM -0500, Rick Macklem wrote: >> > Andriy Gapon wrote: >> > > on 31/01/2013 15:29 Sergey Kandaurov said the following: >> > > > Hi. >> > > > >> > > > Got this assertion on idle NFS server while `ls -la >> > > > /.zfs/shares/' >> > > > issued on NFS client. >> > > > kern/vfs_vnops.c:_vn_lock() >> > > > KASSERT((flags & LK_RETRY) == 0 || error == 0, >> > > > ("LK_RETRY set with incompatible flags >> > > > (0x%x) or >> > > > an error occured (%d)", >> > > > >> > > > panic: LK_RETRY set with incompatible flags (0x200400) or an >> > > > error >> > > > occured (11) >> > > > >> > > > What does that mean and how is it possible? As you can see, both >> > > > parts >> > > > of assertion failed. >> > > > 11 is EDEADLK >> > > > 0x200400: LK_RETRY & LK_UPGRADE >> > > >> > > LK_SHARED, not LK_UPGRADE. >> > > Apparently the thread already holds an exlusive lock on the vnode, >> > > which you >> > > confirm below. >> > > >> > > >> > > > Tracing pid 2943 tid 101532 td 0xfffffe004f5b7000 >> > > > kdb_enter() at kdb_enter+0x3e/frame 0xffffff848e45ef50 >> > > > vpanic() at vpanic+0x147/frame 0xffffff848e45ef90 >> > > > kassert_panic() at kassert_panic+0x136/frame 0xffffff848e45f000 >> > > > _vn_lock() at _vn_lock+0x70/frame 0xffffff848e45f070 >> > > > zfs_lookup() at zfs_lookup+0x392/frame 0xffffff848e45f100 >> > > > zfs_freebsd_lookup() at zfs_freebsd_lookup+0x6d/frame >> > > > 0xffffff848e45f240 >> > > > VOP_CACHEDLOOKUP_APV() at VOP_CACHEDLOOKUP_APV+0xc2/frame >> > > > 0xffffff848e45f260 >> > > > vfs_cache_lookup() at vfs_cache_lookup+0xcf/frame >> > > > 0xffffff848e45f2b0 >> > > > VOP_LOOKUP_APV() at VOP_LOOKUP_APV+0xc2/frame 0xffffff848e45f2d0 >> > > > lookup() at lookup+0x548/frame 0xffffff848e45f350 >> > > > nfsvno_namei() at nfsvno_namei+0x1a5/frame 0xffffff848e45f400 >> > > > nfsrvd_lookup() at nfsrvd_lookup+0x13a/frame 0xffffff848e45f6b0 >> > > > nfsrvd_dorpc() at nfsrvd_dorpc+0xca5/frame 0xffffff848e45f8a0 >> > > > nfssvc_program() at nfssvc_program+0x482/frame >> > > > 0xffffff848e45fa00 >> > > > svc_run_internal() at svc_run_internal+0x1e9/frame >> > > > 0xffffff848e45fba0 >> > > > svc_thread_start() at svc_thread_start+0xb/frame >> > > > 0xffffff848e45fbb0 >> > > > fork_exit() at fork_exit+0x84/frame 0xffffff848e45fbf0 >> > > > fork_trampoline() at fork_trampoline+0xe/frame >> > > > 0xffffff848e45fbf0 >> > > > --- trap 0xc, rip = 0x800883e9a, rsp = 0x7fffffffd488, rbp = >> > > > 0x7fffffffd730 --- >> > > > >> > > > db> show lockedvnods >> > > > Locked vnodes >> > > > >> > > > 0xfffffe02e21b11d8: tag zfs, type VDIR >> > > > usecount 4, writecount 0, refcount 4 mountedhere 0 >> > > > flags (VI_ACTIVE) >> > > > v_object 0xfffffe02d9f2eb40 ref 0 pages 0 >> > > > lock type zfs: EXCL by thread 0xfffffe004f5b7000 (pid 2943, >> > > > nfsd, >> > > > tid 101532) >> > > > >> > > > >> > > > >> > I just took a look at zfs_vnops.c and I am probably missing >> > something, >> > but I can't see how this ever worked for a lookup of ".." when at >> > the >> > root (unless ZFS doesn't do the ".." is the current directory when >> > at >> > the root). >> > >> > Here's the code snippet: >> > 1442 if (error == 0 && (nm[0] != '.' || nm[1] != '\0')) { >> > 1443 int ltype = 0; >> > 1444 >> > 1445 if (cnp->cn_flags & ISDOTDOT) { >> > 1446 ltype = VOP_ISLOCKED(dvp); >> > 1447 VOP_UNLOCK(dvp, 0); >> > 1448 } >> > 1449 ZFS_EXIT(zfsvfs); >> > 1450 error = zfs_vnode_lock(*vpp, cnp->cn_lkflags); >> > 1451 if (cnp->cn_flags & ISDOTDOT) >> > 1452 vn_lock(dvp, ltype | LK_RETRY); >> > 1453 if (error != 0) { >> > 1454 VN_RELE(*vpp); >> > 1455 *vpp = NULL; >> > 1456 return (error); >> > 1457 } >> > >> > Maybe line# 1451 should be changed to: >> > if ((cnp->cn_flags & ISDOTDOT) && *vpp != dvp) >> > >> > I'm not at all familiar with ZFS, so I've probably way >> > off the mark on this, rick >> > ps: I hope kib and jhb don't mind being added as cc's, since >> > they are familiar with this stuff, although maybe not ZFS >> > specifics. >> >> VFS (should) never call VOP_LOOKUP for the dotdot and root vnode. >> The logic in the lookup() prevents it. >> > Correcting my previous posts, like usual. If you look at the above snippet of > code, it seems that zfs_lock_vnode() must lock the same vnode as > *dvp. Notice that vn_lock() is only called when ISDOTDOT is set and the > code does a VOP_UNLOCK(dvp, 0); for this case, just before the > zfs_vnode_lock(). > > This assumes that the vn_lock() call at #1452 causes the panic. > This is the only vn_lock() call in zfs_lookup(), so unless the compiler > has done something weird, it seems the case. > > Sergey, do you have this kernel handy? If so, maybe you could check the > line# for zfs_lookup+0x392. (If you haven't done this before, just email > and I'll give you the steps. You just need the kernel.symbols file for > the kernel that panic'd.) Yep, kgdb returned zfs_vnops.c:1453. -- wbr, pluknet From owner-freebsd-current@FreeBSD.ORG Mon Feb 4 12:13:34 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 16A33BD4; Mon, 4 Feb 2013 12:13:34 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by mx1.freebsd.org (Postfix) with ESMTP id AC5DE175F; Mon, 4 Feb 2013 12:13:33 +0000 (UTC) Received: by mail-qc0-f172.google.com with SMTP id b25so2623355qca.17 for ; Mon, 04 Feb 2013 04:13:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=ApLUm/zW4HaVI/bUz3D/J0rfb6LV6YHiq+SzAg/sUak=; b=NuspONuU1saGFkE0TjwgynMdqDkrccK9aXDkiK1WzG38D2X8gMESwNOeK8CLygVxpo 5jLv3bmsSmL9OwR32Bg7AE5rZoUsHJW2cp1+JeYCeNkZuVRUB336Oql7CW3nvaSBn5kP Q6AGPflG5KEVhwL7w3ONdYkKF7SSzxrKionHCmlbhH0tw4U9wXGl3eIjf4sq31xmcdl5 qrvp4oomd0Qy2m1gKfUu/Fq1f/3/4JlGyg4MEzQt8KIDzh/1kM9Y7NwQ4Ayzdb9romGB jKOq4WoNwmGrL6IvtEr1eSD4qxCNoIKGXGrtTBrI1Mg6nkqtlyy9DivrzpmILmDxL8OS s4Xw== MIME-Version: 1.0 X-Received: by 10.224.27.77 with SMTP id h13mr18100913qac.23.1359980013098; Mon, 04 Feb 2013 04:13:33 -0800 (PST) Received: by 10.229.105.201 with HTTP; Mon, 4 Feb 2013 04:13:32 -0800 (PST) In-Reply-To: <510FA448.8020204@FreeBSD.org> References: <510E9877.5000701@FreeBSD.org> <1515954355.2640466.1359940065810.JavaMail.root@erie.cs.uoguelph.ca> <510FA448.8020204@FreeBSD.org> Date: Mon, 4 Feb 2013 15:13:32 +0300 Message-ID: Subject: Re: panic: LK_RETRY set with incompatible flags From: Sergey Kandaurov To: Andriy Gapon Content-Type: text/plain; charset=ISO-8859-1 Cc: Konstantin Belousov , Rick Macklem , FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 04 Feb 2013 12:13:34 -0000 On 4 February 2013 16:06, Andriy Gapon wrote: > on 04/02/2013 13:49 Sergey Kandaurov said the following: >> Hi, Rick! Here is the requested info regarding witness, and a bit more. >> The triggered KASSERT is now different though. > > It's exactly the same problem though :-) > Do you have a crashdump? > If yes, please print **vpp. Yep, but it's in a bad form :( It has many bits optimized out (compiled with clang). I'll rebuild the kernel with -O or so and will try again. #8 0xffffffff808bc4ce in kdb_enter (why=0xffffffff80e7ed99 "panic", msg=) at cpufunc.h:63 #9 0xffffffff80888fb7 in vpanic (fmt=, ap=) at /usr/src/sys/kern/kern_shutdown.c:746 #10 0xffffffff80888e66 in kassert_panic (fmt=) at /usr/src/sys/kern/kern_shutdown.c:641 #11 0xffffffff808d2259 in witness_checkorder (lock=0xfffffe00a1b44240, ---Type to continue, or q to quit--- flags=1, file=0xffffffff81b2bb36 "/usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c", line=1452, interlock=) at /usr/src/sys/kern/subr_witness.c:1122 #12 0xffffffff8086c11e in __lockmgr_args (lk=0xfffffe00a1b44240, flags=, ilk=0xfffffe00a1b44270, wmesg=0xffffffff81b2808d "zfs", pri=96, timo=51, file=0xffffffff80e8e407 "/usr/src/sys/kern/vfs_default.c", line=0) at /usr/src/sys/kern/kern_lock.c:511 #13 0xffffffff8091439c in vop_stdlock (ap=) at lockmgr.h:97 #14 0xffffffff80cb70c0 in VOP_LOCK1_APV (vop=, a=) at vnode_if.c:2022 #15 0xffffffff80932fbb in _vn_lock (vp=0xfffffe00a1b441d8, flags=, file=0xffffffff81b2bb36 "/usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c", line=1452) at vnode_if.h:859 #16 0xffffffff81abd902 in zfs_lookup () at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:1452 #17 0xffffffff81abdc1d in zfs_freebsd_lookup (ap=0xffffff848e6c0270) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:5864 ---Type to continue, or q to quit--- #18 0xffffffff80cb51b2 in VOP_CACHEDLOOKUP_APV (vop=, a=) at vnode_if.c:191 #19 0xffffffff8091177f in vfs_cache_lookup (ap=) at vnode_if.h:80 #20 0xffffffff80cb50a2 in VOP_LOOKUP_APV (vop=, a=) at vnode_if.c:125 #21 0xffffffff80919658 in lookup (ndp=0xffffff848e6c05d8) at vnode_if.h:54 #22 0xffffffff807dffe5 in nfsvno_namei (nd=0xffffff848e6c08c8, ndp=0xffffff848e6c05d8, dp=, islocked=, exp=, p=, retdirp=) at /usr/src/sys/fs/nfsserver/nfs_nfsdport.c:413 #23 0xffffffff807d8ffa in nfsrvd_lookup (nd=0xffffff848e6c08c8, isdgram=, dp=0xfffffe00a1b441d8, vpp=0xffffff848e6c0810, fhp=0xffffff848e6c07f4, p=0xfffffe00a1198000, exp=0xffffff848e6c07a0) at /usr/src/sys/fs/nfsserver/nfs_nfsdserv.c:517 #24 0xffffffff807cb845 in nfsrvd_dorpc (nd=0xffffff848e6c08c8, isdgram=0, p=0xfffffe00a1198000) at /usr/src/sys/fs/nfsserver/nfs_nfsdsocket.c:823 #25 0xffffffff807d7af2 in nfssvc_program (rqst=0xfffffe00a17bb000, xprt=0xfffffe00a124b200) at /usr/src/sys/fs/nfsserver/nfs_nfsdkrpc.c:347 #26 0xffffffff80a70659 in svc_run_internal (pool=0xfffffe00067db600, ismaster=0) at /usr/src/sys/rpc/svc.c:895 #27 0xffffffff80a7155b in svc_thread_start (arg=0xffffff848e6bfc50) ---Type to continue, or q to quit--- at /usr/src/sys/rpc/svc.c:1200 #28 0xffffffff80858944 in fork_exit ( callout=0xffffffff80a71550 , arg=0xfffffe00067db600, frame=0xffffff848e6c0c00) at /usr/src/sys/kern/kern_fork.c:991 #29 0xffffffff80bfa86e in fork_trampoline () at exception.S:602 #30 0x0000000000000080 in ?? () #31 0x00007fffffffd820 in ?? () #32 0x0000000000000001 in ?? () #33 0x0000000000000000 in ?? () Current language: auto; currently minimal (kgdb) p vpp Cannot access memory at address 0x0 (kgdb) p dvp Cannot access memory at address 0x0 > >> Full witness is at http://people.freebsd.org/~pluknet/witness-zfs-20130204.txt >> >> shared lock of (lockmgr) zfs @ >> /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:1452 >> while exclusively locked from >> /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c:1747 >> panic: share->excl >> cpuid = 2 >> KDB: enter: panic >> [ thread pid 812 tid 100884 ] >> Stopped at kdb_enter+0x3e: movq $0,kdb_why >> >> The 1st line is at zfs_lookup(): >> if (error == 0 && (nm[0] != '.' || nm[1] != '\0')) { >> int ltype = 0; >> >> if (cnp->cn_flags & ISDOTDOT) { >> ltype = VOP_ISLOCKED(dvp); >> VOP_UNLOCK(dvp, 0); >> } >> ZFS_EXIT(zfsvfs); >> error = zfs_vnode_lock(*vpp, cnp->cn_lkflags); >> if (cnp->cn_flags & ISDOTDOT) >> ==> vn_lock(dvp, ltype | LK_RETRY); >> if (error != 0) { >> VN_RELE(*vpp); >> *vpp = NULL; >> return (error); >> } >> } else { >> ZFS_EXIT(zfsvfs); >> } >> >> The 2nd line is at zfs_vnode_lock(): >> int >> zfs_vnode_lock(vnode_t *vp, int flags) >> { >> int error; >> >> ASSERT(vp != NULL); >> >> error = vn_lock(vp, flags); >> return (error); >> } >> >> db> show locks >> exclusive lockmgr zfs (zfs) r = 0 (0xfffffe00a1b44240) locked @ >> /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c:1747 >> db> show alllocks >> Process 812 (nfsd) thread 0xfffffe00a1198000 (100884) >> exclusive lockmgr zfs (zfs) r = 0 (0xfffffe00a1b44240) locked @ >> /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c:1747 >> Process 750 (syslogd) thread 0xfffffe0015a4c480 (100706) >> exclusive lockmgr ufs (ufs) r = 0 (0xfffffe00a1962d50) locked @ >> /usr/src/sys/kern/vfs_syscalls.c:3433 >> Process 12 (intr) thread 0xfffffe0006813000 (100033) >> exclusive sleep mutex AAC I/O lock (AAC I/O lock) r = 0 >> (0xffffff8001bfb210) locked @ /usr/src/sys/dev/aac/aac.c:827 >> >> db> show lock 0xfffffe00a1b44240 >> class: lockmgr >> name: zfs >> state: XLOCK: 0xfffffe00a1198000 (tid 100884, pid 812, "nfsd") >> waiters: none >> spinners: none >> >> As KASSERT is different: >> >> db> bt >> Tracing pid 812 tid 100884 td 0xfffffe00a1198000 >> kdb_enter() at kdb_enter+0x3e/frame 0xffffff848e6bfd60 >> vpanic() at vpanic+0x147/frame 0xffffff848e6bfda0 >> kassert_panic() at kassert_panic+0x136/frame 0xffffff848e6bfe10 >> witness_checkorder() at witness_checkorder+0x289/frame 0xffffff848e6bfe90 >> __lockmgr_args() at __lockmgr_args+0x43e/frame 0xffffff848e6bffc0 >> vop_stdlock() at vop_stdlock+0x3c/frame 0xffffff848e6bffe0 >> VOP_LOCK1_APV() at VOP_LOCK1_APV+0xd0/frame 0xffffff848e6c0000 >> _vn_lock() at _vn_lock+0xab/frame 0xffffff848e6c0070 >> zfs_lookup() at zfs_lookup+0x392/frame 0xffffff848e6c0100 >> zfs_freebsd_lookup() at zfs_freebsd_lookup+0x6d/frame 0xffffff848e6c0240 >> VOP_CACHEDLOOKUP_APV() at VOP_CACHEDLOOKUP_APV+0xc2/frame 0xffffff848e6c0260 >> vfs_cache_lookup() at vfs_cache_lookup+0xcf/frame 0xffffff848e6c02b0 >> VOP_LOOKUP_APV() at VOP_LOOKUP_APV+0xc2/frame 0xffffff848e6c02d0 >> lookup() at lookup+0x548/frame 0xffffff848e6c0350 >> nfsvno_namei() at nfsvno_namei+0x1a5/frame 0xffffff848e6c0400 >> nfsrvd_lookup() at nfsrvd_lookup+0x13a/frame 0xffffff848e6c06b0 >> nfsrvd_dorpc() at nfsrvd_dorpc+0xca5/frame 0xffffff848e6c08a0 >> nfssvc_program() at nfssvc_program+0x482/frame 0xffffff848e6c0a00 >> svc_run_internal() at svc_run_internal+0x1e9/frame 0xffffff848e6c0ba0 >> svc_thread_start() at svc_thread_start+0xb/frame 0xffffff848e6c0bb0 >> fork_exit() at fork_exit+0x84/frame 0xffffff848e6c0bf0 >> fork_trampoline() at fork_trampoline+0xe/frame 0xffffff848e6c0bf0 >> --- trap 0xc, rip = 0x800883b7a, rsp = 0x7fffffffd6c8, rbp = 0x7fffffffd970 --- >> > > > -- > Andriy Gapon -- wbr, pluknet From owner-freebsd-current@FreeBSD.ORG Mon Feb 4 12:30:19 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 3F89B1D9; Mon, 4 Feb 2013 12:30:19 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-ia0-x22f.google.com (mail-ia0-x22f.google.com [IPv6:2607:f8b0:4001:c02::22f]) by mx1.freebsd.org (Postfix) with ESMTP id 01EEF1852; Mon, 4 Feb 2013 12:30:18 +0000 (UTC) Received: by mail-ia0-f175.google.com with SMTP id r4so8046975iaj.34 for ; Mon, 04 Feb 2013 04:30:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=eoHeQbZt8+PDG05lXMKGu4vbNji4x/mb4Ci+JjWjzJM=; b=ETLjJmIje9KGRZ/BEQGFYCF75VyMqV/7OUX5YZsE1/wC+Thyld7rIEvuCaLpDIQk9l ws4N9y+fa3M2gVeIiV1qdayC15GQFIp7u4cbRhXDG2MGrwSdwbcxxScwTVOp4kz43AKb e8zGqGjt7u4WaeAElMecnPKoAS/5YY850RM8AmanAZGJS8sXs7zycX0awuVcX00cGs/m YIGyHPqvUPq7A8BjMV/v+PPSBzUG47kwasW7qXm2VlOSgRHrZ8Wg1Ytgur4wiTQ/yi3/ jMzZkIdY2a6Ov5HLVldzzdjmXWCZLiDbYCC0Keu6IVwcI1RBCRv5Q73i0ap9Y/d8QVDo 2B7w== MIME-Version: 1.0 X-Received: by 10.50.161.130 with SMTP id xs2mr6104443igb.34.1359981017914; Mon, 04 Feb 2013 04:30:17 -0800 (PST) Received: by 10.64.29.13 with HTTP; Mon, 4 Feb 2013 04:30:17 -0800 (PST) In-Reply-To: References: <510E9877.5000701@FreeBSD.org> <1515954355.2640466.1359940065810.JavaMail.root@erie.cs.uoguelph.ca> <510FA448.8020204@FreeBSD.org> Date: Mon, 4 Feb 2013 15:30:17 +0300 Message-ID: Subject: Re: panic: LK_RETRY set with incompatible flags From: Sergey Kandaurov To: Andriy Gapon Content-Type: text/plain; charset=ISO-8859-1 Cc: Konstantin Belousov , Rick Macklem , FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 04 Feb 2013 12:30:19 -0000 On 4 February 2013 16:13, Sergey Kandaurov wrote: > On 4 February 2013 16:06, Andriy Gapon wrote: >> on 04/02/2013 13:49 Sergey Kandaurov said the following: >>> Hi, Rick! Here is the requested info regarding witness, and a bit more. >>> The triggered KASSERT is now different though. >> >> It's exactly the same problem though :-) >> Do you have a crashdump? >> If yes, please print **vpp. > > Yep, but it's in a bad form :( > It has many bits optimized out (compiled with clang). > I'll rebuild the kernel with -O or so and will try again. > > #8 0xffffffff808bc4ce in kdb_enter (why=0xffffffff80e7ed99 "panic", > msg=) at cpufunc.h:63 > #9 0xffffffff80888fb7 in vpanic (fmt=, > ap=) at /usr/src/sys/kern/kern_shutdown.c:746 > #10 0xffffffff80888e66 in kassert_panic (fmt=) > at /usr/src/sys/kern/kern_shutdown.c:641 > #11 0xffffffff808d2259 in witness_checkorder (lock=0xfffffe00a1b44240, > ---Type to continue, or q to quit--- > flags=1, > file=0xffffffff81b2bb36 > "/usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c", > line=1452, > interlock=) at /usr/src/sys/kern/subr_witness.c:1122 > #12 0xffffffff8086c11e in __lockmgr_args (lk=0xfffffe00a1b44240, > flags=, ilk=0xfffffe00a1b44270, > wmesg=0xffffffff81b2808d "zfs", pri=96, timo=51, > file=0xffffffff80e8e407 "/usr/src/sys/kern/vfs_default.c", line=0) > at /usr/src/sys/kern/kern_lock.c:511 > #13 0xffffffff8091439c in vop_stdlock (ap=) > at lockmgr.h:97 > #14 0xffffffff80cb70c0 in VOP_LOCK1_APV (vop=, > a=) at vnode_if.c:2022 > #15 0xffffffff80932fbb in _vn_lock (vp=0xfffffe00a1b441d8, > flags=, > file=0xffffffff81b2bb36 > "/usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c", > line=1452) at vnode_if.h:859 > #16 0xffffffff81abd902 in zfs_lookup () > at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:1452 > #17 0xffffffff81abdc1d in zfs_freebsd_lookup (ap=0xffffff848e6c0270) > at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:5864 > ---Type to continue, or q to quit--- > #18 0xffffffff80cb51b2 in VOP_CACHEDLOOKUP_APV (vop=, > a=) at vnode_if.c:191 > #19 0xffffffff8091177f in vfs_cache_lookup (ap=) > at vnode_if.h:80 > #20 0xffffffff80cb50a2 in VOP_LOOKUP_APV (vop=, > a=) at vnode_if.c:125 > #21 0xffffffff80919658 in lookup (ndp=0xffffff848e6c05d8) at vnode_if.h:54 > #22 0xffffffff807dffe5 in nfsvno_namei (nd=0xffffff848e6c08c8, > ndp=0xffffff848e6c05d8, dp=, > islocked=, exp=, > p=, retdirp=) > at /usr/src/sys/fs/nfsserver/nfs_nfsdport.c:413 > #23 0xffffffff807d8ffa in nfsrvd_lookup (nd=0xffffff848e6c08c8, > isdgram=, dp=0xfffffe00a1b441d8, > vpp=0xffffff848e6c0810, fhp=0xffffff848e6c07f4, p=0xfffffe00a1198000, > exp=0xffffff848e6c07a0) at /usr/src/sys/fs/nfsserver/nfs_nfsdserv.c:517 > #24 0xffffffff807cb845 in nfsrvd_dorpc (nd=0xffffff848e6c08c8, isdgram=0, > p=0xfffffe00a1198000) at /usr/src/sys/fs/nfsserver/nfs_nfsdsocket.c:823 > #25 0xffffffff807d7af2 in nfssvc_program (rqst=0xfffffe00a17bb000, > xprt=0xfffffe00a124b200) at /usr/src/sys/fs/nfsserver/nfs_nfsdkrpc.c:347 > #26 0xffffffff80a70659 in svc_run_internal (pool=0xfffffe00067db600, > ismaster=0) at /usr/src/sys/rpc/svc.c:895 > #27 0xffffffff80a7155b in svc_thread_start (arg=0xffffff848e6bfc50) > ---Type to continue, or q to quit--- > at /usr/src/sys/rpc/svc.c:1200 > #28 0xffffffff80858944 in fork_exit ( > callout=0xffffffff80a71550 , arg=0xfffffe00067db600, > frame=0xffffff848e6c0c00) at /usr/src/sys/kern/kern_fork.c:991 > #29 0xffffffff80bfa86e in fork_trampoline () at exception.S:602 > #30 0x0000000000000080 in ?? () > #31 0x00007fffffffd820 in ?? () > #32 0x0000000000000001 in ?? () > #33 0x0000000000000000 in ?? () > Current language: auto; currently minimal > > (kgdb) p vpp > Cannot access memory at address 0x0 > (kgdb) p dvp > Cannot access memory at address 0x0 > That was from f 16. And as Andriy suggested in private (thanks Andriy!) those pointers could be reached from ap in f 17. On the other hand, zfs_lookup() is large, and *vpp might be rewritten several times there. Here it is: (kgdb) f 17 #17 0xffffffff81abdc1d in zfs_freebsd_lookup (ap=0xffffff848e6c0270) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:5864 5864 return (zfs_lookup(ap->a_dvp, nm, ap->a_vpp, cnp, cnp->cn_nameiop, (kgdb) p ap->a_vpp $4 = (struct vnode **) 0xffffff848e6c0618 (kgdb) p *ap->a_vpp $5 = (struct vnode *) 0xfffffe00a1b441d8 (kgdb) p **ap->a_vpp $6 = {v_tag = 0xffffffff81b2808d "zfs", v_op = 0xffffffff81b35808, v_data = 0xfffffe00a188f000, v_mount = 0xfffffe0015a5f000, v_nmntvnodes = { tqe_next = 0xfffffe00a1b44000, tqe_prev = 0xfffffe00a1b443d0}, v_un = { vu_mount = 0x0, vu_socket = 0x0, vu_cdev = 0x0, vu_fifoinfo = 0x0}, v_hashlist = {le_next = 0x0, le_prev = 0x0}, v_cache_src = {lh_first = 0x0}, v_cache_dst = {tqh_first = 0x0, tqh_last = 0xfffffe00a1b44228}, v_cache_dd = 0x0, v_lock = {lock_object = { lo_name = 0xffffffff81b2808d "zfs", lo_flags = 91947008, lo_data = 0, lo_witness = 0xffffff80006d2700}, lk_lock = 18446741877389099008, lk_exslpfail = 0, lk_timo = 51, lk_pri = 96}, v_interlock = { lock_object = {lo_name = 0xffffffff80e873f0 "vnode interlock", lo_flags = 16973824, lo_data = 0, lo_witness = 0xffffff80006c9600}, mtx_lock = 4}, v_vnlock = 0xfffffe00a1b44240, v_actfreelist = { tqe_next = 0xfffffe000bd363b0, tqe_prev = 0xfffffe0015a5f078}, v_bufobj = { bo_mtx = {lock_object = {lo_name = 0xffffffff80e8f3d5 "bufobj interlock", lo_flags = 16973824, lo_data = 0, lo_witness = 0xffffff80006d0580}, mtx_lock = 4}, bo_ops = 0xffffffff8121cc30, bo_object = 0xfffffe00a1872780, bo_synclist = {le_next = 0x0, le_prev = 0x0}, bo_private = 0xfffffe00a1b441d8, __bo_vnode = 0xfffffe00a1b441d8, bo_clean = {bv_hd = {tqh_first = 0x0, tqh_last = 0xfffffe00a1b442f8}, bv_root = 0x0, bv_cnt = 0}, bo_dirty = {bv_hd = {tqh_first = 0x0, tqh_last = 0xfffffe00a1b44318}, bv_root = 0x0, bv_cnt = 0}, bo_numoutput = 0, bo_flag = 0, ---Type to continue, or q to quit--- bo_bsize = 131072}, v_pollinfo = 0x0, v_label = 0x0, v_lockf = 0x0, v_rl = {rl_waiters = {tqh_first = 0x0, tqh_last = 0xfffffe00a1b44360}, rl_currdep = 0x0}, v_cstart = 0, v_lasta = 0, v_lastw = 0, v_clen = 0, v_holdcnt = 4, v_usecount = 4, v_iflag = 512, v_vflag = 0, v_writecount = 0, v_hash = 10597441, v_type = VDIR} Anyway, new kernel is almost ready. Stay tuned :). -- wbr, pluknet From owner-freebsd-current@FreeBSD.ORG Mon Feb 4 13:20:37 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 0EB001AA; Mon, 4 Feb 2013 13:20:37 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) by mx1.freebsd.org (Postfix) with ESMTP id C40741B63; Mon, 4 Feb 2013 13:20:36 +0000 (UTC) Received: by mail-ie0-f180.google.com with SMTP id bn7so4625658ieb.25 for ; Mon, 04 Feb 2013 05:20:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=DkdRNYRILjDLWXTYV9dHcS0g93gblvFgndk2/ABIxU8=; b=TSqBE1ct6MCi4tlIt6SMMXdkhRyBI9LE1taVQAIHpa+IimNZa9bSn0jDe4TwYS3RVD TItJZUBKVO2lZfZ0GxX+Je6++KenDT6kv6nU+TQ6kv8vizL9kAvOUR2tF/O49y+Pm8BL zQu8b+obJbENqgKnubqcfprqieuAMpGDW/3ovrUkjVG3YW0pOui7/C31ACKM5MAp8dC4 hqzBte4jsjNrcKuvrH3eKfggVw26B53i7jN/n8hKEzrp4ie47SlqAVEVYiCKJdw+ndWx rncVHr2ezR2IYG+J77hrJ4YZQDTo0/s4ViFQd1qJ7Z39CZCYnrIBpASLGfv3PH1b++Yz pdDw== MIME-Version: 1.0 X-Received: by 10.50.187.169 with SMTP id ft9mr6379252igc.25.1359984036381; Mon, 04 Feb 2013 05:20:36 -0800 (PST) Received: by 10.64.29.13 with HTTP; Mon, 4 Feb 2013 05:20:36 -0800 (PST) In-Reply-To: References: <510E9877.5000701@FreeBSD.org> <1515954355.2640466.1359940065810.JavaMail.root@erie.cs.uoguelph.ca> <510FA448.8020204@FreeBSD.org> Date: Mon, 4 Feb 2013 16:20:36 +0300 Message-ID: Subject: Re: panic: LK_RETRY set with incompatible flags From: Sergey Kandaurov To: Andriy Gapon Content-Type: text/plain; charset=ISO-8859-1 Cc: Konstantin Belousov , Rick Macklem , FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 04 Feb 2013 13:20:37 -0000 On 4 February 2013 16:30, Sergey Kandaurov wrote: > On 4 February 2013 16:13, Sergey Kandaurov wrote: >> On 4 February 2013 16:06, Andriy Gapon wrote: >>> on 04/02/2013 13:49 Sergey Kandaurov said the following: >>>> Hi, Rick! Here is the requested info regarding witness, and a bit more. >>>> The triggered KASSERT is now different though. >>> >>> It's exactly the same problem though :-) >>> Do you have a crashdump? >>> If yes, please print **vpp. >> >> Yep, but it's in a bad form :( >> It has many bits optimized out (compiled with clang). >> I'll rebuild the kernel with -O or so and will try again. >> >> #8 0xffffffff808bc4ce in kdb_enter (why=0xffffffff80e7ed99 "panic", >> msg=) at cpufunc.h:63 >> #9 0xffffffff80888fb7 in vpanic (fmt=, >> ap=) at /usr/src/sys/kern/kern_shutdown.c:746 >> #10 0xffffffff80888e66 in kassert_panic (fmt=) >> at /usr/src/sys/kern/kern_shutdown.c:641 >> #11 0xffffffff808d2259 in witness_checkorder (lock=0xfffffe00a1b44240, >> ---Type to continue, or q to quit--- >> flags=1, >> file=0xffffffff81b2bb36 >> "/usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c", >> line=1452, >> interlock=) at /usr/src/sys/kern/subr_witness.c:1122 >> #12 0xffffffff8086c11e in __lockmgr_args (lk=0xfffffe00a1b44240, >> flags=, ilk=0xfffffe00a1b44270, >> wmesg=0xffffffff81b2808d "zfs", pri=96, timo=51, >> file=0xffffffff80e8e407 "/usr/src/sys/kern/vfs_default.c", line=0) >> at /usr/src/sys/kern/kern_lock.c:511 >> #13 0xffffffff8091439c in vop_stdlock (ap=) >> at lockmgr.h:97 >> #14 0xffffffff80cb70c0 in VOP_LOCK1_APV (vop=, >> a=) at vnode_if.c:2022 >> #15 0xffffffff80932fbb in _vn_lock (vp=0xfffffe00a1b441d8, >> flags=, >> file=0xffffffff81b2bb36 >> "/usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c", >> line=1452) at vnode_if.h:859 >> #16 0xffffffff81abd902 in zfs_lookup () >> at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:1452 >> #17 0xffffffff81abdc1d in zfs_freebsd_lookup (ap=0xffffff848e6c0270) >> at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:5864 >> ---Type to continue, or q to quit--- >> #18 0xffffffff80cb51b2 in VOP_CACHEDLOOKUP_APV (vop=, >> a=) at vnode_if.c:191 >> #19 0xffffffff8091177f in vfs_cache_lookup (ap=) >> at vnode_if.h:80 >> #20 0xffffffff80cb50a2 in VOP_LOOKUP_APV (vop=, >> a=) at vnode_if.c:125 >> #21 0xffffffff80919658 in lookup (ndp=0xffffff848e6c05d8) at vnode_if.h:54 >> #22 0xffffffff807dffe5 in nfsvno_namei (nd=0xffffff848e6c08c8, >> ndp=0xffffff848e6c05d8, dp=, >> islocked=, exp=, >> p=, retdirp=) >> at /usr/src/sys/fs/nfsserver/nfs_nfsdport.c:413 >> #23 0xffffffff807d8ffa in nfsrvd_lookup (nd=0xffffff848e6c08c8, >> isdgram=, dp=0xfffffe00a1b441d8, >> vpp=0xffffff848e6c0810, fhp=0xffffff848e6c07f4, p=0xfffffe00a1198000, >> exp=0xffffff848e6c07a0) at /usr/src/sys/fs/nfsserver/nfs_nfsdserv.c:517 >> #24 0xffffffff807cb845 in nfsrvd_dorpc (nd=0xffffff848e6c08c8, isdgram=0, >> p=0xfffffe00a1198000) at /usr/src/sys/fs/nfsserver/nfs_nfsdsocket.c:823 >> #25 0xffffffff807d7af2 in nfssvc_program (rqst=0xfffffe00a17bb000, >> xprt=0xfffffe00a124b200) at /usr/src/sys/fs/nfsserver/nfs_nfsdkrpc.c:347 >> #26 0xffffffff80a70659 in svc_run_internal (pool=0xfffffe00067db600, >> ismaster=0) at /usr/src/sys/rpc/svc.c:895 >> #27 0xffffffff80a7155b in svc_thread_start (arg=0xffffff848e6bfc50) >> ---Type to continue, or q to quit--- >> at /usr/src/sys/rpc/svc.c:1200 >> #28 0xffffffff80858944 in fork_exit ( >> callout=0xffffffff80a71550 , arg=0xfffffe00067db600, >> frame=0xffffff848e6c0c00) at /usr/src/sys/kern/kern_fork.c:991 >> #29 0xffffffff80bfa86e in fork_trampoline () at exception.S:602 >> #30 0x0000000000000080 in ?? () >> #31 0x00007fffffffd820 in ?? () >> #32 0x0000000000000001 in ?? () >> #33 0x0000000000000000 in ?? () >> Current language: auto; currently minimal >> >> (kgdb) p vpp >> Cannot access memory at address 0x0 >> (kgdb) p dvp >> Cannot access memory at address 0x0 >> > > That was from f 16. And as Andriy suggested in private (thanks Andriy!) > those pointers could be reached from ap in f 17. > On the other hand, zfs_lookup() is large, and *vpp might be > rewritten several times there. Here it is: > > (kgdb) f 17 > #17 0xffffffff81abdc1d in zfs_freebsd_lookup (ap=0xffffff848e6c0270) > at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:5864 > 5864 return (zfs_lookup(ap->a_dvp, nm, ap->a_vpp, cnp, > cnp->cn_nameiop, > (kgdb) p ap->a_vpp > $4 = (struct vnode **) 0xffffff848e6c0618 > (kgdb) p *ap->a_vpp > $5 = (struct vnode *) 0xfffffe00a1b441d8 > (kgdb) p **ap->a_vpp > $6 = {v_tag = 0xffffffff81b2808d "zfs", v_op = 0xffffffff81b35808, > v_data = 0xfffffe00a188f000, v_mount = 0xfffffe0015a5f000, v_nmntvnodes = { > tqe_next = 0xfffffe00a1b44000, tqe_prev = 0xfffffe00a1b443d0}, v_un = { > vu_mount = 0x0, vu_socket = 0x0, vu_cdev = 0x0, vu_fifoinfo = 0x0}, > v_hashlist = {le_next = 0x0, le_prev = 0x0}, v_cache_src = {lh_first = 0x0}, > v_cache_dst = {tqh_first = 0x0, tqh_last = 0xfffffe00a1b44228}, > v_cache_dd = 0x0, v_lock = {lock_object = { > lo_name = 0xffffffff81b2808d "zfs", lo_flags = 91947008, lo_data = 0, > lo_witness = 0xffffff80006d2700}, lk_lock = 18446741877389099008, > lk_exslpfail = 0, lk_timo = 51, lk_pri = 96}, v_interlock = { > lock_object = {lo_name = 0xffffffff80e873f0 "vnode interlock", > lo_flags = 16973824, lo_data = 0, lo_witness = 0xffffff80006c9600}, > mtx_lock = 4}, v_vnlock = 0xfffffe00a1b44240, v_actfreelist = { > tqe_next = 0xfffffe000bd363b0, tqe_prev = 0xfffffe0015a5f078}, v_bufobj = { > bo_mtx = {lock_object = {lo_name = 0xffffffff80e8f3d5 "bufobj interlock", > lo_flags = 16973824, lo_data = 0, lo_witness = 0xffffff80006d0580}, > mtx_lock = 4}, bo_ops = 0xffffffff8121cc30, > bo_object = 0xfffffe00a1872780, bo_synclist = {le_next = 0x0, > le_prev = 0x0}, bo_private = 0xfffffe00a1b441d8, > __bo_vnode = 0xfffffe00a1b441d8, bo_clean = {bv_hd = {tqh_first = 0x0, > tqh_last = 0xfffffe00a1b442f8}, bv_root = 0x0, bv_cnt = 0}, > bo_dirty = {bv_hd = {tqh_first = 0x0, tqh_last = 0xfffffe00a1b44318}, > bv_root = 0x0, bv_cnt = 0}, bo_numoutput = 0, bo_flag = 0, > ---Type to continue, or q to quit--- > bo_bsize = 131072}, v_pollinfo = 0x0, v_label = 0x0, v_lockf = 0x0, > v_rl = {rl_waiters = {tqh_first = 0x0, tqh_last = 0xfffffe00a1b44360}, > rl_currdep = 0x0}, v_cstart = 0, v_lasta = 0, v_lastw = 0, v_clen = 0, > v_holdcnt = 4, v_usecount = 4, v_iflag = 512, v_vflag = 0, v_writecount = 0, > v_hash = 10597441, v_type = VDIR} And here is dvp, cnp. So yes, *vpp == dvp. (kgdb) p *ap->a_vpp $7 = (struct vnode *) 0xfffffe00a1b441d8 (kgdb) p ap->a_dvp $5 = (struct vnode *) 0xfffffe00a1b441d8 (kgdb) p *ap->a_dvp $8 = {v_tag = 0xffffffff81b2808d "zfs", v_op = 0xffffffff81b35808, v_data = 0xfffffe00a188f000, v_mount = 0xfffffe0015a5f000, v_nmntvnodes = {tqe_next = 0xfffffe00a1b44000, tqe_prev = 0xfffffe00a1b443d0}, v_un = {vu_mount = 0x0, vu_socket = 0x0, vu_cdev = 0x0, vu_fifoinfo = 0x0}, v_hashlist = {le_next = 0x0, le_prev = 0x0}, v_cache_src = {lh_first = 0x0}, v_cache_dst = { tqh_first = 0x0, tqh_last = 0xfffffe00a1b44228}, v_cache_dd = 0x0, v_lock = {lock_object = {lo_name = 0xffffffff81b2808d "zfs", lo_flags = 91947008, lo_data = 0, lo_witness = 0xffffff80006d2700}, lk_lock = 18446741877389099008, lk_exslpfail = 0, lk_timo = 51, lk_pri = 96}, v_interlock = {lock_object = {lo_name = 0xffffffff80e873f0 "vnode interlock", lo_flags = 16973824, lo_data = 0, lo_witness = 0xffffff80006c9600}, mtx_lock = 4}, v_vnlock = 0xfffffe00a1b44240, v_actfreelist = { tqe_next = 0xfffffe000bd363b0, tqe_prev = 0xfffffe0015a5f078}, v_bufobj = {bo_mtx = {lock_object = { lo_name = 0xffffffff80e8f3d5 "bufobj interlock", lo_flags = 16973824, lo_data = 0, lo_witness = 0xffffff80006d0580}, mtx_lock = 4}, bo_ops = 0xffffffff8121cc30, bo_object = 0xfffffe00a1872780, bo_synclist = {le_next = 0x0, le_prev = 0x0}, bo_private = 0xfffffe00a1b441d8, __bo_vnode = 0xfffffe00a1b441d8, bo_clean = {bv_hd = {tqh_first = 0x0, tqh_last = 0xfffffe00a1b442f8}, bv_root = 0x0, bv_cnt = 0}, bo_dirty = {bv_hd = {tqh_first = 0x0, tqh_last = 0xfffffe00a1b44318}, bv_root = 0x0, bv_cnt = 0}, bo_numoutput = 0, bo_flag = 0, bo_bsize = 131072}, v_pollinfo = 0x0, v_label = 0x0, v_lockf = 0x0, v_rl = {rl_waiters = {tqh_first = 0x0, tqh_last = 0xfffffe00a1b44360}, rl_currdep = 0x0}, v_cstart = 0, v_lasta = 0, v_lastw = 0, v_clen = 0, v_holdcnt = 4, v_usecount = 4, v_iflag = 512, v_vflag = 0, v_writecount = 0, v_hash = 10597441, v_type = VDIR} (kgdb) p/x *ap->a_dvp $2 = {v_tag = 0xffffffff81b2808d, v_op = 0xffffffff81b35808, v_data = 0xfffffe00a188f000, v_mount = 0xfffffe0015a5f000, v_nmntvnodes = {tqe_next = 0xfffffe00a1b44000, tqe_prev = 0xfffffe00a1b443d0}, v_un = {vu_mount = 0x0, vu_socket = 0x0, vu_cdev = 0x0, vu_fifoinfo = 0x0}, v_hashlist = {le_next = 0x0, le_prev = 0x0}, v_cache_src = {lh_first = 0x0}, v_cache_dst = { tqh_first = 0x0, tqh_last = 0xfffffe00a1b44228}, v_cache_dd = 0x0, v_lock = {lock_object = {lo_name = 0xffffffff81b2808d, lo_flags = 0x57b0000, lo_data = 0x0, lo_witness = 0xffffff80006d2700}, lk_lock = 0xfffffe00a1198000, lk_exslpfail = 0x0, lk_timo = 0x33, lk_pri = 0x60}, v_interlock = {lock_object = {lo_name = 0xffffffff80e873f0, lo_flags = 0x1030000, lo_data = 0x0, lo_witness = 0xffffff80006c9600}, mtx_lock = 0x4}, v_vnlock = 0xfffffe00a1b44240, v_actfreelist = { tqe_next = 0xfffffe000bd363b0, tqe_prev = 0xfffffe0015a5f078}, v_bufobj = {bo_mtx = {lock_object = { lo_name = 0xffffffff80e8f3d5, lo_flags = 0x1030000, lo_data = 0x0, lo_witness = 0xffffff80006d0580}, mtx_lock = 0x4}, bo_ops = 0xffffffff8121cc30, bo_object = 0xfffffe00a1872780, bo_synclist = {le_next = 0x0, le_prev = 0x0}, bo_private = 0xfffffe00a1b441d8, __bo_vnode = 0xfffffe00a1b441d8, bo_clean = {bv_hd = {tqh_first = 0x0, tqh_last = 0xfffffe00a1b442f8}, bv_root = 0x0, bv_cnt = 0x0}, bo_dirty = {bv_hd = {tqh_first = 0x0, tqh_last = 0xfffffe00a1b44318}, bv_root = 0x0, bv_cnt = 0x0}, bo_numoutput = 0x0, bo_flag = 0x0, bo_bsize = 0x20000}, v_pollinfo = 0x0, v_label = 0x0, v_lockf = 0x0, v_rl = {rl_waiters = {tqh_first = 0x0, tqh_last = 0xfffffe00a1b44360}, rl_currdep = 0x0}, v_cstart = 0x0, v_lasta = 0x0, v_lastw = 0x0, v_clen = 0x0, v_holdcnt = 0x4, v_usecount = 0x4, v_iflag = 0x200, v_vflag = 0x0, v_writecount = 0x0, v_hash = 0xa1b441, v_type = 0x2} (kgdb) p ap->a_cnp $9 = (struct componentname *) 0xffffff848e6c0640 (kgdb) p *ap->a_cnp $10 = {cn_nameiop = 0, cn_flags = 8451076, cn_thread = 0xfffffe00a1198000, cn_cred = 0xfffffe00a167cc00, cn_lkflags = 524288, cn_pnbuf = 0xfffffe000bdee400 "..", cn_nameptr = 0xfffffe000bdee400 "..", cn_namelen = 2, cn_consume = 0} (kgdb) p/x *ap->a_cnp $4 = {cn_nameiop = 0x0, cn_flags = 0x80f404, cn_thread = 0xfffffe00a1198000, cn_cred = 0xfffffe00a167cc00, cn_lkflags = 0x80000, cn_pnbuf = 0xfffffe000bdee400, cn_nameptr = 0xfffffe000bdee400, cn_namelen = 0x2, cn_consume = 0x0} -- wbr, pluknet From owner-freebsd-current@FreeBSD.ORG Mon Feb 4 13:41:01 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 935FF80A; Mon, 4 Feb 2013 13:41:01 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-ia0-x22e.google.com (mail-ia0-x22e.google.com [IPv6:2607:f8b0:4001:c02::22e]) by mx1.freebsd.org (Postfix) with ESMTP id 57E6E1C75; Mon, 4 Feb 2013 13:41:01 +0000 (UTC) Received: by mail-ia0-f174.google.com with SMTP id o25so7941683iad.5 for ; Mon, 04 Feb 2013 05:41:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=T9EHwgEq6i4XJlNNdIq4C/uMzgKuBEHaVI/j2ul5t7M=; b=YW0GxhsDIWYoYtXhce+JbJC+jfeHD51XEcT4rUobKITWpZ6DGM+UDy4H3yio9H4+ib /jsl3wzkXH33o7d7LNptQkTkEYPqTr07V2UExqCDE5yjUgq1ev4+Sg3TPV1ijAwKrm5w XgVg3QGc92JSaMK+IUhFdh2FJmZ45xTwya9fgHH8t1c9GX4WqygDIG10iyCV3w1ViRdb mfnkL9z1nN2osI6djvO7NtTLHJTf9hS/CgdOqtjHK5tY++8miN4vt48n1wiRZXPOTVje AFv29VXAe4u1HB3mrQr7KilupXAMpxf8u6ZUj+0eqPqa1FW0k76+e+8fC2EW1YB+2Cz7 BytA== MIME-Version: 1.0 X-Received: by 10.50.155.134 with SMTP id vw6mr6507082igb.34.1359985261027; Mon, 04 Feb 2013 05:41:01 -0800 (PST) Received: by 10.64.29.13 with HTTP; Mon, 4 Feb 2013 05:41:00 -0800 (PST) In-Reply-To: <2051134267.2641928.1359945139386.JavaMail.root@erie.cs.uoguelph.ca> References: <20130203110759.GM2522@kib.kiev.ua> <2051134267.2641928.1359945139386.JavaMail.root@erie.cs.uoguelph.ca> Date: Mon, 4 Feb 2013 16:41:00 +0300 Message-ID: Subject: Re: panic: LK_RETRY set with incompatible flags From: Sergey Kandaurov To: Rick Macklem Content-Type: text/plain; charset=ISO-8859-1 Cc: Konstantin Belousov , FreeBSD Current , Andriy Gapon X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 04 Feb 2013 13:41:01 -0000 On 4 February 2013 06:32, Rick Macklem wrote: > Konstantin Belousov wrote: >> On Sat, Feb 02, 2013 at 09:30:39PM -0500, Rick Macklem wrote: >> > Andriy Gapon wrote: >> > > on 31/01/2013 15:29 Sergey Kandaurov said the following: >> > > > Hi. >> > > > >> > > > Got this assertion on idle NFS server while `ls -la >> > > > /.zfs/shares/' >> > > > issued on NFS client. > Ok, here's a snippet of zfs_dirlook() from zfs_dir.c: > 388 } else if (name[0] == '.' && name[1] == '.' && name[2] == 0) { > 389 zfsvfs_t *zfsvfs = dzp->z_zfsvfs; > 390 > 391 /* > 392 * If we are a snapshot mounted under .zfs, return > 393 * the vp for the snapshot directory. > 394 */ > 395 if ((error = sa_lookup(dzp->z_sa_hdl, > 396 SA_ZPL_PARENT(zfsvfs), &parent, sizeof (parent))) != 0) > 397 return (error); > 398 if (parent == dzp->z_id && zfsvfs->z_parent != zfsvfs) { > 399 error = zfsctl_root_lookup(zfsvfs->z_parent->z_ctldir, > 400 "snapshot", vpp, NULL, 0, NULL, kcred, > 401 NULL, NULL, NULL); > 402 return (error); > 403 } > > Just reading the comment, I don't know what it is referring to by > "snapshot directory". Would that be "shares" for Sergey's case? > > It seems too obvious, but maybe the lookup of ".." is returning the > vnode for /.zfs/shares for this case? > > I don't know why this wouldn't have shown up before, but maybe it usually > replies from its cache (I think zfs_lookup() calls it a "fast path"). > > It might still be interesting to replace zfs_vnops.c line# 1451 with: > if ((cnp->cn_flags & ISDOTDOT) && *vpp != dvp) > and see what happens? > With this change `ls /home/user1001/.zfs/shares/' lists empty directory (although the relevant dataset has snapshot, but that's a different story :)). Great! Nothing panics/asserts/etc, just seemingly unrelated LOR 1st 0xfffffe00b9569d50 zfs (zfs) @ /usr/src/sys/fs/nfsserver/nfs_nfsdsocket.c:884 2nd 0xfffffe001dfd89a0 ufs (ufs) @ /usr/src/sys/kern/vfs_vnops.c:461 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xffffff848e709d00 kdb_backtrace() at kdb_backtrace+0x39/frame 0xffffff848e709db0 witness_checkorder() at witness_checkorder+0xc47/frame 0xffffff848e709e30 __lockmgr_args() at __lockmgr_args+0x6c9/frame 0xffffff848e709f60 ffs_lock() at ffs_lock+0x84/frame 0xffffff848e709fb0 VOP_LOCK1_APV() at VOP_LOCK1_APV+0xd0/frame 0xffffff848e709fd0 _vn_lock() at _vn_lock+0xab/frame 0xffffff848e70a040 vn_rdwr() at vn_rdwr+0x1f1/frame 0xffffff848e70a100 nfsrv_writestable() at nfsrv_writestable+0xbe/frame 0xffffff848e70a170 nfsrv_openupdate() at nfsrv_openupdate+0x489/frame 0xffffff848e70a5d0 nfsrvd_openconfirm() at nfsrvd_openconfirm+0x123/frame 0xffffff848e70a6b0 nfsrvd_dorpc() at nfsrvd_dorpc+0xf9a/frame 0xffffff848e70a8a0 nfssvc_program() at nfssvc_program+0x482/frame 0xffffff848e70aa00 svc_run_internal() at svc_run_internal+0x1e9/frame 0xffffff848e70aba0 svc_thread_start() at svc_thread_start+0xb/frame 0xffffff848e70abb0 fork_exit() at fork_exit+0x84/frame 0xffffff848e70abf0 fork_trampoline() at fork_trampoline+0xe/frame 0xffffff848e70abf0 --- trap 0xc, rip = 0x800883b7a, rsp = 0x7fffffffd6c8, rbp = 0x7fffffffd970 --- -- wbr, pluknet From owner-freebsd-current@FreeBSD.ORG Mon Feb 4 15:44:03 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C28F9F1A for ; Mon, 4 Feb 2013 15:44:03 +0000 (UTC) (envelope-from tomek.cedro@gmail.com) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by mx1.freebsd.org (Postfix) with ESMTP id 8C4062DA for ; Mon, 4 Feb 2013 15:44:03 +0000 (UTC) Received: by mail-qa0-f51.google.com with SMTP id cr7so1331850qab.3 for ; Mon, 04 Feb 2013 07:43:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:date:x-google-sender-auth:message-id :subject:from:to:content-type; bh=CkQx67VEaiOKus5x+apU05YUdghhfOYPpc4HR0di7Qo=; b=ppMFi1VKEJhKQdmzEhOsGKQa8o5cinAHh5dcJQAGt5aXnVJK4WSCpoHSKOVCrOoPQ+ HKZ+UA0VHbExKbRSo9vyqqCICHcugw2AA0v2PuBZxImFY9ZKGbMcyGy8kC6+mSO0Z4fA 24OQivZivrJ8BAfz19cp6C9NEiItmmR5NYJyFmMzWB7/tcM+Q0fAYnz1lz63nx+BfEY5 sRglxT23406rVdzWQ9JtcHhurG6l/vuS9k4ufwyPZLYL2rfldh13sezdMOQDhyx3p3O0 Fev1ttg7cmMFnYYgSFuGJj6Mma6JDbN+Y20iG/SVXXpSuhrbziWuJl9ygqILoCCXK8+D 9LGw== MIME-Version: 1.0 X-Received: by 10.224.222.15 with SMTP id ie15mr18561383qab.75.1359992244600; Mon, 04 Feb 2013 07:37:24 -0800 (PST) Sender: tomek.cedro@gmail.com Received: by 10.49.71.204 with HTTP; Mon, 4 Feb 2013 07:37:24 -0800 (PST) Date: Mon, 4 Feb 2013 16:37:24 +0100 X-Google-Sender-Auth: fSKb5UktLy94Podw8dh-yBfsRwU Message-ID: Subject: wifi and wpa_supplicant From: CeDeROM To: freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 04 Feb 2013 15:44:03 -0000 Hello :-) I am wondering how exactly the wifi interface and wpa_supplicant is organized - is there any script at wlan0 interface up that starts wpa_supplicant for that interface? Do I have to start wpa_supplicant by hand any time I bring interface down and up (it looks yes for me)? I have ifconfig_wlan0="WPA DHCP" set in rc.conf so I guess after/when interface is up both wpa_supplicant and dhclient should be started..? What should I make to wpa_supplicant starts automatically when I bring wlan0 up? I am using iwn intel wifi driver. Any hints appreciated :-) Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info From owner-freebsd-current@FreeBSD.ORG Mon Feb 4 15:48:04 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id DB32E310 for ; Mon, 4 Feb 2013 15:48:04 +0000 (UTC) (envelope-from lifanov@mail.lifanov.com) Received: from mail.lifanov.com (mail.lifanov.com [206.125.175.12]) by mx1.freebsd.org (Postfix) with ESMTP id B284032E for ; Mon, 4 Feb 2013 15:48:04 +0000 (UTC) Received: from [10.1.3.40] (cnet520-windstream.mcclatchyinteractive.com [166.108.16.2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.lifanov.com (Postfix) with ESMTPSA id C2B0F1A0859; Mon, 4 Feb 2013 15:47:57 +0000 (UTC) Message-ID: <510FD82C.3070303@mail.lifanov.com> Date: Mon, 04 Feb 2013 10:47:56 -0500 From: Nikolai Lifanov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130109 Thunderbird/17.0.2 MIME-Version: 1.0 To: CeDeROM Subject: Re: wifi and wpa_supplicant References: In-Reply-To: X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 04 Feb 2013 15:48:04 -0000 On 02/04/2013 10:37 AM, CeDeROM wrote: > Hello :-) > > I am wondering how exactly the wifi interface and wpa_supplicant is > organized - is there any script at wlan0 interface up that starts > wpa_supplicant for that interface? Do I have to start wpa_supplicant > by hand any time I bring interface down and up (it looks yes for me)? > I have ifconfig_wlan0="WPA DHCP" set in rc.conf so I guess after/when > interface is up both wpa_supplicant and dhclient should be started..? > What should I make to wpa_supplicant starts automatically when I bring > wlan0 up? I am using iwn intel wifi driver. > > Any hints appreciated :-) > Tomek > If you want to do this automatically outside of rc.conf, take a look at devd(8). - Nikolai Lifanov From owner-freebsd-current@FreeBSD.ORG Mon Feb 4 16:03:13 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A67EDA5F for ; Mon, 4 Feb 2013 16:03:13 +0000 (UTC) (envelope-from lifanov@mail.lifanov.com) Received: from mail.lifanov.com (mail.lifanov.com [206.125.175.12]) by mx1.freebsd.org (Postfix) with ESMTP id 7488C623 for ; Mon, 4 Feb 2013 16:03:13 +0000 (UTC) Received: from [10.1.3.40] (cnet520-windstream.mcclatchyinteractive.com [166.108.16.2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.lifanov.com (Postfix) with ESMTPSA id DBA7D1A0859; Mon, 4 Feb 2013 16:03:12 +0000 (UTC) Message-ID: <510FDBBF.1070707@mail.lifanov.com> Date: Mon, 04 Feb 2013 11:03:11 -0500 From: Nikolai Lifanov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130109 Thunderbird/17.0.2 MIME-Version: 1.0 To: CeDeROM Subject: Re: wifi and wpa_supplicant References: <510FD82C.3070303@mail.lifanov.com> In-Reply-To: X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 04 Feb 2013 16:03:13 -0000 On 02/04/2013 10:58 AM, CeDeROM wrote: > Thank you Nikolai! Shouldn't this be a default when > ifconfig_wlan0="WPA DHCP" in rc.conf? :-) > > Best regards :-) > Tomek > > On Mon, Feb 4, 2013 at 4:47 PM, Nikolai Lifanov > wrote: >> On 02/04/2013 10:37 AM, CeDeROM wrote: >>> Hello :-) >>> >>> I am wondering how exactly the wifi interface and wpa_supplicant is >>> organized - is there any script at wlan0 interface up that starts >>> wpa_supplicant for that interface? Do I have to start wpa_supplicant >>> by hand any time I bring interface down and up (it looks yes for me)? >>> I have ifconfig_wlan0="WPA DHCP" set in rc.conf so I guess after/when >>> interface is up both wpa_supplicant and dhclient should be started..? >>> What should I make to wpa_supplicant starts automatically when I bring >>> wlan0 up? I am using iwn intel wifi driver. >>> >>> Any hints appreciated :-) >>> Tomek >>> >> >> If you want to do this automatically outside of rc.conf, take a look at >> devd(8). >> >> - Nikolai Lifanov >> >> _______________________________________________ >> 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" > > > Well, ifconfig_wlan0="WPA DHCP" should connect you at boot if you have your wpa_supplicant.conf(5) configured for it. There is a good writeup for it in the handbook: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/network-wireless.html Also, this should probably have gone to freebsd-users@ and not freebsd-current@ - Nikolai Lifanov From owner-freebsd-current@FreeBSD.ORG Mon Feb 4 20:09:40 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3C339798; Mon, 4 Feb 2013 20:09:40 +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 DD6C0A54; Mon, 4 Feb 2013 20:09:39 +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 <1U2SM9-000fk4-Fm>; Mon, 04 Feb 2013 21:09:33 +0100 Received: from e178022078.adsl.alicedsl.de ([85.178.22.78] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1U2SM9-003yIw-CJ>; Mon, 04 Feb 2013 21:09:33 +0100 Message-ID: <5110157B.3010800@zedat.fu-berlin.de> Date: Mon, 04 Feb 2013 21:09:31 +0100 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130131 Thunderbird/17.0.2 MIME-Version: 1.0 To: Dimitry Andric Subject: Re: r246057: buildworld fails with: /usr/obj/usr/src/tmp/usr/lib/libc++.so: undefined reference to `std::bad_alloc::~bad_alloc()' References: <51079F0A.20309@zedat.fu-berlin.de> <510ECD2A.5000104@FreeBSD.org> In-Reply-To: <510ECD2A.5000104@FreeBSD.org> X-Enigmail-Version: 1.4.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig69CE476899603FA1DC4F9B71" X-Originating-IP: 85.178.22.78 Cc: Current FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 04 Feb 2013 20:09:40 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig69CE476899603FA1DC4F9B71 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Am 02/03/13 21:48, schrieb Dimitry Andric: > On 2013-01-29 11:06, O. Hartmann wrote: >> I receive this error since yesterday building world and it is still >> sticky on most recent sources (r246057) and I was wondering why the >> tinderboxes do not pick this up on the 10.0-CURRENT builds ... just fo= r >> a notice for the development folks ... > ... >> /usr/obj/usr/src/tmp/usr/lib/libc++.so: undefined reference to >> `std::bad_alloc::~bad_alloc()' >=20 > I have committed a fix for libcxxrt's symbol version map in r246297. > Please update to that revision, clean out /usr/obj, and try buildworld > again. >=20 > -Dimitry Thank you, works. Oliver --------------enig69CE476899603FA1DC4F9B71 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) iQEcBAEBAgAGBQJREBV8AAoJEOgBcD7A/5N8jSAH/RsekzA/AJtVWf+mdg24Rl0T 2z1ziadbRTTYv0z4853sWwifEZc/YCpgynEWcx8/Mdrbahsh88DWbq1hcShKAGCA nwvxS9OQC0nq2ZjG7pRWNFCXwqiljgbLzxl5ju6G3mNXTguLRRyhFz6o7jyEe8iT VE8Vl6IAsFtuexhcmVJX5/YpGHJoEW/Xx9sYJathcn2kHfhu+UCIs+UapHClK5Av X7ZMSrKlcb7k0yVHCU0LNgG858ZoXdvp+yysDPTi2KWGgWHK+Okz5bCPCNl7n/iY AVteS7nYRR/CKzIS6GrMyKwrJ/FTxSnqVJG94knawEPuMJzitZlvwwesjXT9AEs= =CuQV -----END PGP SIGNATURE----- --------------enig69CE476899603FA1DC4F9B71-- From owner-freebsd-current@FreeBSD.ORG Mon Feb 4 20:46:20 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3BA4D392 for ; Mon, 4 Feb 2013 20:46: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 9CBAAD36 for ; Mon, 4 Feb 2013 20:46:19 +0000 (UTC) Received: from pakbsde14.localnet (unknown [38.105.238.108]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id ADE37B9AC; Mon, 4 Feb 2013 15:46:18 -0500 (EST) From: John Baldwin To: freebsd-current@freebsd.org Subject: Re: CURRENT: Broken on > r246222? Date: Mon, 4 Feb 2013 14:50:59 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p22; KDE/4.5.5; amd64; ; ) References: <510E8FCD.1040701@zedat.fu-berlin.de> In-Reply-To: <510E8FCD.1040701@zedat.fu-berlin.de> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201302041450.59809.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 04 Feb 2013 15:46:18 -0500 (EST) Cc: "O. Hartmann" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 04 Feb 2013 20:46:20 -0000 On Sunday, February 03, 2013 11:26:53 am O. Hartmann wrote: > CURRENT, as of recent Revision 246285 (see below) fails and > crashes/reboots on an Ivy-Bridge platform (see below). Since the box > does not have debugging switched on (not yet, will do eventually > Monday), Last thing I see on screen is > > p4tcc3: on cpu3 > > then the system run dark and reboots without any notice (kernel doesn't > have debugging switched on so far, will do this after Monday). I don't think there are any known issues. Can you narrow it down to a specific commit? -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Feb 4 21:46:20 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 13C88A17; Mon, 4 Feb 2013 21:46:20 +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 B9C5920F; Mon, 4 Feb 2013 21:46:19 +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 <1U2Trm-000ynb-Qh>; Mon, 04 Feb 2013 22:46:18 +0100 Received: from e178031025.adsl.alicedsl.de ([85.178.31.25] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1U2Trm-0043j3-NE>; Mon, 04 Feb 2013 22:46:18 +0100 Message-ID: <51102C29.4020106@zedat.fu-berlin.de> Date: Mon, 04 Feb 2013 22:46:17 +0100 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130131 Thunderbird/17.0.2 MIME-Version: 1.0 To: John Baldwin Subject: Re: CURRENT: Broken on > r246222? References: <510E8FCD.1040701@zedat.fu-berlin.de> <201302041450.59809.jhb@freebsd.org> In-Reply-To: <201302041450.59809.jhb@freebsd.org> X-Enigmail-Version: 1.4.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigC1894A71F6220CDAD54F8333" X-Originating-IP: 85.178.31.25 Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 04 Feb 2013 21:46:20 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigC1894A71F6220CDAD54F8333 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Am 02/04/13 20:50, schrieb John Baldwin: > On Sunday, February 03, 2013 11:26:53 am O. Hartmann wrote: >> CURRENT, as of recent Revision 246285 (see below) fails and >> crashes/reboots on an Ivy-Bridge platform (see below). Since the box >> does not have debugging switched on (not yet, will do eventually >> Monday), Last thing I see on screen is >> >> p4tcc3: on cpu3 >> >> then the system run dark and reboots without any notice (kernel doesn'= t >> have debugging switched on so far, will do this after Monday). >=20 > I don't think there are any known issues. Can you narrow it down to a > specific commit? >=20 No, I can't. But I can now confirm, that with r246326 the problem has go= ne. Oliver --------------enigC1894A71F6220CDAD54F8333 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) iQEcBAEBAgAGBQJRECwqAAoJEOgBcD7A/5N8q0kH/R5sjElEHx+7zzhx2uk0YJbK e4cfzY8ZpPU3aS4Pv8Bu1QlcvhVB5BQVpwm7WCxpKCrUHh0W9vxa98zRW4XiumTJ ihTcq+PoDctL/tFdSRAg5FKk2TZeYnlULwU/ZCqmWosN/WDM3qJUdcWEcbxN6kda TcdbwN2QeZ8JY5V78n6rm90/EhkOOTIWCn35EFwvCIUvL2pxfJvh9hv1ryN/2np7 tfZGbaR/tqtT/KiqYZtjmlpYhLApXpJugRmc6tHmay1yr4Cnw6xMzzv+xUWB7rwZ ALMKwQQrWk9uZwXblv0lRzNmVTU6J2nkO7Jp/WIgH0odLJZarIhh4wBx2BQOdZk= =4ovV -----END PGP SIGNATURE----- --------------enigC1894A71F6220CDAD54F8333-- From owner-freebsd-current@FreeBSD.ORG Mon Feb 4 23:20:35 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 0E0B0E22 for ; Mon, 4 Feb 2013 23:20:35 +0000 (UTC) (envelope-from pfg@FreeBSD.org) Received: from nm4-vm3.bullet.mail.ne1.yahoo.com (nm4-vm3.bullet.mail.ne1.yahoo.com [98.138.91.134]) by mx1.freebsd.org (Postfix) with ESMTP id 91108879 for ; Mon, 4 Feb 2013 23:20:34 +0000 (UTC) Received: from [98.138.90.49] by nm4.bullet.mail.ne1.yahoo.com with NNFMP; 04 Feb 2013 23:18:19 -0000 Received: from [98.138.226.131] by tm2.bullet.mail.ne1.yahoo.com with NNFMP; 04 Feb 2013 23:18:19 -0000 Received: from [127.0.0.1] by smtp218.mail.ne1.yahoo.com with NNFMP; 04 Feb 2013 23:18:19 -0000 X-Yahoo-Newman-Id: 866240.63167.bm@smtp218.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: lWzcEbwVM1n9D_eX0XzgC03x3LdrDjxBx6fheEjhCGu.ilr d9ZXwd.yzCJtPXfyz7vScHycIgDsPs8wonrECJV0joIIyeNTYQm.kGZbM7UG 6uzrbw4mCZj0bbpcSU8LC7_jDF8YhTHwismqhlWN5HPFm.Lqg0sADH0kQWJI oJyA_hdW1KgzDhbf_8GMM58kXkx3h8K2f7.xV4mr1EDqSa_koyMauLJUU0um xzYNZeK86JxYkEMQsSgO6JS6RtaoWdkhFgmMpwrWPyxbyVq7J0g9ttRYmAvQ 4l0lEHMQvgxTKSqqu2kLWWqiPmyquKj_Esvg7BfR.rMr1LMHvieNQgCB_6yG 2.ZTjTSqRiKfoOi.ozj.sdUAG2mCjUYzOWub88b2EmiTIOxuXwE_xOrPdKrX AF3h62stATqVvYJUiyJve2yePlcvynqpzgrjtZrYg2svxDRfIqvC2.hPIFRA Y5zW0ZydNGgZfPUgIHM.5Dac2sngjDPeCK0jjYdtG3iHZTpDDw3VxpuhZHY1 4P9Ls4zTAhzDRgzg4KnoYk58E8LSFLeASD1H0PVTK9SIFHQhDdeV8IqpciPC xLzrCez1_tu.IrLArESZUGZB6tEIj.vaCcHZva996Lw7ZQ278UZkFbTzOarl It.iSOfxYjpql_.E9q3Rl5bh5ZxL96XfERj32k1SVaH.J0V2O91L64hGfSa7 mX66T44D5.kpAJoyN X-Yahoo-SMTP: xcjD0guswBAZaPPIbxpWwLcp9Unf Received: from [192.168.10.102] (pfg@200.118.157.7 with plain) by smtp218.mail.ne1.yahoo.com with SMTP; 04 Feb 2013 15:18:19 -0800 PST Message-ID: <511041BF.9000601@FreeBSD.org> Date: Mon, 04 Feb 2013 18:18:23 -0500 From: Pedro Giffuni User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: freebsd-current@FreeBSD.org Subject: Dtrace status - material for someone's TODO list. Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 04 Feb 2013 23:20:35 -0000 Hello; Last year I did an attempt to merge some of the changes from illumos' Dtrace into FreeBSD. I don't use Dtrace a lot, so this was done mainly for fun. In general, merging changes from Illumos was pretty straightforward; just a matter of readapting the paths to match our layout. I was able to merge some basic stuff (semilog plots) and fixes but we are at a point now where they are building upon their own developments and we need to merge their stuff in the same order they did. Some of their changes (KVM and zones) we can just ignore. As of lately, I got stuck because our userland support is different from the Solaris stuff. The conflicts I am seeing now are not easy for my (non-)level of inner Dtrace-foo and I am not working more on this so I will post the links to the patches in the hope that someone will pick up where I left: - 1368 enablings on defunct providers prevent providers from unregistering http://people.freebsd.org/~pfg/patches/dtrace/illumos-gate-8e6add739e38.diff - 1455 DTrace tracemem() should take an optional size argument http://people.freebsd.org/~pfg/patches/dtrace/illumos-gate-571b0355c2e3.diff Once done with those we can continue bringing the nicer features: http://dtrace.org/blogs/eschrock/2011/10/26/your-mdb-fell-into-my-dtrace/ Cheers, Pedro. From owner-freebsd-current@FreeBSD.ORG Tue Feb 5 00:02:22 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 154926F2; Tue, 5 Feb 2013 00:02:22 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 868469EC; Tue, 5 Feb 2013 00:02:21 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap8EAGtLEFGDaFvO/2dsb2JhbABFhki5EnOCHwEBBAEjBFIbDgoCAg0ZAiM2BhOHfwMJBqkaiF8NiVaBI4p6hCKBEwOIZothgViJVYFqhRKDGoIG X-IronPort-AV: E=Sophos;i="4.84,602,1355115600"; d="scan'208";a="15063763" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 04 Feb 2013 19:02:14 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 490B4B4044; Mon, 4 Feb 2013 19:02:14 -0500 (EST) Date: Mon, 4 Feb 2013 19:02:14 -0500 (EST) From: Rick Macklem To: Sergey Kandaurov Message-ID: <1077235459.2683307.1360022534263.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: Subject: Re: panic: LK_RETRY set with incompatible flags MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.201] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: Konstantin Belousov , FreeBSD Current , Andriy Gapon X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 05 Feb 2013 00:02:22 -0000 Sergey Kandaurov wrote: > On 4 February 2013 16:30, Sergey Kandaurov wrote: > > On 4 February 2013 16:13, Sergey Kandaurov > > wrote: > >> On 4 February 2013 16:06, Andriy Gapon wrote: > >>> on 04/02/2013 13:49 Sergey Kandaurov said the following: > >>>> Hi, Rick! Here is the requested info regarding witness, and a bit > >>>> more. > >>>> The triggered KASSERT is now different though. > >>> > >>> It's exactly the same problem though :-) > >>> Do you have a crashdump? > >>> If yes, please print **vpp. > >> > >> Yep, but it's in a bad form :( > >> It has many bits optimized out (compiled with clang). > >> I'll rebuild the kernel with -O or so and will try again. > >> > >> #8 0xffffffff808bc4ce in kdb_enter (why=0xffffffff80e7ed99 "panic", > >> msg=) at cpufunc.h:63 > >> #9 0xffffffff80888fb7 in vpanic (fmt=, > >> ap=) at > >> /usr/src/sys/kern/kern_shutdown.c:746 > >> #10 0xffffffff80888e66 in kassert_panic (fmt=) > >> at /usr/src/sys/kern/kern_shutdown.c:641 > >> #11 0xffffffff808d2259 in witness_checkorder > >> (lock=0xfffffe00a1b44240, > >> ---Type to continue, or q to quit--- > >> flags=1, > >> file=0xffffffff81b2bb36 > >> "/usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c", > >> line=1452, > >> interlock=) at > >> /usr/src/sys/kern/subr_witness.c:1122 > >> #12 0xffffffff8086c11e in __lockmgr_args (lk=0xfffffe00a1b44240, > >> flags=, ilk=0xfffffe00a1b44270, > >> wmesg=0xffffffff81b2808d "zfs", pri=96, timo=51, > >> file=0xffffffff80e8e407 "/usr/src/sys/kern/vfs_default.c", > >> line=0) > >> at /usr/src/sys/kern/kern_lock.c:511 > >> #13 0xffffffff8091439c in vop_stdlock (ap=) > >> at lockmgr.h:97 > >> #14 0xffffffff80cb70c0 in VOP_LOCK1_APV (vop=, > >> a=) at vnode_if.c:2022 > >> #15 0xffffffff80932fbb in _vn_lock (vp=0xfffffe00a1b441d8, > >> flags=, > >> file=0xffffffff81b2bb36 > >> "/usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c", > >> line=1452) at vnode_if.h:859 > >> #16 0xffffffff81abd902 in zfs_lookup () > >> at > >> /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:1452 > >> #17 0xffffffff81abdc1d in zfs_freebsd_lookup > >> (ap=0xffffff848e6c0270) > >> at > >> /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:5864 > >> ---Type to continue, or q to quit--- > >> #18 0xffffffff80cb51b2 in VOP_CACHEDLOOKUP_APV (vop= >> optimized out>, > >> a=) at vnode_if.c:191 > >> #19 0xffffffff8091177f in vfs_cache_lookup (ap= >> out>) > >> at vnode_if.h:80 > >> #20 0xffffffff80cb50a2 in VOP_LOOKUP_APV (vop= >> out>, > >> a=) at vnode_if.c:125 > >> #21 0xffffffff80919658 in lookup (ndp=0xffffff848e6c05d8) at > >> vnode_if.h:54 > >> #22 0xffffffff807dffe5 in nfsvno_namei (nd=0xffffff848e6c08c8, > >> ndp=0xffffff848e6c05d8, dp=, > >> islocked=, exp=, > >> p=, retdirp=) > >> at /usr/src/sys/fs/nfsserver/nfs_nfsdport.c:413 > >> #23 0xffffffff807d8ffa in nfsrvd_lookup (nd=0xffffff848e6c08c8, > >> isdgram=, dp=0xfffffe00a1b441d8, > >> vpp=0xffffff848e6c0810, fhp=0xffffff848e6c07f4, > >> p=0xfffffe00a1198000, > >> exp=0xffffff848e6c07a0) at > >> /usr/src/sys/fs/nfsserver/nfs_nfsdserv.c:517 > >> #24 0xffffffff807cb845 in nfsrvd_dorpc (nd=0xffffff848e6c08c8, > >> isdgram=0, > >> p=0xfffffe00a1198000) at > >> /usr/src/sys/fs/nfsserver/nfs_nfsdsocket.c:823 > >> #25 0xffffffff807d7af2 in nfssvc_program (rqst=0xfffffe00a17bb000, > >> xprt=0xfffffe00a124b200) at > >> /usr/src/sys/fs/nfsserver/nfs_nfsdkrpc.c:347 > >> #26 0xffffffff80a70659 in svc_run_internal > >> (pool=0xfffffe00067db600, > >> ismaster=0) at /usr/src/sys/rpc/svc.c:895 > >> #27 0xffffffff80a7155b in svc_thread_start (arg=0xffffff848e6bfc50) > >> ---Type to continue, or q to quit--- > >> at /usr/src/sys/rpc/svc.c:1200 > >> #28 0xffffffff80858944 in fork_exit ( > >> callout=0xffffffff80a71550 , > >> arg=0xfffffe00067db600, > >> frame=0xffffff848e6c0c00) at /usr/src/sys/kern/kern_fork.c:991 > >> #29 0xffffffff80bfa86e in fork_trampoline () at exception.S:602 > >> #30 0x0000000000000080 in ?? () > >> #31 0x00007fffffffd820 in ?? () > >> #32 0x0000000000000001 in ?? () > >> #33 0x0000000000000000 in ?? () > >> Current language: auto; currently minimal > >> > >> (kgdb) p vpp > >> Cannot access memory at address 0x0 > >> (kgdb) p dvp > >> Cannot access memory at address 0x0 > >> > > > > That was from f 16. And as Andriy suggested in private (thanks > > Andriy!) > > those pointers could be reached from ap in f 17. > > On the other hand, zfs_lookup() is large, and *vpp might be > > rewritten several times there. Here it is: > > > > (kgdb) f 17 > > #17 0xffffffff81abdc1d in zfs_freebsd_lookup (ap=0xffffff848e6c0270) > > at > > /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:5864 > > 5864 return (zfs_lookup(ap->a_dvp, nm, ap->a_vpp, cnp, > > cnp->cn_nameiop, > > (kgdb) p ap->a_vpp > > $4 = (struct vnode **) 0xffffff848e6c0618 > > (kgdb) p *ap->a_vpp > > $5 = (struct vnode *) 0xfffffe00a1b441d8 > > (kgdb) p **ap->a_vpp > > $6 = {v_tag = 0xffffffff81b2808d "zfs", v_op = 0xffffffff81b35808, > > v_data = 0xfffffe00a188f000, v_mount = 0xfffffe0015a5f000, > > v_nmntvnodes = { > > tqe_next = 0xfffffe00a1b44000, tqe_prev = 0xfffffe00a1b443d0}, > > v_un = { > > vu_mount = 0x0, vu_socket = 0x0, vu_cdev = 0x0, vu_fifoinfo = > > 0x0}, > > v_hashlist = {le_next = 0x0, le_prev = 0x0}, v_cache_src = > > {lh_first = 0x0}, > > v_cache_dst = {tqh_first = 0x0, tqh_last = 0xfffffe00a1b44228}, > > v_cache_dd = 0x0, v_lock = {lock_object = { > > lo_name = 0xffffffff81b2808d "zfs", lo_flags = 91947008, > > lo_data = 0, > > lo_witness = 0xffffff80006d2700}, lk_lock = > > 18446741877389099008, > > lk_exslpfail = 0, lk_timo = 51, lk_pri = 96}, v_interlock = { > > lock_object = {lo_name = 0xffffffff80e873f0 "vnode interlock", > > lo_flags = 16973824, lo_data = 0, lo_witness = > > 0xffffff80006c9600}, > > mtx_lock = 4}, v_vnlock = 0xfffffe00a1b44240, v_actfreelist = { > > tqe_next = 0xfffffe000bd363b0, tqe_prev = 0xfffffe0015a5f078}, > > v_bufobj = { > > bo_mtx = {lock_object = {lo_name = 0xffffffff80e8f3d5 "bufobj > > interlock", > > lo_flags = 16973824, lo_data = 0, lo_witness = > > 0xffffff80006d0580}, > > mtx_lock = 4}, bo_ops = 0xffffffff8121cc30, > > bo_object = 0xfffffe00a1872780, bo_synclist = {le_next = 0x0, > > le_prev = 0x0}, bo_private = 0xfffffe00a1b441d8, > > __bo_vnode = 0xfffffe00a1b441d8, bo_clean = {bv_hd = {tqh_first > > = 0x0, > > tqh_last = 0xfffffe00a1b442f8}, bv_root = 0x0, bv_cnt = 0}, > > bo_dirty = {bv_hd = {tqh_first = 0x0, tqh_last = > > 0xfffffe00a1b44318}, > > bv_root = 0x0, bv_cnt = 0}, bo_numoutput = 0, bo_flag = 0, > > ---Type to continue, or q to quit--- > > bo_bsize = 131072}, v_pollinfo = 0x0, v_label = 0x0, v_lockf = > > 0x0, > > v_rl = {rl_waiters = {tqh_first = 0x0, tqh_last = > > 0xfffffe00a1b44360}, > > rl_currdep = 0x0}, v_cstart = 0, v_lasta = 0, v_lastw = 0, > > v_clen = 0, > > v_holdcnt = 4, v_usecount = 4, v_iflag = 512, v_vflag = 0, > > v_writecount = 0, > > v_hash = 10597441, v_type = VDIR} > > And here is dvp, cnp. So yes, *vpp == dvp. > > (kgdb) p *ap->a_vpp > $7 = (struct vnode *) 0xfffffe00a1b441d8 > (kgdb) p ap->a_dvp > $5 = (struct vnode *) 0xfffffe00a1b441d8 > > (kgdb) p *ap->a_dvp > $8 = {v_tag = 0xffffffff81b2808d "zfs", v_op = 0xffffffff81b35808, > v_data = 0xfffffe00a188f000, v_mount = 0xfffffe0015a5f000, > v_nmntvnodes = {tqe_next = 0xfffffe00a1b44000, tqe_prev = > 0xfffffe00a1b443d0}, v_un = {vu_mount = 0x0, vu_socket = 0x0, > vu_cdev = 0x0, vu_fifoinfo = 0x0}, v_hashlist = {le_next = 0x0, > le_prev = 0x0}, v_cache_src = {lh_first = 0x0}, v_cache_dst = { > tqh_first = 0x0, tqh_last = 0xfffffe00a1b44228}, v_cache_dd = 0x0, > v_lock = {lock_object = {lo_name = 0xffffffff81b2808d "zfs", > lo_flags = 91947008, lo_data = 0, lo_witness = > 0xffffff80006d2700}, lk_lock = 18446741877389099008, lk_exslpfail = 0, > lk_timo = 51, lk_pri = 96}, v_interlock = {lock_object = {lo_name > = 0xffffffff80e873f0 "vnode interlock", lo_flags = 16973824, > lo_data = 0, lo_witness = 0xffffff80006c9600}, mtx_lock = 4}, > v_vnlock = 0xfffffe00a1b44240, v_actfreelist = { > tqe_next = 0xfffffe000bd363b0, tqe_prev = 0xfffffe0015a5f078}, > v_bufobj = {bo_mtx = {lock_object = { > lo_name = 0xffffffff80e8f3d5 "bufobj interlock", lo_flags = > 16973824, lo_data = 0, lo_witness = 0xffffff80006d0580}, > mtx_lock = 4}, bo_ops = 0xffffffff8121cc30, bo_object = > 0xfffffe00a1872780, bo_synclist = {le_next = 0x0, le_prev = 0x0}, > bo_private = 0xfffffe00a1b441d8, __bo_vnode = 0xfffffe00a1b441d8, > bo_clean = {bv_hd = {tqh_first = 0x0, > tqh_last = 0xfffffe00a1b442f8}, bv_root = 0x0, bv_cnt = 0}, > bo_dirty = {bv_hd = {tqh_first = 0x0, > tqh_last = 0xfffffe00a1b44318}, bv_root = 0x0, bv_cnt = 0}, > bo_numoutput = 0, bo_flag = 0, bo_bsize = 131072}, > v_pollinfo = 0x0, v_label = 0x0, v_lockf = 0x0, v_rl = {rl_waiters = > {tqh_first = 0x0, tqh_last = 0xfffffe00a1b44360}, > rl_currdep = 0x0}, v_cstart = 0, v_lasta = 0, v_lastw = 0, v_clen > = 0, v_holdcnt = 4, v_usecount = 4, v_iflag = 512, > v_vflag = 0, v_writecount = 0, v_hash = 10597441, v_type = VDIR} > (kgdb) p/x *ap->a_dvp > $2 = {v_tag = 0xffffffff81b2808d, v_op = 0xffffffff81b35808, v_data = > 0xfffffe00a188f000, v_mount = 0xfffffe0015a5f000, > v_nmntvnodes = {tqe_next = 0xfffffe00a1b44000, tqe_prev = > 0xfffffe00a1b443d0}, v_un = {vu_mount = 0x0, vu_socket = 0x0, > vu_cdev = 0x0, vu_fifoinfo = 0x0}, v_hashlist = {le_next = 0x0, > le_prev = 0x0}, v_cache_src = {lh_first = 0x0}, v_cache_dst = { > tqh_first = 0x0, tqh_last = 0xfffffe00a1b44228}, v_cache_dd = 0x0, > v_lock = {lock_object = {lo_name = 0xffffffff81b2808d, > lo_flags = 0x57b0000, lo_data = 0x0, lo_witness = > 0xffffff80006d2700}, lk_lock = 0xfffffe00a1198000, lk_exslpfail = 0x0, > lk_timo = 0x33, lk_pri = 0x60}, v_interlock = {lock_object = > {lo_name = 0xffffffff80e873f0, lo_flags = 0x1030000, lo_data = 0x0, > lo_witness = 0xffffff80006c9600}, mtx_lock = 0x4}, v_vnlock = > 0xfffffe00a1b44240, v_actfreelist = { > tqe_next = 0xfffffe000bd363b0, tqe_prev = 0xfffffe0015a5f078}, > v_bufobj = {bo_mtx = {lock_object = { > lo_name = 0xffffffff80e8f3d5, lo_flags = 0x1030000, lo_data = > 0x0, lo_witness = 0xffffff80006d0580}, mtx_lock = 0x4}, > bo_ops = 0xffffffff8121cc30, bo_object = 0xfffffe00a1872780, > bo_synclist = {le_next = 0x0, le_prev = 0x0}, > bo_private = 0xfffffe00a1b441d8, __bo_vnode = 0xfffffe00a1b441d8, > bo_clean = {bv_hd = {tqh_first = 0x0, > tqh_last = 0xfffffe00a1b442f8}, bv_root = 0x0, bv_cnt = 0x0}, > bo_dirty = {bv_hd = {tqh_first = 0x0, > tqh_last = 0xfffffe00a1b44318}, bv_root = 0x0, bv_cnt = 0x0}, > bo_numoutput = 0x0, bo_flag = 0x0, bo_bsize = 0x20000}, > v_pollinfo = 0x0, v_label = 0x0, v_lockf = 0x0, v_rl = {rl_waiters = > {tqh_first = 0x0, tqh_last = 0xfffffe00a1b44360}, > rl_currdep = 0x0}, v_cstart = 0x0, v_lasta = 0x0, v_lastw = 0x0, > v_clen = 0x0, v_holdcnt = 0x4, v_usecount = 0x4, > v_iflag = 0x200, v_vflag = 0x0, v_writecount = 0x0, v_hash = > 0xa1b441, v_type = 0x2} > > (kgdb) p ap->a_cnp > $9 = (struct componentname *) 0xffffff848e6c0640 > (kgdb) p *ap->a_cnp > $10 = {cn_nameiop = 0, cn_flags = 8451076, cn_thread = > 0xfffffe00a1198000, cn_cred = 0xfffffe00a167cc00, cn_lkflags = 524288, > cn_pnbuf = 0xfffffe000bdee400 "..", cn_nameptr = 0xfffffe000bdee400 > "..", cn_namelen = 2, cn_consume = 0} > (kgdb) p/x *ap->a_cnp > $4 = {cn_nameiop = 0x0, cn_flags = 0x80f404, cn_thread = > 0xfffffe00a1198000, cn_cred = 0xfffffe00a167cc00, cn_lkflags = > 0x80000, > cn_pnbuf = 0xfffffe000bdee400, cn_nameptr = 0xfffffe000bdee400, > cn_namelen = 0x2, cn_consume = 0x0} > > -- > wbr, > pluknet First off, Sergey, thanks for collecting this information. It would appear that, for this case, zfs_lookup() sets *vpp to dvp for the ".." lookup. The vnode is not flagged VV_ROOT and v_mountedhere == NULL, so I'm not sure what this means? Maybe someone familiar with ZFS can explain what these snapshots are supposed to look like: - a mount point - a directory - a regular file or ??? Does anyone know why ZFS chooses to return the same directory vnode for a lookup of ".." for this case? (The comment in the code doesn't say why, just that it does this.) Sorry, but I've never touched ZFS, rick From owner-freebsd-current@FreeBSD.ORG Tue Feb 5 00:14:21 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A4A72ABA; Tue, 5 Feb 2013 00:14:21 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.net.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 22517A5B; Tue, 5 Feb 2013 00:14:20 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap8EAIFOEFGDaFvO/2dsb2JhbABFhki5EnOCHwEBBAEjBFIFFg4KAgINGQJZBhOICwapH5JDgSOPHIETA4hmjTmJVYZ8gxqCBg X-IronPort-AV: E=Sophos;i="4.84,602,1355115600"; d="scan'208";a="12427217" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu.net.uoguelph.ca with ESMTP; 04 Feb 2013 19:13:50 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 1C079B3F17; Mon, 4 Feb 2013 19:13:50 -0500 (EST) Date: Mon, 4 Feb 2013 19:13:50 -0500 (EST) From: Rick Macklem To: Sergey Kandaurov Message-ID: <1105316997.2683638.1360023230093.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: Subject: Re: panic: LK_RETRY set with incompatible flags MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.202] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: Konstantin Belousov , FreeBSD Current , Andriy Gapon X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 05 Feb 2013 00:14:21 -0000 Sergey Kandaurov wrote: > On 4 February 2013 06:32, Rick Macklem wrote: > > Konstantin Belousov wrote: > >> On Sat, Feb 02, 2013 at 09:30:39PM -0500, Rick Macklem wrote: > >> > Andriy Gapon wrote: > >> > > on 31/01/2013 15:29 Sergey Kandaurov said the following: > >> > > > Hi. > >> > > > > >> > > > Got this assertion on idle NFS server while `ls -la > >> > > > /.zfs/shares/' > >> > > > issued on NFS client. > > Ok, here's a snippet of zfs_dirlook() from zfs_dir.c: > > 388 } else if (name[0] == '.' && name[1] == '.' && name[2] == 0) { > > 389 zfsvfs_t *zfsvfs = dzp->z_zfsvfs; > > 390 > > 391 /* > > 392 * If we are a snapshot mounted under .zfs, return > > 393 * the vp for the snapshot directory. > > 394 */ > > 395 if ((error = sa_lookup(dzp->z_sa_hdl, > > 396 SA_ZPL_PARENT(zfsvfs), &parent, sizeof (parent))) != 0) > > 397 return (error); > > 398 if (parent == dzp->z_id && zfsvfs->z_parent != zfsvfs) { > > 399 error = zfsctl_root_lookup(zfsvfs->z_parent->z_ctldir, > > 400 "snapshot", vpp, NULL, 0, NULL, kcred, > > 401 NULL, NULL, NULL); > > 402 return (error); > > 403 } > > > > Just reading the comment, I don't know what it is referring to by > > "snapshot directory". Would that be "shares" for Sergey's case? > > > > It seems too obvious, but maybe the lookup of ".." is returning the > > vnode for /.zfs/shares for this case? > > > > I don't know why this wouldn't have shown up before, but maybe it > > usually > > replies from its cache (I think zfs_lookup() calls it a "fast > > path"). > > > > It might still be interesting to replace zfs_vnops.c line# 1451 > > with: > > if ((cnp->cn_flags & ISDOTDOT) && *vpp != dvp) > > and see what happens? > > > > With this change `ls /home/user1001/.zfs/shares/' lists empty > directory > (although the relevant dataset has snapshot, but that's a different > story :)). > Great! > Nothing panics/asserts/etc, just seemingly unrelated LOR > Yes, I think the patch is relatively safe, since lookup() checks for same vnode and does a vrele() instead of a vput() when they are the same, at least for a plain lookup without wantparent. So, since I've never used ZFS, what does a "ls -la /home/user1001/.zfs/shares/" give you when done locally one the server? > 1st 0xfffffe00b9569d50 zfs (zfs) @ > /usr/src/sys/fs/nfsserver/nfs_nfsdsocket.c:884 > 2nd 0xfffffe001dfd89a0 ufs (ufs) @ /usr/src/sys/kern/vfs_vnops.c:461 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame > 0xffffff848e709d00 > kdb_backtrace() at kdb_backtrace+0x39/frame 0xffffff848e709db0 > witness_checkorder() at witness_checkorder+0xc47/frame > 0xffffff848e709e30 > __lockmgr_args() at __lockmgr_args+0x6c9/frame 0xffffff848e709f60 > ffs_lock() at ffs_lock+0x84/frame 0xffffff848e709fb0 > VOP_LOCK1_APV() at VOP_LOCK1_APV+0xd0/frame 0xffffff848e709fd0 > _vn_lock() at _vn_lock+0xab/frame 0xffffff848e70a040 > vn_rdwr() at vn_rdwr+0x1f1/frame 0xffffff848e70a100 > nfsrv_writestable() at nfsrv_writestable+0xbe/frame 0xffffff848e70a170 > nfsrv_openupdate() at nfsrv_openupdate+0x489/frame 0xffffff848e70a5d0 > nfsrvd_openconfirm() at nfsrvd_openconfirm+0x123/frame > 0xffffff848e70a6b0 > nfsrvd_dorpc() at nfsrvd_dorpc+0xf9a/frame 0xffffff848e70a8a0 > nfssvc_program() at nfssvc_program+0x482/frame 0xffffff848e70aa00 > svc_run_internal() at svc_run_internal+0x1e9/frame 0xffffff848e70aba0 > svc_thread_start() at svc_thread_start+0xb/frame 0xffffff848e70abb0 > fork_exit() at fork_exit+0x84/frame 0xffffff848e70abf0 > fork_trampoline() at fork_trampoline+0xe/frame 0xffffff848e70abf0 > --- trap 0xc, rip = 0x800883b7a, rsp = 0x7fffffffd6c8, rbp = > 0x7fffffffd970 --- > I don't think this LOR is an issue. It definitely isn't related to the panic/crash. Thanks for collecting this information and passing it along, rick > > -- > wbr, > pluknet From owner-freebsd-current@FreeBSD.ORG Tue Feb 5 07:16:10 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 6BCE44BB; Tue, 5 Feb 2013 07:16:10 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) by mx1.freebsd.org (Postfix) with ESMTP id 89422A81; Tue, 5 Feb 2013 07:16:09 +0000 (UTC) Received: by mail-wi0-f179.google.com with SMTP id ez12so3850623wid.6 for ; Mon, 04 Feb 2013 23:16:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=u/B2vCbnOVvhSSOzvO5YBNAvfldMeB/9PI8vs4ZT5Qc=; b=iR/cPI6upN/yhHV3h3uqiVo9wQ4EPCqlkCJ7QStjwm7tTj3HEutFQS6lxPa+pvMP42 NvyQmuyxpjjI9AABB6uzLmm7nW55i+AM5jZXwerhLZeFDLXIJteun03o6enywtIErud3 Xc1aYLQQMxe65ENhJt67jduPPfcJSZaRywvmaSsiQ1KTqVNYR/aYwwmiODbxOtL9fjfw M2xEfrwL++iw5hmUgxpWa/QKEdy8S+OYjg0GherFysALKAMWySQQd5TAxphozS5R2XV1 /UGowWUGyB1QVTSe5LwnGgfMixCkWmFSLMEwdYyqdzsgrXOqVMASF7AB76Mg5RCGmflW cw4A== MIME-Version: 1.0 X-Received: by 10.194.171.198 with SMTP id aw6mr40121070wjc.3.1360048568488; Mon, 04 Feb 2013 23:16:08 -0800 (PST) Received: by 10.195.12.163 with HTTP; Mon, 4 Feb 2013 23:16:08 -0800 (PST) In-Reply-To: <1105316997.2683638.1360023230093.JavaMail.root@erie.cs.uoguelph.ca> References: <1105316997.2683638.1360023230093.JavaMail.root@erie.cs.uoguelph.ca> Date: Tue, 5 Feb 2013 10:16:08 +0300 Message-ID: Subject: Re: panic: LK_RETRY set with incompatible flags From: Sergey Kandaurov To: Rick Macklem Content-Type: text/plain; charset=ISO-8859-1 Cc: Konstantin Belousov , FreeBSD Current , Andriy Gapon X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 05 Feb 2013 07:16:10 -0000 On 5 February 2013 04:13, Rick Macklem wrote: > Sergey Kandaurov wrote: >> On 4 February 2013 06:32, Rick Macklem wrote: >> > Konstantin Belousov wrote: >> >> On Sat, Feb 02, 2013 at 09:30:39PM -0500, Rick Macklem wrote: >> >> > Andriy Gapon wrote: >> >> > > on 31/01/2013 15:29 Sergey Kandaurov said the following: >> >> > > > Hi. >> >> > > > >> >> > > > Got this assertion on idle NFS server while `ls -la >> >> > > > /.zfs/shares/' >> >> > > > issued on NFS client. >> > Ok, here's a snippet of zfs_dirlook() from zfs_dir.c: >> > 388 } else if (name[0] == '.' && name[1] == '.' && name[2] == 0) { >> > 389 zfsvfs_t *zfsvfs = dzp->z_zfsvfs; >> > 390 >> > 391 /* >> > 392 * If we are a snapshot mounted under .zfs, return >> > 393 * the vp for the snapshot directory. >> > 394 */ >> > 395 if ((error = sa_lookup(dzp->z_sa_hdl, >> > 396 SA_ZPL_PARENT(zfsvfs), &parent, sizeof (parent))) != 0) >> > 397 return (error); >> > 398 if (parent == dzp->z_id && zfsvfs->z_parent != zfsvfs) { >> > 399 error = zfsctl_root_lookup(zfsvfs->z_parent->z_ctldir, >> > 400 "snapshot", vpp, NULL, 0, NULL, kcred, >> > 401 NULL, NULL, NULL); >> > 402 return (error); >> > 403 } >> > >> > Just reading the comment, I don't know what it is referring to by >> > "snapshot directory". Would that be "shares" for Sergey's case? >> > >> > It seems too obvious, but maybe the lookup of ".." is returning the >> > vnode for /.zfs/shares for this case? >> > >> > I don't know why this wouldn't have shown up before, but maybe it >> > usually >> > replies from its cache (I think zfs_lookup() calls it a "fast >> > path"). >> > >> > It might still be interesting to replace zfs_vnops.c line# 1451 >> > with: >> > if ((cnp->cn_flags & ISDOTDOT) && *vpp != dvp) >> > and see what happens? >> > >> >> With this change `ls /home/user1001/.zfs/shares/' lists empty >> directory >> (although the relevant dataset has snapshot, but that's a different >> story :)). >> Great! >> Nothing panics/asserts/etc, just seemingly unrelated LOR >> > Yes, I think the patch is relatively safe, since lookup() checks for > same vnode and does a vrele() instead of a vput() when they are the same, > at least for a plain lookup without wantparent. > > So, since I've never used ZFS, what does a "ls -la /home/user1001/.zfs/shares/" > give you when done locally one the server? On server (with unmodified kernel): # ls -la /pool1/user1001/.zfs/share total 2 dr-xr-xr-x 2 root wheel 2 Feb 2 20:06 . dr-xr-xr-x 4 root wheel 4 Feb 2 20:06 .. It crashes only when .zfs/share is accessed via NFS (with and without snapshots), and not when accessed locally. -- wbr, pluknet From owner-freebsd-current@FreeBSD.ORG Tue Feb 5 20:46:50 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 2DF215DC for ; Tue, 5 Feb 2013 20:46:50 +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 EB93877D for ; Tue, 5 Feb 2013 20:46:49 +0000 (UTC) Received: from pakbsde14.localnet (unknown [38.105.238.108]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id CED5BB91A for ; Tue, 5 Feb 2013 15:46:48 -0500 (EST) From: John Baldwin To: current@freebsd.org Subject: [PATCH] open_memstream() and open_wmemstream() Date: Tue, 5 Feb 2013 15:46:43 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p22; KDE/4.5.5; amd64; ; ) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201302051546.43839.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 05 Feb 2013 15:46:48 -0500 (EST) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 05 Feb 2013 20:46:50 -0000 I've written an implementation of open_memstream() and open_wmemstream() along with a set of regression tests. I'm pretty sure open_memstream() is correct, and I believe open_wmemstream() is correct for expected usage. The latter might even do the right thing if you split a multi-byte character across multiple writes. One question I have is if my choice to discard any pending multi-byte state in the stream anytime a seek changes the effective position in the output stream. I think this is correct as stdio will flush any pending data before doing a seek, so if there is a partially parsed character we aren't going to get the rest of it. http://www.FreeBSD.org/~jhb/patches/open_memstream.patch -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Wed Feb 6 01:30:03 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 81EDE16B; Wed, 6 Feb 2013 01:30:03 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.net.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 3772F338; Wed, 6 Feb 2013 01:30:03 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAEAByxEVGDaFvO/2dsb2JhbABFhki5OHOCHwEBAQQBAQEgBCcgCxsOCgICDRkCKQEJJgYIBwQBHASHcAyoNYJAkBeBI4wAgyWBEwOIZosJgjKBHYg4hn2DHIFRNQ X-IronPort-AV: E=Sophos;i="4.84,612,1355115600"; d="scan'208";a="12632084" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu.net.uoguelph.ca with ESMTP; 05 Feb 2013 20:30:02 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 67A04B3F14; Tue, 5 Feb 2013 20:30:02 -0500 (EST) Date: Tue, 5 Feb 2013 20:30:02 -0500 (EST) From: Rick Macklem To: Sergey Kandaurov Message-ID: <1283189660.2731919.1360114202411.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: Subject: Re: panic: LK_RETRY set with incompatible flags MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.203] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: Konstantin Belousov , FreeBSD Current , Andriy Gapon X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 06 Feb 2013 01:30:03 -0000 Sergey Kandaurov wrote: > On 5 February 2013 04:13, Rick Macklem wrote: > > Sergey Kandaurov wrote: > >> On 4 February 2013 06:32, Rick Macklem > >> wrote: > >> > Konstantin Belousov wrote: > >> >> On Sat, Feb 02, 2013 at 09:30:39PM -0500, Rick Macklem wrote: > >> >> > Andriy Gapon wrote: > >> >> > > on 31/01/2013 15:29 Sergey Kandaurov said the following: > >> >> > > > Hi. > >> >> > > > > >> >> > > > Got this assertion on idle NFS server while `ls -la > >> >> > > > /.zfs/shares/' > >> >> > > > issued on NFS client. > >> > Ok, here's a snippet of zfs_dirlook() from zfs_dir.c: > >> > 388 } else if (name[0] == '.' && name[1] == '.' && name[2] == 0) > >> > { > >> > 389 zfsvfs_t *zfsvfs = dzp->z_zfsvfs; > >> > 390 > >> > 391 /* > >> > 392 * If we are a snapshot mounted under .zfs, return > >> > 393 * the vp for the snapshot directory. > >> > 394 */ > >> > 395 if ((error = sa_lookup(dzp->z_sa_hdl, > >> > 396 SA_ZPL_PARENT(zfsvfs), &parent, sizeof (parent))) != 0) > >> > 397 return (error); > >> > 398 if (parent == dzp->z_id && zfsvfs->z_parent != zfsvfs) { > >> > 399 error = zfsctl_root_lookup(zfsvfs->z_parent->z_ctldir, > >> > 400 "snapshot", vpp, NULL, 0, NULL, kcred, > >> > 401 NULL, NULL, NULL); > >> > 402 return (error); > >> > 403 } > >> > > >> > Just reading the comment, I don't know what it is referring to by > >> > "snapshot directory". Would that be "shares" for Sergey's case? > >> > > >> > It seems too obvious, but maybe the lookup of ".." is returning > >> > the > >> > vnode for /.zfs/shares for this case? > >> > > >> > I don't know why this wouldn't have shown up before, but maybe it > >> > usually > >> > replies from its cache (I think zfs_lookup() calls it a "fast > >> > path"). > >> > > >> > It might still be interesting to replace zfs_vnops.c line# 1451 > >> > with: > >> > if ((cnp->cn_flags & ISDOTDOT) && *vpp != dvp) > >> > and see what happens? > >> > > >> > >> With this change `ls /home/user1001/.zfs/shares/' lists empty > >> directory > >> (although the relevant dataset has snapshot, but that's a different > >> story :)). > >> Great! > >> Nothing panics/asserts/etc, just seemingly unrelated LOR > >> > > Yes, I think the patch is relatively safe, since lookup() checks for > > same vnode and does a vrele() instead of a vput() when they are the > > same, > > at least for a plain lookup without wantparent. > > > > So, since I've never used ZFS, what does a "ls -la > > /home/user1001/.zfs/shares/" > > give you when done locally one the server? > > On server (with unmodified kernel): > # ls -la /pool1/user1001/.zfs/share > total 2 > dr-xr-xr-x 2 root wheel 2 Feb 2 20:06 . > dr-xr-xr-x 4 root wheel 4 Feb 2 20:06 .. > > It crashes only when .zfs/share is accessed via NFS > (with and without snapshots), and not when accessed locally. > I'm not surprised. If it crashed for local accesses, I would suspect people would have reported it much sooner. I also suspect it only happens for NFSv4 mounts, since those try and cross server mount points. Since I don't understand ZFS, I have just posted a query on freebsd-fs@, which I hope will get noticed by people who may know why ZFS is doing this. rick > -- > wbr, > pluknet > _______________________________________________ > 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 Feb 6 06:34:29 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 0CEB58D5 for ; Wed, 6 Feb 2013 06:34:29 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id C6A8E29 for ; Wed, 6 Feb 2013 06:34:28 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r166YLL3090386 for freebsd-current@freebsd.org; Wed, 6 Feb 2013 06:34:21 GMT (envelope-from kientzle@freebsd.org) Received: from [192.168.2.143] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id vz8qvujrqskzj3x8ycmuhdfmqe; for freebsd-current@freebsd.org; Wed, 06 Feb 2013 06:34:21 +0000 (UTC) (envelope-from kientzle@freebsd.org) From: Tim Kientzle Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: Cross-architecture package installs Date: Tue, 5 Feb 2013 22:34:18 -0800 Message-Id: <4703DEB0-E2DC-403E-9F14-DE968CBE4921@freebsd.org> To: freebsd-current Current Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 06 Feb 2013 06:34:29 -0000 I'm working on tools to build ARM system images. Usually, these tools run on x86, which creates a problem for packages. I would like to install packages onto the image as it's built. So I've been experimenting with variations of pkg -c add I'm running into a few problems but I think they can all be solved. Only the first is critical; the rest are relatively minor annoyances. 1) Pre-install/post-install scripts. These obviously don't work since the DESTDIR is for a different architecture. At least for post-install, it should be possible to record which packages still need their post-install scripts run and arrange to run them after first boot. I'm picturing an rc.d script that invokes pkg with appropriate options to find all packages that still need their post-install run and runs them. This won't work for pre-install, but those are rarer and we can hopefully work around them on a case-by-case basis. 2) The chroot happens before opening the package files. It's possible to work around this by copying all of the package files into DESTDIR first, but that's both time-consuming and rather awkward. (And quite tricky if you're installing directly onto a mounted image that has very little free space.) It should be feasible to open the package files first and then chroot. Then the actual installation still happens entirely inside DESTDIR. 3) Bogus "failed to install" messages. As far as I can tell, if "bar" depends on "foo", then "pkg add bar foo" will do this: Installing bar =85 Installing foo =85 done done Installing foo =85 foo already installed. Failed to install the following package: foo. This is surprising since foo did in fact get installed. In my case, I want to say "pkg add *" and just have it DTRT. It mostly does get the ordering right (I'm impressed!) but the error message is a bit odd. From owner-freebsd-current@FreeBSD.ORG Wed Feb 6 06:44:37 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 078DABF9 for ; Wed, 6 Feb 2013 06:44:37 +0000 (UTC) (envelope-from kolyasir@gmail.com) Received: from mail-qc0-f173.google.com (mail-qc0-f173.google.com [209.85.216.173]) by mx1.freebsd.org (Postfix) with ESMTP id 9D147E6 for ; Wed, 6 Feb 2013 06:44:36 +0000 (UTC) Received: by mail-qc0-f173.google.com with SMTP id b12so392134qca.4 for ; Tue, 05 Feb 2013 22:44:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=xQFEN19l7AzDIr83rLHGsOYg+sskAXGWQBks8mFO1DU=; b=EwTMkj9YQNLVZOB+HnWETh1H84hqePMRc9cYBtydm2m1C6A8BX6RdRjjFUKmqnrxF+ +FQ+ZAIFs/CukwGGoSSZSf+c9Hc8OHBw1845XyfTkeWrGDqYpPJnXuCxlcGpzQ4Hb8Dp w/pjCha4LxE1MkiD+NEkmg0Bv61a0LtFifjGrtHQ52VvAIQE0nV0SLVxqk7InAshZ4Rk 7od+uQ26JgGRWvAfWiNxSZM3AHuKsKaDgUGdZ1i5R3ffs1Scmc0PJq7gveop6ydIptv7 g4atPEkVWkdlDgz/sHcCmAKIelyATXtTYnZpv2Cr3TwbKrFO1KY5MJeEamKW0BkNNdf1 GsGg== MIME-Version: 1.0 X-Received: by 10.224.78.209 with SMTP id m17mr21258029qak.45.1360133070296; Tue, 05 Feb 2013 22:44:30 -0800 (PST) Received: by 10.49.71.232 with HTTP; Tue, 5 Feb 2013 22:44:30 -0800 (PST) Date: Wed, 6 Feb 2013 01:44:30 -0500 Message-ID: Subject: Need to test new patch of Ethernet Switch Framework From: Yasir hussan To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 06 Feb 2013 06:44:37 -0000 Hi, I saw a report that covers FreeBSD-related projects between October and December 2010 and I observe that it have new patch for Ethernet Switch Framework, I have also seen a little bit inside the code of patch( http://loos.no-ip.org/rspro/switch-1.diff). I downloaded fresh code of FreeBSD v9 and apply command git apply switch-1.diff but it shows me these errors: Code: switch.diff:397: trailing whitespace. printf("\tphy %d ", ifmr.ifm_phy); switch.diff:445: trailing whitespace. printb("options", ifswr.ifsw_flags, IFSWBITS); switch.diff:486: trailing whitespace. printf("\tvlans: "); switch.diff:869: trailing whitespace. } switch.diff:1826: trailing whitespace. } warning: sbin/ifconfig/Makefile has type 100755, expected 100644 error: patch failed: sbin/ifconfig/Makefile:23 error: sbin/ifconfig/Makefile: patch does not apply error: patch failed: sys/mips/atheros/ar71xx_machdep.c:144 error: sys/mips/atheros/ar71xx_machdep.c: patch does not apply error: patch failed: sys/mips/atheros/if_arge.c:565 error: sys/mips/atheros/if_arge.c: patch does not apply I am very interested to test this patch, can anyone help me out to do this... Thanks From owner-freebsd-current@FreeBSD.ORG Wed Feb 6 06:55:20 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 881FB137; Wed, 6 Feb 2013 06:55:20 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: from mail-ea0-f180.google.com (mail-ea0-f180.google.com [209.85.215.180]) by mx1.freebsd.org (Postfix) with ESMTP id 9FB0816F; Wed, 6 Feb 2013 06:55:19 +0000 (UTC) Received: by mail-ea0-f180.google.com with SMTP id c1so387522eaa.25 for ; Tue, 05 Feb 2013 22:55:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=WpLURna2Ixeo7onmSiJ0vov0wxbeNmMWog1a50aJvYE=; b=n/DZtZEpe4HXprsmaAnuFs5DoHdR1i25ZVD8hqhSUhTAJhfIB9jaFmdiNN+0fYWxg8 lKUy03mYJEalnBzllFuckP40RCpccZvoEhZB6dvYg/oUJ1memtPkrJ2tT8mynPyiUs0/ ysIQJWnDQTc0jdfwpCglyUy4i/iWkgo4IGldiuonXMEZ6hY16a41cubqRoOUkh4ZLymv AAG7OqiRwoGObPyzsdc4cQH1qrrVTplHOdw2sEt5QEfMq7yF7Y+E0PVoyHE5g337yUvC anhyaJwU/DjjmmEjHFLq/+8XQa9fBlD509dGafXYSTwp6SqmTu1rU1VNZwvuRqD3DZfj p0Ag== X-Received: by 10.14.173.69 with SMTP id u45mr93547261eel.21.1360133718147; Tue, 05 Feb 2013 22:55:18 -0800 (PST) Received: from ithaqua.etoilebsd.net (ithaqua.etoilebsd.net. [37.59.37.188]) by mx.google.com with ESMTPS id q42sm25885961eem.14.2013.02.05.22.55.16 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 05 Feb 2013 22:55:17 -0800 (PST) Sender: Baptiste Daroussin Date: Wed, 6 Feb 2013 07:55:15 +0100 From: Baptiste Daroussin To: Tim Kientzle Subject: Re: Cross-architecture package installs Message-ID: <20130206065514.GB1268@ithaqua.etoilebsd.net> References: <4703DEB0-E2DC-403E-9F14-DE968CBE4921@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tjCHc7DPkfUGtrlw" Content-Disposition: inline In-Reply-To: <4703DEB0-E2DC-403E-9F14-DE968CBE4921@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: pkg@FreeBSD.org, freebsd-current Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 06 Feb 2013 06:55:20 -0000 --tjCHc7DPkfUGtrlw Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Feb 05, 2013 at 10:34:18PM -0800, Tim Kientzle wrote: > I'm working on tools to build ARM system images. > Usually, these tools run on x86, which creates a problem > for packages. First Yes cross-installation of packages is something we highly want in pkg= ng and is plan since the beginning, that is one of the reason pkg -c is readig= the ABI from the DESTDIR, to make sure we only install things that are abi compatible.. >=20 > I would like to install packages onto the image as it's built. > So I've been experimenting with variations of > pkg -c add > I'm running into a few problems but I think they can all be > solved. Only the first is critical; the rest are relatively > minor annoyances. >=20 > 1) Pre-install/post-install scripts. >=20 > These obviously don't work since the DESTDIR > is for a different architecture. >=20 > At least for post-install, it should be possible to > record which packages still need their post-install > scripts run and arrange to run them after first > boot. I'm picturing an rc.d script that invokes pkg > with appropriate options to find all packages > that still need their post-install run and runs them. >=20 > This won't work for pre-install, but those are rarer > and we can hopefully work around them on a > case-by-case basis. This is imho the main problem, and one of the long term goal of pkgng is to= remove as much as possible any pre-instal/post-install scripts. The second problem= you will get into is the API that call system()/exec()/etc for example all the = call the pw_mkdb from libutil :( We are open for all suggestions here >=20 > 2) The chroot happens before opening the package files. >=20 > It's possible to work around this by copying all of the > package files into DESTDIR first, but that's both > time-consuming and rather awkward. (And quite > tricky if you're installing directly onto a mounted > image that has very little free space.) >=20 > It should be feasible to open the package files first > and then chroot. Then the actual installation still > happens entirely inside DESTDIR. In fact pkg add is only mean to be used in special case if in that particul= ar case you would have used pkg -c DESTDIR install using a repos= itory you would have created on your host using pkg repo to create the metadata t= hing necessary. problem your packagesite should served via a http/ftp not file e= xcept if the files are also locate inside the chroot. >=20 > 3) Bogus "failed to install" messages. >=20 > As far as I can tell, if "bar" depends on "foo", then > "pkg add bar foo" will do this: >=20 > Installing bar =E2=80=A6 > Installing foo =E2=80=A6 > done > done > Installing foo =E2=80=A6 foo already installed. Yeah as said above pkg add as to be forgotten as much as possible, it has b= een created mostly for the ports tree and the ports build script so that they d= on't need too much changes other that s/pkg_add/pkg add/g >=20 > Failed to install the following package: foo. >=20 > This is surprising since foo did in fact get installed. >=20 > In my case, I want to say "pkg add *" and just have > it DTRT. It mostly does get the ordering right (I'm impressed!) > but the error message is a bit odd. Just do "pkg install -x ." or "pkg install -g *" ordering would be ok witho= ut odd message. pkg add does not ordering, I'm surprised you got it right :) regards, Bapt PS: I CCed freebsd-pkg@, which is a new mailing list dedicated to this kind= of discussion --tjCHc7DPkfUGtrlw Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlER/lIACgkQ8kTtMUmk6EwWwwCeLQA2NF/FMU/MGDxCmBPZlhbf N/0AoLZ04bVsLLzY3qG4pGdmRYpLO8RC =tOn2 -----END PGP SIGNATURE----- --tjCHc7DPkfUGtrlw-- From owner-freebsd-current@FreeBSD.ORG Wed Feb 6 07:58:57 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 9BC428FB; Wed, 6 Feb 2013 07:58:57 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (pancho.soaustin.net [76.74.250.40]) by mx1.freebsd.org (Postfix) with ESMTP id 6D5C8618; Wed, 6 Feb 2013 07:58:57 +0000 (UTC) Received: by mail.soaustin.net (Postfix, from userid 502) id 8F96F56074; Wed, 6 Feb 2013 01:58:56 -0600 (CST) Date: Wed, 6 Feb 2013 01:58:56 -0600 From: Mark Linimon To: Tim Kientzle Subject: Re: Cross-architecture package installs Message-ID: <20130206075856.GA14482@lonesome.com> References: <4703DEB0-E2DC-403E-9F14-DE968CBE4921@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4703DEB0-E2DC-403E-9F14-DE968CBE4921@freebsd.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-current Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 06 Feb 2013 07:58:57 -0000 On Tue, Feb 05, 2013 at 10:34:18PM -0800, Tim Kientzle wrote: > I'm working on tools to build ARM system images. > Usually, these tools run on x86, which creates a problem > for packages. fwiw, before the intrusion 3 months ago, I had been able to build native ARM packages with a loaned system. Now, granted, this was pretty slow, but it was a useful reference point. Unfortunately none of the packages or logfiles are online at this time. When I was at MeetBSD in California, I learned that the Foundation is sponsoring an effort to get emulation for tier-2 machines in working order, and that this will be the plan for package building going forwards. This is just FYI so you don't spend a great deal of time on each individual port. I know the problems will be hard to solve. mcl From owner-freebsd-current@FreeBSD.ORG Wed Feb 6 09:14:31 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 8BEF015C for ; Wed, 6 Feb 2013 09:14:31 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id BAFDB989 for ; Wed, 6 Feb 2013 09:14:30 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id LAA13717; Wed, 06 Feb 2013 11:14:19 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1U3159-000IWn-4r; Wed, 06 Feb 2013 11:14:19 +0200 Message-ID: <51121EE8.3010906@FreeBSD.org> Date: Wed, 06 Feb 2013 11:14:16 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130121 Thunderbird/17.0.2 MIME-Version: 1.0 To: Rick Macklem Subject: Re: panic: LK_RETRY set with incompatible flags References: <1283189660.2731919.1360114202411.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <1283189660.2731919.1360114202411.JavaMail.root@erie.cs.uoguelph.ca> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Konstantin Belousov , Sergey Kandaurov , FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 06 Feb 2013 09:14:31 -0000 on 06/02/2013 03:30 Rick Macklem said the following: > Since I don't understand ZFS, I have just posted a query on > freebsd-fs@, which I hope will get noticed by people who > may know why ZFS is doing this. Actually I think I have an explanation, just been busy past couple of days. The problem is precisely with .zfs/shares, which is a strange beast that currently has no practical use on FreeBSD. .zfs/shares has its own on-disk node. The node has some special properties: - it is a directory node - it is not reachable from any other node - its parent ID is set to itself (as for a root node) - its ID is stored in a special filesystem property At run time ZFS creates special vnodes for .zfs, .zfs/snapshot and .zfs/shares. The vnodes are special is a sense that each of them has its own v_ops different from v_ops of the regular ZFS vnodes. For example, vop_lookup method of .zfs/shares should return the .zfs vnode for a ".." lookup. The v_ops are sane and self-consistent and everything is supposed to work fine with them and provide some ".zfs magic". Except for one hole. The .zfs/shares vnode has the same inode number as the on-disk node. Also, its vop_vptofh generates fid_t consistent with the on-disk node. Then, ZFS vfs_fhtovp has a special case to do the right thing for fid_t-s of .zfs and .zfs/snapshot. But for some reason there is no special code for .zfs/shares. And so a regular ZFS vnode is created/returned in that case. And this is the problem. Regular zfs_lookup for ".." in this vnode returns the vnode itself because of the magic properties described in the beginning. And so on. We seem to have inherited this problem from the upstream: http://thread.gmane.org/gmane.os.illumos.zfs/599 I believe that currently NFS is the only user of VOP_FID and VFS_FHTOVP. There are also getfh(2), lgetfh(2) and fhopen(2), but I am not sure how widely they are used. In either case, I believe that zfs_fhtovp should grow a check for object == zfsvfs->z_shares_dir and return the "made up" .zfs/shares vnode in that case (instead of a regular zfs vnode). Additionally, I am not sure, but perhaps zfs_vget() should do the same kind of tricks as zfs_fhtovp. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Wed Feb 6 13:20:27 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 1228A10A; Wed, 6 Feb 2013 13:20:27 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id C7977978; Wed, 6 Feb 2013 13:20:26 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.6/8.14.6) with ESMTP id r16DKPpl010177; Wed, 6 Feb 2013 06:20:26 -0700 (MST) (envelope-from ian@FreeBSD.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r16DKNsn033192; Wed, 6 Feb 2013 06:20:23 -0700 (MST) (envelope-from ian@FreeBSD.org) Subject: Re: Cross-architecture package installs From: Ian Lepore To: Tim Kientzle In-Reply-To: <4703DEB0-E2DC-403E-9F14-DE968CBE4921@freebsd.org> References: <4703DEB0-E2DC-403E-9F14-DE968CBE4921@freebsd.org> Content-Type: text/plain; charset="us-ascii" Date: Wed, 06 Feb 2013 06:20:22 -0700 Message-ID: <1360156822.93359.575.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-current Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 06 Feb 2013 13:20:27 -0000 On Tue, 2013-02-05 at 22:34 -0800, Tim Kientzle wrote: > I'm working on tools to build ARM system images. > Usually, these tools run on x86, which creates a problem > for packages. > > I would like to install packages onto the image as it's built. > So I've been experimenting with variations of > pkg -c add > > I'm running into a few problems but I think they can all be > solved. Only the first is critical; the rest are relatively > minor annoyances. > > 1) Pre-install/post-install scripts. > > These obviously don't work since the DESTDIR > is for a different architecture. > > At least for post-install, it should be possible to > record which packages still need their post-install > scripts run and arrange to run them after first > boot. I'm picturing an rc.d script that invokes pkg > with appropriate options to find all packages > that still need their post-install run and runs them. > > This won't work for pre-install, but those are rarer > and we can hopefully work around them on a > case-by-case basis. > > 2) The chroot happens before opening the package files. > > It's possible to work around this by copying all of the > package files into DESTDIR first, but that's both > time-consuming and rather awkward. (And quite > tricky if you're installing directly onto a mounted > image that has very little free space.) > > It should be feasible to open the package files first > and then chroot. Then the actual installation still > happens entirely inside DESTDIR. > If you have a directory full of the package files, you can nullfs-mount it within the chroot rather than copying its contents in. Nullfs mounts are great for crossing chroot barriers in such situations. Using them does make your scripts more complex, because you need abort and exit handling in the scripts to undo the mounts no matter what kind of exit the script encounters. If you don't, you end up leaving nullfs mounts that make later things fail (such as running the script again, or trying to clean/remove a chroot tree). -- Ian From owner-freebsd-current@FreeBSD.ORG Wed Feb 6 15:15:51 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A8EC2AF7; Wed, 6 Feb 2013 15:15:51 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.net.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 5FA7217D; Wed, 6 Feb 2013 15:15:50 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAEAHtyElGDaFvO/2dsb2JhbABFhki6EnOCHwEBAQMBAQEBIAQnIAsFFg4KAgINGQIpAQkmBggHBAEcBIdqBgypR5JdgSOMAIMlgRMDiGaLCYIygR2IOIZ9gxyBUTU X-IronPort-AV: E=Sophos;i="4.84,615,1355115600"; d="scan'208";a="12709974" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu.net.uoguelph.ca with ESMTP; 06 Feb 2013 10:15:49 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 574E6B3F4A; Wed, 6 Feb 2013 10:15:49 -0500 (EST) Date: Wed, 6 Feb 2013 10:15:49 -0500 (EST) From: Rick Macklem To: Andriy Gapon Message-ID: <1502349220.2745137.1360163749334.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <51121EE8.3010906@FreeBSD.org> Subject: Re: panic: LK_RETRY set with incompatible flags MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.201] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: Konstantin Belousov , Sergey Kandaurov , FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 06 Feb 2013 15:15:51 -0000 Andriy Gapon wrote: > on 06/02/2013 03:30 Rick Macklem said the following: > > Since I don't understand ZFS, I have just posted a query on > > freebsd-fs@, which I hope will get noticed by people who > > may know why ZFS is doing this. > > Actually I think I have an explanation, just been busy past couple of > days. > The problem is precisely with .zfs/shares, which is a strange beast > that > currently has no practical use on FreeBSD. > > .zfs/shares has its own on-disk node. The node has some special > properties: > - it is a directory node > - it is not reachable from any other node > - its parent ID is set to itself (as for a root node) > - its ID is stored in a special filesystem property > > At run time ZFS creates special vnodes for .zfs, .zfs/snapshot and > .zfs/shares. > The vnodes are special is a sense that each of them has its own v_ops > different > from v_ops of the regular ZFS vnodes. > For example, vop_lookup method of .zfs/shares should return the .zfs > vnode for a > ".." lookup. The v_ops are sane and self-consistent and everything is > supposed > to work fine with them and provide some ".zfs magic". > > Except for one hole. The .zfs/shares vnode has the same inode number > as the > on-disk node. Also, its vop_vptofh generates fid_t consistent with the > on-disk > node. > Then, ZFS vfs_fhtovp has a special case to do the right thing for > fid_t-s of > .zfs and .zfs/snapshot. But for some reason there is no special code > for > .zfs/shares. And so a regular ZFS vnode is created/returned in that > case. > > And this is the problem. > > Regular zfs_lookup for ".." in this vnode returns the vnode itself > because of > the magic properties described in the beginning. And so on. > > We seem to have inherited this problem from the upstream: > http://thread.gmane.org/gmane.os.illumos.zfs/599 > > I believe that currently NFS is the only user of VOP_FID and > VFS_FHTOVP. > There are also getfh(2), lgetfh(2) and fhopen(2), but I am not sure > how widely > they are used. > > In either case, I believe that zfs_fhtovp should grow a check for > object == > zfsvfs->z_shares_dir and return the "made up" .zfs/shares vnode in > that case > (instead of a regular zfs vnode). > Ok, great. Thanks for the good explanation. > Additionally, I am not sure, but perhaps zfs_vget() should do the same > kind of > tricks as zfs_fhtovp. > Well, zfs_vget() returns EOPNOTSUPP for .zfs, so the NFS server knows to switch over to using VOP_LOOKUP(). If the .zfs/snapshot and .zfs/share do the same thing, that should be fine, at least for the NFS server, I think. Thanks again for the explanation, rick > -- > Andriy Gapon > _______________________________________________ > 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 Feb 6 15:26:16 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 6A66C50B for ; Wed, 6 Feb 2013 15:26:16 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id B557526F for ; Wed, 6 Feb 2013 15:26:15 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id RAA17662; Wed, 06 Feb 2013 17:26:11 +0200 (EET) (envelope-from avg@FreeBSD.org) Message-ID: <51127612.8000305@FreeBSD.org> Date: Wed, 06 Feb 2013 17:26:10 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130206 Thunderbird/17.0.2 MIME-Version: 1.0 To: Rick Macklem Subject: Re: panic: LK_RETRY set with incompatible flags References: <1502349220.2745137.1360163749334.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <1502349220.2745137.1360163749334.JavaMail.root@erie.cs.uoguelph.ca> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Konstantin Belousov , Sergey Kandaurov , FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 06 Feb 2013 15:26:16 -0000 on 06/02/2013 17:15 Rick Macklem said the following: > Well, zfs_vget() returns EOPNOTSUPP for .zfs, so the NFS server knows to > switch over to using VOP_LOOKUP(). If the .zfs/snapshot and .zfs/share > do the same thing, that should be fine, at least for the NFS server, > I think. Ah, right, but again this is done only for .zfs and .zfs/snapshot. .zfs/shares is not special-cased and thus is problematic here too in the same fashion as zfs_fhtovp. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Wed Feb 6 23:20:22 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E5B07692 for ; Wed, 6 Feb 2013 23:20:22 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) by mx1.freebsd.org (Postfix) with ESMTP id 7F001256 for ; Wed, 6 Feb 2013 23:20:22 +0000 (UTC) Received: by mail-we0-f176.google.com with SMTP id s43so1536811wey.7 for ; Wed, 06 Feb 2013 15:20:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=IFmy7ngP5NYspd/b/mD4z0Japgvn8OAQPmA+9aPZ86E=; b=tewbRCP4aInrfx04OA9w+xdf7LPFp2rC8+pYl9KMVjFT0H3Cx+BVD5Kp7vy7W0IYWv eMZWstuKdM40FM58icqrWIJU7WV8wgza0qywHBdtILtqExup9QH4VvDZxMVtJEdGQxE8 OqgaTjEqUQi2lxKL+0VSPnmhOi4i0S5AKKwutNeshKC224imIX6wuZDUhCPTDNnuDlgg h7RiCRNvbfiTK3Ot/IJ1vUYDfb7REynKYJx8JMy3WxN1hxi0htg7yvryrpb/sOoo9OSb yygrrGq98yf4irUH7PAbdamoW3Xgb7UYhhwZ+V5JVq6Pm1Jad/DgT4zmYIwyiIToNKHZ AX3A== MIME-Version: 1.0 X-Received: by 10.180.101.98 with SMTP id ff2mr8303505wib.0.1360192821580; Wed, 06 Feb 2013 15:20:21 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.236.88 with HTTP; Wed, 6 Feb 2013 15:20:21 -0800 (PST) In-Reply-To: References: Date: Wed, 6 Feb 2013 15:20:21 -0800 X-Google-Sender-Auth: v2Es-ObGUGAYOjwGd6MJDj-rBqg Message-ID: Subject: Re: Need to test new patch of Ethernet Switch Framework From: Adrian Chadd To: Yasir hussan Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 06 Feb 2013 23:20:23 -0000 A switch framework made it into -HEAD. Adrian On 5 February 2013 22:44, Yasir hussan wrote: > Hi, > > I saw a report that covers FreeBSD-related projects between October and > December 2010 and I observe that it have new patch for Ethernet Switch > Framework, I have also seen a little bit inside the code of patch( > http://loos.no-ip.org/rspro/switch-1.diff). > > I downloaded fresh code of FreeBSD v9 and apply command git apply > switch-1.diff but it shows me these errors: > > Code: > > switch.diff:397: trailing whitespace. > printf("\tphy %d ", ifmr.ifm_phy); > switch.diff:445: trailing whitespace. > printb("options", ifswr.ifsw_flags, IFSWBITS); > switch.diff:486: trailing whitespace. > printf("\tvlans: "); > switch.diff:869: trailing whitespace. > } > switch.diff:1826: trailing whitespace. > } > warning: sbin/ifconfig/Makefile has type 100755, expected 100644 > error: patch failed: sbin/ifconfig/Makefile:23 > error: sbin/ifconfig/Makefile: patch does not apply > error: patch failed: sys/mips/atheros/ar71xx_machdep.c:144 > error: sys/mips/atheros/ar71xx_machdep.c: patch does not apply > error: patch failed: sys/mips/atheros/if_arge.c:565 > error: sys/mips/atheros/if_arge.c: patch does not apply > > I am very interested to test this patch, can anyone help me out to do > this... > > Thanks > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Thu Feb 7 02:13:14 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 8B4F8FAE; Thu, 7 Feb 2013 02:13:14 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 40B04ACB; Thu, 7 Feb 2013 02:13:13 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAEAP4LE1GDaFvO/2dsb2JhbABFhkm2MoNrc4IfAQEFIwRSGw4KERkCBFUGiCSqP5JEkEaBEwOIZoYthw6JVYZ9gxyCBg X-IronPort-AV: E=Sophos;i="4.84,619,1355115600"; d="scan'208";a="15437100" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 06 Feb 2013 21:13:07 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 5E22CB40BB; Wed, 6 Feb 2013 21:13:07 -0500 (EST) Date: Wed, 6 Feb 2013 21:13:07 -0500 (EST) From: Rick Macklem To: Andriy Gapon Message-ID: <1137922035.2777364.1360203187367.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <51127612.8000305@FreeBSD.org> Subject: Re: panic: LK_RETRY set with incompatible flags MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_2777363_1983939593.1360203187359" X-Originating-IP: [172.17.91.203] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: Konstantin Belousov , Sergey Kandaurov , FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 07 Feb 2013 02:13:14 -0000 ------=_Part_2777363_1983939593.1360203187359 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Andriy Gapon wrote: > on 06/02/2013 17:15 Rick Macklem said the following: > > Well, zfs_vget() returns EOPNOTSUPP for .zfs, so the NFS server > > knows to > > switch over to using VOP_LOOKUP(). If the .zfs/snapshot and > > .zfs/share > > do the same thing, that should be fine, at least for the NFS server, > > I think. > > Ah, right, but again this is done only for .zfs and .zfs/snapshot. > .zfs/shares is not special-cased and thus is problematic here too in > the same > fashion as zfs_fhtovp. > Well, I have no way to test this, but maybe the attached patch is a start in the right direction. Maybe you can take a look at it and/or Sergey could test it? Thanks for all your help with this, rick > -- > Andriy Gapon ------=_Part_2777363_1983939593.1360203187359 Content-Type: text/x-patch; name=zfs-shares.patch Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=zfs-shares.patch LS0tIGNkZGwvY29udHJpYi9vcGVuc29sYXJpcy91dHMvY29tbW9uL2ZzL3pmcy96ZnNfdmZzb3Bz LmMuc2F2CTIwMTMtMDItMDYgMTk6Mzg6NDEuMDAwMDAwMDAwIC0wNTAwCisrKyBjZGRsL2NvbnRy aWIvb3BlbnNvbGFyaXMvdXRzL2NvbW1vbi9mcy96ZnMvemZzX3Zmc29wcy5jCTIwMTMtMDItMDYg MjA6MDY6MzguMDAwMDAwMDAwIC0wNTAwCkBAIC0yMDA5LDcgKzIwMDksOCBAQCB6ZnNfdmdldCh2 ZnNfdCAqdmZzcCwgaW5vX3QgaW5vLCBpbnQgZmxhCiAJICogLnpmcy9zbmFwc2hvdC8gZGlyZWN0 b3JpZXMsIHRoYXQncyB3aHkgd2UgcmV0dXJuIEVPUE5PVFNVUFAuCiAJICogVGhpcyB3aWxsIG1h a2UgTkZTIHRvIHN3aXRjaCB0byBMT09LVVAgaW5zdGVhZCBvZiB1c2luZyBWR0VULgogCSAqLwot CWlmIChpbm8gPT0gWkZTQ1RMX0lOT19ST09UIHx8IGlubyA9PSBaRlNDVExfSU5PX1NOQVBESVIp CisJaWYgKGlubyA9PSBaRlNDVExfSU5PX1JPT1QgfHwgaW5vID09IFpGU0NUTF9JTk9fU05BUERJ UiB8fAorCSAgICBpbm8gPT0gemZzdmZzLT56X3NoYXJlc19kaXIpCiAJCXJldHVybiAoRU9QTk9U U1VQUCk7CiAKIAlaRlNfRU5URVIoemZzdmZzKTsKQEAgLTIwOTksMTQgKzIxMDAsMjIgQEAgemZz X2ZodG92cCh2ZnNfdCAqdmZzcCwgZmlkX3QgKmZpZHAsIGludAogCQlyZXR1cm4gKEVJTlZBTCk7 CiAJfQogCi0JLyogQSB6ZXJvIGZpZF9nZW4gbWVhbnMgd2UgYXJlIGluIHRoZSAuemZzIGNvbnRy b2wgZGlyZWN0b3JpZXMgKi8KLQlpZiAoZmlkX2dlbiA9PSAwICYmCi0JICAgIChvYmplY3QgPT0g WkZTQ1RMX0lOT19ST09UIHx8IG9iamVjdCA9PSBaRlNDVExfSU5PX1NOQVBESVIpKSB7CisJLyoK KwkgKiBBIHplcm8gZmlkX2dlbiBtZWFucyB3ZSBhcmUgaW4gLnpmcyBvciB0aGUgLnpmcy9zbmFw c2hvdAorCSAqIGRpcmVjdG9yeSB0cmVlLiBJZiB0aGUgb2JqZWN0ID09IHpmc3Zmcy0+el9zaGFy ZXNfZGlyLCB0aGVuCisJICogd2UgYXJlIGluIHRoZSAuemZzL3NoYXJlcyBkaXJlY3RvcnkgdHJl ZS4KKwkgKi8KKwlpZiAoKGZpZF9nZW4gPT0gMCAmJgorCSAgICAgKG9iamVjdCA9PSBaRlNDVExf SU5PX1JPT1QgfHwgb2JqZWN0ID09IFpGU0NUTF9JTk9fU05BUERJUikpIHx8CisJICAgIG9iamVj dCA9PSB6ZnN2ZnMtPnpfc2hhcmVzX2RpcikgewogCQkqdnBwID0gemZzdmZzLT56X2N0bGRpcjsK IAkJQVNTRVJUKCp2cHAgIT0gTlVMTCk7CiAJCWlmIChvYmplY3QgPT0gWkZTQ1RMX0lOT19TTkFQ RElSKSB7CiAJCQlWRVJJRlkoemZzY3RsX3Jvb3RfbG9va3VwKCp2cHAsICJzbmFwc2hvdCIsIHZw cCwgTlVMTCwKIAkJCSAgICAwLCBOVUxMLCBOVUxMLCBOVUxMLCBOVUxMLCBOVUxMKSA9PSAwKTsK KwkJfSBlbHNlIGlmIChvYmplY3QgPT0gemZzdmZzLT56X3NoYXJlc19kaXIpIHsKKwkJCVZFUklG WSh6ZnNjdGxfcm9vdF9sb29rdXAoKnZwcCwgInNoYXJlcyIsIHZwcCwgTlVMTCwKKwkJCSAgICAw LCBOVUxMLCBOVUxMLCBOVUxMLCBOVUxMLCBOVUxMKSA9PSAwKTsKIAkJfSBlbHNlIHsKIAkJCVZO X0hPTEQoKnZwcCk7CiAJCX0K ------=_Part_2777363_1983939593.1360203187359-- From owner-freebsd-current@FreeBSD.ORG Thu Feb 7 02:32:58 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 5BF0F4BB; Thu, 7 Feb 2013 02:32:58 +0000 (UTC) (envelope-from kientzle@FreeBSD.org) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id F066CBD9; Thu, 7 Feb 2013 02:32:54 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r172WsPY096226; Thu, 7 Feb 2013 02:32:54 GMT (envelope-from kientzle@FreeBSD.org) Received: from [192.168.2.143] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id 3sukwci2ei6nutm77ztf99brns; Thu, 07 Feb 2013 02:32:54 +0000 (UTC) (envelope-from kientzle@FreeBSD.org) Subject: Re: Cross-architecture package installs Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/signed; boundary="Apple-Mail=_8C6A3E66-BC58-4C99-AC56-2A77AEEB7BCE"; protocol="application/pgp-signature"; micalg=pgp-sha1 From: Tim Kientzle In-Reply-To: <20130206065514.GB1268@ithaqua.etoilebsd.net> Date: Wed, 6 Feb 2013 18:32:53 -0800 Message-Id: <1004D96B-38AF-43FA-8BE0-49046D9446E2@FreeBSD.org> References: <4703DEB0-E2DC-403E-9F14-DE968CBE4921@freebsd.org> <20130206065514.GB1268@ithaqua.etoilebsd.net> To: Baptiste Daroussin X-Mailer: Apple Mail (2.1283) Cc: pkg@FreeBSD.org, freebsd-current Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 07 Feb 2013 02:32:58 -0000 --Apple-Mail=_8C6A3E66-BC58-4C99-AC56-2A77AEEB7BCE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Feb 5, 2013, at 10:55 PM, Baptiste Daroussin wrote: > On Tue, Feb 05, 2013 at 10:34:18PM -0800, Tim Kientzle wrote: >> I'm working on tools to build ARM system images. >> Usually, these tools run on x86, which creates a problem >> for packages. >=20 >> 1) Pre-install/post-install scripts. >>=20 >> These obviously don't work since the DESTDIR >> is for a different architecture. > This is imho the main problem, and one of the long term goal of pkgng = is to remove as much as possible any pre-instal/post-install scripts. Here's an approach that would handle post-install fairly graciously in this case. I'll presume you're cross-building from x86 to ARM in this example: * On x86, run "pkg -c $ARMSYS install " * During install, record the post-install scripts in the package database but don't run them. * When the ARM system is first booted, an rc.d script runs "pkg finish" (or "pkg install --some-option" if you prefer) "pkg finish" finds the post-install scripts that have not yet been run and runs them. This way, the post-install scripts always run on the native architecture. This won't work for pre-install scripts, of course. > The second problem you > will get into is the API that call system()/exec()/etc for example all = the call > the pw_mkdb from libutil :( >=20 > We are open for all suggestions here A "first boot fixup" as above might handle some of these cases. (Instead of running these commands immediately, register them to run on next boot.) For others, I think the only feasible option is to identify them and get people to help push the necessary functionality into libraries. Tim --Apple-Mail=_8C6A3E66-BC58-4C99-AC56-2A77AEEB7BCE Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) iQEcBAEBAgAGBQJRExJVAAoJEGMNyGo0rfFB+0wH+weesTJ4K1bguEfei4OJLPCx empmVuDoPXdRvQN7c8RSfUJVB+9mcBVeknCcQj3gISvqd3BE7uW5kJPXg5wNZfzG wTVQAR/olntYEtDbuT36Nsa4xTlFtnpyd7QEzTjqqfnkCX+/Izs7MO4tOLkcqtK+ boa+ny2zqWIPlZszDj5c2XoTHWZBjZY8mBBh/Lami1Ee15Qivies2S5VRzD+aYCb p9affOExpfWu0UTyRvlfCiv+c7u5kja91d1bXkDLsVZOXeMlcU+CDslz52CyFVu3 hgfVcqG+nnbI4t14ScRQ3AYPhjkwDqJ3/RO5q1S459NTHLV81pqjz/RnIyI/Gyw= =yFPx -----END PGP SIGNATURE----- --Apple-Mail=_8C6A3E66-BC58-4C99-AC56-2A77AEEB7BCE-- From owner-freebsd-current@FreeBSD.ORG Thu Feb 7 13:43:49 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 70F8CEAA for ; Thu, 7 Feb 2013 13:43:49 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id BBF8AEFC for ; Thu, 7 Feb 2013 13:43:48 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id PAA29282; Thu, 07 Feb 2013 15:43:37 +0200 (EET) (envelope-from avg@FreeBSD.org) Message-ID: <5113AF89.4070303@FreeBSD.org> Date: Thu, 07 Feb 2013 15:43:37 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130206 Thunderbird/17.0.2 MIME-Version: 1.0 To: Rick Macklem Subject: Re: panic: LK_RETRY set with incompatible flags References: <1137922035.2777364.1360203187367.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <1137922035.2777364.1360203187367.JavaMail.root@erie.cs.uoguelph.ca> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Konstantin Belousov , Sergey Kandaurov , FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 07 Feb 2013 13:43:49 -0000 on 07/02/2013 04:13 Rick Macklem said the following: > Andriy Gapon wrote: >> on 06/02/2013 17:15 Rick Macklem said the following: >>> Well, zfs_vget() returns EOPNOTSUPP for .zfs, so the NFS server >>> knows to >>> switch over to using VOP_LOOKUP(). If the .zfs/snapshot and >>> .zfs/share >>> do the same thing, that should be fine, at least for the NFS server, >>> I think. >> >> Ah, right, but again this is done only for .zfs and .zfs/snapshot. >> .zfs/shares is not special-cased and thus is problematic here too in >> the same >> fashion as zfs_fhtovp. >> > Well, I have no way to test this, but maybe the attached patch is a > start in the right direction. > > Maybe you can take a look at it and/or Sergey could test it? > > Thanks for all your help with this, rick Rick, the patch looks 99% percent good to me :-) I am not sure if I am overly paranoid here, but I would add a check for zfsvfs->z_shares_dir being non-zero before comparing anything with it. I am also not sure if doing actual zfs_zget only to check zp_gen != fid_gen or z_unlinked is required. Probably not. Sergey, could you please test Rick's patch? -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Thu Feb 7 14:18:37 2013 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1E0E7868; Thu, 7 Feb 2013 14:18:37 +0000 (UTC) (envelope-from uqs@FreeBSD.org) Received: from acme.spoerlein.net (acme.spoerlein.net [IPv6:2a01:4f8:131:23c2::1]) by mx1.freebsd.org (Postfix) with ESMTP id 8FB5A12B; Thu, 7 Feb 2013 14:18:36 +0000 (UTC) Received: from localhost (acme.spoerlein.net [IPv6:2a01:4f8:131:23c2::1]) by acme.spoerlein.net (8.14.6/8.14.6) with ESMTP id r17EIXFv016138 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 7 Feb 2013 15:18:33 +0100 (CET) (envelope-from uqs@FreeBSD.org) Date: Thu, 7 Feb 2013 15:18:33 +0100 From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= To: current@FreeBSD.org, pjd@FreeBSD.org Subject: geli(8) breaks after a couple hours of uptime Message-ID: <20130207141833.GA15884@acme.spoerlein.net> Mail-Followup-To: current@FreeBSD.org, pjd@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 07 Feb 2013 14:18:37 -0000 Yes, it's pretty much as weird as it sounds. All new machine, forklifted the image from on old i386 machine running 8.x to current on amd64. Everything seemingly works fine, attaching geli volumes shortly after boot is fine, attached devices continue to work fine. There are no strange crashes with this machine or anything, but when I try to attach an USB volume the next day, geli attach segfaults. This seems unrelated to USB however, as the same happens for md(4) devices. % geli status Name Status Components gpt/swap.eli ACTIVE gpt/swap ada1.eli ACTIVE ada1 These all work fine, so I've rebuild geli with debugging symbols and when you run geli init md1: root@coyote:/usr/src/sbin/geom/class/eli# gdb geli 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"...(no debugging symbols found)... (gdb) r init md1 Starting program: /sbin/geli init md1 (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)... Program received signal SIGSEGV, Segmentation fault. 0x0000000801c06307 in eli_genkey (req=0x801817040, md=0x7fffffff85c8, key=0x7fffffff9de0 "", new=true) at /usr/src/sbin/geom/class/eli/geom_eli.c:546 546 { Current language: auto; currently minimal (gdb) bt #0 0x0000000801c06307 in eli_genkey (req=0x801817040, md=0x7fffffff85c8, key=0x7fffffff9de0 "", new=true) at /usr/src/sbin/geom/class/eli/geom_eli.c:546 #1 0x0000000801c054a4 in eli_main (req=0x801817040, flags=) at /usr/src/sbin/geom/class/eli/geom_eli.c:820 #2 0x000000000040298f in main () (gdb) l 818 813 } 814 815 md.md_keys = 0x01; 816 arc4rand(md.md_salt, sizeof(md.md_salt)); 817 arc4rand(md.md_mkeys, sizeof(md.md_mkeys)); 818 819 /* Generate user key. */ 820 if (eli_genkey(req, &md, key, true) == NULL) { 821 bzero(key, sizeof(key)); 822 bzero(&md, sizeof(md)); hu? Uli From owner-freebsd-current@FreeBSD.ORG Thu Feb 7 14:37:45 2013 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 28C46D3D; Thu, 7 Feb 2013 14:37:45 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.29.23]) by mx1.freebsd.org (Postfix) with ESMTP id DB28C2AE; Thu, 7 Feb 2013 14:37:44 +0000 (UTC) Received: from [78.35.161.30] (helo=fabiankeil.de) by smtprelay01.ispgateway.de with esmtpsa (SSLv3:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1U3SbZ-0003L6-Gi; Thu, 07 Feb 2013 15:37:37 +0100 Date: Thu, 7 Feb 2013 15:33:22 +0100 From: Fabian Keil To: Ulrich =?UTF-8?B?U3DDtnJsZWlu?= Subject: Re: geli(8) breaks after a couple hours of uptime Message-ID: <20130207153322.5c371beb@fabiankeil.de> In-Reply-To: <20130207141833.GA15884@acme.spoerlein.net> References: <20130207141833.GA15884@acme.spoerlein.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_//qz5fUG3uxll6e=GiQwnUoM"; protocol="application/pgp-signature" X-Df-Sender: Nzc1MDY3 Cc: current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 07 Feb 2013 14:37:45 -0000 --Sig_//qz5fUG3uxll6e=GiQwnUoM Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Ulrich Sp=C3=B6rlein wrote: > Yes, it's pretty much as weird as it sounds. All new machine, forklifted > the image from on old i386 machine running 8.x to current on amd64. >=20 > Everything seemingly works fine, attaching geli volumes shortly after > boot is fine, attached devices continue to work fine. There are no > strange crashes with this machine or anything, but when I try to attach > an USB volume the next day, geli attach segfaults. This could be: http://www.freebsd.org/cgi/query-pr.cgi?pr=3D174831 Fabian --Sig_//qz5fUG3uxll6e=GiQwnUoM Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlETuzYACgkQBYqIVf93VJ1gxQCeNfgWU91z6sCm61NvQjLrg5Bz lKUAn1tga5w/1UY1rmF8a/BZTM49LQNC =v55K -----END PGP SIGNATURE----- --Sig_//qz5fUG3uxll6e=GiQwnUoM-- From owner-freebsd-current@FreeBSD.ORG Thu Feb 7 15:04:26 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 15F3E1DD; Thu, 7 Feb 2013 15:04:26 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.net.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id BFD2163C; Thu, 7 Feb 2013 15:04:25 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAEAGnBE1GDaFvO/2dsb2JhbABFhkm6M3OCHwEBAQMBAQEBIAQnIAsFFg4KAgINGQIpAQkmBggHBAEcBIdqBgysIpJXgSOMAYMlgRMDiGaLCYIygR2IOIZ9gx6BUTU X-IronPort-AV: E=Sophos;i="4.84,622,1355115600"; d="scan'208";a="12895953" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu.net.uoguelph.ca with ESMTP; 07 Feb 2013 10:04:24 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 9901EB3F43; Thu, 7 Feb 2013 10:04:24 -0500 (EST) Date: Thu, 7 Feb 2013 10:04:24 -0500 (EST) From: Rick Macklem To: Andriy Gapon Message-ID: <236652418.2788560.1360249464612.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <5113AF89.4070303@FreeBSD.org> Subject: Re: panic: LK_RETRY set with incompatible flags MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.202] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: Konstantin Belousov , Sergey Kandaurov , FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 07 Feb 2013 15:04:26 -0000 Andriy Gapon wrote: > on 07/02/2013 04:13 Rick Macklem said the following: > > Andriy Gapon wrote: > >> on 06/02/2013 17:15 Rick Macklem said the following: > >>> Well, zfs_vget() returns EOPNOTSUPP for .zfs, so the NFS server > >>> knows to > >>> switch over to using VOP_LOOKUP(). If the .zfs/snapshot and > >>> .zfs/share > >>> do the same thing, that should be fine, at least for the NFS > >>> server, > >>> I think. > >> > >> Ah, right, but again this is done only for .zfs and .zfs/snapshot. > >> .zfs/shares is not special-cased and thus is problematic here too > >> in > >> the same > >> fashion as zfs_fhtovp. > >> > > Well, I have no way to test this, but maybe the attached patch is a > > start in the right direction. > > > > Maybe you can take a look at it and/or Sergey could test it? > > > > Thanks for all your help with this, rick > > Rick, > the patch looks 99% percent good to me :-) > I am not sure if I am overly paranoid here, but I would add a check > for > zfsvfs->z_shares_dir being non-zero before comparing anything with it. Yes, I think checking that it is non-zero sounds like a good idea. > I am also not sure if doing actual zfs_zget only to check zp_gen != > fid_gen or > z_unlinked is required. Probably not. > I don't think so, either. At least w.r.t. NFS, all the generation # does is check for a recycled i-node. The other thing I wondered about is "can zfsvfs->z_shares_dir ever not fit in 32bits?". I notice it is a uint64_t, but ino_t is still 32bits for FreeBSD. If it didn't fit in 32bits, the check in zfs_vget() wouldn't work. (I have a hunch that, for now, the ZFS code doesn't exceed 32bit fids, but haven't looked at the code to try and see. I'll take a closer look at that, too.) Thanks for looking at it, rick > Sergey, > could you please test Rick's patch? > > -- > Andriy Gapon > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Thu Feb 7 15:25:29 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C9330D3F for ; Thu, 7 Feb 2013 15:25:29 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 0415782C for ; Thu, 7 Feb 2013 15:25:28 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id RAA00509; Thu, 07 Feb 2013 17:25:25 +0200 (EET) (envelope-from avg@FreeBSD.org) Message-ID: <5113C764.4010902@FreeBSD.org> Date: Thu, 07 Feb 2013 17:25:24 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130206 Thunderbird/17.0.2 MIME-Version: 1.0 To: Rick Macklem Subject: Re: panic: LK_RETRY set with incompatible flags References: <236652418.2788560.1360249464612.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <236652418.2788560.1360249464612.JavaMail.root@erie.cs.uoguelph.ca> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Konstantin Belousov , Sergey Kandaurov , FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 07 Feb 2013 15:25:29 -0000 on 07/02/2013 17:04 Rick Macklem said the following: > The other thing I wondered about is "can zfsvfs->z_shares_dir ever not > fit in 32bits?". Usually it should be one of the first objects created in a new filesystem, so it should have a small ID (typically 7). > I notice it is a uint64_t, but ino_t is still 32bits for > FreeBSD. If it didn't fit in 32bits, the check in zfs_vget() wouldn't > work. (I have a hunch that, for now, the ZFS code doesn't exceed 32bit > fids, but haven't looked at the code to try and see. I'll take a closer > look at that, too.) As far as I understand, ZFS actually uses 48 bits for object IDs at the moment. Since they are generated incrementally they do not overflow 32 bits soon. But you are right that this is a potential problem as long as ino_t stays 32-bit. However, it seems that VFS_VGET is mostly used by filesystem drivers internally. And ZFS doesn't seem to do that. The only external user appears to be NFS. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Thu Feb 7 15:37:02 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 98BCE295; Thu, 7 Feb 2013 15:37:02 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) by mx1.freebsd.org (Postfix) with ESMTP id 09B768B6; Thu, 7 Feb 2013 15:37:01 +0000 (UTC) Received: by mail-wi0-f179.google.com with SMTP id ez12so3057607wid.0 for ; Thu, 07 Feb 2013 07:37:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=Xcm+HYzJKTba8U2Jc1g4rKNnfrYfLBOpr8V7xwquC04=; b=ltwwrH5K9mdSs0/2VkM13JXOl5VplqQNCXSbZUFfBNBo94BC8tz+ZgwbZVfTiCwNKd XdwlBLsGEt8SCO/s3w3hUFDpq4I18K3SN2qRghyjiwTHTWYRjoM8L+RqEcg6STF6DwYK yxVl8WtxWP9KQ5BC+DCtNuZk3hB2rZmUuZF5rAaX1quTt9eZw05hkMFXquj/i1mbp/7g dWUBiclw6mxXSTNtwQsw7fSy7+uVJEGsY6kXLT6gpDNnx5HAGbOERsOI0sOuo0lQo9bQ AgsFxgRKtLuqCzw76kCysfyhUVKOKhhdGPuLyeowIPO9kdv3hy+CTNb7PV2W4swjIPiq RbkA== MIME-Version: 1.0 X-Received: by 10.194.171.198 with SMTP id aw6mr3759489wjc.3.1360251406078; Thu, 07 Feb 2013 07:36:46 -0800 (PST) Received: by 10.195.12.163 with HTTP; Thu, 7 Feb 2013 07:36:45 -0800 (PST) In-Reply-To: <5113AF89.4070303@FreeBSD.org> References: <1137922035.2777364.1360203187367.JavaMail.root@erie.cs.uoguelph.ca> <5113AF89.4070303@FreeBSD.org> Date: Thu, 7 Feb 2013 18:36:45 +0300 Message-ID: Subject: Re: panic: LK_RETRY set with incompatible flags From: Sergey Kandaurov To: Andriy Gapon Content-Type: text/plain; charset=ISO-8859-1 Cc: Konstantin Belousov , Rick Macklem , FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 07 Feb 2013 15:37:02 -0000 On 7 February 2013 17:43, Andriy Gapon wrote: > on 07/02/2013 04:13 Rick Macklem said the following: >> Andriy Gapon wrote: >>> on 06/02/2013 17:15 Rick Macklem said the following: >>>> Well, zfs_vget() returns EOPNOTSUPP for .zfs, so the NFS server >>>> knows to >>>> switch over to using VOP_LOOKUP(). If the .zfs/snapshot and >>>> .zfs/share >>>> do the same thing, that should be fine, at least for the NFS server, >>>> I think. >>> >>> Ah, right, but again this is done only for .zfs and .zfs/snapshot. >>> .zfs/shares is not special-cased and thus is problematic here too in >>> the same >>> fashion as zfs_fhtovp. >>> >> Well, I have no way to test this, but maybe the attached patch is a >> start in the right direction. >> >> Maybe you can take a look at it and/or Sergey could test it? >> >> Thanks for all your help with this, rick > > Rick, > the patch looks 99% percent good to me :-) > I am not sure if I am overly paranoid here, but I would add a check for > zfsvfs->z_shares_dir being non-zero before comparing anything with it. > I am also not sure if doing actual zfs_zget only to check zp_gen != fid_gen or > z_unlinked is required. Probably not. > > Sergey, > could you please test Rick's patch? Hi Rick, Andriy. I tested the patch without the (*vpp != dvp) change. It works well. It's something unrelated but when doing ls -l on server (patched) and client (unpatched) sides, I found some inconsistency in returned stats. Or more precisely: NFS server # stat -s /pool1/user1000/.zfs/shares/.. st_dev=2050684725 st_ino=1 st_mode=040555 st_nlink=4 st_uid=0 st_gid=0 st_rdev=0 st_size=4 st_atime=1360251211 st_mtime=1359551493 st_ctime=1359551493 st_birthtime=1359551493 st_blksize=4096 st_blocks=0 st_flags=0 NFS client # stat -s /home/user1000/.zfs/shares/.. st_dev=2050684725 st_ino=7 st_mode=040555 st_nlink=2 st_uid=0 st_gid=0 st_rdev=1377468712 st_size=2 st_atime=1360251104 st_mtime=1359551493 st_ctime=1359551493 st_birthtime=-1 st_blksize=4096 st_blocks=3 st_flags=0 JFYI. -- wbr, pluknet From owner-freebsd-current@FreeBSD.ORG Thu Feb 7 15:42:48 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 6E06B73E for ; Thu, 7 Feb 2013 15:42:48 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 9AE6F910 for ; Thu, 7 Feb 2013 15:42:46 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id RAA00638; Thu, 07 Feb 2013 17:42:43 +0200 (EET) (envelope-from avg@FreeBSD.org) Message-ID: <5113CB72.4080604@FreeBSD.org> Date: Thu, 07 Feb 2013 17:42:42 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130206 Thunderbird/17.0.2 MIME-Version: 1.0 To: Sergey Kandaurov Subject: Re: panic: LK_RETRY set with incompatible flags References: <1137922035.2777364.1360203187367.JavaMail.root@erie.cs.uoguelph.ca> <5113AF89.4070303@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Konstantin Belousov , Rick Macklem , FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 07 Feb 2013 15:42:48 -0000 on 07/02/2013 17:36 Sergey Kandaurov said the following: > I tested the patch without the (*vpp != dvp) change. > It works well. > > It's something unrelated but when doing ls -l > on server (patched) and client (unpatched) sides, > I found some inconsistency in returned stats. > Or more precisely: > > NFS server > # stat -s /pool1/user1000/.zfs/shares/.. > st_dev=2050684725 st_ino=1 st_mode=040555 st_nlink=4 st_uid=0 st_gid=0 > st_rdev=0 st_size=4 st_atime=1360251211 st_mtime=1359551493 > st_ctime=1359551493 st_birthtime=1359551493 st_blksize=4096 > st_blocks=0 st_flags=0 > > NFS client > # stat -s /home/user1000/.zfs/shares/.. > st_dev=2050684725 st_ino=7 st_mode=040555 st_nlink=2 st_uid=0 st_gid=0 > st_rdev=1377468712 st_size=2 st_atime=1360251104 st_mtime=1359551493 > st_ctime=1359551493 st_birthtime=-1 st_blksize=4096 st_blocks=3 > st_flags=0 Hmm, this looks more consistent with the earlier patch. Are you sure that you really tested the new kernel (on the server)? -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Thu Feb 7 16:09:01 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 56AA3DFC; Thu, 7 Feb 2013 16:09:01 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-wg0-f51.google.com (mail-wg0-f51.google.com [74.125.82.51]) by mx1.freebsd.org (Postfix) with ESMTP id 9F857A44; Thu, 7 Feb 2013 16:09:00 +0000 (UTC) Received: by mail-wg0-f51.google.com with SMTP id 8so2119781wgl.18 for ; Thu, 07 Feb 2013 08:08:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=8aZdXzSPkMiQ1eZw7e9KqhkB9MMxrIcyrvU5oreGeYI=; b=sLmMkpljAKI19wwL1MJm4t8a0nUXKoCKgd1GAYmVViKWX71Tg/oJub0wVTOHWZtWxp 7YPilyDLBikVdnCy31mJsC7LC/FSqNI1ixO3zHLq/GZso0SYRRjf/bNJB98RcFKmTqVr QFTL+YKGOio+xR86KrdUNeU1RTR+KcRneY1F0PzXD6FR+tO1GR/drQf/uNJKJeDlkmm0 5BwHTsxc3A7DymoZOxGTXfYd49UgNtXW7qa1fX6eTlnDMDoUxgr08Y3kmnp/9tcxW3s4 zWzsjsGZhn8OucCdhXSLdlJC8vUPT1URFgrsNu5cUcdstyaxlTehLmA9vqbIDTqZvfv6 o2EQ== MIME-Version: 1.0 X-Received: by 10.180.90.106 with SMTP id bv10mr3909894wib.12.1360253339497; Thu, 07 Feb 2013 08:08:59 -0800 (PST) Received: by 10.195.12.163 with HTTP; Thu, 7 Feb 2013 08:08:59 -0800 (PST) In-Reply-To: <5113CB72.4080604@FreeBSD.org> References: <1137922035.2777364.1360203187367.JavaMail.root@erie.cs.uoguelph.ca> <5113AF89.4070303@FreeBSD.org> <5113CB72.4080604@FreeBSD.org> Date: Thu, 7 Feb 2013 19:08:59 +0300 Message-ID: Subject: Re: panic: LK_RETRY set with incompatible flags From: Sergey Kandaurov To: Andriy Gapon Content-Type: text/plain; charset=ISO-8859-1 Cc: Konstantin Belousov , Rick Macklem , FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 07 Feb 2013 16:09:01 -0000 On 7 February 2013 19:42, Andriy Gapon wrote: > on 07/02/2013 17:36 Sergey Kandaurov said the following: >> I tested the patch without the (*vpp != dvp) change. >> It works well. >> >> It's something unrelated but when doing ls -l >> on server (patched) and client (unpatched) sides, >> I found some inconsistency in returned stats. >> Or more precisely: >> >> NFS server >> # stat -s /pool1/user1000/.zfs/shares/.. >> st_dev=2050684725 st_ino=1 st_mode=040555 st_nlink=4 st_uid=0 st_gid=0 >> st_rdev=0 st_size=4 st_atime=1360251211 st_mtime=1359551493 >> st_ctime=1359551493 st_birthtime=1359551493 st_blksize=4096 >> st_blocks=0 st_flags=0 >> >> NFS client >> # stat -s /home/user1000/.zfs/shares/.. >> st_dev=2050684725 st_ino=7 st_mode=040555 st_nlink=2 st_uid=0 st_gid=0 >> st_rdev=1377468712 st_size=2 st_atime=1360251104 st_mtime=1359551493 >> st_ctime=1359551493 st_birthtime=-1 st_blksize=4096 st_blocks=3 >> st_flags=0 > > Hmm, this looks more consistent with the earlier patch. > Are you sure that you really tested the new kernel (on the server)? Sorry, I indeed booted a wrong kernel. Now tested the really new kernel :) And it works as well. stat -s looks consistent, thanks. # stat -s /home/user1000/.zfs/shares/.. st_dev=2050684725 st_ino=1 st_mode=040555 st_nlink=4 st_uid=0 st_gid=0 st_rdev=0 st_size=4 st_atime=1360252962 st_mtime=1359551493 st_ctime=1359551493 st_birthtime=-1 st_blksize=4096 st_blocks=0 st_flags=0 -- wbr, pluknet From owner-freebsd-current@FreeBSD.ORG Thu Feb 7 18:01:56 2013 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 275BF2AE; Thu, 7 Feb 2013 18:01:56 +0000 (UTC) (envelope-from uqs@FreeBSD.org) Received: from acme.spoerlein.net (acme.spoerlein.net [IPv6:2a01:4f8:131:23c2::1]) by mx1.freebsd.org (Postfix) with ESMTP id B78971B0; Thu, 7 Feb 2013 18:01:55 +0000 (UTC) Received: from localhost (acme.spoerlein.net [IPv6:2a01:4f8:131:23c2::1]) by acme.spoerlein.net (8.14.6/8.14.6) with ESMTP id r17I1ro8020567 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 7 Feb 2013 19:01:54 +0100 (CET) (envelope-from uqs@FreeBSD.org) Date: Thu, 7 Feb 2013 19:01:53 +0100 From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= To: Fabian Keil Subject: Re: geli(8) breaks after a couple hours of uptime Message-ID: <20130207180153.GX35868@acme.spoerlein.net> Mail-Followup-To: Fabian Keil , current@FreeBSD.org, pjd@FreeBSD.org References: <20130207141833.GA15884@acme.spoerlein.net> <20130207153322.5c371beb@fabiankeil.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20130207153322.5c371beb@fabiankeil.de> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 07 Feb 2013 18:01:56 -0000 On Thu, 2013-02-07 at 15:33:22 +0100, Fabian Keil wrote: > Ulrich Spörlein wrote: > > > Yes, it's pretty much as weird as it sounds. All new machine, forklifted > > the image from on old i386 machine running 8.x to current on amd64. > > > > Everything seemingly works fine, attaching geli volumes shortly after > > boot is fine, attached devices continue to work fine. There are no > > strange crashes with this machine or anything, but when I try to attach > > an USB volume the next day, geli attach segfaults. > > This could be: > http://www.freebsd.org/cgi/query-pr.cgi?pr=174831 > > Fabian Except it happens to me when run as root, and: root@coyote:~# sysctl vm.old_mlock vm.old_mlock: 0 I should probably have added that I'm at r246045. Hmm Uli From owner-freebsd-current@FreeBSD.ORG Thu Feb 7 18:14:42 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 1AD0D558 for ; Thu, 7 Feb 2013 18:14:42 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) by mx1.freebsd.org (Postfix) with ESMTP id 0134A24F for ; Thu, 7 Feb 2013 18:14:41 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.5/8.14.5) with ESMTP id r17IEfV5058995 for ; Thu, 7 Feb 2013 10:14:41 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.5/8.14.5/Submit) id r17IEfd9058994 for freebsd-current@freebsd.org; Thu, 7 Feb 2013 10:14:41 -0800 (PST) (envelope-from sgk) Date: Thu, 7 Feb 2013 10:14:41 -0800 From: Steve Kargl To: freebsd-current@freebsd.org Subject: compiling libc and libthr with debugging? Message-ID: <20130207181441.GA58987@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 07 Feb 2013 18:14:42 -0000 What's the preferred method for compiling libc and libthr with debugging enable? -- Steve From owner-freebsd-current@FreeBSD.ORG Thu Feb 7 18:23:00 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id F1F4D774 for ; Thu, 7 Feb 2013 18:23:00 +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 CDB912BE for ; Thu, 7 Feb 2013 18:23:00 +0000 (UTC) Received: from pakbsde14.localnet (unknown [38.105.238.108]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 355E2B918; Thu, 7 Feb 2013 13:23:00 -0500 (EST) From: John Baldwin To: freebsd-current@freebsd.org Subject: Re: compiling libc and libthr with debugging? Date: Thu, 7 Feb 2013 13:20:16 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p22; KDE/4.5.5; amd64; ; ) References: <20130207181441.GA58987@troutmask.apl.washington.edu> In-Reply-To: <20130207181441.GA58987@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201302071320.17136.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 07 Feb 2013 13:23:00 -0500 (EST) Cc: Steve Kargl X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 07 Feb 2013 18:23:01 -0000 On Thursday, February 07, 2013 1:14:41 pm Steve Kargl wrote: > What's the preferred method for compiling libc > and libthr with debugging enable? I just do: cd /path/to/src/lib/libc make clean make DEBUG_FLAGS=-g Then when I run the binary I use a custom LD_LIBRARY_PATH that points at the directory holding the custom libc. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu Feb 7 18:43:40 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 12FBCD5B; Thu, 7 Feb 2013 18:43:40 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) by mx1.freebsd.org (Postfix) with ESMTP id D47DB65A; Thu, 7 Feb 2013 18:43:39 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.5/8.14.5) with ESMTP id r17IhdCB059116; Thu, 7 Feb 2013 10:43:39 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.5/8.14.5/Submit) id r17Ihdc5059115; Thu, 7 Feb 2013 10:43:39 -0800 (PST) (envelope-from sgk) Date: Thu, 7 Feb 2013 10:43:39 -0800 From: Steve Kargl To: John Baldwin Subject: Re: compiling libc and libthr with debugging? Message-ID: <20130207184339.GA59000@troutmask.apl.washington.edu> References: <20130207181441.GA58987@troutmask.apl.washington.edu> <201302071320.17136.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201302071320.17136.jhb@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 07 Feb 2013 18:43:40 -0000 On Thu, Feb 07, 2013 at 01:20:16PM -0500, John Baldwin wrote: > On Thursday, February 07, 2013 1:14:41 pm Steve Kargl wrote: > > What's the preferred method for compiling libc > > and libthr with debugging enable? > > I just do: > > cd /path/to/src/lib/libc > make clean > make DEBUG_FLAGS=-g > > Then when I run the binary I use a custom LD_LIBRARY_PATH that points at the > directory holding the custom libc. > Thanks. I give it a try, but I'll install the libraries at lesat for a few days. -- Steve From owner-freebsd-current@FreeBSD.ORG Thu Feb 7 18:44:39 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B8BC5E75 for ; Thu, 7 Feb 2013 18:44:39 +0000 (UTC) (envelope-from kolyasir@gmail.com) Received: from mail-qe0-f66.google.com (mail-qe0-f66.google.com [209.85.128.66]) by mx1.freebsd.org (Postfix) with ESMTP id 83C5767D for ; Thu, 7 Feb 2013 18:44:39 +0000 (UTC) Received: by mail-qe0-f66.google.com with SMTP id 1so200273qec.5 for ; Thu, 07 Feb 2013 10:44:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=3n36QVjJaDzSNZjvXqv1q1aGa06XaKRNVueH6FjOd3E=; b=ky460ypePDuDXp50AFn5t3pjfuiIfS8YXWe7KpQBNdPKutv9vMG/ZNRYdlcg6gSzov eHBJu7o6w6rPCci9Ik0bI2+jWYAHQEqMTlObIlTc7s8ZWgPxuikiAAAh+0DFAZNGhwg0 hdtN0BrOs/BME2otzlLilA6hiBvYnYd3jmgBurKgU/ImmuGaOG18DhL9gT0rfy4Y2kC3 z2L5HttCscDdmmsD1HO60jsEJ8WW30a7sDgUGTtwSR6ukC8zWM7A47xUiZLaGFIpNj9k 1ZIJwsFlRUCYEBpNuCfJfoZX5CVwI6pgFDxlGz5vGggghUeOJob03D+GzWV37IuOVnF1 N0MA== MIME-Version: 1.0 X-Received: by 10.49.73.232 with SMTP id o8mr991816qev.0.1360258724798; Thu, 07 Feb 2013 09:38:44 -0800 (PST) Received: by 10.49.71.232 with HTTP; Thu, 7 Feb 2013 09:38:44 -0800 (PST) Date: Thu, 7 Feb 2013 12:38:44 -0500 Message-ID: Subject: getting problems with compiling kernel From: Yasir hussan To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 07 Feb 2013 18:44:39 -0000 hi, i yesterday i was tried to patch file on my freensd code, because it was my custom code so i had to patch my code by update file to file, with my calculation everything should go perfectly it didn`t, i am getting some errors like cc -c -O -pipe -march=mips32 -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 -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=10000 --param large-function-growth=100000 --param max-inline-insns-single=10000 -fno-pic -mno-abicalls -G0 -march=mips32 -msoft-float -ffreestanding -Werror /usr/src/sys/dev/switch/switch.c cc1: warnings being treated as errors /usr/src/sys/dev/switch/switch.c: In function 'switchbus_child_pnpinfo_str': /usr/src/sys/dev/switch/switch.c:207: warning: implicit declaration of function 'MII_OUI' /usr/src/sys/dev/switch/switch.c:207: warning: nested extern declaration of 'MII_OUI' [-Wnested-externs] /usr/src/sys/dev/switch/switch.c:208: warning: implicit declaration of function 'MII_MODEL' /usr/src/sys/dev/switch/switch.c:208: warning: nested extern declaration of 'MII_MODEL' [-Wnested-externs] /usr/src/sys/dev/switch/switch.c:208: warning: implicit declaration of function 'MII_REV' /usr/src/sys/dev/switch/switch.c:208: warning: nested extern declaration of 'MII_REV' [-Wnested-externs] *** Error code 1 MII_OUI are simple macro which u can also view on open source freebsd v9 at location "src/sys/dev/mii/miivar.h", and "switch" is the driver folder which you can check from patch(http://loos.no-ip.org/rspro/switch-1.diff) any help will be appreciative... Thanks, Regards: Yasir Amin From owner-freebsd-current@FreeBSD.ORG Thu Feb 7 19:42:55 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 563A115F; Thu, 7 Feb 2013 19:42:55 +0000 (UTC) (envelope-from kpaasial@gmail.com) Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [IPv6:2a00:1450:400c:c03::234]) by mx1.freebsd.org (Postfix) with ESMTP id A5594930; Thu, 7 Feb 2013 19:42:54 +0000 (UTC) Received: by mail-we0-f180.google.com with SMTP id k14so2373195wer.39 for ; Thu, 07 Feb 2013 11:42:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=cfMfmsYGLIoG3VEcdwOLgP8dYB+BhDw6zQiRC4DCdMw=; b=MQxeAbfYPWrxHQI53DwxeNuAPE5ZZlsqKzlHzyTwx4LKzsXEGLpy8IZdf/zstj17VM KwTPzzAqg29i52YwsRG4xsfp+274W70OY3MUD3ZIHDODDWsNrcT72x10TObgPBt6JLUt TyJto2ayPTfBgBzM00AkQpOyn20zgAoWge/pZJuXkD4zPY4FJcR3d8ekJWEfdXDIXOtX iP687sT/eT5UgNVEXMVlo9/bDmuVsATGj/StklnrY3X9DNG+pJz+eLyMQDGqRSXP3WXu wXjq87I+xzKpQBzJcuqBTj6ozwxlXBSb6SHXZGioomUC+twBcyGMpXEdm0UXVvkYLipo H9sw== MIME-Version: 1.0 X-Received: by 10.180.102.7 with SMTP id fk7mr5064963wib.27.1360266173810; Thu, 07 Feb 2013 11:42:53 -0800 (PST) Received: by 10.216.120.193 with HTTP; Thu, 7 Feb 2013 11:42:53 -0800 (PST) Date: Thu, 7 Feb 2013 21:42:53 +0200 Message-ID: Subject: CLANG and -fstack-protector From: Kimmo Paasiala To: freebsd-stable@freebsd.org, FreeBSD current Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 07 Feb 2013 19:42:55 -0000 Hello, Does the -fstack-protector option work on CLANG 3.1 and 3.2? There is thread on FreeBSD forums about the stack protector and ports and I'm wondering if it's possible to use the -fstack-protector option with CLANG. http://forums.freebsd.org/showthread.php?t=36927 -Kimmo From owner-freebsd-current@FreeBSD.ORG Thu Feb 7 20:02:49 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 6B93587D for ; Thu, 7 Feb 2013 20:02:49 +0000 (UTC) (envelope-from adrian.chadd@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 04F66A51 for ; Thu, 7 Feb 2013 20:02:48 +0000 (UTC) Received: by mail-wi0-f178.google.com with SMTP id o1so19510wic.17 for ; Thu, 07 Feb 2013 12:02:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=zrTCcOIzMq8djMG9dVfTc0yK7JRYFKgY6uPX1M28o3k=; b=yS3iUGrW/rqxZKGqmPCK0RRPsH8SsA8KR5Ux4Dwr4fkfE7RmUG3DUVoIYaVNnuI1kn Hd20buDFTU2da3UN4rPSDXGUYzIuhdtB601jKah2H9xjp0jNdBHVG+bfynEoqe+5WJEK 8YkRnJeEyNl58euqBl0iCihJWADO37I/oxdOanXmoz6zJ9RVW7cSTsGFLX2jQ/ZT7Zia VqhoWRnTM7RRsTxPYCbixNph6oa6eS2Pb2Foht06rpV83owQOoLSrnB9Y7GfsOOfLGqy 97XttJsT61/kF42b60q1JWMqcwSBFixQ86n1wnEt/ZXLx1JQ9ZWXXXp3dBYQmZCq1IJU i0cg== MIME-Version: 1.0 X-Received: by 10.180.99.72 with SMTP id eo8mr14226892wib.34.1360267367839; Thu, 07 Feb 2013 12:02:47 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.236.88 with HTTP; Thu, 7 Feb 2013 12:02:47 -0800 (PST) In-Reply-To: References: Date: Thu, 7 Feb 2013 12:02:47 -0800 X-Google-Sender-Auth: cgkSOKCUTqGI1eiNdLStaEQhPdk Message-ID: Subject: Re: getting problems with compiling kernel From: Adrian Chadd To: Yasir hussan Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 07 Feb 2013 20:02:49 -0000 You need to dig through the patch and the freebsd tree you're using and try to figure out where that is defined and why it isn't being found. Luis' patch is against -HEAD from a couple years ago, and you're (I think) trying to patch -9. There's likely some code drift since then.. Adrian On 7 February 2013 09:38, Yasir hussan wrote: > hi, > > i yesterday i was tried to patch file on my freensd code, because it was my > custom code so i had to patch my code by update file to file, with my > calculation everything should go perfectly it didn`t, i am getting some > errors like > > cc -c -O -pipe -march=mips32 -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 -nostdinc -I. > -I/usr/src/sys -I/usr/src/sys/contrib/altq -D_KERNEL > -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common > -finline-limit=8000 --param inline-unit-growth=10000 --param > large-function-growth=100000 --param max-inline-insns-single=10000 > -fno-pic -mno-abicalls -G0 -march=mips32 -msoft-float -ffreestanding > -Werror /usr/src/sys/dev/switch/switch.c > cc1: warnings being treated as errors > /usr/src/sys/dev/switch/switch.c: In function 'switchbus_child_pnpinfo_str': > /usr/src/sys/dev/switch/switch.c:207: warning: implicit declaration of > function 'MII_OUI' > /usr/src/sys/dev/switch/switch.c:207: warning: nested extern declaration of > 'MII_OUI' [-Wnested-externs] > /usr/src/sys/dev/switch/switch.c:208: warning: implicit declaration of > function 'MII_MODEL' > /usr/src/sys/dev/switch/switch.c:208: warning: nested extern declaration of > 'MII_MODEL' [-Wnested-externs] > /usr/src/sys/dev/switch/switch.c:208: warning: implicit declaration of > function 'MII_REV' > /usr/src/sys/dev/switch/switch.c:208: warning: nested extern declaration of > 'MII_REV' [-Wnested-externs] > *** Error code 1 > > MII_OUI are simple macro which u can also view on open source freebsd v9 at > location "src/sys/dev/mii/miivar.h", and "switch" is the driver folder > which you can check from patch(http://loos.no-ip.org/rspro/switch-1.diff) > > any help will be appreciative... > > Thanks, > > Regards: > Yasir Amin > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Thu Feb 7 21:06:54 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 249B03FE; Thu, 7 Feb 2013 21:06:54 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [IPv6:2001:7b8:3a7:1:2d0:b7ff:fea0:8c26]) by mx1.freebsd.org (Postfix) with ESMTP id DDB1ADA9; Thu, 7 Feb 2013 21:06:53 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:204:4bff:fe01:de8a] (spaceball.andric.com [IPv6:2001:7b8:3a7:0:204:4bff:fe01:de8a]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id E718D5C43; Thu, 7 Feb 2013 22:06:51 +0100 (CET) Message-ID: <51141769.5060905@FreeBSD.org> Date: Thu, 07 Feb 2013 22:06:49 +0100 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/20130117 Thunderbird/19.0 MIME-Version: 1.0 To: Kimmo Paasiala , freebsd-stable@freebsd.org, FreeBSD current Subject: Re: CLANG and -fstack-protector References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 07 Feb 2013 21:06:54 -0000 On 2013-02-07 20:42, Kimmo Paasiala wrote: > Does the -fstack-protector option work on CLANG 3.1 and 3.2? Yes, it works with both clang and gcc. > There is thread on FreeBSD forums about the stack protector and ports > and I'm wondering if it's possible to use the -fstack-protector option > with CLANG. > > http://forums.freebsd.org/showthread.php?t=36927 That thread seems to be full of confusion. :-) The base system is mostly built with -fstack-protector, except for the ia64, arm and mips arches, and for some specific cases where it is not necessary, or unwanted. Ports are largely independent of the base system, and their compilation flags are different from port to port. You could set -fstack-protector for your ports in either make.conf or ports.conf, if you wanted. From owner-freebsd-current@FreeBSD.ORG Thu Feb 7 21:12:25 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 8F11380B; Thu, 7 Feb 2013 21:12:25 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay02.stack.nl [IPv6:2001:610:1108:5010::104]) by mx1.freebsd.org (Postfix) with ESMTP id 40622E04; Thu, 7 Feb 2013 21:12:25 +0000 (UTC) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id B4F91358C55; Thu, 7 Feb 2013 22:12:23 +0100 (CET) Received: by snail.stack.nl (Postfix, from userid 1677) id 8020E2848C; Thu, 7 Feb 2013 22:12:23 +0100 (CET) Date: Thu, 7 Feb 2013 22:12:22 +0100 From: Jilles Tjoelker To: John Baldwin Subject: Re: [PATCH] open_memstream() and open_wmemstream() Message-ID: <20130207211222.GA98989@stack.nl> References: <201302051546.43839.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201302051546.43839.jhb@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 07 Feb 2013 21:12:25 -0000 On Tue, Feb 05, 2013 at 03:46:43PM -0500, John Baldwin wrote: > I've written an implementation of open_memstream() and > open_wmemstream() along with a set of regression tests. I'm pretty > sure open_memstream() is correct, and I believe open_wmemstream() is > correct for expected usage. The latter might even do the right thing > if you split a multi-byte character across multiple writes. One > question I have is if my choice to discard any pending multi-byte > state in the stream anytime a seek changes the effective position in > the output stream. I think this is correct as stdio will flush any > pending data before doing a seek, so if there is a partially parsed > character we aren't going to get the rest of it. I don't think partially parsed characters can happen with a correct application. As per C99, an application must not call byte output functions on a wide-oriented stream, and vice versa. Discarding the shift state on fseek()/fseeko() is permitted (but should be documented as this is implementation-defined behaviour). State-dependent encodings (where this is relevant) are rarely used nowadays. The conversion to bytes and back probably makes open_wmemstream() quite slow but I don't think that is very important. > http://www.FreeBSD.org/~jhb/patches/open_memstream.patch The seek functions should check for overflow in the addition (for SEEK_CUR and SEEK_END) and the conversion to size_t. -- Jilles Tjoelker From owner-freebsd-current@FreeBSD.ORG Thu Feb 7 21:45:37 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 041E54C4; Thu, 7 Feb 2013 21:45:37 +0000 (UTC) (envelope-from monthadar@gmail.com) Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) by mx1.freebsd.org (Postfix) with ESMTP id 61A22E9; Thu, 7 Feb 2013 21:45:36 +0000 (UTC) Received: by mail-wi0-f179.google.com with SMTP id ez12so127392wid.6 for ; Thu, 07 Feb 2013 13:45:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=y5R6EhY9OCJkwv0uRsjO88qzOExF2KBqSLkmUHCJcm0=; b=o0e2zgjYPhnmu2MZadoMLzavZ/QfuJYB7al1lZYyJlznfLiWMQhboqzGgaUgAg5tJS fE8xFSJA4jn6rArtWlOZA/UWymOtZZpm3vrnKsALS+mmKBEd+cTq+B+3JcmbB8WmDzHg 0v2MfW6a/twdcj4NGTBdZOG9MVCMQckBDoiKcXoQrpn+bZW5IlYF0q3lhT4tXtYkc+Ew zkksqct6YFAxDLrSQlyb3BMqNS4gt4BZto7oHPMRk6FkYhKPbUA2yQapvFvy0ktxtfd4 Osxitw1hMrYCx6DeT8g2pNevNi+a3ZM6etDP8vm9jTGeyGm+lx+BPjmFmBwpFNmF+Loq Kd7Q== MIME-Version: 1.0 X-Received: by 10.194.235.225 with SMTP id up1mr5836126wjc.11.1360273535320; Thu, 07 Feb 2013 13:45:35 -0800 (PST) Received: by 10.227.59.19 with HTTP; Thu, 7 Feb 2013 13:45:35 -0800 (PST) Date: Thu, 7 Feb 2013 22:45:35 +0100 Message-ID: Subject: FreeBSD IEEE802.11 Mesh status update. From: Monthadar Al Jaberi To: freebsd-current , freebsd-wireless@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 07 Feb 2013 21:45:37 -0000 Hi everyone! I am pleased to say that FreeBSD has gotten a little closer to getting a working IEEE802.11 Mesh. A lot more is to be done. Please try it out! You have to update to head revision 246520. Check out the great wiki we have about Mesh :) https://wiki.freebsd.org/WifiMesh There is still a lot to be desired. Next I would like to put more focus on the following issues: * Wireshark validation * Update tcpdump (A great debuggin tool!) * Wtap mesh simulator (more usable more documentation, maybe even a wiki) * More test cases * More mesh stuff People interesting in helping are always welcome. Thnx to Alexander, Bernhard, Rui and everyone on freebsd-git IRC channel! And a special thnx to Adrian Chadd for being my mentor and friend. Thnx everyone and keep up the great work on net80211! br, -- Monthadar Al Jaberi From owner-freebsd-current@FreeBSD.ORG Thu Feb 7 22:52:55 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id BDFA232B; Thu, 7 Feb 2013 22:52:55 +0000 (UTC) (envelope-from jlh@FreeBSD.org) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [IPv6:2a01:e0c:1:1599::14]) by mx1.freebsd.org (Postfix) with ESMTP id 4A20F34E; Thu, 7 Feb 2013 22:52:52 +0000 (UTC) Received: from endor.tataz.chchile.org (unknown [82.233.239.98]) by smtp5-g21.free.fr (Postfix) with ESMTP id 435FED48098; Thu, 7 Feb 2013 23:52:44 +0100 (CET) Received: from felucia.tataz.chchile.org (felucia.tataz.chchile.org [192.168.1.9]) by endor.tataz.chchile.org (Postfix) with ESMTP id 2998E278; Thu, 7 Feb 2013 23:52:43 +0100 (CET) Received: by felucia.tataz.chchile.org (Postfix, from userid 1000) id 02CDE13096; Thu, 7 Feb 2013 22:52:42 +0000 (UTC) Date: Thu, 7 Feb 2013 23:52:42 +0100 From: Jeremie Le Hen To: Dimitry Andric Subject: Re: CLANG and -fstack-protector Message-ID: <20130207225242.GA5900@felucia.tataz.chchile.org> Mail-Followup-To: Dimitry Andric , Kimmo Paasiala , freebsd-stable@freebsd.org, FreeBSD current References: <51141769.5060905@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51141769.5060905@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Kimmo Paasiala , FreeBSD current , freebsd-stable@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 07 Feb 2013 22:52:55 -0000 Hi Kimmo, On Thu, Feb 07, 2013 at 10:06:49PM +0100, Dimitry Andric wrote: > On 2013-02-07 20:42, Kimmo Paasiala wrote: > > Does the -fstack-protector option work on CLANG 3.1 and 3.2? > > Yes, it works with both clang and gcc. > > > > There is thread on FreeBSD forums about the stack protector and ports > > and I'm wondering if it's possible to use the -fstack-protector option > > with CLANG. > > > > http://forums.freebsd.org/showthread.php?t=36927 > > That thread seems to be full of confusion. :-) The base system is mostly > built with -fstack-protector, except for the ia64, arm and mips arches, > and for some specific cases where it is not necessary, or unwanted. > > Ports are largely independent of the base system, and their compilation > flags are different from port to port. You could set -fstack-protector > for your ports in either make.conf or ports.conf, if you wanted. You can do this, it will work for most of the ports but some ports do not honor CFLAGS. If those ports happen to be linked againsst libraries that were compiled with -fstack-protector, you will get a missing symbol error. Well, to be honest, I don't remember enough details, they faded from my memory, I need to check this. So if you care about security enough, go for it! If you meet weird error like a missing "stack_chk_fail" symbol for some ports (lang/perl might be a candidate in my memory), then look at the PR below, it will probably solve your problem. Time has passed and I am interested in your feedback without the patch (and then with, if relevant). Basically the following PR contains a patch that waits for an exp run to be committed into the base system. This just turns libc.so into an ld script that pulls in libssp_nonshared.a. You just have to run "make all install" in src/lib/libc after applying it. http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/168010 I run it on my servers with -fstack-protector enabled for ports without any problem. Cheers! -- Jeremie Le Hen Scientists say the world is made up of Protons, Neutrons and Electrons. They forgot to mention Morons. From owner-freebsd-current@FreeBSD.ORG Thu Feb 7 23:25:27 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id BCFC09BF; Thu, 7 Feb 2013 23:25:27 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-we0-x229.google.com (we-in-x0229.1e100.net [IPv6:2a00:1450:400c:c03::229]) by mx1.freebsd.org (Postfix) with ESMTP id 08EAB6AE; Thu, 7 Feb 2013 23:25:26 +0000 (UTC) Received: by mail-we0-f169.google.com with SMTP id t11so2602965wey.14 for ; Thu, 07 Feb 2013 15:25:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=GDL5hfCNAcDcd+PMyCkD9yWRphPXXDXJOZPMsSfyXw0=; b=ZApfeXtQAHFOMml9k4g8Q0UHI97ChDHFSzkZN8k/2I0tfbXTP0QKcCzF2VZRx/tcza olb5+uDC/+Nz8PPHwgdtavNqcogC6fQaAvJ6T+fnMmTtBP+jTiESty+7cVsFMEE5B+/L L4wCjQOec0vnja65uBEwEtdS5TbpbjidRMCfyH0RYfFFTpK+yFOFiTXvhMx1+PzFJR7d afnsB1zfZN+ACICo8AxzDo7RAzXxFenzxM6IL1WImEJ2Fkv79CVa24HaEuDmLEVQf2ED w3Pi1HIVJhr085uRCu3HzLzrrKR+o+aI4oGgQa9NoEERJUWvIxjYSzoGetwJf+uxilJK HVSQ== MIME-Version: 1.0 X-Received: by 10.180.99.227 with SMTP id et3mr6020840wib.6.1360279526111; Thu, 07 Feb 2013 15:25:26 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.236.88 with HTTP; Thu, 7 Feb 2013 15:25:25 -0800 (PST) In-Reply-To: References: Date: Thu, 7 Feb 2013 15:25:25 -0800 X-Google-Sender-Auth: u-YTBaR3-z3DbGBOfY6uORvFNCw Message-ID: Subject: Re: FreeBSD IEEE802.11 Mesh status update. From: Adrian Chadd To: Monthadar Al Jaberi Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current , freebsd-wireless@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 07 Feb 2013 23:25:27 -0000 Hi! Thanks so much for your hard work to date. I'm so glad that FreeBSD's 802.11s support is growing in leaps and bounds. Adrian On 7 February 2013 13:45, Monthadar Al Jaberi wrote: > Hi everyone! > > I am pleased to say that FreeBSD has gotten a little closer to getting > a working IEEE802.11 Mesh. > A lot more is to be done. > > Please try it out! You have to update to head revision 246520. Check > out the great wiki we have about Mesh :) > https://wiki.freebsd.org/WifiMesh > > There is still a lot to be desired. Next I would like to put more > focus on the following issues: > > * Wireshark validation > * Update tcpdump (A great debuggin tool!) > * Wtap mesh simulator (more usable more documentation, maybe even a wiki) > * More test cases > * More mesh stuff > > People interesting in helping are always welcome. > > Thnx to Alexander, Bernhard, Rui and everyone on freebsd-git IRC channel! > And a special thnx to Adrian Chadd for being my mentor and friend. > > Thnx everyone and keep up the great work on net80211! > > br, > > -- > Monthadar Al Jaberi > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Thu Feb 7 23:34:24 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 6D756CD9; Thu, 7 Feb 2013 23:34:24 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 0FF0C72E; Thu, 7 Feb 2013 23:34:23 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAEALo5FFGDaFvO/2dsb2JhbABFhkm2RoQAc4IfAQEFIwRSGw4KAgINGQJZBogkrWiSUIEjjyaBEwOIZo07iVWGfYMeggY X-IronPort-AV: E=Sophos;i="4.84,625,1355115600"; d="scan'208";a="15670865" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 07 Feb 2013 18:33:57 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id D882FB4046; Thu, 7 Feb 2013 18:33:57 -0500 (EST) Date: Thu, 7 Feb 2013 18:33:57 -0500 (EST) From: Rick Macklem To: Andriy Gapon Message-ID: <1978437261.2814435.1360280037874.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <5113C764.4010902@FreeBSD.org> Subject: Re: panic: LK_RETRY set with incompatible flags MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.203] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: Konstantin Belousov , Sergey Kandaurov , FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 07 Feb 2013 23:34:24 -0000 Andriy Gapon wrote: > on 07/02/2013 17:04 Rick Macklem said the following: > > The other thing I wondered about is "can zfsvfs->z_shares_dir ever > > not > > fit in 32bits?". > > Usually it should be one of the first objects created in a new > filesystem, so it > should have a small ID (typically 7). > > > I notice it is a uint64_t, but ino_t is still 32bits for > > FreeBSD. If it didn't fit in 32bits, the check in zfs_vget() > > wouldn't > > work. (I have a hunch that, for now, the ZFS code doesn't exceed > > 32bit > > fids, but haven't looked at the code to try and see. I'll take a > > closer > > look at that, too.) > > As far as I understand, ZFS actually uses 48 bits for object IDs at > the moment. > Since they are generated incrementally they do not overflow 32 bits > soon. > But you are right that this is a potential problem as long as ino_t > stays 32-bit. > > However, it seems that VFS_VGET is mostly used by filesystem drivers > internally. > And ZFS doesn't seem to do that. > The only external user appears to be NFS. > Cool. Sounds fine, rick > -- > Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Thu Feb 7 23:40:02 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B1671EFC; Thu, 7 Feb 2013 23:40:02 +0000 (UTC) (envelope-from kpaasial@gmail.com) Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) by mx1.freebsd.org (Postfix) with ESMTP id F2D7577E; Thu, 7 Feb 2013 23:40:01 +0000 (UTC) Received: by mail-wi0-f179.google.com with SMTP id ez12so219425wid.6 for ; Thu, 07 Feb 2013 15:40:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=denVb4VY8GZoHyzmxs5P+cwN4N515gPQDzAuynArfAQ=; b=qjon24ct1j4S6ztTjKH4lSUVSBjbDJZ0uSLTNnAvL/Pn3mjn7xntHLCd5V7ZH9NLx6 Z/lDweQkhThSYp+pAlUIp6hZ0bmpeXssy2kFdWdlPqmesVKuDCBWOQfX8+KqeIymBRlz PGoep5iT17woJz94Qcakq6CxVx1lK7vSkNlqCbtilNTLrEhXbda3HZ9xn35ZVm6aSpCf s8Z2JYUymYSa72SSLQ4NagFeDu9DmmstS+iI7fstR1flWoYOvtlpMBEuo4YW50y6ktI5 9JYoGKAIrgT7hiIuWhLecsT+LH5ixptzd9Rbkbfx5Yd1KzGNX96gE/vmXOP322YnAXhL 4noA== MIME-Version: 1.0 X-Received: by 10.194.122.199 with SMTP id lu7mr6088083wjb.42.1360280400722; Thu, 07 Feb 2013 15:40:00 -0800 (PST) Received: by 10.216.120.193 with HTTP; Thu, 7 Feb 2013 15:40:00 -0800 (PST) In-Reply-To: <51141769.5060905@FreeBSD.org> References: <51141769.5060905@FreeBSD.org> Date: Fri, 8 Feb 2013 01:40:00 +0200 Message-ID: Subject: Re: CLANG and -fstack-protector From: Kimmo Paasiala To: Dimitry Andric Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD current , freebsd-stable@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 07 Feb 2013 23:40:02 -0000 On Thu, Feb 7, 2013 at 11:06 PM, Dimitry Andric wrote: > On 2013-02-07 20:42, Kimmo Paasiala wrote: >> >> Does the -fstack-protector option work on CLANG 3.1 and 3.2? > > > Yes, it works with both clang and gcc. > Good to know thank you! > >> There is thread on FreeBSD forums about the stack protector and ports >> and I'm wondering if it's possible to use the -fstack-protector option >> with CLANG. >> >> http://forums.freebsd.org/showthread.php?t=36927 > > > That thread seems to be full of confusion. :-) The base system is mostly > built with -fstack-protector, except for the ia64, arm and mips arches, > and for some specific cases where it is not necessary, or unwanted. I was aware of the base system being built with the stack protector on systems where it makes sense. > > Ports are largely independent of the base system, and their compilation > flags are different from port to port. You could set -fstack-protector > for your ports in either make.conf or ports.conf, if you wanted. Is there any work being done to provide an optional Makefile knob (WITH_STACK_PROTECTOR ?) to turn on -fstack-protector for ports that install network services (or other critical code)? I'd bet such feature would be popular. From owner-freebsd-current@FreeBSD.ORG Thu Feb 7 23:41:40 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 837241F9; Thu, 7 Feb 2013 23:41:40 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.net.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 38DA07B8; Thu, 7 Feb 2013 23:41:39 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAEAFw6FFGDaFvO/2dsb2JhbABFhkm6R3OCHwEBAQQBAQEgBCcgCxsOCgICDRkCKQEJJgYIBwQBHASHcAytXJJQgSOMAYMlgRMDiGaLCYIygR2IOIZ9gx6BUTU X-IronPort-AV: E=Sophos;i="4.84,625,1355115600"; d="scan'208";a="13004509" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu.net.uoguelph.ca with ESMTP; 07 Feb 2013 18:41:38 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id E01D9B402B; Thu, 7 Feb 2013 18:41:38 -0500 (EST) Date: Thu, 7 Feb 2013 18:41:38 -0500 (EST) From: Rick Macklem To: Sergey Kandaurov Message-ID: <1644867646.2814542.1360280498907.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: Subject: Re: panic: LK_RETRY set with incompatible flags MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.202] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: Konstantin Belousov , FreeBSD Current , Andriy Gapon X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 07 Feb 2013 23:41:40 -0000 Sergey Kandaurov wrote: > On 7 February 2013 19:42, Andriy Gapon wrote: > > on 07/02/2013 17:36 Sergey Kandaurov said the following: > >> I tested the patch without the (*vpp != dvp) change. > >> It works well. > >> > >> It's something unrelated but when doing ls -l > >> on server (patched) and client (unpatched) sides, > >> I found some inconsistency in returned stats. > >> Or more precisely: > >> > >> NFS server > >> # stat -s /pool1/user1000/.zfs/shares/.. > >> st_dev=2050684725 st_ino=1 st_mode=040555 st_nlink=4 st_uid=0 > >> st_gid=0 > >> st_rdev=0 st_size=4 st_atime=1360251211 st_mtime=1359551493 > >> st_ctime=1359551493 st_birthtime=1359551493 st_blksize=4096 > >> st_blocks=0 st_flags=0 > >> > >> NFS client > >> # stat -s /home/user1000/.zfs/shares/.. > >> st_dev=2050684725 st_ino=7 st_mode=040555 st_nlink=2 st_uid=0 > >> st_gid=0 > >> st_rdev=1377468712 st_size=2 st_atime=1360251104 > >> st_mtime=1359551493 > >> st_ctime=1359551493 st_birthtime=-1 st_blksize=4096 st_blocks=3 > >> st_flags=0 > > > > Hmm, this looks more consistent with the earlier patch. > > Are you sure that you really tested the new kernel (on the server)? > > Sorry, I indeed booted a wrong kernel. > Now tested the really new kernel :) And it works as well. > stat -s looks consistent, thanks. > > # stat -s /home/user1000/.zfs/shares/.. > st_dev=2050684725 st_ino=1 st_mode=040555 st_nlink=4 st_uid=0 st_gid=0 > st_rdev=0 st_size=4 st_atime=1360252962 st_mtime=1359551493 > st_ctime=1359551493 st_birthtime=-1 st_blksize=4096 st_blocks=0 > st_flags=0 > Sounds good. I've attached a slightly updated patch with Andriy's suggested addition of a check for zfsvfs->z_shares_dir != 0. I can't do any commits until April, so if one of you guys is comfortable enough with the patch to commit it, you are more than welcome to do so. Thanks everyone for your help in resolving this, rick > -- > wbr, > pluknet > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Thu Feb 7 23:43:08 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 352D030D; Thu, 7 Feb 2013 23:43:08 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.net.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id CBAB57D0; Thu, 7 Feb 2013 23:43:07 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAEAJA7FFGDaFvO/2dsb2JhbABFhkm6R3OCHwEBAQQBAQEgBCcgCxsOChEZAgQlAQkmBggHBAEcBIdwDK1dklCNJIMlgRMDiGaGLYRcgjKBHYg4hn2DHoFRNQ X-IronPort-AV: E=Sophos;i="4.84,625,1355115600"; d="scan'208";a="13004652" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu.net.uoguelph.ca with ESMTP; 07 Feb 2013 18:43:06 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id DF840B403A; Thu, 7 Feb 2013 18:43:06 -0500 (EST) Date: Thu, 7 Feb 2013 18:43:06 -0500 (EST) From: Rick Macklem To: Sergey Kandaurov Message-ID: <645868904.2814576.1360280586902.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <1644867646.2814542.1360280498907.JavaMail.root@erie.cs.uoguelph.ca> Subject: Re: panic: LK_RETRY set with incompatible flags MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_2814575_1074866324.1360280586899" X-Originating-IP: [172.17.91.202] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: Konstantin Belousov , FreeBSD Current , Andriy Gapon X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 07 Feb 2013 23:43:08 -0000 ------=_Part_2814575_1074866324.1360280586899 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sergey Kandaurov wrote: > Sergey Kandaurov wrote: > > On 7 February 2013 19:42, Andriy Gapon wrote: > > > on 07/02/2013 17:36 Sergey Kandaurov said the following: > > >> I tested the patch without the (*vpp != dvp) change. > > >> It works well. > > >> > > >> It's something unrelated but when doing ls -l > > >> on server (patched) and client (unpatched) sides, > > >> I found some inconsistency in returned stats. > > >> Or more precisely: > > >> > > >> NFS server > > >> # stat -s /pool1/user1000/.zfs/shares/.. > > >> st_dev=2050684725 st_ino=1 st_mode=040555 st_nlink=4 st_uid=0 > > >> st_gid=0 > > >> st_rdev=0 st_size=4 st_atime=1360251211 st_mtime=1359551493 > > >> st_ctime=1359551493 st_birthtime=1359551493 st_blksize=4096 > > >> st_blocks=0 st_flags=0 > > >> > > >> NFS client > > >> # stat -s /home/user1000/.zfs/shares/.. > > >> st_dev=2050684725 st_ino=7 st_mode=040555 st_nlink=2 st_uid=0 > > >> st_gid=0 > > >> st_rdev=1377468712 st_size=2 st_atime=1360251104 > > >> st_mtime=1359551493 > > >> st_ctime=1359551493 st_birthtime=-1 st_blksize=4096 st_blocks=3 > > >> st_flags=0 > > > > > > Hmm, this looks more consistent with the earlier patch. > > > Are you sure that you really tested the new kernel (on the > > > server)? > > > > Sorry, I indeed booted a wrong kernel. > > Now tested the really new kernel :) And it works as well. > > stat -s looks consistent, thanks. > > > > # stat -s /home/user1000/.zfs/shares/.. > > st_dev=2050684725 st_ino=1 st_mode=040555 st_nlink=4 st_uid=0 > > st_gid=0 > > st_rdev=0 st_size=4 st_atime=1360252962 st_mtime=1359551493 > > st_ctime=1359551493 st_birthtime=-1 st_blksize=4096 st_blocks=0 > > st_flags=0 > > > Sounds good. I've attached a slightly updated patch with Andriy's > suggested addition of a check for zfsvfs->z_shares_dir != 0. > > I can't do any commits until April, so if one of you guys is > comfortable > enough with the patch to commit it, you are more than welcome to do > so. > > Thanks everyone for your help in resolving this, rick > I did my usual brain fart and forgot to attach the updated patch. Here it is..rick > > -- > > wbr, > > pluknet > > _______________________________________________ > > 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" > _______________________________________________ > 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" ------=_Part_2814575_1074866324.1360280586899 Content-Type: text/x-patch; name=zfs-shares.patch Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=zfs-shares.patch LS0tIGNkZGwvY29udHJpYi9vcGVuc29sYXJpcy91dHMvY29tbW9uL2ZzL3pmcy96ZnNfdmZzb3Bz LmMuc2F2CTIwMTMtMDItMDYgMTk6Mzg6NDEuMDAwMDAwMDAwIC0wNTAwCisrKyBjZGRsL2NvbnRy aWIvb3BlbnNvbGFyaXMvdXRzL2NvbW1vbi9mcy96ZnMvemZzX3Zmc29wcy5jCTIwMTMtMDItMDcg MTA6MjU6MDQuMDAwMDAwMDAwIC0wNTAwCkBAIC0yMDA5LDcgKzIwMDksOCBAQCB6ZnNfdmdldCh2 ZnNfdCAqdmZzcCwgaW5vX3QgaW5vLCBpbnQgZmxhCiAJICogLnpmcy9zbmFwc2hvdC8gZGlyZWN0 b3JpZXMsIHRoYXQncyB3aHkgd2UgcmV0dXJuIEVPUE5PVFNVUFAuCiAJICogVGhpcyB3aWxsIG1h a2UgTkZTIHRvIHN3aXRjaCB0byBMT09LVVAgaW5zdGVhZCBvZiB1c2luZyBWR0VULgogCSAqLwot CWlmIChpbm8gPT0gWkZTQ1RMX0lOT19ST09UIHx8IGlubyA9PSBaRlNDVExfSU5PX1NOQVBESVIp CisJaWYgKGlubyA9PSBaRlNDVExfSU5PX1JPT1QgfHwgaW5vID09IFpGU0NUTF9JTk9fU05BUERJ UiB8fAorCSAgICAoemZzdmZzLT56X3NoYXJlc19kaXIgIT0gMCAmJiBpbm8gPT0gemZzdmZzLT56 X3NoYXJlc19kaXIpKQogCQlyZXR1cm4gKEVPUE5PVFNVUFApOwogCiAJWkZTX0VOVEVSKHpmc3Zm cyk7CkBAIC0yMDk5LDE0ICsyMTAwLDIyIEBAIHpmc19maHRvdnAodmZzX3QgKnZmc3AsIGZpZF90 ICpmaWRwLCBpbnQKIAkJcmV0dXJuIChFSU5WQUwpOwogCX0KIAotCS8qIEEgemVybyBmaWRfZ2Vu IG1lYW5zIHdlIGFyZSBpbiB0aGUgLnpmcyBjb250cm9sIGRpcmVjdG9yaWVzICovCi0JaWYgKGZp ZF9nZW4gPT0gMCAmJgotCSAgICAob2JqZWN0ID09IFpGU0NUTF9JTk9fUk9PVCB8fCBvYmplY3Qg PT0gWkZTQ1RMX0lOT19TTkFQRElSKSkgeworCS8qCisJICogQSB6ZXJvIGZpZF9nZW4gbWVhbnMg d2UgYXJlIGluIC56ZnMgb3IgdGhlIC56ZnMvc25hcHNob3QKKwkgKiBkaXJlY3RvcnkgdHJlZS4g SWYgdGhlIG9iamVjdCA9PSB6ZnN2ZnMtPnpfc2hhcmVzX2RpciwgdGhlbgorCSAqIHdlIGFyZSBp biB0aGUgLnpmcy9zaGFyZXMgZGlyZWN0b3J5IHRyZWUuCisJICovCisJaWYgKChmaWRfZ2VuID09 IDAgJiYKKwkgICAgIChvYmplY3QgPT0gWkZTQ1RMX0lOT19ST09UIHx8IG9iamVjdCA9PSBaRlND VExfSU5PX1NOQVBESVIpKSB8fAorCSAgICAoemZzdmZzLT56X3NoYXJlc19kaXIgIT0gMCAmJiBv YmplY3QgPT0gemZzdmZzLT56X3NoYXJlc19kaXIpKSB7CiAJCSp2cHAgPSB6ZnN2ZnMtPnpfY3Rs ZGlyOwogCQlBU1NFUlQoKnZwcCAhPSBOVUxMKTsKIAkJaWYgKG9iamVjdCA9PSBaRlNDVExfSU5P X1NOQVBESVIpIHsKIAkJCVZFUklGWSh6ZnNjdGxfcm9vdF9sb29rdXAoKnZwcCwgInNuYXBzaG90 IiwgdnBwLCBOVUxMLAogCQkJICAgIDAsIE5VTEwsIE5VTEwsIE5VTEwsIE5VTEwsIE5VTEwpID09 IDApOworCQl9IGVsc2UgaWYgKG9iamVjdCA9PSB6ZnN2ZnMtPnpfc2hhcmVzX2RpcikgeworCQkJ VkVSSUZZKHpmc2N0bF9yb290X2xvb2t1cCgqdnBwLCAic2hhcmVzIiwgdnBwLCBOVUxMLAorCQkJ ICAgIDAsIE5VTEwsIE5VTEwsIE5VTEwsIE5VTEwsIE5VTEwpID09IDApOwogCQl9IGVsc2Ugewog CQkJVk5fSE9MRCgqdnBwKTsKIAkJfQo= ------=_Part_2814575_1074866324.1360280586899-- From owner-freebsd-current@FreeBSD.ORG Fri Feb 8 00:43:56 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id BE8D95AC; Fri, 8 Feb 2013 00:43:56 +0000 (UTC) (envelope-from f0andrey@gmail.com) Received: from mail-wg0-f51.google.com (mail-wg0-f51.google.com [74.125.82.51]) by mx1.freebsd.org (Postfix) with ESMTP id 2AA1AA06; Fri, 8 Feb 2013 00:43:55 +0000 (UTC) Received: by mail-wg0-f51.google.com with SMTP id 8so2556384wgl.30 for ; Thu, 07 Feb 2013 16:43:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=8wURsjdPOUPMgX+mogOjGS44kfFtrlw19+UH7VvStvo=; b=PyXe6RSsrm3fjyhxM/fC/TEWv8R6Vygp5O52ivCCnGwp4foYsNdcSu+0r+dXWwHYHG 62+CJ5T9ial1/vkK4GNQL1rwnCqMLQAn82n7qexQeiJxU0bjRCm3TfRr1DhsUsh8qNns BPf2meCzVBlZ2zlxkdQoC50rm8LRW2Pj0wAwl61GfcSIB7N6jIJYYjQIYAU/iLRH/37e jSbJjyE/Yx0Q3NWcgSmWHUtI+UkKGKDrjV8Ros1IZQyxVSWBOsT6Jo/5ksiSEn4M6tbC cYqGQ19/TXCDD/lWBEE/kkgYgZkD34OK4DeCVLGnNrnpQ219M6vMyS1pgemD568u1w7P 26Vw== MIME-Version: 1.0 X-Received: by 10.180.72.232 with SMTP id g8mr15299767wiv.0.1360284234846; Thu, 07 Feb 2013 16:43:54 -0800 (PST) Received: by 10.194.41.10 with HTTP; Thu, 7 Feb 2013 16:43:54 -0800 (PST) Date: Fri, 8 Feb 2013 00:43:54 +0000 Message-ID: Subject: SDL No available video device (sdl12 installed) From: Andrey Fesenko To: freebsd-current , freebsd-x11@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 08 Feb 2013 00:43:56 -0000 Hello, do not run the game using sdl. % uname -a FreeBSD x220.local 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r246229: Sat Feb 2 17:42:00 UTC 2013 andrey@x220.local:/usr/obj/usr/src/sys/W_BOOK amd64 # cat /etc/make.conf WITH_NEW_XORG=true WITH_KMS=true X.Org X Server 1.10.6 Release Date: 2012-02-10 intel(0): Integrated Graphics Chipset: Intel(R) Sandybridge Mobile (GT2+) # pkg info | grep ^sdl sdl-1.2.15_2,2 Cross-platform multimedia development API sdl_gfx-2.0.23 SDL graphics drawing primitives and other support functions sdl_image-1.2.12_1 A simple library to load images of various formats as SDL surfaces sdl_mixer-1.2.12_2 A sample multi-channel audio mixer library sdl_net-1.2.8 A small sample cross-platform networking library sdl_pango-0.1.2_7 SDL_Pango is the SDL API to the Pango text rendering engine of GNOME 2.x sdl_ttf-2.0.11 A library to use TrueType fonts to render text in SDL applications % sdl-config --version 1.2.15 % sdl-config --libs -L/usr/local/lib -Wl,-rpath,/usr/local/lib -lSDL -pthread % sdl-config --cflags -I/usr/local/include/SDL -I/usr/local/include -D_GNU_SOURCE=1 -D_REENTRANT % ufo ... ------- video initialization ------- Video SDL_Init failed: No available video device % openttd -I OpenGFX -S OpenSFX -M OpenMSX Error: Couldn't find any suitable video driver % openttd -I OpenGFX -S OpenSFX -M OpenMSX -v sdl Error: Unable to load driver 'sdl'. The error was: No available video device From owner-freebsd-current@FreeBSD.ORG Fri Feb 8 00:59:22 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 8F3D29A2; Fri, 8 Feb 2013 00:59:22 +0000 (UTC) (envelope-from andy@neu.net) Received: from mail.neu.net (neu.net [199.48.129.194]) by mx1.freebsd.org (Postfix) with ESMTP id 3654EAD2; Fri, 8 Feb 2013 00:59:19 +0000 (UTC) Received: from neu.net (neu.net [199.48.129.194]) by mail.neu.net (8.14.6/8.14.5) with ESMTP id r180xBoO030803; Thu, 7 Feb 2013 19:59:11 -0500 (EST) (envelope-from andy@neu.net) Date: Thu, 7 Feb 2013 19:59:11 -0500 (EST) From: AN To: freebsd-current@freebsd.org, freebsd-security@freebsd.org Subject: FYI - OpenSSL Security Advisory [05 Feb 2013] In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Virus-Scanned: clamav-milter 0.97.6 at my.mail.server X-Virus-Status: Clean X-Spam-Status: No, score=0.0 required=4.5 tests=RP_MATCHES_RCVD autolearn=unavailable version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on mail.neu.net X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 08 Feb 2013 00:59:22 -0000 SSL, TLS and DTLS Plaintext Recovery Attack (CVE-2013-0169) http://www.mail-archive.com/openssl-announce@openssl.org/msg00124.html http://www.isg.rhul.ac.uk/tls/ From owner-freebsd-current@FreeBSD.ORG Fri Feb 8 03:01:04 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9168A718 for ; Fri, 8 Feb 2013 03:01:04 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) by mx1.freebsd.org (Postfix) with ESMTP id 6C214FA3 for ; Fri, 8 Feb 2013 03:01:04 +0000 (UTC) Received: by mail-pa0-f54.google.com with SMTP id fa10so1758304pad.13 for ; Thu, 07 Feb 2013 19:01:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=3rNxy1C8i1YIkOqBO9HkiqvSlCfnKD4qJ0zEFioThDQ=; b=bUEDBEo7cAt8ScDpXwLS9bf0WMvVWq6HvtsDdBwHPzag5YsRxOSTczYhSPaHZ2iwFa qqR6CDC8zg3hNRIw2n1qlPY95hqnDAwWpeUY7jI+qwyCGWz0Go7dwt90+TexTy8ldZU5 yknx0EPwaI6kMSNBkLOsFpyl5wcqzu7gZ+9BU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=3rNxy1C8i1YIkOqBO9HkiqvSlCfnKD4qJ0zEFioThDQ=; b=Z1wljdPyPVjOwVftIfGMWsx6Fwr9n7gSjwftDrhkQSJE2410roEQfKE++rd9nioxsp 0o3yAx9Xu6WXrtbBBtGdcYt0Jk2HVCCCIcyYcHiyzoUXf5wgIBai7XiJEidELYMhJhB/ tLJLqdyua04iUGHgXp0kR1lHslkQH4sPUQpvBcDooOFzQxw1T+2iB2peIsln5zlqKcyK NrhVAP9cQ5D8EwFLICPS9NRie91FBg3PcXE6B1nLsCI9gOd6TwXM3TJ4wIbhlH9aht/Y OhNy+ON2y8c5D646ayScX1u7/K33FAY+pA5YnMeiunotFHIWKeX9Q2m91xnjsZJL5cma uVWg== X-Received: by 10.66.74.234 with SMTP id x10mr12482564pav.10.1360292463250; Thu, 07 Feb 2013 19:01:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.66.148.10 with HTTP; Thu, 7 Feb 2013 19:00:33 -0800 (PST) In-Reply-To: References: <51141769.5060905@FreeBSD.org> From: Eitan Adler Date: Thu, 7 Feb 2013 22:00:33 -0500 Message-ID: Subject: Re: CLANG and -fstack-protector To: Kimmo Paasiala Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQmYjv72OMQGSDWpwejL+cpqwj456vnE4AxjuUN0s6pmQtefrpRU6KWpiOvZg8b37OXGjrr0 Cc: freebsd-stable@freebsd.org, FreeBSD current , Dimitry Andric X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 08 Feb 2013 03:01:04 -0000 On 7 February 2013 18:40, Kimmo Paasiala wrote: >> Ports are largely independent of the base system, and their compilation >> flags are different from port to port. You could set -fstack-protector >> for your ports in either make.conf or ports.conf, if you wanted. > > Is there any work being done to provide an optional Makefile knob > (WITH_STACK_PROTECTOR ?) to turn on -fstack-protector for ports that > install network services (or other critical code)? I'd bet such > feature would be popular. As far as I am aware no such feature exists. In any case it would be subject to the same problem of many ports ignoring CFLAGS and friends. -- Eitan Adler From owner-freebsd-current@FreeBSD.ORG Fri Feb 8 07:37:23 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id AEA7DEE; Fri, 8 Feb 2013 07:37:23 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id C175B957; Fri, 8 Feb 2013 07:37:22 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id JAA07938; Fri, 08 Feb 2013 09:37:21 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1U3iWO-0002Tt-Si; Fri, 08 Feb 2013 09:37:20 +0200 Message-ID: <5114AB2E.2050909@FreeBSD.org> Date: Fri, 08 Feb 2013 09:37:18 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130121 Thunderbird/17.0.2 MIME-Version: 1.0 To: FreeBSD Current Subject: call suspend_cpus() under smp_ipi_mtx X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=X-VIET-VPS Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 08 Feb 2013 07:37:23 -0000 Could you please review and/or test the following patch? The idea is exactly the same as for cpu_stop() invocation in the shutdown path. Please note that I've kept intr_disable() just because potentially mtx_lock_spin could be implemented in such a way that it wouldn't block all interrupts via CPU flags, but would use LAPIC TPR, for example. I've also decided to add smp_ipi_mtx assertions to suspend_cpus and stop_cpus. diff --git a/sys/dev/acpica/acpi.c b/sys/dev/acpica/acpi.c index f0c750f..9750d46 100644 --- a/sys/dev/acpica/acpi.c +++ b/sys/dev/acpica/acpi.c @@ -2741,6 +2741,15 @@ acpi_EnterSleepState(struct acpi_softc *sc, int state) if (sc->acpi_sleep_delay > 0) DELAY(sc->acpi_sleep_delay * 1000000); +#ifdef SMP + /* + * Prevent inter-CPU deadlock possibility between suspend_cpus() + * and other inter-CPU synchronous calls like smp_rendezvous and + * TLB shootdowns. + */ + if (state != ACPI_STATE_S1) + mtx_lock_spin(&smp_ipi_mtx); +#endif intr = intr_disable(); if (state != ACPI_STATE_S1) { sleep_result = acpi_sleep_machdep(sc, state); @@ -2784,6 +2793,9 @@ acpi_EnterSleepState(struct acpi_softc *sc, int state) } intr_restore(intr); +#ifdef SMP + mtx_unlock_spin(&smp_ipi_mtx); +#endif /* call acpi_wakeup_machdep() again with interrupt enabled */ acpi_wakeup_machdep(sc, state, sleep_result, 1); diff --git a/sys/kern/subr_smp.c b/sys/kern/subr_smp.c index 3614798..edf16db 100644 --- a/sys/kern/subr_smp.c +++ b/sys/kern/subr_smp.c @@ -260,6 +260,7 @@ int stop_cpus(cpuset_t map) { + mtx_assert(&smp_ipi_mtx, MA_OWNED); return (generic_stop_cpus(map, IPI_STOP)); } @@ -275,6 +276,7 @@ int suspend_cpus(cpuset_t map) { + mtx_assert(&smp_ipi_mtx, MA_OWNED); return (generic_stop_cpus(map, IPI_SUSPEND)); } #endif -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Fri Feb 8 07:51:47 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 00F04856 for ; Fri, 8 Feb 2013 07:51:46 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 461D3A2D for ; Fri, 8 Feb 2013 07:51:45 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id JAA08030; Fri, 08 Feb 2013 09:51:41 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1U3ikH-0002VN-B2; Fri, 08 Feb 2013 09:51:41 +0200 Message-ID: <5114AE8C.30109@FreeBSD.org> Date: Fri, 08 Feb 2013 09:51:40 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130121 Thunderbird/17.0.2 MIME-Version: 1.0 To: Rick Macklem Subject: Re: panic: LK_RETRY set with incompatible flags References: <1644867646.2814542.1360280498907.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <1644867646.2814542.1360280498907.JavaMail.root@erie.cs.uoguelph.ca> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Konstantin Belousov , Sergey Kandaurov , FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 08 Feb 2013 07:51:47 -0000 on 08/02/2013 01:41 Rick Macklem said the following: > Sounds good. I've attached a slightly updated patch with Andriy's > suggested addition of a check for zfsvfs->z_shares_dir != 0. > > I can't do any commits until April, so if one of you guys is comfortable > enough with the patch to commit it, you are more than welcome to do so. > > Thanks everyone for your help in resolving this, rick Committed. Thank you very much! -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Fri Feb 8 08:57:25 2013 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E0FCA4ED; Fri, 8 Feb 2013 08:57:25 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay06.ispgateway.de (smtprelay06.ispgateway.de [80.67.31.102]) by mx1.freebsd.org (Postfix) with ESMTP id A3E8EFF; Fri, 8 Feb 2013 08:57:25 +0000 (UTC) Received: from [78.35.140.107] (helo=fabiankeil.de) by smtprelay06.ispgateway.de with esmtpsa (SSLv3:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1U3jlr-0003t7-SV; Fri, 08 Feb 2013 09:57:23 +0100 Date: Fri, 8 Feb 2013 09:57:09 +0100 From: Fabian Keil To: Ulrich =?UTF-8?B?U3DDtnJsZWlu?= Subject: Re: geli(8) breaks after a couple hours of uptime Message-ID: <20130208095709.6ae61cff@fabiankeil.de> In-Reply-To: <20130207180153.GX35868@acme.spoerlein.net> References: <20130207141833.GA15884@acme.spoerlein.net> <20130207153322.5c371beb@fabiankeil.de> <20130207180153.GX35868@acme.spoerlein.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/h++L8yc30rwoEDsDec_f+m5"; protocol="application/pgp-signature" X-Df-Sender: Nzc1MDY3 Cc: current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 08 Feb 2013 08:57:25 -0000 --Sig_/h++L8yc30rwoEDsDec_f+m5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Ulrich Sp=C3=B6rlein wrote: > On Thu, 2013-02-07 at 15:33:22 +0100, Fabian Keil wrote: > > Ulrich Sp=C3=B6rlein wrote: > >=20 > > > Yes, it's pretty much as weird as it sounds. All new machine, forklif= ted > > > the image from on old i386 machine running 8.x to current on amd64. > > >=20 > > > Everything seemingly works fine, attaching geli volumes shortly after > > > boot is fine, attached devices continue to work fine. There are no > > > strange crashes with this machine or anything, but when I try to atta= ch > > > an USB volume the next day, geli attach segfaults. > >=20 > > This could be: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=3D174831 > Except it happens to me when run as root, and: Depending on your settings the limit could still apply. Did you check with ulimit -l to be sure? > root@coyote:~# sysctl vm.old_mlock > vm.old_mlock: 0 Looks like I got the logic wrong in the PR ... fk@r500 ~ $sysctl -d vm.old_mlock vm.old_mlock: Do not apply RLIMIT_MEMLOCK on mlockall Fabian --Sig_/h++L8yc30rwoEDsDec_f+m5 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlEUvfcACgkQBYqIVf93VJ3fVACgnx429Dv/ClOXdIazkKioJ4QG QGAAnRfpp305wunsNV48sxvFJRD7AHBb =mkuc -----END PGP SIGNATURE----- --Sig_/h++L8yc30rwoEDsDec_f+m5-- From owner-freebsd-current@FreeBSD.ORG Fri Feb 8 10:39:06 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id F313ABF3; Fri, 8 Feb 2013 10:39:05 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id CAFDEAC2; Fri, 8 Feb 2013 10:39:05 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r18APC7Y081614; Fri, 8 Feb 2013 05:25:12 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r18APCtX081594; Fri, 8 Feb 2013 10:25:12 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 8 Feb 2013 10:25:12 GMT Message-Id: <201302081025.r18APCtX081594@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on mips/mips Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Feb 2013 10:39:06 -0000 TB --- 2013-02-08 09:22:13 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-02-08 09:22:13 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-02-08 09:22:13 - starting HEAD tinderbox run for mips/mips TB --- 2013-02-08 09:22:13 - cleaning the object tree TB --- 2013-02-08 09:22:13 - /usr/local/bin/svn stat /src TB --- 2013-02-08 09:22:17 - At svn revision 246529 TB --- 2013-02-08 09:22:18 - building world TB --- 2013-02-08 09:22:18 - CROSS_BUILD_TESTING=YES TB --- 2013-02-08 09:22:18 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-08 09:22:18 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-08 09:22:18 - SRCCONF=/dev/null TB --- 2013-02-08 09:22:18 - TARGET=mips TB --- 2013-02-08 09:22:18 - TARGET_ARCH=mips TB --- 2013-02-08 09:22:18 - TZ=UTC TB --- 2013-02-08 09:22:18 - __MAKE_CONF=/dev/null TB --- 2013-02-08 09:22:18 - cd /src TB --- 2013-02-08 09:22:18 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Fri Feb 8 09:22:22 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Fri Feb 8 10:22:20 UTC 2013 TB --- 2013-02-08 10:22:20 - cd /src/sys/mips/conf TB --- 2013-02-08 10:22:20 - /usr/sbin/config -m ADM5120 TB --- 2013-02-08 10:22:20 - skipping ADM5120 kernel TB --- 2013-02-08 10:22:20 - cd /src/sys/mips/conf TB --- 2013-02-08 10:22:20 - /usr/sbin/config -m ALCHEMY TB --- 2013-02-08 10:22:20 - skipping ALCHEMY kernel TB --- 2013-02-08 10:22:20 - cd /src/sys/mips/conf TB --- 2013-02-08 10:22:20 - /usr/sbin/config -m AP91 TB --- 2013-02-08 10:22:20 - building AP91 kernel TB --- 2013-02-08 10:22:20 - CROSS_BUILD_TESTING=YES TB --- 2013-02-08 10:22:20 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-08 10:22:20 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-08 10:22:20 - SRCCONF=/dev/null TB --- 2013-02-08 10:22:20 - TARGET=mips TB --- 2013-02-08 10:22:20 - TARGET_ARCH=mips TB --- 2013-02-08 10:22:20 - TZ=UTC TB --- 2013-02-08 10:22:20 - __MAKE_CONF=/dev/null TB --- 2013-02-08 10:22:20 - cd /src TB --- 2013-02-08 10:22:20 - /usr/bin/make -B buildkernel KERNCONF=AP91 >>> Kernel build for AP91 started on Fri Feb 8 10:22:21 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -O -pipe -G0 -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/mips.mips/src/sys/AP91/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -G0 -fno-pic -mno-abicalls -mlong-calls -I/obj/mips.mips/src/sys/AP91 -msoft-float -ffreestanding -std=iso9899:1999 -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 -c /src/sys/modules/wlan/../../net80211/ieee80211_input.c cc -O -pipe -G0 -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/mips.mips/src/sys/AP91/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -G0 -fno-pic -mno-abicalls -mlong-calls -I/obj/mips.mips/src/sys/AP91 -msoft-float -ffreestanding -std=iso9899:1999 -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 -c /src/sys/modules/wlan/../../net80211/ieee80211_ioctl.c cc -O -pipe -G0 -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/mips.mips/src/sys/AP91/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -G0 -fno-pic -mno-abicalls -mlong-calls -I/obj/mips.mips/src/sys/AP91 -msoft-float -ffreestanding -std=iso9899:1999 -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 -c /src/sys/modules/wlan/../../net80211/ieee80211_mesh.c cc1: warnings being treated as errors /src/sys/modules/wlan/../../net80211/ieee80211_mesh.c: In function 'mesh_transmit_to_gate': /src/sys/modules/wlan/../../net80211/ieee80211_mesh.c:1124: warning: implicit declaration of function 'ieee80211_ff_check' /src/sys/modules/wlan/../../net80211/ieee80211_mesh.c:1124: warning: nested extern declaration of 'ieee80211_ff_check' [-Wnested-externs] /src/sys/modules/wlan/../../net80211/ieee80211_mesh.c:1124: warning: assignment makes pointer from integer without a cast *** [ieee80211_mesh.o] Error code 1 Stop in /src/sys/modules/wlan. *** [all] Error code 1 Stop in /src/sys/modules. *** [modules-all] Error code 1 Stop in /obj/mips.mips/src/sys/AP91. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-02-08 10:25:12 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-02-08 10:25:12 - ERROR: failed to build AP91 kernel TB --- 2013-02-08 10:25:12 - 2780.33 user 649.06 system 3779.08 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-mips-mips.full From owner-freebsd-current@FreeBSD.ORG Fri Feb 8 11:28:48 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 90B474D3; Fri, 8 Feb 2013 11:28:48 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) by mx1.freebsd.org (Postfix) with ESMTP id CD568E34; Fri, 8 Feb 2013 11:28:47 +0000 (UTC) Received: by mail-wi0-f179.google.com with SMTP id ez12so704223wid.0 for ; Fri, 08 Feb 2013 03:28:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=fKG62IAn1avtODbhU3GXG+covLyb5g8tURWoEJGKb5I=; b=uv9efqnM/twzwA9AEfdSivhbPENNOsyGBHtoF0aMZ2yAO7w3a0WVs+qb/sGENmnkxn abaoOAeoz0Cxq8DG4RnlumBKTzxRVzCHYryUUjFvYCg8lW0+dxqaW1LyGxfJNMcmKkS2 qv7szbZ8H5rK0sfiKiLWCUsTjEqyG+004r0PCwSArAUBWc/QArknGpWHg908HTRHDWQ6 Qf+jXNI7Q4qvba9HEYst8El4keRk27LOIRvZgSRm9mIpdBvzC0qhHby77rCDB0zfCoUE Q+aPOqg5mpVGYWP8+nvyPRF3/hvmUP/ZqYDO9hGWKxJ331N7ck+B5jbc0WHyjQ6hRuo7 TIcw== MIME-Version: 1.0 X-Received: by 10.181.12.103 with SMTP id ep7mr1810841wid.12.1360322926824; Fri, 08 Feb 2013 03:28:46 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.236.88 with HTTP; Fri, 8 Feb 2013 03:28:46 -0800 (PST) In-Reply-To: <201302081025.r18APCtX081594@freebsd-current.sentex.ca> References: <201302081025.r18APCtX081594@freebsd-current.sentex.ca> Date: Fri, 8 Feb 2013 03:28:46 -0800 X-Google-Sender-Auth: za5QVtfl0kEhHFoi_-Y5bn8k78A Message-ID: Subject: Re: [head tinderbox] failure on mips/mips From: Adrian Chadd To: FreeBSD Tinderbox Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mips@freebsd.org, current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 08 Feb 2013 11:28:48 -0000 Fixed. Adrian On 8 February 2013 02:25, FreeBSD Tinderbox wrote: > TB --- 2013-02-08 09:22:13 - tinderbox 2.10 running on freebsd-current.se= ntex.ca > TB --- 2013-02-08 09:22:13 - FreeBSD freebsd-current.sentex.ca 8.3-PREREL= EASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebs= d-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 > TB --- 2013-02-08 09:22:13 - starting HEAD tinderbox run for mips/mips > TB --- 2013-02-08 09:22:13 - cleaning the object tree > TB --- 2013-02-08 09:22:13 - /usr/local/bin/svn stat /src > TB --- 2013-02-08 09:22:17 - At svn revision 246529 > TB --- 2013-02-08 09:22:18 - building world > TB --- 2013-02-08 09:22:18 - CROSS_BUILD_TESTING=3DYES > TB --- 2013-02-08 09:22:18 - MAKEOBJDIRPREFIX=3D/obj > TB --- 2013-02-08 09:22:18 - PATH=3D/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2013-02-08 09:22:18 - SRCCONF=3D/dev/null > TB --- 2013-02-08 09:22:18 - TARGET=3Dmips > TB --- 2013-02-08 09:22:18 - TARGET_ARCH=3Dmips > TB --- 2013-02-08 09:22:18 - TZ=3DUTC > TB --- 2013-02-08 09:22:18 - __MAKE_CONF=3D/dev/null > TB --- 2013-02-08 09:22:18 - cd /src > TB --- 2013-02-08 09:22:18 - /usr/bin/make -B buildworld >>>> Building an up-to-date make(1) >>>> World build started on Fri Feb 8 09:22:22 UTC 2013 >>>> Rebuilding the temporary build tree >>>> stage 1.1: legacy release compatibility shims >>>> stage 1.2: bootstrap tools >>>> stage 2.1: cleaning up the object tree >>>> stage 2.2: rebuilding the object tree >>>> stage 2.3: build tools >>>> stage 3: cross tools >>>> stage 4.1: building includes >>>> stage 4.2: building libraries >>>> stage 4.3: make dependencies >>>> stage 4.4: building everything >>>> World build completed on Fri Feb 8 10:22:20 UTC 2013 > TB --- 2013-02-08 10:22:20 - cd /src/sys/mips/conf > TB --- 2013-02-08 10:22:20 - /usr/sbin/config -m ADM5120 > TB --- 2013-02-08 10:22:20 - skipping ADM5120 kernel > TB --- 2013-02-08 10:22:20 - cd /src/sys/mips/conf > TB --- 2013-02-08 10:22:20 - /usr/sbin/config -m ALCHEMY > TB --- 2013-02-08 10:22:20 - skipping ALCHEMY kernel > TB --- 2013-02-08 10:22:20 - cd /src/sys/mips/conf > TB --- 2013-02-08 10:22:20 - /usr/sbin/config -m AP91 > TB --- 2013-02-08 10:22:20 - building AP91 kernel > TB --- 2013-02-08 10:22:20 - CROSS_BUILD_TESTING=3DYES > TB --- 2013-02-08 10:22:20 - MAKEOBJDIRPREFIX=3D/obj > TB --- 2013-02-08 10:22:20 - PATH=3D/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2013-02-08 10:22:20 - SRCCONF=3D/dev/null > TB --- 2013-02-08 10:22:20 - TARGET=3Dmips > TB --- 2013-02-08 10:22:20 - TARGET_ARCH=3Dmips > TB --- 2013-02-08 10:22:20 - TZ=3DUTC > TB --- 2013-02-08 10:22:20 - __MAKE_CONF=3D/dev/null > TB --- 2013-02-08 10:22:20 - cd /src > TB --- 2013-02-08 10:22:20 - /usr/bin/make -B buildkernel KERNCONF=3DAP91 >>>> Kernel build for AP91 started on Fri Feb 8 10:22:21 UTC 2013 >>>> stage 1: configuring the kernel >>>> stage 2.1: cleaning up the object tree >>>> stage 2.2: rebuilding the object tree >>>> stage 2.3: build tools >>>> stage 3.1: making dependencies >>>> stage 3.2: building everything > [...] > cc -O -pipe -G0 -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_= OPTION_HEADERS -include /obj/mips.mips/src/sys/AP91/opt_global.h -I. -I@ -I= @/contrib/altq -finline-limit=3D8000 --param inline-unit-growth=3D100 --par= am large-function-growth=3D1000 -fno-common -g -G0 -fno-pic -mno-abicalls -= mlong-calls -I/obj/mips.mips/src/sys/AP91 -msoft-float -ffreestanding -std= =3Diso9899:1999 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototype= s -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-= pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show= -option -c /src/sys/modules/wlan/../../net80211/ieee80211_input.c > cc -O -pipe -G0 -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_= OPTION_HEADERS -include /obj/mips.mips/src/sys/AP91/opt_global.h -I. -I@ -I= @/contrib/altq -finline-limit=3D8000 --param inline-unit-growth=3D100 --par= am large-function-growth=3D1000 -fno-common -g -G0 -fno-pic -mno-abicalls -= mlong-calls -I/obj/mips.mips/src/sys/AP91 -msoft-float -ffreestanding -std= =3Diso9899:1999 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototype= s -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-= pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show= -option -c /src/sys/modules/wlan/../../net80211/ieee80211_ioctl.c > cc -O -pipe -G0 -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_= OPTION_HEADERS -include /obj/mips.mips/src/sys/AP91/opt_global.h -I. -I@ -I= @/contrib/altq -finline-limit=3D8000 --param inline-unit-growth=3D100 --par= am large-function-growth=3D1000 -fno-common -g -G0 -fno-pic -mno-abicalls -= mlong-calls -I/obj/mips.mips/src/sys/AP91 -msoft-float -ffreestanding -std= =3Diso9899:1999 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototype= s -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-= pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show= -option -c /src/sys/modules/wlan/../../net80211/ieee80211_mesh.c > cc1: warnings being treated as errors > /src/sys/modules/wlan/../../net80211/ieee80211_mesh.c: In function 'mesh_= transmit_to_gate': > /src/sys/modules/wlan/../../net80211/ieee80211_mesh.c:1124: warning: impl= icit declaration of function 'ieee80211_ff_check' > /src/sys/modules/wlan/../../net80211/ieee80211_mesh.c:1124: warning: nest= ed extern declaration of 'ieee80211_ff_check' [-Wnested-externs] > /src/sys/modules/wlan/../../net80211/ieee80211_mesh.c:1124: warning: assi= gnment makes pointer from integer without a cast > *** [ieee80211_mesh.o] Error code 1 > > Stop in /src/sys/modules/wlan. > *** [all] Error code 1 > > Stop in /src/sys/modules. > *** [modules-all] Error code 1 > > Stop in /obj/mips.mips/src/sys/AP91. > *** [buildkernel] Error code 1 > > Stop in /src. > *** Error code 1 > > Stop in /src. > TB --- 2013-02-08 10:25:12 - WARNING: /usr/bin/make returned exit code 1 > TB --- 2013-02-08 10:25:12 - ERROR: failed to build AP91 kernel > TB --- 2013-02-08 10:25:12 - 2780.33 user 649.06 system 3779.08 real > > > http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-mips-mips.full > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " From owner-freebsd-current@FreeBSD.ORG Fri Feb 8 11:48:29 2013 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 2D89EABD; Fri, 8 Feb 2013 11:48:29 +0000 (UTC) (envelope-from uqs@FreeBSD.org) Received: from acme.spoerlein.net (acme.spoerlein.net [IPv6:2a01:4f8:131:23c2::1]) by mx1.freebsd.org (Postfix) with ESMTP id 87E32F25; Fri, 8 Feb 2013 11:48:28 +0000 (UTC) Received: from localhost (acme.spoerlein.net [IPv6:2a01:4f8:131:23c2::1]) by acme.spoerlein.net (8.14.6/8.14.6) with ESMTP id r18BmQEq044930 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 8 Feb 2013 12:48:26 +0100 (CET) (envelope-from uqs@FreeBSD.org) Date: Fri, 8 Feb 2013 12:48:25 +0100 From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= To: Fabian Keil , zont@FreeBSD.org, avg@FreeBSD.org Subject: Re: geli(8) breaks after a couple hours of uptime Message-ID: <20130208114825.GY35868@acme.spoerlein.net> Mail-Followup-To: Fabian Keil , zont@FreeBSD.org, avg@FreeBSD.org, current@FreeBSD.org References: <20130207141833.GA15884@acme.spoerlein.net> <20130207153322.5c371beb@fabiankeil.de> <20130207180153.GX35868@acme.spoerlein.net> <20130208095709.6ae61cff@fabiankeil.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20130208095709.6ae61cff@fabiankeil.de> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 08 Feb 2013 11:48:29 -0000 On Fri, 2013-02-08 at 09:57:09 +0100, Fabian Keil wrote: > Ulrich Spörlein wrote: > > > On Thu, 2013-02-07 at 15:33:22 +0100, Fabian Keil wrote: > > > Ulrich Spörlein wrote: > > > > > > > Yes, it's pretty much as weird as it sounds. All new machine, forklifted > > > > the image from on old i386 machine running 8.x to current on amd64. > > > > > > > > Everything seemingly works fine, attaching geli volumes shortly after > > > > boot is fine, attached devices continue to work fine. There are no > > > > strange crashes with this machine or anything, but when I try to attach > > > > an USB volume the next day, geli attach segfaults. > > > > > > This could be: > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=174831 > > > Except it happens to me when run as root, and: > > Depending on your settings the limit could still apply. > Did you check with ulimit -l to be sure? > > > root@coyote:~# sysctl vm.old_mlock > > vm.old_mlock: 0 > > Looks like I got the logic wrong in the PR ... > > fk@r500 ~ $sysctl -d vm.old_mlock > vm.old_mlock: Do not apply RLIMIT_MEMLOCK on mlockall > > Fabian Of course! root@coyote:~# ulimit -l 64 The problem here is that I login via my user account, then either use sudo or sudo -i for a root shell, this however does not raise the memorylocked limit. So when I said this works during boot and shortly after, it's because I haven't started my screen session yet, through which I do all the work, usually, but have logged in with a direct root shell. D'oh! It looks like 128k as a limit is still too low for geli(8) to work, and I've set it to 256k now, so that I can use "sudo geli". Can you maybe revise the patch to not use 1024k as an arbitrary limit, but rather make sure you test for precisely as much memory as will be needed? Also, can we maybe revisit the new 64k default limit, as it will obviously make peoples work with geli a bit painful, this should work out of the box. Thanks Uli From owner-freebsd-current@FreeBSD.ORG Fri Feb 8 12:36:48 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 3CF9B804 for ; Fri, 8 Feb 2013 12:36:48 +0000 (UTC) (envelope-from jakub_lach@mailplus.pl) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) by mx1.freebsd.org (Postfix) with ESMTP id 2281823B for ; Fri, 8 Feb 2013 12:36:47 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1U3nCA-000133-S3 for freebsd-current@freebsd.org; Fri, 08 Feb 2013 04:36:46 -0800 Date: Fri, 8 Feb 2013 04:36:46 -0800 (PST) From: Jakub Lach To: freebsd-current@freebsd.org Message-ID: <1360327006855-5784992.post@n5.nabble.com> In-Reply-To: References: <51141769.5060905@FreeBSD.org> Subject: Re: CLANG and -fstack-protector MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 08 Feb 2013 12:36:48 -0000 Closest would be http://www.freebsd.org/news/status/report-2008-01-2008-03.html#ProPolice-support-for-FreeBSD but port part it was not committed. -- View this message in context: http://freebsd.1045724.n5.nabble.com/CLANG-and-fstack-protector-tp5784739p5784992.html Sent from the freebsd-current mailing list archive at Nabble.com. From owner-freebsd-current@FreeBSD.ORG Fri Feb 8 12:46:13 2013 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 35931A81; Fri, 8 Feb 2013 12:46:13 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 4F7D42A9; Fri, 8 Feb 2013 12:46:11 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id OAA10755; Fri, 08 Feb 2013 14:46:08 +0200 (EET) (envelope-from avg@FreeBSD.org) Message-ID: <5114F390.4010302@FreeBSD.org> Date: Fri, 08 Feb 2013 14:46:08 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130206 Thunderbird/17.0.2 MIME-Version: 1.0 To: Fabian Keil , zont@FreeBSD.org, current@FreeBSD.org Subject: Re: geli(8) breaks after a couple hours of uptime References: <20130207141833.GA15884@acme.spoerlein.net> <20130207153322.5c371beb@fabiankeil.de> <20130207180153.GX35868@acme.spoerlein.net> <20130208095709.6ae61cff@fabiankeil.de> <20130208114825.GY35868@acme.spoerlein.net> In-Reply-To: <20130208114825.GY35868@acme.spoerlein.net> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 08 Feb 2013 12:46:13 -0000 on 08/02/2013 13:48 Ulrich Spörlein said the following: > The problem here is that I login via my user account, then either use > sudo or sudo -i for a root shell, this however does not raise the > memorylocked limit. So when I said this works during boot and shortly > after, it's because I haven't started my screen session yet, through > which I do all the work, usually, but have logged in with a direct root > shell. D'oh! > > It looks like 128k as a limit is still too low for geli(8) to work, and > I've set it to 256k now, so that I can use "sudo geli". Can you maybe > revise the patch to not use 1024k as an arbitrary limit, but rather make > sure you test for precisely as much memory as will be needed? > > Also, can we maybe revisit the new 64k default limit, as it will > obviously make peoples work with geli a bit painful, this should work > out of the box. I have some, IMO, better suggestions: - use -c option with sudo - tune your system for your needs - [major] abolish the silliness of tying resource limits to login class and apply resource limits based on user and group IDs; including after su/sudo (subject to local policies) -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Fri Feb 8 13:28:24 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 9455294C for ; Fri, 8 Feb 2013 13:28:24 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-da0-f42.google.com (mail-da0-f42.google.com [209.85.210.42]) by mx1.freebsd.org (Postfix) with ESMTP id 6DD18687 for ; Fri, 8 Feb 2013 13:28:24 +0000 (UTC) Received: by mail-da0-f42.google.com with SMTP id z17so1790042dal.1 for ; Fri, 08 Feb 2013 05:28:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=XYfXdnGCHY+gU9uWJ3CbCOnnelzWbzrMM7vFMBkQva4=; b=TUcgFqdJQC25/ecxsTfyXAG/OYd/TMTeQyqYmcJseCUefJIr5bDKxpp/J5jaunsf2I fvTNXrTwb3gCBsX5ncVbYWAxGQuevxTglxdTxzQgZ2gX1/gievj+OJd/mchaoSM1G1jk 4jT08AwRwuWXjowUbfHX6wuL5PTHC2O0JMJqk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=XYfXdnGCHY+gU9uWJ3CbCOnnelzWbzrMM7vFMBkQva4=; b=gXp1qZhYm9Cl4A40//7V05oHRcf0AgaRJVaSsPE/IR4sGp7aVE1EFCbrcYfpWh7keJ fQVqyVZfMJO6DEBpb7iYvrK9/DB9wf8DqPv3KA4eKBfYa9NkBfEzR+/17l0xnOnBvkBx p4iIbCiqPax4lGFmL9HX2hO1zByWTgfIcOP1XkBGLWiyXIYiaPvJuwZkmM2UBk84SISG PaRrUpnaKUMj7m1xY2cDjpTQNn0utxGwHK07eqRyXwEcvNkBEay7VtfAGQQUPgYFielw Ks1fwgw/jTUIooIIYkYUO2ZmXAvEqig+mJ1KhW3Px80d438IgzcJhwWX3kfWZ87+1Fgz 7Gmg== X-Received: by 10.66.76.42 with SMTP id h10mr17301533paw.59.1360330103947; Fri, 08 Feb 2013 05:28:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.66.148.10 with HTTP; Fri, 8 Feb 2013 05:27:53 -0800 (PST) In-Reply-To: <5114F390.4010302@FreeBSD.org> References: <20130207141833.GA15884@acme.spoerlein.net> <20130207153322.5c371beb@fabiankeil.de> <20130207180153.GX35868@acme.spoerlein.net> <20130208095709.6ae61cff@fabiankeil.de> <20130208114825.GY35868@acme.spoerlein.net> <5114F390.4010302@FreeBSD.org> From: Eitan Adler Date: Fri, 8 Feb 2013 08:27:53 -0500 Message-ID: Subject: Re: geli(8) breaks after a couple hours of uptime To: Andriy Gapon Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmNTqZSgWc+kn1Aqn5C1opWP0VtmgPKhqUdCrw0HdXNOMNlfwx82icOv1ZIvzHDZkL6QCDj Cc: zont@freebsd.org, current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 08 Feb 2013 13:28:24 -0000 On 8 February 2013 07:46, Andriy Gapon wrote: > on 08/02/2013 13:48 Ulrich Sp=C3=B6rlein said the following: >> The problem here is that I login via my user account, then either use >> sudo or sudo -i for a root shell, this however does not raise the >> memorylocked limit. So when I said this works during boot and shortly >> after, it's because I haven't started my screen session yet, through >> which I do all the work, usually, but have logged in with a direct root >> shell. D'oh! >> >> It looks like 128k as a limit is still too low for geli(8) to work, and >> I've set it to 256k now, so that I can use "sudo geli". Can you maybe >> revise the patch to not use 1024k as an arbitrary limit, but rather make >> sure you test for precisely as much memory as will be needed? >> >> Also, can we maybe revisit the new 64k default limit, as it will >> obviously make peoples work with geli a bit painful, this should work >> out of the box. > > I have some, IMO, better suggestions: > - use -c option with sudo > - tune your system for your needs > > - [major] abolish the silliness of tying resource limits to login class a= nd apply > resource limits based on user and group IDs; including after su/sudo (sub= ject to > local policies) The default settings should not make another feature unusable. At a minimum it should be documented in geli's man page that such tuning is required. --=20 Eitan Adler From owner-freebsd-current@FreeBSD.ORG Fri Feb 8 16:11:23 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 5A1C072C for ; Fri, 8 Feb 2013 16:11:23 +0000 (UTC) (envelope-from mattblists@icritical.com) Received: from mail2.icritical.com (mail2.icritical.com [212.57.248.50]) by mx1.freebsd.org (Postfix) with SMTP id BA0E0E8F for ; Fri, 8 Feb 2013 16:11:21 +0000 (UTC) Received: (qmail 1942 invoked from network); 8 Feb 2013 16:04:51 -0000 Received: from localhost (127.0.0.1) by mail2.icritical.com with SMTP; 8 Feb 2013 16:04:51 -0000 Received: (qmail 1934 invoked by uid 599); 8 Feb 2013 16:04:50 -0000 Received: from unknown (HELO PDC002.icritical.int) (212.57.254.146) by mail2.icritical.com (qpsmtpd/0.28) with ESMTP; Fri, 08 Feb 2013 16:04:50 +0000 Message-ID: <51152216.9080905@icritical.com> Date: Fri, 8 Feb 2013 16:04:38 +0000 From: Matt Burke User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130122 Thunderbird/17.0.2 MIME-Version: 1.0 To: Subject: [patch] Userland DTrace Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-TLS-Incoming: YES X-Virus-Scanned: by iCritical at mail2.icritical.com X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 08 Feb 2013 16:11:23 -0000 I've been spending some time trying to get the fasttrap provider to work on FreeBSD without panicing. I believe I have succeeded, at least to the point where it's no longer panicing. There were two panic causes. The first was http://www.freebsd.org/cgi/query-pr.cgi?pr=165541 - the FreeBSD port of fasttrap.c caused ftp_rcount to be left >0. To fix this I've got rid of the early return and reverted to the opensolaris way. A second panic then showed up intermittently when fasttrap_pid_cleanup_cb was run while something in userland had locks. Using sx_try_xlock calls has stopped the panics and shouldn't affect operation AFAICT. This is against r246454. Although this has fixed the panics for me, I'm finding a lot of stuff just isn't actually working, with dtrace and the traced process just chewing CPU. Truss on the dtrace shows a heck of a lot of ptrace() calls and I have no idea what the target is doing... CPU time is split 2:1 dtrace:target Also noteworthy is the LOR on the first time you try to use the fasttrap provider: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/165479 The lock order there seems right, so I'm guessing "something else" must have done it wrong first? How can I find out what the "something else" is? Thanks --- a/sys/cddl/contrib/opensolaris/uts/common/dtrace/dtrace.c +++ b/sys/cddl/contrib/opensolaris/uts/common/dtrace/dtrace.c @@ -7536,9 +7536,23 @@ dtrace_unregister(dtrace_provider_id_t id) return (EBUSY); } } else { +#if defined(sun) mutex_enter(&dtrace_provider_lock); mutex_enter(&mod_lock); mutex_enter(&dtrace_lock); +#else + if (sx_try_xlock(&dtrace_provider_lock) == 0) + return (EBUSY); + if (sx_try_xlock(&mod_lock) == 0) { + mutex_exit(&dtrace_provider_lock); + return (EBUSY); + } + if (sx_try_xlock(&dtrace_lock) == 0) { + mutex_exit(&mod_lock); + mutex_exit(&dtrace_provider_lock); + return (EBUSY); + } +#endif } /* --- a/sys/cddl/contrib/opensolaris/uts/common/dtrace/fasttrap.c +++ b/sys/cddl/contrib/opensolaris/uts/common/dtrace/fasttrap.c @@ -1116,23 +1116,28 @@ fasttrap_pid_disable(void *arg, dtrace_id_t id, void *parg) ASSERT(id == probe->ftp_id); - mutex_enter(&provider->ftp_mtx); - /* * We won't be able to acquire a /proc-esque lock on the process * iff the process is dead and gone. In this case, we rely on the * provider lock as a point of mutual exclusion to prevent other * DTrace consumers from disabling this probe. */ - if ((p = pfind(probe->ftp_pid)) == NULL) { - mutex_exit(&provider->ftp_mtx); - return; + +#if defined(sun) + if ((p = sprlock(probe->ftp_pid)) != NULL) { + ASSERT(!(p->p_flag & SVFORK)); + mutex_exit(&p->p_lock); + } +#else + if ((p = pfind(probe->ftp_pid)) != NULL) { + _PHOLD(p); + PROC_UNLOCK(p); } -#ifdef __FreeBSD__ - _PHOLD(p); - PROC_UNLOCK(p); #endif + mutex_enter(&provider->ftp_mtx); + + /* * Disable all the associated tracepoints (for fully enabled probes). */ @@ -1154,6 +1159,13 @@ fasttrap_pid_disable(void *arg, dtrace_id_t id, void *parg) if (provider->ftp_retired && !provider->ftp_marked) whack = provider->ftp_marked = 1; mutex_exit(&provider->ftp_mtx); + +#if defined(sun) + mutex_enter(&p->p_lock); + sprunlock(p); +#else + PRELE(p); +#endif } else { /* * If the process is dead, we're just waiting for the @@ -1167,9 +1179,6 @@ fasttrap_pid_disable(void *arg, dtrace_id_t id, void *parg) if (whack) fasttrap_pid_cleanup(); -#ifdef __FreeBSD__ - PRELE(p); -#endif if (!probe->ftp_enabled) return; -- Sorry for the following... The information contained in this message is confidential and intended for the addressee only. If you have received this message in error, or there are any problems with its content, please contact the sender. iCritical is a trading name of Critical Software Ltd. Registered in England: 04909220. Registered Office: IC2, Keele Science Park, Keele, Staffordshire, ST5 5NH. This message has been scanned for security threats by iCritical. www.icritical.com From owner-freebsd-current@FreeBSD.ORG Fri Feb 8 15:39:22 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 927021A4 for ; Fri, 8 Feb 2013 15:39:22 +0000 (UTC) (envelope-from mueller23@insightbb.com) Received: from mail.insightbb.com (smtp2.insight.synacor.com [208.47.185.24]) by mx1.freebsd.org (Postfix) with ESMTP id 49821D5D for ; Fri, 8 Feb 2013 15:39:22 +0000 (UTC) X_CMAE_Category: 0,0 Undefined,Undefined X-CNFS-Analysis: v=2.0 cv=UL9f7Vjy c=1 sm=0 a=Dm9TOXL4taQ+Gy1KovpL+A==:17 a=106E8bdoDFEA:10 a=jLN7EqiLvroA:10 a=9YQ-1ebCAAAA:8 a=iF0c6FqsOP4A:10 a=pGLkceISAAAA:8 a=aR16PxjQAAAA:8 a=CbMXbFppAAAA:8 a=N37U3Ecr9_CdszznGK4A:9 a=TRaWWqdqQ4oA:10 a=CiSHi91Bn78A:10 a=MSl-tDqOz04A:10 a=aWTTYslQkP0A:10 a=Dm9TOXL4taQ+Gy1KovpL+A==:117 X-CM-Score: 0 X-Scanned-by: Cloudmark Authority Engine Authentication-Results: smtp02.insight.synacor.com header.from=mueller23@insightbb.com; sender-id=softfail Authentication-Results: smtp02.insight.synacor.com smtp.mail=mueller23@insightbb.com; spf=softfail; sender-id=softfail Received-SPF: softfail (smtp02.insight.synacor.com: transitional domain insightbb.com does not designate 74.130.198.7 as permitted sender) Received: from [74.130.198.7] ([74.130.198.7:55342] helo=localhost) by mail.insightbb.com (envelope-from ) (ecelerity 2.2.3.49 r(42060/42061)) with ESMTP id 4A/4F-09449-72C15115; Fri, 08 Feb 2013 10:39:20 -0500 Date: Fri, 08 Feb 2013 10:39:19 -0500 Message-ID: <4A.4F.09449.72C15115@smtp02.insight.synacor.com> From: "Thomas Mueller" To: freebsd-ports@freebsd.org Subject: Re: Xorg totally unusable with KMS and new Xorg on Sandy Bridge system: how to undo X-Mailman-Approved-At: Fri, 08 Feb 2013 16:34:08 +0000 Cc: Andrey Fesenko , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 08 Feb 2013 15:39:22 -0000 Thomas Mueller writes: > I built the newer Xorg and it falls flat: goes to a nongraphic > screen that is blank except for a rectangular cursor in the upper > left corner, and now I want to get back to the earlier Xorg. > > System is Intel Sandy Bridge with i7 CPU. Robert Huff responds: > You don't mention your graphics chip explicitly, but building > libdrm with the KMS option was enough to prevent X from starting on > a Radeon HD 3300. ("Experimental", indeed! :-) > Other will be able to help more if you could post the contents > of "/var/log/Xorg.0.log" and your xorg.conf file. My /var/log/Xorg.0.log has 0 bytes! To Andrey Fesenko : Were you able to start X with # cat /etc/make.conf WITH_NEW_XORG=true WITH_KMS=true X.Org X Server 1.10.6 Release Date: 2012-02-10 intel(0): Integrated Graphics Chipset: Intel(R) Sandybridge Mobile (GT2+) (end of quote from Andrey Fesenko) Xorg -configure (by root) produced an error message, failed but left a file Xorg.conf.new Section "ServerLayout" Identifier "X.org Configured" Screen 0 "Screen0" 0 0 Screen 1 "Screen1" RightOf "Screen0" Screen 2 "Screen2" RightOf "Screen1" InputDevice "Mouse0" "CorePointer" InputDevice "Keyboard0" "CoreKeyboard" EndSection Section "Files" ModulePath "/usr/local/lib/xorg/modules" FontPath "/usr/local/lib/X11/fonts/misc/" FontPath "/usr/local/lib/X11/fonts/TTF/" FontPath "/usr/local/lib/X11/fonts/OTF/" FontPath "/usr/local/lib/X11/fonts/Type1/" FontPath "/usr/local/lib/X11/fonts/100dpi/" FontPath "/usr/local/lib/X11/fonts/75dpi/" EndSection Section "Module" Load "extmod" Load "record" Load "dbe" Load "dri" Load "dri2" Load "glx" EndSection Section "InputDevice" Identifier "Keyboard0" Driver "kbd" EndSection Section "InputDevice" Identifier "Mouse0" Driver "mouse" Option "Protocol" "auto" Option "Device" "/dev/sysmouse" Option "ZAxisMapping" "4 5 6 7" EndSection Section "Monitor" Identifier "Monitor0" VendorName "Monitor Vendor" ModelName "Monitor Model" EndSection Section "Monitor" Identifier "Monitor1" VendorName "Monitor Vendor" ModelName "Monitor Model" EndSection Section "Monitor" Identifier "Monitor2" VendorName "Monitor Vendor" ModelName "Monitor Model" EndSection Section "Device" ### Available Driver options are:- ### Values: : integer, : float, : "True"/"False", ### : "String", : " Hz/kHz/MHz", ### : "%" ### [arg]: arg optional #Option "DRI" # [] #Option "ColorKey" # #Option "VideoKey" # #Option "FallbackDebug" # [] #Option "Tiling" # [] #Option "LinearFramebuffer" # [] #Option "Shadow" # [] #Option "SwapbuffersWait" # [] #Option "TripleBuffer" # [] #Option "XvMC" # [] #Option "XvPreferOverlay" # [] #Option "DebugFlushBatches" # [] #Option "DebugFlushCaches" # [] #Option "DebugWait" # [] #Option "HotPlug" # [] #Option "RelaxedFencing" # [] Identifier "Card0" Driver "intel" BusID "PCI:0:2:0" EndSection Section "Device" ### Available Driver options are:- ### Values: : integer, : float, : "True"/"False", ### : "String", : " Hz/kHz/MHz", ### : "%" ### [arg]: arg optional #Option "ShadowFB" # [] #Option "Rotate" # #Option "fbdev" # #Option "debug" # [] Identifier "Card1" Driver "fbdev" BusID "PCI:0:2:0" EndSection Section "Device" ### Available Driver options are:- ### Values: : integer, : float, : "True"/"False", ### : "String", : " Hz/kHz/MHz", ### : "%" ### [arg]: arg optional #Option "ShadowFB" # [] #Option "DefaultRefresh" # [] #Option "ModeSetClearScreen" # [] Identifier "Card2" Driver "vesa" BusID "PCI:0:2:0" EndSection Section "Screen" Identifier "Screen0" Device "Card0" Monitor "Monitor0" SubSection "Display" Viewport 0 0 Depth 1 EndSubSection SubSection "Display" Viewport 0 0 Depth 4 EndSubSection SubSection "Display" Viewport 0 0 Depth 8 EndSubSection SubSection "Display" Viewport 0 0 Depth 15 EndSubSection SubSection "Display" Viewport 0 0 Depth 16 EndSubSection SubSection "Display" Viewport 0 0 Depth 24 EndSubSection EndSection Section "Screen" Identifier "Screen1" Device "Card1" Monitor "Monitor1" SubSection "Display" Viewport 0 0 Depth 1 EndSubSection SubSection "Display" Viewport 0 0 Depth 4 EndSubSection SubSection "Display" Viewport 0 0 Depth 8 EndSubSection SubSection "Display" Viewport 0 0 Depth 15 EndSubSection SubSection "Display" Viewport 0 0 Depth 16 EndSubSection SubSection "Display" Viewport 0 0 Depth 24 EndSubSection EndSection Section "Screen" Identifier "Screen2" Device "Card2" Monitor "Monitor2" SubSection "Display" Viewport 0 0 Depth 1 EndSubSection SubSection "Display" Viewport 0 0 Depth 4 EndSubSection SubSection "Display" Viewport 0 0 Depth 8 EndSubSection SubSection "Display" Viewport 0 0 Depth 15 EndSubSection SubSection "Display" Viewport 0 0 Depth 16 EndSubSection SubSection "Display" Viewport 0 0 Depth 24 EndSubSection EndSection Tom From owner-freebsd-current@FreeBSD.ORG Fri Feb 8 18:16:58 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 16390941; Fri, 8 Feb 2013 18:16:58 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-ve0-f176.google.com (mail-ve0-f176.google.com [209.85.128.176]) by mx1.freebsd.org (Postfix) with ESMTP id A93716E0; Fri, 8 Feb 2013 18:16:57 +0000 (UTC) Received: by mail-ve0-f176.google.com with SMTP id cz10so3548090veb.21 for ; Fri, 08 Feb 2013 10:16:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to:cc :content-type; bh=/HWKFgz9ZwkiIxlnuu1o7XRIvTSkuVs3bQva9h97swI=; b=cRpzOlHfJOoNMeQHaRLycuqq/MdFZph7Ag1sMD0Q9pkjTIFqoKiCPUFf9t+3jZYdm7 SNolqxT2lGw4tCy85YjurATp8B97qX3gG6FVnXDk/W/xEhwrOorPKeXsf4uw5mJOgyos dli1NHcEw5PhjSfcL23+zACjmLHTBwjnZfn8pnWpZ0Fs0x2VsctWJAEoPBBEceziV7Nc tCskHB5KoakPq6fb+vp5iU6mAUpZvpnpfz3h61cHySnzAdYghotJvZDsOJW7TW8JU7Ue UljccQZE8A8Ac7RV3aXLpPmGOqFa7FoQ2UE1bovSROmap+07DYOL3LqUEgN/8/SfKxGw NU/w== MIME-Version: 1.0 X-Received: by 10.52.29.109 with SMTP id j13mr6919204vdh.111.1360347409285; Fri, 08 Feb 2013 10:16:49 -0800 (PST) Received: by 10.220.191.132 with HTTP; Fri, 8 Feb 2013 10:16:49 -0800 (PST) Date: Fri, 8 Feb 2013 10:16:49 -0800 Message-ID: Subject: Intel 82574 issue reported on Slashdot From: Jack Vogel To: FreeBSD Net , FreeBSD Current , FreeBSD stable Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "Pieper, Jeffrey E" , "Hearn, James R" , "Ronciak, John" , "Vogel, Jack" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 08 Feb 2013 18:16:58 -0000 For those that may have run across the story on Slashdot about this NIC, here is our statement: Recently there were a few stories published, based on a blog post by an end-user, suggesting specific network packets may cause the Intel=AE 82574L Gigabit Ethernet Controller to become unresponsive until corrected by a full platform power cycle. Intel was made aware of this issue in September 2012 by the blogs author. Intel worked with the author as well as the original motherboard manufacturer to investigate and determine root cause. Intel root caused the issue to the specific vendor=92s mother board design where an incorrect EEPROM image was programmed during manufacturing. We communicated the findings and recommended corrections to the motherboard manufacturer. It is Intel=92s belief that this is an implementation issue isolated to a specific manufacturer, not a design problem with the Intel 82574L Gigabit Ethernet controller. Intel has not observed this issue with any implementations which follow Intel=92s published design guidelines. Intel recommends contacting your motherboard manufacturer if you have continued concerns or questions whether your products are impacted. Here is the link: http://communities.intel.com/community/wired/blog/2013/02/07/intel-82574l-g= igabit-ethernet-controller-statement Any questions or concerns may be sent to me. Cheers, Jack From owner-freebsd-current@FreeBSD.ORG Fri Feb 8 18:29:38 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 6F3C711A for ; Fri, 8 Feb 2013 18:29:38 +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 A6B377AE for ; Fri, 8 Feb 2013 18:29:37 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zcs03.jnb1.cloudseed.co.za (Postfix) with ESMTP id 5637A2B42EB2 for ; Fri, 8 Feb 2013 20:21:31 +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 w1N-ErhzDiVG for ; Fri, 8 Feb 2013 20:21:29 +0200 (SAST) Received: from clue.co.za (unknown [41.154.88.19]) by zcs03.jnb1.cloudseed.co.za (Postfix) with ESMTPSA id 0CD2C2B42E67 for ; Fri, 8 Feb 2013 20:21:29 +0200 (SAST) Received: from localhost ([127.0.0.1] helo=new.clue.co.za) by clue.co.za with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1U3sZh-0000aA-Kx for current@freebsd.org; Fri, 08 Feb 2013 20:21:25 +0200 To: current@freebsd.org Subject: uath panic on insert. From: "Ian FREISLICH" X-Attribution: BOFH Date: Fri, 08 Feb 2013 20:21:24 +0200 Message-Id: X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 08 Feb 2013 18:29:38 -0000 Hi I get this panic on insertion of a uath USB dongle. On amd-64: uath0: on us bus1 Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0x0 fault code = supervisor write data, page not present instruction pointer = 0x20:0xffffffff80628f6a stack pointer = 0x28:0xffffff8112ee3750 frame pointer = 0x28:0xffffff8112ee37b0 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 = 14 (usbus1) trap number = 12 panic: page fault cpuid = 1 Uptime: 7s Dumping 237 out of 3971 MB:..7%..14%..21%..34%..41%..54%..61%..75%..81%..95% Reading symbols from /boot/kernel/acpi_asus_wmi.ko...Reading symbols from /boot/kernel/acpi_asus_wmi.ko.symbols...done. done. Loaded symbols for /boot/kernel/acpi_asus_wmi.ko Reading symbols from /boot/kernel/acpi_wmi.ko...Reading symbols from /boot/kernel/acpi_wmi.ko.symbols...done. done. Loaded symbols for /boot/kernel/acpi_wmi.ko Reading symbols from /boot/kernel/if_uath.ko...Reading symbols from /boot/kernel/if_uath.ko.symbols...done. done. Loaded symbols for /boot/kernel/if_uath.ko #0 doadump (textdump=) at pcpu.h:229 229 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump (textdump=) at pcpu.h:229 #1 0x0000000000000000 in ?? () The i386 panic is only slightly more useful: ugen4.3: at usbus4 uath0: on us bus4 Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x0 fault code = supervisor write, page not present instruction pointer = 0x20:0xc08ae31f stack pointer = 0x28:0xebbf8adc frame pointer = 0x28:0xebbf8b10 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 14 (usbus4) trap number = 12 panic: page fault cpuid = 0 Uptime: 16s Physical memory: 2027 MB Dumping 85 MB: 70 54 38 22 6 Reading symbols from /boot/kernel/acpi_video.ko...Reading symbols from /boot/ker nel/acpi_video.ko.symbols...done. done. Loaded symbols for /boot/kernel/acpi_video.ko Reading symbols from /boot/kernel/ohci.ko...Reading symbols from /boot/kernel/oh ci.ko.symbols...done. done. Loaded symbols for /boot/kernel/ohci.ko Reading symbols from /boot/kernel/xhci.ko...Reading symbols from /boot/kernel/xh ci.ko.symbols...done. done. Loaded symbols for /boot/kernel/xhci.ko Reading symbols from /boot/kernel/if_uath.ko...Reading symbols from /boot/kernel /if_uath.ko.symbols...done. done. Loaded symbols for /boot/kernel/if_uath.ko Reading symbols from /boot/kernel/u3g.ko...Reading symbols from /boot/kernel/u3g .ko.symbols...done. done. Loaded symbols for /boot/kernel/u3g.ko #0 doadump (textdump=1) at pcpu.h:249 249 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump (textdump=1) at pcpu.h:249 #1 0xc06a69d5 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:446 #2 0xc06a6c32 in panic (fmt=) at /usr/src/sys/kern/kern_shutdown.c:753 #3 0xc08b05ac in trap_fatal (frame=0xebbf8a9c, eva=0) at /usr/src/sys/i386/i386/trap.c:1046 #4 0xc08b06a2 in trap_pfault (frame=0xebbf8a9c, usermode=0, eva=0) at /usr/src/sys/i386/i386/trap.c:899 #5 0xc08b1476 in trap (frame=0xebbf8a9c) at /usr/src/sys/i386/i386/trap.c:556 #6 0xc089b0dc in calltrap () at /usr/src/sys/i386/i386/exception.s:169 #7 0xc08ae31f in bzero () at /usr/src/sys/i386/i386/support.s:56 Previous frame inner to this frame (corrupt stack?) (kgdb) Ian -- Ian Freislich From owner-freebsd-current@FreeBSD.ORG Fri Feb 8 18:38:17 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id DC7272FA; Fri, 8 Feb 2013 18:38:17 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) by mx1.freebsd.org (Postfix) with ESMTP id F3AE581D; Fri, 8 Feb 2013 18:38:16 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.6/8.14.6) with ESMTP id r18IcAGj068228; Fri, 8 Feb 2013 11:38:10 -0700 (MST) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.6/8.14.6/Submit) with ESMTP id r18IcAFE068225; Fri, 8 Feb 2013 11:38:10 -0700 (MST) (envelope-from wblock@wonkity.com) Date: Fri, 8 Feb 2013 11:38:09 -0700 (MST) From: Warren Block To: Thomas Mueller Subject: Re: Xorg totally unusable with KMS and new Xorg on Sandy Bridge system: how to undo In-Reply-To: <4A.4F.09449.72C15115@smtp02.insight.synacor.com> Message-ID: References: <4A.4F.09449.72C15115@smtp02.insight.synacor.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (wonkity.com [127.0.0.1]); Fri, 08 Feb 2013 11:38:10 -0700 (MST) Cc: Andrey Fesenko , freebsd-current@freebsd.org, freebsd-ports@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 08 Feb 2013 18:38:17 -0000 On Fri, 8 Feb 2013, Thomas Mueller wrote: > Thomas Mueller writes: > >> I built the newer Xorg and it falls flat: goes to a nongraphic >> screen that is blank except for a rectangular cursor in the upper >> left corner, and now I want to get back to the earlier Xorg. >> >> System is Intel Sandy Bridge with i7 CPU. > > Robert Huff responds: > >> You don't mention your graphics chip explicitly, but building >> libdrm with the KMS option was enough to prevent X from starting on >> a Radeon HD 3300. ("Experimental", indeed! :-) >> Other will be able to help more if you could post the contents >> of "/var/log/Xorg.0.log" and your xorg.conf file. > > My /var/log/Xorg.0.log has 0 bytes! > > To Andrey Fesenko : > > Were you able to start X with > > # cat /etc/make.conf > WITH_NEW_XORG=true > WITH_KMS=true > > X.Org X Server 1.10.6 > Release Date: 2012-02-10 > intel(0): Integrated Graphics Chipset: Intel(R) Sandybridge Mobile (GT2+) > > (end of quote from Andrey Fesenko) After adding those, graphics/libdrm must be rebuilt, and x11-drivers/xf86-video-intel must have the KMS option enabled and be rebuilt. If you just added WITH_NEW_XORG, there will be other xorg components that need to be updated. From owner-freebsd-current@FreeBSD.ORG Fri Feb 8 20:08:11 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 682B2C9D for ; Fri, 8 Feb 2013 20:08:11 +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 EDA0DCC1 for ; Fri, 8 Feb 2013 20:08:10 +0000 (UTC) X-T2-Spam-Status: No, hits=-1.0 required=5.0 tests=ALL_TRUSTED Received: from [176.74.213.204] (account mc467741@c2i.net HELO laptop015.hselasky.homeunix.org) by mailfe07.swip.net (CommuniGate Pro SMTP 5.4.4) with ESMTPA id 375331562; Fri, 08 Feb 2013 21:08:03 +0100 From: Hans Petter Selasky To: freebsd-current@freebsd.org Subject: Re: uath panic on insert. Date: Fri, 8 Feb 2013 21:09:13 +0100 User-Agent: KMail/1.13.7 (FreeBSD/9.1-STABLE; KDE/4.8.4; amd64; ; ) References: In-Reply-To: X-Face: ?p&W)c(+80hU; '{.$5K+zq{oC6y| /D'an*6mw>j'f:eBsex\Gi, Cc: Ian FREISLICH X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 08 Feb 2013 20:08:11 -0000 On Friday 08 February 2013 19:21:24 Ian FREISLICH wrote: > Uptime: 7s > Dumping 237 out of 3971 > MB:..7%..14%..21%..34%..41%..54%..61%..75%..81%..95% > > Reading symbols from /boot/kernel/acpi_asus_wmi.ko...Reading symbols from > /boot/kernel/acpi_asus_wmi.ko.symbols...done. do Maybe you can also look into /var/crash for more information? --HPS From owner-freebsd-current@FreeBSD.ORG Fri Feb 8 20:10:52 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 029CBE4D for ; Fri, 8 Feb 2013 20:10:52 +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 5EF73CE4 for ; Fri, 8 Feb 2013 20:10:51 +0000 (UTC) X-T2-Spam-Status: No, hits=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 Received: from [176.74.213.204] (account mc467741@c2i.net HELO laptop015.hselasky.homeunix.org) by mailfe06.swip.net (CommuniGate Pro SMTP 5.4.4) with ESMTPA id 375008777; Fri, 08 Feb 2013 21:05:42 +0100 From: Hans Petter Selasky To: freebsd-current@freebsd.org Subject: Re: uath panic on insert. Date: Fri, 8 Feb 2013 21:06:51 +0100 User-Agent: KMail/1.13.7 (FreeBSD/9.1-STABLE; KDE/4.8.4; amd64; ; ) References: In-Reply-To: X-Face: ?p&W)c(+80hU; '{.$5K+zq{oC6y| /D'an*6mw>j'f:eBsex\Gi, Cc: Ian FREISLICH X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 08 Feb 2013 20:10:52 -0000 On Friday 08 February 2013 19:21:24 Ian FREISLICH wrote: > Hi > > I get this panic on insertion of a uath USB dongle. > > On amd-64: > > uath0: > on us bus1 > > > Fatal trap 12: page fault while in kernel mode > cpuid = 1; apic id = 01 > fault virtual address = 0x0 > fault code = supervisor write data, page not present > instruction pointer = 0x20:0xffffffff80628f6a > stack pointer = 0x28:0xffffff8112ee3750 > frame pointer = 0x28:0xffffff8112ee37b0 > 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 = 14 (usbus1) > trap number = 12 > panic: page fault > cpuid = 1 > Uptime: 7s > Dumping 237 out of 3971 > MB:..7%..14%..21%..34%..41%..54%..61%..75%..81%..95% > > Reading symbols from /boot/kernel/acpi_asus_wmi.ko...Reading symbols from > /boot/kernel/acpi_asus_wmi.ko.symbols...done. done. > Loaded symbols for /boot/kernel/acpi_asus_wmi.ko > Reading symbols from /boot/kernel/acpi_wmi.ko...Reading symbols from > /boot/kernel/acpi_wmi.ko.symbols...done. done. > Loaded symbols for /boot/kernel/acpi_wmi.ko > Reading symbols from /boot/kernel/if_uath.ko...Reading symbols from > /boot/kernel/if_uath.ko.symbols...done. done. > Loaded symbols for /boot/kernel/if_uath.ko > #0 doadump (textdump=) at pcpu.h:229 > 229 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) #0 doadump (textdump=) at pcpu.h:229 > #1 0x0000000000000000 in ?? () > > The i386 panic is only slightly more useful: > ugen4.3: at usbus4 > uath0: > on us bus4 > > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x0 > fault code = supervisor write, page not present > instruction pointer = 0x20:0xc08ae31f > stack pointer = 0x28:0xebbf8adc > frame pointer = 0x28:0xebbf8b10 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 14 (usbus4) > trap number = 12 > panic: page fault > cpuid = 0 > Uptime: 16s > Physical memory: 2027 MB > Dumping 85 MB: 70 54 38 22 6 > > Reading symbols from /boot/kernel/acpi_video.ko...Reading symbols from > /boot/ker nel/acpi_video.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/acpi_video.ko > Reading symbols from /boot/kernel/ohci.ko...Reading symbols from > /boot/kernel/oh ci.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/ohci.ko > Reading symbols from /boot/kernel/xhci.ko...Reading symbols from > /boot/kernel/xh ci.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/xhci.ko > Reading symbols from /boot/kernel/if_uath.ko...Reading symbols from > /boot/kernel /if_uath.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/if_uath.ko > Reading symbols from /boot/kernel/u3g.ko...Reading symbols from > /boot/kernel/u3g .ko.symbols...done. > done. > Loaded symbols for /boot/kernel/u3g.ko > #0 doadump (textdump=1) at pcpu.h:249 > 249 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) #0 doadump (textdump=1) at pcpu.h:249 > #1 0xc06a69d5 in kern_reboot (howto=260) > at /usr/src/sys/kern/kern_shutdown.c:446 > #2 0xc06a6c32 in panic (fmt=) > at /usr/src/sys/kern/kern_shutdown.c:753 > #3 0xc08b05ac in trap_fatal (frame=0xebbf8a9c, eva=0) > at /usr/src/sys/i386/i386/trap.c:1046 > #4 0xc08b06a2 in trap_pfault (frame=0xebbf8a9c, usermode=0, eva=0) > at /usr/src/sys/i386/i386/trap.c:899 > #5 0xc08b1476 in trap (frame=0xebbf8a9c) at > /usr/src/sys/i386/i386/trap.c:556 #6 0xc089b0dc in calltrap () at > /usr/src/sys/i386/i386/exception.s:169 #7 0xc08ae31f in bzero () at > /usr/src/sys/i386/i386/support.s:56 > Previous frame inner to this frame (corrupt stack?) > (kgdb) > > Ian Can you compile the kernel with debugging enabled? --HPS From owner-freebsd-current@FreeBSD.ORG Fri Feb 8 21:17:16 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id BBE14A26 for ; Fri, 8 Feb 2013 21:17:16 +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 4B126140 for ; Fri, 8 Feb 2013 21:17:15 +0000 (UTC) X-T2-Spam-Status: No, hits=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 Received: from [176.74.213.204] (account mc467741@c2i.net HELO laptop015.hselasky.homeunix.org) by mailfe02.swip.net (CommuniGate Pro SMTP 5.4.4) with ESMTPA id 376880860; Fri, 08 Feb 2013 22:17:13 +0100 From: Hans Petter Selasky To: freebsd-current@freebsd.org Subject: Re: uath panic on insert. Date: Fri, 8 Feb 2013 22:18:24 +0100 User-Agent: KMail/1.13.7 (FreeBSD/9.1-STABLE; KDE/4.8.4; amd64; ; ) References: In-Reply-To: X-Face: ?p&W)c(+80hU; '{.$5K+zq{oC6y| /D'an*6mw>j'f:eBsex\Gi, Cc: Ian FREISLICH X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 08 Feb 2013 21:17:16 -0000 Hi, Your problem should be fixed by: http://svnweb.freebsd.org/changeset/base/246565 Please test and report back if it doesn't. --HPS From owner-freebsd-current@FreeBSD.ORG Fri Feb 8 21:20:45 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 10BF1BF8 for ; Fri, 8 Feb 2013 21:20:45 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe09.c2i.net [212.247.155.2]) by mx1.freebsd.org (Postfix) with ESMTP id 9F0DA17D for ; Fri, 8 Feb 2013 21:20:43 +0000 (UTC) X-T2-Spam-Status: No, hits=-1.0 required=5.0 tests=ALL_TRUSTED Received: from [176.74.213.204] (account mc467741@c2i.net HELO laptop015.hselasky.homeunix.org) by mailfe09.swip.net (CommuniGate Pro SMTP 5.4.4) with ESMTPA id 202222720; Fri, 08 Feb 2013 22:20:41 +0100 From: Hans Petter Selasky To: freebsd-current@freebsd.org Subject: Re: uath panic on insert. Date: Fri, 8 Feb 2013 22:21:50 +0100 User-Agent: KMail/1.13.7 (FreeBSD/9.1-STABLE; KDE/4.8.4; amd64; ; ) References: <201302082218.24033.hselasky@c2i.net> In-Reply-To: <201302082218.24033.hselasky@c2i.net> X-Face: ?p&W)c(+80hU; '{.$5K+zq{oC6y| /D'an*6mw>j'f:eBsex\Gi, Cc: Ian FREISLICH X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 08 Feb 2013 21:20:45 -0000 On Friday 08 February 2013 22:18:24 Hans Petter Selasky wrote: > Hi, > > Your problem should be fixed by: > http://svnweb.freebsd.org/changeset/base/246565 > > Please test and report back if it doesn't. > FYI: This is only a problem in -current, because the changes which introduced this behaviour are not MFC'ed to any -stable and will probably not be although the commit message indicates so. --HPS From owner-freebsd-current@FreeBSD.ORG Fri Feb 8 21:22:35 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 22F24D32 for ; Fri, 8 Feb 2013 21:22:35 +0000 (UTC) (envelope-from ianf@clue.co.za) Received: from zcs04.jnb1.cloudseed.co.za (zcs04.jnb1.cloudseed.co.za [41.154.0.161]) by mx1.freebsd.org (Postfix) with ESMTP id B45BF19F for ; Fri, 8 Feb 2013 21:22:34 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zcs04.jnb1.cloudseed.co.za (Postfix) with ESMTP id 6CE602A82E77; Fri, 8 Feb 2013 23:14:55 +0200 (SAST) X-Virus-Scanned: amavisd-new at zcs04.jnb1.cloudseed.co.za Received: from zcs04.jnb1.cloudseed.co.za ([127.0.0.1]) by localhost (zcs04.jnb1.cloudseed.co.za [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zPhDOe6YEEB6; Fri, 8 Feb 2013 23:14:54 +0200 (SAST) Received: from clue.co.za (unknown [41.154.88.19]) by zcs04.jnb1.cloudseed.co.za (Postfix) with ESMTPSA id 7DE0B2A82DE7; Fri, 8 Feb 2013 23:14:54 +0200 (SAST) Received: from localhost ([127.0.0.1] helo=new.clue.co.za) by clue.co.za with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1U3vHZ-0001DC-4I; Fri, 08 Feb 2013 23:14:53 +0200 To: Hans Petter Selasky From: Ian FREISLICH Subject: Re: uath panic on insert. In-Reply-To: <201302082109.13251.hselasky@c2i.net> References: <201302082109.13251.hselasky@c2i.net> X-Attribution: BOFH Date: Fri, 08 Feb 2013 23:14:52 +0200 Message-Id: Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 08 Feb 2013 21:22:35 -0000 Hans Petter Selasky wrote: > On Friday 08 February 2013 19:21:24 Ian FREISLICH wrote: > > Uptime: 7s > > Dumping 237 out of 3971 > > MB:..7%..14%..21%..34%..41%..54%..61%..75%..81%..95% > > > > Reading symbols from /boot/kernel/acpi_asus_wmi.ko...Reading symbols from > > /boot/kernel/acpi_asus_wmi.ko.symbols...done. do > > Maybe you can also look into /var/crash for more information? This is from /var/crash. The vmcore is quite badly corrupted. [new] /var/crash # kgdb -c vmcore.4 /boot/kernel/kernel 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"...(no debugging symbols found)... Attempt to extract a component of a value that is not a structure pointer. Attempt to extract a component of a value that is not a structure pointer. #0 0xffffffff8041a3e4 in doadump () (kgdb) I've just noticed that I had USB_DEBUG="yes" set. I'm trying a kernel without that set just in case that tickles an issue. It's been ages (2 years or more) since I used this card so a binary search is nearly out of the question. I'm trying to ressurect it because I got a new laptop with a totally useless new iwn(4) "Centrino Advanced-N 6235" card in it that can't do 40MHz channels and can't stay connected to a 20MHz channel for longer than 15 minutes at a stretch. And, the antenna cables have w-FL connectors so I can't just replace it with a good old AR9285. I'm not sure I'll be able to desolder the w-FL connectors and move them to my Atheros card without destroying them. I'll try to capture some more useful debugging data, but it blows up pretty badly when the card is inserted. Ian -- Ian Freislich From owner-freebsd-current@FreeBSD.ORG Fri Feb 8 22:52:06 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 47DEBF21 for ; Fri, 8 Feb 2013 22:52:06 +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 D767F7C1 for ; Fri, 8 Feb 2013 22:52:05 +0000 (UTC) X-T2-Spam-Status: No, hits=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 Received: from [176.74.213.204] (account mc467741@c2i.net HELO laptop015.hselasky.homeunix.org) by mailfe06.swip.net (CommuniGate Pro SMTP 5.4.4) with ESMTPA id 375031144; Fri, 08 Feb 2013 23:52:03 +0100 From: Hans Petter Selasky To: Ian FREISLICH Subject: Re: uath panic on insert. Date: Fri, 8 Feb 2013 23:53:13 +0100 User-Agent: KMail/1.13.7 (FreeBSD/9.1-STABLE; KDE/4.8.4; amd64; ; ) References: <201302082218.24033.hselasky@c2i.net> In-Reply-To: X-Face: ?p&W)c(+80hU; '{.$5K+zq{oC6y| /D'an*6mw>j'f:eBsex\Gi, Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 08 Feb 2013 22:52:06 -0000 On Friday 08 February 2013 22:43:17 Ian FREISLICH wrote: > Hans Petter Selasky wrote: > > Hi, > > > > Your problem should be fixed by: > > http://svnweb.freebsd.org/changeset/base/246565 > > > > Please test and report back if it doesn't. > > It doesn't panic anymore. Thanks. There's a new problem though: > > uath0: > on usbus1 wlan1: Ethernet address: 00:11:95:d3:4a:af Hi, Can you try this patch: http://svnweb.freebsd.org/changeset/base/246570 --HPS From owner-freebsd-current@FreeBSD.ORG Sat Feb 9 00:38:25 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 050EFF81; Sat, 9 Feb 2013 00:38:25 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id 7F730CC8; Sat, 9 Feb 2013 00:38:23 +0000 (UTC) Received: from [10.138.22.220] ([1.124.113.155]) (authenticated bits=0) by cain.gsoft.com.au (8.14.4/8.14.3) with ESMTP id r190bqro039647 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 9 Feb 2013 11:07:59 +1030 (CST) (envelope-from doconnor@gsoft.com.au) Subject: Re: Intel 82574 issue reported on Slashdot Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=windows-1252 From: "Daniel O'Connor" In-Reply-To: Date: Sat, 9 Feb 2013 11:07:51 +1030 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Jack Vogel X-Mailer: Apple Mail (2.1499) X-Spam-Score: -0.023 () BAYES_00,HELO_MISC_IP,RDNS_NONE X-Scanned-By: MIMEDefang 2.67 on 203.31.81.10 Cc: FreeBSD stable , "Pieper, Jeffrey E" , FreeBSD Net , "Hearn, James R" , "Vogel, Jack" , "Ronciak, John" , FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 09 Feb 2013 00:38:25 -0000 On 09/02/2013, at 4:46, Jack Vogel wrote: > recommends contacting your motherboard manufacturer if you have = continued > concerns or questions whether your products are impacted. > Here is the link: >=20 > = http://communities.intel.com/community/wired/blog/2013/02/07/intel-82574l-= gigabit-ethernet-controller-statement >=20 > Any questions or concerns may be sent to me. In all honesty.. The blog post (and your email) are basically = information free, they don't name names and provide no script or = downloadable code that will allow end users to check if they are = affected. "Contact your motherboard manufacturer" is much more time consuming than = "Run sysctl... | grep foo | awk ..." to see if your system is affected. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C From owner-freebsd-current@FreeBSD.ORG Sat Feb 9 03:18:55 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E34CACDE for ; Sat, 9 Feb 2013 03:18:55 +0000 (UTC) (envelope-from mueller23@insightbb.com) Received: from mail.insightbb.com (smtp1.insight.synacor.com [208.47.185.23]) by mx1.freebsd.org (Postfix) with ESMTP id 9FD4C337 for ; Sat, 9 Feb 2013 03:18:55 +0000 (UTC) X_CMAE_Category: 0,0 Undefined,Undefined X-CNFS-Analysis: v=2.0 cv=G4+e4qY5 c=1 sm=0 a=Dm9TOXL4taQ+Gy1KovpL+A==:17 a=106E8bdoDFEA:10 a=jLN7EqiLvroA:10 a=9YQ-1ebCAAAA:8 a=iF0c6FqsOP4A:10 a=s1O25tkdAAAA:8 a=U3-AZJamp_Ule4E6froA:9 a=OyOq_G8mXAEA:10 a=Dm9TOXL4taQ+Gy1KovpL+A==:117 X-CM-Score: 0 X-Scanned-by: Cloudmark Authority Engine Authentication-Results: smtp01.insight.synacor.com smtp.mail=mueller23@insightbb.com; spf=softfail; sender-id=softfail Authentication-Results: smtp01.insight.synacor.com header.from=mueller23@insightbb.com; sender-id=softfail Received-SPF: softfail (smtp01.insight.synacor.com: transitional domain insightbb.com does not designate 74.130.198.7 as permitted sender) Received: from [74.130.198.7] ([74.130.198.7:19486] helo=localhost) by mail.insightbb.com (envelope-from ) (ecelerity 2.2.3.49 r(42060/42061)) with ESMTP id 83/63-06175-810C5115; Fri, 08 Feb 2013 22:18:48 -0500 Date: Fri, 08 Feb 2013 22:18:48 -0500 Message-ID: <83.63.06175.810C5115@smtp01.insight.synacor.com> From: "Thomas Mueller" To: freebsd-ports@freebsd.org Subject: Re: Xorg totally unusable with KMS and new Xorg on Sandy Bridge system: how to undo X-Mailman-Approved-At: Sat, 09 Feb 2013 04:38:54 +0000 Cc: Warren Block , Andrey Fesenko , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 09 Feb 2013 03:18:55 -0000 >From Warren Block : > After adding those, graphics/libdrm must be rebuilt, and > x11-drivers/xf86-video-intel must have the KMS option enabled and be > rebuilt. If you just added WITH_NEW_XORG, there will be other xorg > components that need to be updated. O no, I'm getting rid of KMS and WITH_NEW_XORG because they produce an unusable Xorg installation that just crashes the system and requires Reset button. I guess I need to use portmaster with --force-config on x11/xorg ? Tom From owner-freebsd-current@FreeBSD.ORG Sat Feb 9 07:32:57 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 912BBC6E for ; Sat, 9 Feb 2013 07:32:57 +0000 (UTC) (envelope-from joel@FreeBSD.org) Received: from mail.vnode.se (mail.vnode.se [62.119.52.80]) by mx1.freebsd.org (Postfix) with ESMTP id 3408FCD1 for ; Sat, 9 Feb 2013 07:32:57 +0000 (UTC) Received: from mail.vnode.se (localhost [127.0.0.1]) by mail.vnode.se (Postfix) with ESMTP id 2337FE3F07A for ; Sat, 9 Feb 2013 08:32:55 +0100 (CET) X-Virus-Scanned: amavisd-new at vnode.se Received: from mail.vnode.se ([127.0.0.1]) by mail.vnode.se (mail.vnode.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W+foQgkqT-4N for ; Sat, 9 Feb 2013 08:32:52 +0100 (CET) Received: from jd.benders.se (jd.benders.se [212.247.52.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.vnode.se (Postfix) with ESMTPSA id 86131E3F079 for ; Sat, 9 Feb 2013 08:32:52 +0100 (CET) Date: Sat, 9 Feb 2013 08:32:41 +0100 From: Joel Dahl To: current@freebsd.org Subject: HEAD memsticks broken? Message-ID: <20130209073241.GN21730@jd.benders.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 09 Feb 2013 07:32:57 -0000 Hi, I suspect something is broken with memsticks built from HEAD. I noticed that I couldn't boot the latest HEAD (amd64) memstick snapshot on two machines (Lenovo X220 and HP ProLiant ML350 G5). Trying snapshots from the FreeBSD.org FTP or allbsd.org makes no difference. It boots fine until mountroot, where I get (help messages removed): Trying to mount root from ufs:/dev/ufs/FreeBSD_Install [ro,noatime]... mountroot: waiting for device /dev/ufs/FreeBSD_Install ... Mounting from ufs:/dev/ufs/FreeBSD_Install failed with error 19. Loader variables: vfs.root.mountfrom=ufs:/dev/ufs/FreeBSD_Install vfs.root.mountfrom.option=ro,noatime mountroot> I then tried a few older HEAD snapshots, but the problem persists. I've tried the following HEAD snapshots available at allbsd.org: FreeBSD-10.0-HEAD-r246472-JPSNAP-amd64-amd64-memstick.img FreeBSD-10.0-HEAD-r243701-JPSNAP-amd64-amd64-memstick.img FreeBSD-10.0-HEAD-r242396-JPSNAP-amd64-amd64-memstick.img FreeBSD-10.0-HEAD-r241545-JPSNAP-amd64-amd64-memstick.img FreeBSD-10.0-HEAD-r241070-JPSNAP-amd64-amd64-memstick.img I've also tried the following two snapshots from FreeBSD.org: FreeBSD-10.0-CURRENT-amd64-20130202-r246254-memstick FreeBSD-10.0-CURRENT-amd64-20130108-r245175-memstick None of the above works on these machines. Problem is exactly the same. Next up, I tried a 9.1-RELEASE amd64 memstick from FreeBSD.org. Boots without any problems whatsoever. After that, tried the latest (r246455) RELENG_9 amd64 snapshot from allbsd.org - also boots fine on both machines. Any ideas? -- Joel From owner-freebsd-current@FreeBSD.ORG Sat Feb 9 08:15:47 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 5D487293; Sat, 9 Feb 2013 08:15:47 +0000 (UTC) (envelope-from bygg@mail.cafax.se) Received: from mail.cafax.se (mail.cafax.se [IPv6:2a00:801:11:53::4]) by mx1.freebsd.org (Postfix) with ESMTP id BDC7BDDC; Sat, 9 Feb 2013 08:15:45 +0000 (UTC) Received: from mail.cafax.se (localhost [127.0.0.1]) by mail.cafax.se (8.14.6/8.14.6) with ESMTP id r198FhOv018342 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 9 Feb 2013 09:15:43 +0100 (MET) Received: (from bygg@localhost) by mail.cafax.se (8.14.6/8.14.6/Submit) id r198Fh51009505; Sat, 9 Feb 2013 09:15:43 +0100 (MET) Sender: Johnny Eriksson Date: Sat, 9 Feb 2013 9:15:43 WET From: Johnny Eriksson To: FreeBSD Net Subject: Re: Intel 82574 issue reported on Slashdot In-Reply-To: Your message of Sat, 9 Feb 2013 11:07:51 +1030 Message-ID: X-Scanned-By: MIMEDefang 2.71 on 192.71.228.4 Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Johnny Eriksson List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Feb 2013 08:15:47 -0000 > In all honesty.. The blog post (and your email) are basically > information free, they don't name names and provide no script > or downloadable code that will allow end users to check if they > are affected. A link with a little bit more information: http://blog.krisk.org/2013/02/packets-of-death.html > Daniel O'Connor software and network engineer --Johnny From owner-freebsd-current@FreeBSD.ORG Sat Feb 9 08:47:54 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E0C9593F for ; Sat, 9 Feb 2013 08:47:54 +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 5A469E91 for ; Sat, 9 Feb 2013 08:47:53 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zcs03.jnb1.cloudseed.co.za (Postfix) with ESMTP id C6DE02B42E6E; Sat, 9 Feb 2013 10:47:50 +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 dzwq8+9sjQZ0; Sat, 9 Feb 2013 10:47:49 +0200 (SAST) Received: from clue.co.za (unknown [41.154.88.19]) by zcs03.jnb1.cloudseed.co.za (Postfix) with ESMTPSA id 741022B42D93; Sat, 9 Feb 2013 10:47:49 +0200 (SAST) Received: from localhost ([127.0.0.1] helo=new.clue.co.za) by clue.co.za with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1U4667-0003Jw-1f; Sat, 09 Feb 2013 10:47:47 +0200 To: Hans Petter Selasky From: Ian FREISLICH Subject: Re: uath panic on insert. In-Reply-To: <201302082353.13581.hselasky@c2i.net> References: <201302082353.13581.hselasky@c2i.net> <201302082218.24033.hselasky@c2i.net> X-Attribution: BOFH Date: Sat, 09 Feb 2013 10:47:46 +0200 Message-Id: Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 09 Feb 2013 08:47:54 -0000 Hans Petter Selasky wrote: > On Friday 08 February 2013 22:43:17 Ian FREISLICH wrote: > > Hans Petter Selasky wrote: > > > Hi, > > > > > > Your problem should be fixed by: > > > http://svnweb.freebsd.org/changeset/base/246565 > > > > > > Please test and report back if it doesn't. > > > > It doesn't panic anymore. Thanks. There's a new problem though: > > > > uath0: > > on usbus1 wlan1: Ethernet address: 00:11:95:d3:4a:af > > Hi, > > Can you try this patch: > http://svnweb.freebsd.org/changeset/base/246570 ugen1.5: at usbus1 on usbus1 Ethernet address: 00:11:95:d3:4a:af uath_cmdsend: empty inactive queue could not init Tx queues, error 55 uath_cmdsend: empty inactive queue could not set channel, error 55 uath_cmdsend: empty inactive queue could not set channel, error 55 uath_cmdsend: empty inactive queue could not set channel, error 55 uath_cmdsend: empty inactive queue could not set channel, error 55 uath_cmdsend: empty inactive queue could not set channel, error 55 at uhub2, port 2, addr 5 (disconnected) <--- uath_cmdsend: empty inactive queue uath_cmdsend: empty inactive queue ugen1.5: at usbus1 (disconnected) The card still disconnects after attempting to scan unsupported frequencies. The sequence above happens when I 'ifconfig wlan1 up'. Also, the uath driver reports 2.4GHz and 5GHz as supported channels for this chip but it's a D-Link DWL-G132 which is a 2.4GHz device. Is this a problem for Adrian to look at? Ian -- Ian Freislich From owner-freebsd-current@FreeBSD.ORG Sat Feb 9 09:16:54 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 7C340F0C for ; Sat, 9 Feb 2013 09:16:54 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe03.c2i.net [212.247.154.66]) by mx1.freebsd.org (Postfix) with ESMTP id F0B07F51 for ; Sat, 9 Feb 2013 09:16:53 +0000 (UTC) X-T2-Spam-Status: No, hits=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 Received: from [176.74.213.204] (account mc467741@c2i.net HELO laptop015.hselasky.homeunix.org) by mailfe03.swip.net (CommuniGate Pro SMTP 5.4.4) with ESMTPA id 209076364; Sat, 09 Feb 2013 10:16:46 +0100 From: Hans Petter Selasky To: freebsd-current@freebsd.org Subject: Re: uath panic on insert. Date: Sat, 9 Feb 2013 10:17:56 +0100 User-Agent: KMail/1.13.7 (FreeBSD/9.1-STABLE; KDE/4.8.4; amd64; ; ) References: <201302082353.13581.hselasky@c2i.net> In-Reply-To: X-Face: ?p&W)c(+80hU; '{.$5K+zq{oC6y| /D'an*6mw>j'f:eBsex\Gi, Cc: Ian FREISLICH X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 09 Feb 2013 09:16:54 -0000 On Saturday 09 February 2013 09:47:46 Ian FREISLICH wrote: > Hans Petter Selasky wrote: > > On Friday 08 February 2013 22:43:17 Ian FREISLICH wrote: > > > Hans Petter Selasky wrote: > > > > Hi, > > > > > > > > Your problem should be fixed by: > > > > http://svnweb.freebsd.org/changeset/base/246565 > > > > > > > > Please test and report back if it doesn't. > > > > > > It doesn't panic anymore. Thanks. There's a new problem though: > > > > > > uath0: > > 5> on usbus1 wlan1: Ethernet address: 00:11:95:d3:4a:af > > > > Hi, > > > > Can you try this patch: > > http://svnweb.freebsd.org/changeset/base/246570 > > ugen1.5: at usbus1 > on > usbus1 Ethernet address: 00:11:95:d3:4a:af > uath_cmdsend: empty inactive queue > could not init Tx queues, error 55 > uath_cmdsend: empty inactive queue > could not set channel, error 55 > uath_cmdsend: empty inactive queue > could not set channel, error 55 > uath_cmdsend: empty inactive queue > could not set channel, error 55 > uath_cmdsend: empty inactive queue > could not set channel, error 55 > uath_cmdsend: empty inactive queue > could not set channel, error 55 > at uhub2, port 2, addr 5 (disconnected) <--- > uath_cmdsend: empty inactive queue > uath_cmdsend: empty inactive queue > ugen1.5: at usbus1 (disconnected) > > The card still disconnects after attempting to scan unsupported > frequencies. The sequence above happens when I 'ifconfig wlan1 > up'. Also, the uath driver reports 2.4GHz and 5GHz as supported > channels for this chip but it's a D-Link DWL-G132 which is a 2.4GHz > device. Is this a problem for Adrian to look at? Hi, I see the same over here. I think it is not a USB problem. --HPS From owner-freebsd-current@FreeBSD.ORG Sat Feb 9 09:27:12 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A0EBA3E6 for ; Sat, 9 Feb 2013 09:27:12 +0000 (UTC) (envelope-from joel@FreeBSD.org) Received: from mail.vnode.se (mail.vnode.se [62.119.52.80]) by mx1.freebsd.org (Postfix) with ESMTP id 620ECFD4 for ; Sat, 9 Feb 2013 09:27:12 +0000 (UTC) Received: from mail.vnode.se (localhost [127.0.0.1]) by mail.vnode.se (Postfix) with ESMTP id 44C1DE3F07A for ; Sat, 9 Feb 2013 10:27:11 +0100 (CET) X-Virus-Scanned: amavisd-new at vnode.se Received: from mail.vnode.se ([127.0.0.1]) by mail.vnode.se (mail.vnode.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xl5rFkFWKpTl for ; Sat, 9 Feb 2013 10:27:01 +0100 (CET) Received: from jd.benders.se (jd.benders.se [212.247.52.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.vnode.se (Postfix) with ESMTPSA id 5FAA7E3F079 for ; Sat, 9 Feb 2013 10:27:01 +0100 (CET) Date: Sat, 9 Feb 2013 10:26:59 +0100 From: Joel Dahl To: current@freebsd.org Subject: Re: HEAD memsticks broken? [USB/CAM Problems?] Message-ID: <20130209092659.GO21730@jd.benders.se> References: <20130209073241.GN21730@jd.benders.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130209073241.GN21730@jd.benders.se> User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 09 Feb 2013 09:27:12 -0000 On 09-02-2013 8:32, Joel Dahl wrote: > Hi, > > I suspect something is broken with memsticks built from HEAD. I noticed that I > couldn't boot the latest HEAD (amd64) memstick snapshot on two machines > (Lenovo X220 and HP ProLiant ML350 G5). Trying snapshots from the FreeBSD.org > FTP or allbsd.org makes no difference. I compared output from booting RELENG_9 and HEAD: RELENG_9: ugen2.3: at usbus2 umass0: on usbus2 umass0: SCSI over Bulk-Only; quirks = 0x0100 umass0:4:0:-1: Attached to scbus4 da0 at umass-sim0 bus 0 scbus4 target 0 lun 0 da0: Removable Direct Access SCSI-2 device ??????????? da0: 40.000MB/s transfers da0: 1905MB (3903264 512 byte sectors: 255H 63S/T 24SC) (da0-umass-sim0:0:0:0): PREVENT ALLOW MEDIUM REMOVAL. CDB: 1e 0 0 0 1 0 (da0-umass-sim0:0:0:0): CAM status: SCSI Status Error (da0-umass-sim0:0:0:0): SCSI status: Check Condition (da0-umass-sim0:0:0:0): SCSI sense: No sense data present (da0-umass-sim0:0:0:0): Retrying command (per sense data) Root mount waiting for: usbus2 ugen2.4: at usbus2 Trying to mount root from ufs:/dev/ufs/FreeBSD_Install [ro,noatime]... Starting file system checks: /dev/ufs/FreeBSD_Install: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ufs/FreeBSD_Install: clean, 43155 free (507 frags, 5331 blocks, 0.1% fragmentation) Mounting local file systems:. and it works. HEAD: ugen2.3: at usbus2 umass0: on usbus2 umass0: SCSI over Bulk-Only; quirks = 0x0100 umass0:5:0:-1: Attached to scbus5 da0 at umass-sim0 bus 0 scbus5 target 0 lun 0 da0: Removable Direct Access SCSI-0 device ?????????? da0: 40.000MB/s transfers da0: 3690MB (7557704 512 byte sectors: 255H 63S/T 470SC) (da0-umass-sim0:0:0:0): PREVENT ALLOW MEDIUM REMOVAL. CDB: 1e 0 0 0 1 0 (da0-umass-sim0:0:0:0): CAM status: SCSI Status Error (da0-umass-sim0:0:0:0): SCSI status: Check Condition (da0-umass-sim0:0:0:0): SCSI sense: No sense data present (da0-umass-sim0:0:0:0): Retrying command (per sense data) (da0-umass-sim0:0:0:0): Error 5, Retries exhausted (da0-umass-sim0:0:0:0): got CAM status 0x8c (da0-umass-sim0:0:0:0): fatal error, failed to attach to device (da0-umass-sim0:0:0:0): lost device - 0 outstanding, 4 refs (da0-umass-sim0:0:0:0): removing device entry ugen2.4: at usbus2 Trying to mount root from ufs:/dev/ufs/FreeBSD_Install [ro,noatime]... mountroot: waiting for device /dev/ufs/FreeBSD_Install ... Mounting from ufs:/dev/ufs/FreeBSD_Install failed with error 19. BOOM -- Joel From owner-freebsd-current@FreeBSD.ORG Sat Feb 9 10:14:17 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 32F501B3; Sat, 9 Feb 2013 10:14:17 +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 36A581B7; Sat, 9 Feb 2013 10:14:15 +0000 (UTC) X-T2-Spam-Status: No, hits=-1.0 required=5.0 tests=ALL_TRUSTED Received: from [176.74.213.204] (account mc467741@c2i.net HELO laptop015.hselasky.homeunix.org) by mailfe08.swip.net (CommuniGate Pro SMTP 5.4.4) with ESMTPA id 377388283; Sat, 09 Feb 2013 11:14:14 +0100 From: Hans Petter Selasky To: freebsd-current@freebsd.org, mav@freebsd.org Subject: Re: HEAD memsticks broken? [USB/CAM Problems?] Date: Sat, 9 Feb 2013 11:15:24 +0100 User-Agent: KMail/1.13.7 (FreeBSD/9.1-STABLE; KDE/4.8.4; amd64; ; ) References: <20130209073241.GN21730@jd.benders.se> <20130209092659.GO21730@jd.benders.se> In-Reply-To: <20130209092659.GO21730@jd.benders.se> X-Face: ?p&W)c(+80hU; '{.$5K+zq{oC6y| /D'an*6mw>j'f:eBsex\Gi, Cc: Joel Dahl X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 09 Feb 2013 10:14:17 -0000 On Saturday 09 February 2013 10:26:59 Joel Dahl wrote: > On 09-02-2013 8:32, Joel Dahl wrote: > > Hi, > > > > I suspect something is broken with memsticks built from HEAD. I noticed > > that I couldn't boot the latest HEAD (amd64) memstick snapshot on two > > machines (Lenovo X220 and HP ProLiant ML350 G5). Trying snapshots from > > the FreeBSD.org FTP or allbsd.org makes no difference. > > I compared output from booting RELENG_9 and HEAD: > > RELENG_9: > > ugen2.3: at usbus2 > umass0: on > usbus2 umass0: SCSI over Bulk-Only; quirks = 0x0100 > umass0:4:0:-1: Attached to scbus4 > da0 at umass-sim0 bus 0 scbus4 target 0 lun 0 > da0: Removable Direct Access SCSI-2 device > ??????????? da0: 40.000MB/s transfers > da0: 1905MB (3903264 512 byte sectors: 255H 63S/T 24SC) > (da0-umass-sim0:0:0:0): PREVENT ALLOW MEDIUM REMOVAL. CDB: 1e 0 0 0 1 0 > (da0-umass-sim0:0:0:0): CAM status: SCSI Status Error > (da0-umass-sim0:0:0:0): SCSI status: Check Condition > (da0-umass-sim0:0:0:0): SCSI sense: No sense data present > (da0-umass-sim0:0:0:0): Retrying command (per sense data) > > > > Root mount waiting for: usbus2 > ugen2.4: at usbus2 > Trying to mount root from ufs:/dev/ufs/FreeBSD_Install [ro,noatime]... > Starting file system checks: > /dev/ufs/FreeBSD_Install: FILE SYSTEM CLEAN; SKIPPING CHECKS > /dev/ufs/FreeBSD_Install: clean, 43155 free (507 frags, 5331 blocks, 0.1% > fragmentation) Mounting local file systems:. > > and it works. > > HEAD: > > ugen2.3: at usbus2 > umass0: on > usbus2 umass0: SCSI over Bulk-Only; quirks = 0x0100 > umass0:5:0:-1: Attached to scbus5 > da0 at umass-sim0 bus 0 scbus5 target 0 lun 0 > da0: Removable Direct Access SCSI-0 device > ?????????? da0: 40.000MB/s transfers > da0: 3690MB (7557704 512 byte sectors: 255H 63S/T 470SC) > (da0-umass-sim0:0:0:0): PREVENT ALLOW MEDIUM REMOVAL. CDB: 1e 0 0 0 1 0 > (da0-umass-sim0:0:0:0): CAM status: SCSI Status Error > (da0-umass-sim0:0:0:0): SCSI status: Check Condition > (da0-umass-sim0:0:0:0): SCSI sense: No sense data present > (da0-umass-sim0:0:0:0): Retrying command (per sense data) > > > > (da0-umass-sim0:0:0:0): Error 5, Retries exhausted > (da0-umass-sim0:0:0:0): got CAM status 0x8c > (da0-umass-sim0:0:0:0): fatal error, failed to attach to device > (da0-umass-sim0:0:0:0): lost device - 0 outstanding, 4 refs > (da0-umass-sim0:0:0:0): removing device entry > ugen2.4: at usbus2 > Trying to mount root from ufs:/dev/ufs/FreeBSD_Install [ro,noatime]... > mountroot: waiting for device /dev/ufs/FreeBSD_Install ... > Mounting from ufs:/dev/ufs/FreeBSD_Install failed with error 19. Hi, You can try to set the no-synchronize cache quirk in sys/dev/usb/quirk/usb_quirk.c for your device. I'm not sure if it helps, but else I suspect it is not an USB issue. --HPS From owner-freebsd-current@FreeBSD.ORG Sat Feb 9 10:15:41 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id BB5D12D3; Sat, 9 Feb 2013 10:15:41 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id 420451D2; Sat, 9 Feb 2013 10:15:40 +0000 (UTC) Received: from ur.dons.net.au (ppp118-210-73-50.lns20.adl2.internode.on.net [118.210.73.50]) (authenticated bits=0) by cain.gsoft.com.au (8.14.4/8.14.3) with ESMTP id r19AFQce071839 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 9 Feb 2013 20:45:32 +1030 (CST) (envelope-from doconnor@gsoft.com.au) Subject: Re: Intel 82574 issue reported on Slashdot Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=us-ascii From: "Daniel O'Connor" In-Reply-To: <20130209101219.GA2133@holstein.holy.cow> Date: Sat, 9 Feb 2013 20:45:26 +1030 Content-Transfer-Encoding: quoted-printable Message-Id: <1D962264-6DF6-4192-8190-34E22AADE843@gsoft.com.au> References: <20130209101219.GA2133@holstein.holy.cow> To: Parv X-Mailer: Apple Mail (2.1499) X-Spam-Score: 0.163 () BAYES_00,RDNS_DYNAMIC X-Scanned-By: MIMEDefang 2.67 on 203.31.81.10 Cc: FreeBSD stable , FreeBSD Current , "Pieper, Jeffrey E" , FreeBSD Net , "Hearn, James R" , "Vogel, Jack" , "Ronciak, John" , Jack Vogel X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 09 Feb 2013 10:15:41 -0000 On 09/02/2013, at 20:42, Parv wrote: >> "Contact your motherboard manufacturer" is much more time >> consuming than "Run sysctl... | grep foo | awk ..." to see if your >> system is affected. >=20 > Gift^WStraight from horse's mouth ... >=20 > http://blog.krisk.org/2013/02/packets-of-death.html I've already read this. > http://www.kriskinc.com/intel-pod I'd really rather a test which reads the EEPROM and tells me if it's a = problem rather than hang the interface on a machine :) In any case that isn't the point - this may be a "vendor issue" but it = reflects poorly on Intel that they didn't take proper ownership of the = issue. It would be far, far better for their image to say "some systems = may have the fault, go to http://.... to find a way to test for your = operating system". -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C From owner-freebsd-current@FreeBSD.ORG Sat Feb 9 12:17:10 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D17257A5 for ; Sat, 9 Feb 2013 12:17:10 +0000 (UTC) (envelope-from current@freebsd.org) Received: from mail.morrisontesl.com (mail.morrisontesl.com [194.125.152.211]) by mx1.freebsd.org (Postfix) with ESMTP id 51CD5747 for ; Sat, 9 Feb 2013 12:17:10 +0000 (UTC) Received: from dubmail02.tesldublin.local ([10.10.10.17]) by mail.morrisontesl.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 7 Feb 2013 15:18:09 +0000 Message-ID: <14471.1360250289723.mlfjunkn.root@dubmail02> Date: Thu, 7 Feb 2013 15:18:09 +0000 From: Admin Junk Summary To: "current@freebsd.org" Subject: Summary of junk emails blocked - 1 Junk Emails Blocked Mime-Version: 1.0 Precedence: bulk X-Mlf-Communication-Key: ahad-acga-aaab-fdag-adfe-ahae; disposition=internal X-Mlf-loginurl: http://10.10.10.17:10080 X-Mlf-version: 7.2.3.3599 X-OriginalArrivalTime: 07 Feb 2013 15:18:09.0723 (UTC) FILETIME=[567D60B0:01CE0546] Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Feb 2013 12:17:10 -0000 Junk Box Summary for: current@freebsd.org The 1 emails listed below have been placed in your personal Junk Box since your last Junk Box Summary and will be deleted after 30 days. To retrieve any of these messages, visit your Junk Box at: Login using your standard username/password combination. Junk Box Summary --------------------------------------------------------------------- nvza@gmail.com =?windows-1251?B?W8rIxcJdIMLA0NjAwtHKwN8gwcjQxsAg1sXNzd... --------------------------------------------------------------------- Junk blocking by SonicWALL From owner-freebsd-current@FreeBSD.ORG Sat Feb 9 12:17:46 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9FB7F8E2; Sat, 9 Feb 2013 12:17: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 5380A772; Sat, 9 Feb 2013 12:17: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 <1U49NC-000SJA-Rk>; Sat, 09 Feb 2013 13:17:38 +0100 Received: from e178030124.adsl.alicedsl.de ([85.178.30.124] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1U49NC-001uSu-OF>; Sat, 09 Feb 2013 13:17:38 +0100 Message-ID: <51163E5B.7070602@zedat.fu-berlin.de> Date: Sat, 09 Feb 2013 13:17:31 +0100 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130131 Thunderbird/17.0.2 MIME-Version: 1.0 Subject: Re: Intel 82574 issue reported on Slashdot References: In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigAFCE9A2736331D45EB2F96D7" X-Originating-IP: 85.178.30.124 Cc: FreeBSD Net , FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 09 Feb 2013 12:17:46 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigAFCE9A2736331D45EB2F96D7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Am 02/09/13 09:15, schrieb Johnny Eriksson: >> In all honesty.. The blog post (and your email) are basically >> information free, they don't name names and provide no script >> or downloadable code that will allow end users to check if they >> are affected. >=20 > A link with a little bit more information: >=20 > http://blog.krisk.org/2013/02/packets-of-death.html >=20 >> Daniel O'Connor software and network engineer >=20 > --Johnny We don't even have the tool tcpreplay in the ports mentioned in that BLOG= =2E oh --------------enigAFCE9A2736331D45EB2F96D7 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) iQEcBAEBAgAGBQJRFj5iAAoJEOgBcD7A/5N8JnoH/ii46xUh/BhwbRv8ZommzU81 Ku7zSQErG3Mew51y6j1GmRyBb51Fu6KaQEgR0I8d0c0InL7amJ64tk+4u6KmoRot 1BWuCQUfjonhOqdkoE3pqlfNSh5L9mfmiZrhfgByTDhMlYdiaXtGfKF1I9WV97XU V6780P5vswuFXkGfWdoBMH2JqKVIapeGxZfWUGnDhUWu/5tK7RceZDlhfnyNbYQu AX3Ev7ujGusIyMcYxu8iBYq1sn9y78Sghm+8sFhvlPvSgyZT7fH25ndGeX9Ou3Ty lX//u1MOock7pFpc9LV1FWywtxuJJpwbhoMITuNxlsrdYYk3FvOO61587IYnsYw= =A1er -----END PGP SIGNATURE----- --------------enigAFCE9A2736331D45EB2F96D7-- From owner-freebsd-current@FreeBSD.ORG Sat Feb 9 13:08:19 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 4EA9B707; Sat, 9 Feb 2013 13:08:19 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.18.43]) by mx1.freebsd.org (Postfix) with ESMTP id D4D82981; Sat, 9 Feb 2013 13:08:18 +0000 (UTC) Received: from [78.35.140.200] (helo=fabiankeil.de) by smtprelay01.ispgateway.de with esmtpsa (SSLv3:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1U4AA7-000675-7Q; Sat, 09 Feb 2013 14:08:11 +0100 Date: Sat, 9 Feb 2013 14:07:33 +0100 From: Fabian Keil To: Eitan Adler Subject: Re: geli(8) breaks after a couple hours of uptime Message-ID: <20130209140733.0b753c60@fabiankeil.de> In-Reply-To: References: <20130207141833.GA15884@acme.spoerlein.net> <20130207153322.5c371beb@fabiankeil.de> <20130207180153.GX35868@acme.spoerlein.net> <20130208095709.6ae61cff@fabiankeil.de> <20130208114825.GY35868@acme.spoerlein.net> <5114F390.4010302@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/jY2+Yx8L8PEl1v6N.Rbl=Fs"; protocol="application/pgp-signature" X-Df-Sender: Nzc1MDY3 Cc: zont@freebsd.org, current@freebsd.org, Andriy Gapon X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 09 Feb 2013 13:08:19 -0000 --Sig_/jY2+Yx8L8PEl1v6N.Rbl=Fs Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Eitan Adler wrote: > On 8 February 2013 07:46, Andriy Gapon wrote: > > on 08/02/2013 13:48 Ulrich Sp=C3=B6rlein said the following: > >> It looks like 128k as a limit is still too low for geli(8) to work, and > >> I've set it to 256k now, so that I can use "sudo geli". Can you maybe > >> revise the patch to not use 1024k as an arbitrary limit, but rather ma= ke > >> sure you test for precisely as much memory as will be needed? IIRC 256K didn't work for me, 512K did, so I doubled it to have some leg room. I'm not sure it's possible to reliably estimate the required memory without first changing geli to mlock less generously, something Konstantin suggested in: http://lists.freebsd.org/pipermail/svn-src-all/2013-January/063939.html While I agree that mlocking less generously would technically be a better solution than increasing the limit, it would also require a lot more work, additional audits to make sure it's done correctly and in case of geli I don't really see a problem with mlocking 1024K for a few seconds. > >> Also, can we maybe revisit the new 64k default limit, as it will > >> obviously make peoples work with geli a bit painful, this should work > >> out of the box. > > > > I have some, IMO, better suggestions: > > - use -c option with sudo I usually execute "sudo geli" through a wrapper (zogftw) so this makes patching geli optional for me. Thanks for mentioning it (again). > > - tune your system for your needs > > > > - [major] abolish the silliness of tying resource limits to login class= and apply > > resource limits based on user and group IDs; including after su/sudo (s= ubject to > > local policies) While we are dreaming, it would be nice to have more resource limits that apply to all the processes belonging to the user combined. It also wouldn't hurt to document why a 64K per-process limit with an unlimited number of processes per user is considered a good default in the first place. > The default settings should not make another feature unusable. At a > minimum it should be documented in geli's man page that such tuning is > required. If the consensus is that 1024K are too much for geli and nobody can be bothered to come up with a more fine grained mlocking patch, geli could be changed to check the mlock limit and exit with a useful error message if it's too low. This would at least prevent the segfault. Fabian --Sig_/jY2+Yx8L8PEl1v6N.Rbl=Fs Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlEWSj8ACgkQBYqIVf93VJ3rAgCgu1iYg5yzcXQcPdIbZkIEDpt6 b4UAn0jMgyb4DIpCJQTh3sBMVaN6pNfP =wEMK -----END PGP SIGNATURE----- --Sig_/jY2+Yx8L8PEl1v6N.Rbl=Fs-- From owner-freebsd-current@FreeBSD.ORG Sat Feb 9 10:12:26 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 97EE3EAD; Sat, 9 Feb 2013 10:12:26 +0000 (UTC) (envelope-from parv@pair.com) Received: from hrndva-omtalb.mail.rr.com (hrndva-omtalb.mail.rr.com [71.74.56.122]) by mx1.freebsd.org (Postfix) with ESMTP id 18E1E191; Sat, 9 Feb 2013 10:12:24 +0000 (UTC) X-Authority-Analysis: v=2.0 cv=bJmU0YCZ c=1 sm=0 a=lLOF/jpPrR0dcgWXP1EvZg==:17 a=xCuMbNp8hPoA:10 a=dLZphiicA4cA:10 a=R5FhY6rjjCMA:10 a=kj9zAlcOel0A:10 a=Ymsr-CWnAAAA:8 a=LDrFwfghZz0A:10 a=iReALljSAAAA:8 a=pGLkceISAAAA:8 a=QyXUC8HyAAAA:8 a=RaItmienAAAA:8 a=E70Ph-o_AAAA:8 a=WxxYND6mw3PQpSCbB8QA:9 a=CjuIK1q_8ugA:10 a=4elu-xP5etcA:10 a=MSl-tDqOz04A:10 a=lLOF/jpPrR0dcgWXP1EvZg==:117 X-Cloudmark-Score: 0 X-Authenticated-User: X-Originating-IP: 204.210.114.114 Received: from [204.210.114.114] ([204.210.114.114:49924] helo=localhost.hawaii.res.rr.com) by hrndva-oedge01.mail.rr.com (envelope-from ) (ecelerity 2.2.3.46 r()) with ESMTP id 59/B5-06157-10126115; Sat, 09 Feb 2013 10:12:18 +0000 Received: by localhost.hawaii.res.rr.com (Postfix, from userid 1000) id AFE745CAD; Sat, 9 Feb 2013 00:12:19 -1000 (HST) Date: Sat, 9 Feb 2013 00:12:19 -1000 From: Parv To: Daniel O'Connor Subject: Re: Intel 82574 issue reported on Slashdot Message-ID: <20130209101219.GA2133@holstein.holy.cow> Mail-Followup-To: Daniel O'Connor , Jack Vogel , FreeBSD stable , "Pieper, Jeffrey E" , FreeBSD Net , "Hearn, James R" , "Vogel, Jack" , "Ronciak, John" , FreeBSD Current References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Mailman-Approved-At: Sat, 09 Feb 2013 13:09:32 +0000 Cc: FreeBSD stable , FreeBSD Current , "Pieper, Jeffrey E" , FreeBSD Net , "Hearn, James R" , "Vogel, Jack" , "Ronciak, John" , Jack Vogel X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 09 Feb 2013 10:12:26 -0000 in message , wrote Daniel O'Connor thusly... > > > On 09/02/2013, at 4:46, Jack Vogel wrote: > > > recommends contacting your motherboard manufacturer if you have > > continued concerns or questions whether your products are > > impacted. Here is the link: > > > > http://communities.intel.com/community/wired/blog/2013/02/07/intel-82574l-gigabit-ethernet-controller-statement > > > > Any questions or concerns may be sent to me. > > In all honesty.. The blog post (and your email) are basically > information free, they don't name names and provide no script or > downloadable code that will allow end users to check if they are > affected. > "Contact your motherboard manufacturer" is much more time > consuming than "Run sysctl... | grep foo | awk ..." to see if your > system is affected. Gift^WStraight from horse's mouth ... http://blog.krisk.org/2013/02/packets-of-death.html http://www.kriskinc.com/intel-pod - parv -- From owner-freebsd-current@FreeBSD.ORG Sat Feb 9 13:23:21 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9B54CC00 for ; Sat, 9 Feb 2013 13:23:21 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.31.35]) by mx1.freebsd.org (Postfix) with ESMTP id 5DA31A11 for ; Sat, 9 Feb 2013 13:23:21 +0000 (UTC) Received: from [78.35.140.200] (helo=fabiankeil.de) by smtprelay01.ispgateway.de with esmtpsa (SSLv3:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1U4AOf-00043l-SN; Sat, 09 Feb 2013 14:23:13 +0100 Date: Sat, 9 Feb 2013 14:21:12 +0100 From: Fabian Keil To: Konstantin Belousov Subject: Re: Physbio changes final call for tests and reviews Message-ID: <20130209142112.5531bbf9@fabiankeil.de> In-Reply-To: <20130202163322.GA2522@kib.kiev.ua> References: <20130202163322.GA2522@kib.kiev.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/.vQdn9saT1v=LKUG3caXq6u"; protocol="application/pgp-signature" X-Df-Sender: Nzc1MDY3 Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 09 Feb 2013 13:23:21 -0000 --Sig_/.vQdn9saT1v=LKUG3caXq6u Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Konstantin Belousov wrote: > I finished the last (insignificant) missed bits in the Jeff' physbio > work. Now I am asking for the last round of testing and review, esp. for > the !x86 architectures. Another testing focus are the SCSI HBAs and RAID > controllers which drivers are changed by the patchset. Please do test > this before the patchset is committed into HEAD ! I could only test on amd64 without fancy SCSI controllers, but it works for me. Fabian --Sig_/.vQdn9saT1v=LKUG3caXq6u Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlEWTWQACgkQBYqIVf93VJ3YZQCgkarZEB1/Ktq/SJMR0FqBdn+I NDkAoMHmJ3uFZbY2PLu+Vnn/69SghyDT =ayri -----END PGP SIGNATURE----- --Sig_/.vQdn9saT1v=LKUG3caXq6u-- From owner-freebsd-current@FreeBSD.ORG Sat Feb 9 14:45:00 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D2BB737B for ; Sat, 9 Feb 2013 14:45:00 +0000 (UTC) (envelope-from cmt@burggraben.net) Received: from smtp.burggraben.net (base.exwg.net [IPv6:2a01:4f8:140:50a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id 94177D8E for ; Sat, 9 Feb 2013 14:45:00 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.burggraben.net (Postfix) with ESMTP id 7999F6003CD for ; Sat, 9 Feb 2013 15:44:59 +0100 (CET) X-Spam-Scanned: by amavisd-new at exwg.net Received: from smtp.burggraben.net ([127.0.0.1]) by localhost (ns.burggraben.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r2f66r77BEQZ for ; Sat, 9 Feb 2013 15:44:58 +0100 (CET) Received: from elch.exwg.net (dslb-088-066-015-247.pools.arcor-ip.net [88.66.15.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "elch.exwg.net", Issuer "Christoph Moench-Tegeder" (verified OK)) by smtp.burggraben.net (Postfix) with ESMTPS for ; Sat, 9 Feb 2013 15:44:58 +0100 (CET) Received: by elch.exwg.net (Postfix, from userid 1000) id 598B13104B; Sat, 9 Feb 2013 15:44:58 +0100 (CET) Date: Sat, 9 Feb 2013 15:44:58 +0100 From: Christoph Moench-Tegeder To: freebsd-current@freebsd.org Subject: Re: Intel 82574 issue reported on Slashdot Message-ID: <20130209144457.GA2067@elch.exwg.net> References: <51163E5B.7070602@zedat.fu-berlin.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51163E5B.7070602@zedat.fu-berlin.de> User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 09 Feb 2013 14:45:00 -0000 ## O. Hartmann (ohartman@zedat.fu-berlin.de): > We don't even have the tool tcpreplay in the ports mentioned in that BLOG. It's in net-mgmt/tcpreplay. Regards, Christoph -- Spare Space From owner-freebsd-current@FreeBSD.ORG Sat Feb 9 14:46:03 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 6E2B2573 for ; Sat, 9 Feb 2013 14:46:03 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay06.ispgateway.de (smtprelay06.ispgateway.de [80.67.31.103]) by mx1.freebsd.org (Postfix) with ESMTP id 05114DB0 for ; Sat, 9 Feb 2013 14:46:02 +0000 (UTC) Received: from [78.35.140.200] (helo=fabiankeil.de) by smtprelay06.ispgateway.de with esmtpsa (SSLv3:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1U4Bgh-0006ll-IF for freebsd-current@freebsd.org; Sat, 09 Feb 2013 15:45:55 +0100 Date: Sat, 9 Feb 2013 15:42:10 +0100 From: Fabian Keil To: FreeBSD Current Subject: Destroying ZFS snapshots "too quickly": xpt_scan_lun: can't allocate CCB, can't continue Message-ID: <20130209154210.02af9e1e@fabiankeil.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/fTb7xoZWDGDAkZjIYqIG7KH"; protocol="application/pgp-signature" X-Df-Sender: Nzc1MDY3 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 09 Feb 2013 14:46:03 -0000 --Sig_/fTb7xoZWDGDAkZjIYqIG7KH Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Before the introduction of async_destroy I wrote a script to destroy ZFS snapshots in parallel to speed up the process. It's available at: http://www.fabiankeil.de/sourcecode/zfs-snapshot-destroyer/zsd.pl A couple of years ago the only downside seemed to be that it requires more memory and file descriptors (due to multiple zfs processes running at the same time) and that errors are ignored (implementation detail of the script). Recently I noticed that destroying several hundred (500) snapshots this way risks rendering the system unresponsive. I rarely do that, so it might not actually be a regression. When using X the screen freezes and keyboard input is ignored so it's hard to tell what's going on. When running the script on the console alt+Fx are often still accepted to switch consoles, but other keyboard input like entering commands or trying to login has no visible effect. A running top is killed and the system frequently logs: "xpt_scan_lun: can't allocate CCB, can't continue". Plugging in USB devices still result in the expected messages, but other than this the system seems to be unresponsive and doesn't recover (I only waited a couple of minutes, though). A "CCB" seems to be rather small: http://fxr.watson.org/fxr/source/cam/cam_xpt.c#L4386 therefore I suspect that ZFS got greedy and didn't play nice with the rest of the system. I have no proof that ZFS isn't merely triggering a problem in another subsystem, though. So far I haven't been able to reproduce the problem with snapshots intentionally created for testing, but I also used a somewhat simplistic approach to populate the snapshots. Is this considered a bug or is quickly destroying snapshots just something for the "don't do this" or "not without proper tuning" departments? I would also be interested to know if there's a way to somehow roughly figure out from userland how many snapshots can be safely destroyed in a row. Example: Look at "some" system state, destroy a safe amount of snapshots, look at "some" system state again and interpolate. Before top gets killed it usually shows that zfskern takes more than 50% WCPU, but this can also happen when the system doesn't become unresponsive and thus probably isn't a good metric (the delay also doesn't help of course). Fabian --Sig_/fTb7xoZWDGDAkZjIYqIG7KH Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlEWYFAACgkQBYqIVf93VJ26AQCgyNSEu4olFRduLjVrDfIbi0Zp TgEAoKFbVhd3A+I109Bq1zFcFz48iDk6 =4Q/q -----END PGP SIGNATURE----- --Sig_/fTb7xoZWDGDAkZjIYqIG7KH-- From owner-freebsd-current@FreeBSD.ORG Sat Feb 9 15:04:41 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id DF5CCBC9 for ; Sat, 9 Feb 2013 15:04:41 +0000 (UTC) (envelope-from andrey@zonov.org) Received: from mail-la0-x230.google.com (la-in-x0230.1e100.net [IPv6:2a00:1450:4010:c03::230]) by mx1.freebsd.org (Postfix) with ESMTP id 650E4E3C for ; Sat, 9 Feb 2013 15:04:41 +0000 (UTC) Received: by mail-la0-f48.google.com with SMTP id fq13so4689080lab.35 for ; Sat, 09 Feb 2013 07:04:40 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:sender:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:x-enigmail-version:content-type :x-gm-message-state; bh=jQJakDNWSINowQqLrKjuayiyOEwJXZWxp9+i82VVkTk=; b=I+rKZkCaGCNcHc+nxWllwkYmR1G/07dg+srgm01kINsfVhq6+JXMLt5C25U8S4mRfO vCYLxcREfr50RxACGwKGDuWylK153edwyZR0Neke8uZmudZMJ/tX0u8ZZaaJTw5fU7ww 0Hfdc0bzWkmhLsirsddkRpxb4rbzoTszd/2lFchPWBbj11WQBRyr60jkYh0koby9O0hh zFZ0S0sUGrZIx05rkjmaUKqjeaGMgA38djNlpOQ4Ol7qDBjh3VM1y5XV2Ck6TPEpSGy2 Auei+sSqKmVZ47evMAB1MuDKZVu+dPF2LqaAYZ/YREAJdbIG9pOFhA0p+VyguQFkzDw6 zJqw== X-Received: by 10.152.46.131 with SMTP id v3mr5385962lam.57.1360422279946; Sat, 09 Feb 2013 07:04:39 -0800 (PST) Received: from zont-osx.local (ppp95-165-158-215.pppoe.spdop.ru. [95.165.158.215]) by mx.google.com with ESMTPS id ns7sm18623581lab.5.2013.02.09.07.04.37 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 09 Feb 2013 07:04:38 -0800 (PST) Sender: Andrey Zonov Message-ID: <51166580.4080603@FreeBSD.org> Date: Sat, 09 Feb 2013 19:04:32 +0400 From: Andrey Zonov User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Fabian Keil Subject: Re: geli(8) breaks after a couple hours of uptime References: <20130207141833.GA15884@acme.spoerlein.net> <20130207153322.5c371beb@fabiankeil.de> <20130207180153.GX35868@acme.spoerlein.net> <20130208095709.6ae61cff@fabiankeil.de> <20130208114825.GY35868@acme.spoerlein.net> <5114F390.4010302@FreeBSD.org> <20130209140733.0b753c60@fabiankeil.de> In-Reply-To: <20130209140733.0b753c60@fabiankeil.de> X-Enigmail-Version: 1.5 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2JIFTPCALEFSATLEMVGHW" X-Gm-Message-State: ALoCoQk0aslsp1p4vyxkX7wnrPbZQHfy9lmne+FbMinArIQx296+8ZQcoVXT7cHbuYVwrKuviKgh Cc: Eitan Adler , current@freebsd.org, Andriy Gapon X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 09 Feb 2013 15:04:41 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2JIFTPCALEFSATLEMVGHW Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 2/9/13 5:07 PM, Fabian Keil wrote: >=20 > This would at least prevent the segfault. >=20 I see two possibilities to get segfault: - no checking for result from memory allocation functions - too big stack I have no found any broken memory allocation checking, but I found two big objects on the stack. One is buf[MAXPHYS] in eli_genkey_files() and another is passbuf[MAXPHYS] in eli_genkey_passphrase(). If we change these two to malloc(), then we can handle error from malloc(), print some useful message and prevent segfault. --=20 Andrey Zonov ------enig2JIFTPCALEFSATLEMVGHW Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJRFmWEAAoJEBWLemxX/CvTqykIAKS9djh3rFeDUNCHiOZNh9g/ Qfvmb62qYujYIO1dTdgsTi1zG7x56TftEV8rXktKcoVTWyNUEZ1BlmiBtv8YWJEW HFVCBBISzSgxtJw5j4c5CqwcE0IgJjSMLO7I61jJ46BcOtgc8VJsSieKVQnhYnEe 3CTGHK277UuwrGHvBirTMHpE49j14bu0cnPPROUFbxhhQSjWi+LFG5LzTbV8OJzY CtWd15xw/6dNLZKaltwxZH45vwNim/vNqilTG20R2cCwid7VpzhkiUuqAsxFXdA9 eSIm3uCgBJtDLCuNdkN8SclxkStSmbT0mfYD+FGKMO5+GrF56I13NFtYn/MJhiM= =C4e8 -----END PGP SIGNATURE----- ------enig2JIFTPCALEFSATLEMVGHW-- From owner-freebsd-current@FreeBSD.ORG Sat Feb 9 15:25:12 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C17286A for ; Sat, 9 Feb 2013 15:25:12 +0000 (UTC) (envelope-from tomek.cedro@gmail.com) Received: from mail-qa0-f43.google.com (mail-qa0-f43.google.com [209.85.216.43]) by mx1.freebsd.org (Postfix) with ESMTP id 8A295F77 for ; Sat, 9 Feb 2013 15:25:12 +0000 (UTC) Received: by mail-qa0-f43.google.com with SMTP id dx4so694111qab.9 for ; Sat, 09 Feb 2013 07:25:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=TRd6/4ov9J/sPaKlO82TEpQLMskxqBxC27RnaMZkv2o=; b=nPfr1cM+K5ff726NlDR3S/sWuWhIE5yZmqUE1lgKxG75t7eWmiulAOgUsU2oztGkpP 5jC5x/1ubnDZOJ/9cyCzt/3uQPerjNA/JXZ6Sjr+DS+tGS4K5MMOz6XIVtZb9sQ4JOvd S5YcwbG5uDxAJyqV8yCCbIxfZzfjgawzgFkI9rtbFudVB/ZeB3Ev/rDIXbx5CmqiACO7 Hih6hDAjpDwQOXArxid9hUOmdUcI89fwH2ZWedt2Yos41Fyt2a4R5zHXgcR79l7t3giU EQHGI8Drz+OqQQ4gUwMpjBSzrQcLxFlmW3GlAkdYklLLT1j5MCoCi1LqKRFap2UdWexo NH6w== MIME-Version: 1.0 X-Received: by 10.49.127.238 with SMTP id nj14mr3775374qeb.9.1360423506114; Sat, 09 Feb 2013 07:25:06 -0800 (PST) Sender: tomek.cedro@gmail.com Received: by 10.49.71.204 with HTTP; Sat, 9 Feb 2013 07:25:06 -0800 (PST) In-Reply-To: <20130209144457.GA2067@elch.exwg.net> References: <51163E5B.7070602@zedat.fu-berlin.de> <20130209144457.GA2067@elch.exwg.net> Date: Sat, 9 Feb 2013 16:25:06 +0100 X-Google-Sender-Auth: 39GBo_ePI5ys9Ey51I6jluevFXk Message-ID: Subject: Re: Intel 82574 issue reported on Slashdot From: CeDeROM To: Christoph Moench-Tegeder Content-Type: text/plain; charset=UTF-8 Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 09 Feb 2013 15:25:12 -0000 On Sat, Feb 9, 2013 at 3:44 PM, Christoph Moench-Tegeder wrote: > ## O. Hartmann (ohartman@zedat.fu-berlin.de): >> We don't even have the tool tcpreplay in the ports mentioned in that BLOG. > It's in net-mgmt/tcpreplay. And I managed to build mentioned Ostinato packet crafting utility with no problem on my FreeBSD 9.1-RELEASE AMD64. If they provide package and release (which I already asked from the authors) I will make a port for this tool as well :-) Best regards :-) Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info From owner-freebsd-current@FreeBSD.ORG Sat Feb 9 15:53:45 2013 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 7599654A; Sat, 9 Feb 2013 15:53:45 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 597F27C; Sat, 9 Feb 2013 15:53:43 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id RAA21433; Sat, 09 Feb 2013 17:53:39 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1U4CkF-00086d-IX; Sat, 09 Feb 2013 17:53:39 +0200 Message-ID: <51167101.4010902@FreeBSD.org> Date: Sat, 09 Feb 2013 17:53:37 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130121 Thunderbird/17.0.2 MIME-Version: 1.0 To: Fabian Keil Subject: Re: geli(8) breaks after a couple hours of uptime References: <20130207141833.GA15884@acme.spoerlein.net> <20130207153322.5c371beb@fabiankeil.de> <20130207180153.GX35868@acme.spoerlein.net> <20130208095709.6ae61cff@fabiankeil.de> <20130208114825.GY35868@acme.spoerlein.net> <5114F390.4010302@FreeBSD.org> <20130209140733.0b753c60@fabiankeil.de> In-Reply-To: <20130209140733.0b753c60@fabiankeil.de> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Eitan Adler , zont@FreeBSD.org, current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 09 Feb 2013 15:53:45 -0000 on 09/02/2013 15:07 Fabian Keil said the following: > It also wouldn't hurt to document why a 64K per-process limit with an > unlimited number of processes per user is considered a good default in > the first place. I don't think that maxproc=unlimited is a good default regardless of memorylocked. OTOH, we have kern.maxprocperuid. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Sat Feb 9 16:00:57 2013 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 05B257B9; Sat, 9 Feb 2013 16:00:57 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id DB620CF; Sat, 9 Feb 2013 16:00:55 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id SAA21480; Sat, 09 Feb 2013 18:00:54 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1U4CrF-00087B-Ql; Sat, 09 Feb 2013 18:00:53 +0200 Message-ID: <511672B5.5080300@FreeBSD.org> Date: Sat, 09 Feb 2013 18:00:53 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130121 Thunderbird/17.0.2 MIME-Version: 1.0 To: Andrey Zonov Subject: Re: geli(8) breaks after a couple hours of uptime References: <20130207141833.GA15884@acme.spoerlein.net> <20130207153322.5c371beb@fabiankeil.de> <20130207180153.GX35868@acme.spoerlein.net> <20130208095709.6ae61cff@fabiankeil.de> <20130208114825.GY35868@acme.spoerlein.net> <5114F390.4010302@FreeBSD.org> <20130209140733.0b753c60@fabiankeil.de> <51166580.4080603@FreeBSD.org> In-Reply-To: <51166580.4080603@FreeBSD.org> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Eitan Adler , current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 09 Feb 2013 16:00:57 -0000 on 09/02/2013 17:04 Andrey Zonov said the following: > On 2/9/13 5:07 PM, Fabian Keil wrote: >> >> This would at least prevent the segfault. >> > > I see two possibilities to get segfault: > - no checking for result from memory allocation functions > - too big stack > > I have no found any broken memory allocation checking, but I found two > big objects on the stack. One is buf[MAXPHYS] in eli_genkey_files() and > another is passbuf[MAXPHYS] in eli_genkey_passphrase(). If we change > these two to malloc(), then we can handle error from malloc(), print > some useful message and prevent segfault. I'd rather do what Kostik suggested and Fabian mentioned: instead of mlockall(MCL_FUTURE) the code should mlock only the (explicitly designated) buffers that can contain sensitive data. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Sat Feb 9 17:53:41 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 8C0C86D5 for ; Sat, 9 Feb 2013 17:53:41 +0000 (UTC) (envelope-from venture37@gmail.com) Received: from mail-la0-x22a.google.com (la-in-x022a.1e100.net [IPv6:2a00:1450:4010:c03::22a]) by mx1.freebsd.org (Postfix) with ESMTP id 1B0EB6EB for ; Sat, 9 Feb 2013 17:53:40 +0000 (UTC) Received: by mail-la0-f42.google.com with SMTP id fe20so4758136lab.15 for ; Sat, 09 Feb 2013 09:53:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=J99Dq5lU9h9e7rxq5lfc4J58OPibgE+2R68+HoU/TbU=; b=cNFRy9APH6FFBjTKv3r3mLTEDriXdzo/18BEtQ8QtnKb4dCY/E72UEfYNpxiKx+Q5z mVWMogwIsmN5D6aqKHa74TgPURSpVCDitAAfkLHVQtzojMa0xtM0XQaPIJYm2zBboeH3 0IwNoqVyOty8go9sjlmpeNFsx8Fi2m7gbgIKrvTcOpTjXlLHLdrXxe9glK1fxe3wFUXu X5b09abjkmEeWzrcf+TrN0JhbtyLTfQCtLiCHUfWU0Sj04HZwlRCA00aM1xSf1wPwJCE GkY7A9rL4CJi9xaYHs1zjL+ve1s0/e7A2GxUgYCSo1EVCwjZ5KslxDaxfEROFCw0NTZm N91Q== X-Received: by 10.152.122.100 with SMTP id lr4mr8316890lab.28.1360432418959; Sat, 09 Feb 2013 09:53:38 -0800 (PST) Received: from Sevans-MacBook-Pro.local ([83.167.125.235]) by mx.google.com with ESMTPS id ie3sm18849728lab.4.2013.02.09.09.53.36 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 09 Feb 2013 09:53:37 -0800 (PST) Message-ID: <51168CD5.5050907@gmail.com> Date: Sat, 09 Feb 2013 21:52:21 +0400 From: Sevan / Venture37 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: [patch] Userland DTrace References: <51152216.9080905@icritical.com> In-Reply-To: <51152216.9080905@icritical.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 09 Feb 2013 17:53:41 -0000 On 08/02/2013 20:04, Matt Burke wrote: > I've been spending some time trying to get the fasttrap provider to work > on FreeBSD without panicing. I believe I have succeeded, at least to the > point where it's no longer panicing. > > There were two panic causes. The first was > http://www.freebsd.org/cgi/query-pr.cgi?pr=165541 - the FreeBSD port of > fasttrap.c caused ftp_rcount to be left >0. To fix this I've got rid of > the early return and reverted to the opensolaris way. > > A second panic then showed up intermittently when fasttrap_pid_cleanup_cb > was run while something in userland had locks. Using sx_try_xlock calls > has stopped the panics and shouldn't affect operation AFAICT. > > This is against r246454. > > > Although this has fixed the panics for me, I'm finding a lot of stuff just > isn't actually working, with dtrace and the traced process just chewing > CPU. Truss on the dtrace shows a heck of a lot of ptrace() calls and I > have no idea what the target is doing... CPU time is split 2:1 > dtrace:target > > > Also noteworthy is the LOR on the first time you try to use the fasttrap > provider: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/165479 > > The lock order there seems right, so I'm guessing "something else" must > have done it wrong first? How can I find out what the "something else" > is? Hi Matt, It might be worth posting the question to the dtrace list if your question is unanswered. http://dtrace.org/blogs/mailing-list/ Regards, Sevan From owner-freebsd-current@FreeBSD.ORG Sat Feb 9 20:11:07 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 0226F914; Sat, 9 Feb 2013 20:11:07 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-ee0-f42.google.com (mail-ee0-f42.google.com [74.125.83.42]) by mx1.freebsd.org (Postfix) with ESMTP id 654F29A; Sat, 9 Feb 2013 20:11:05 +0000 (UTC) Received: by mail-ee0-f42.google.com with SMTP id b47so2623857eek.29 for ; Sat, 09 Feb 2013 12:10:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=fFErZ0CpdDv5GjwSuOGnqZK43zqbLz249O9vVFhk1Ns=; b=AyRYggmpJF4fEWADFldX5OgdlQPKGgJao+qCz2eLvCbYw5FcbHtOK4fod8agZzdBgZ FofkJ+HlZyHjwCsVSqV8Qu+3UVg8WbEQj6wNM/P3GoSj60ueE8xSr0+YwbSUhjO0CWBi +oppwhxA9btYmIgupc2Vf4g47ouWa2wDOHj5vZX99/jxld/bvIW3RAJJC7CCsQSrOP+K pqFMWxXT2xXxD9ZbU6hkEOWSs/rMdcVSIEG8gIMqTc6DoIjRCsiX3DK1ZBQ7PULBAVNN drjVWUoHqPoUhRqFgeCjBv7EL4xa5KYRubVxu+erzd2pi0yHH8W5Oo2oDs5t/3U1QHiB x97A== X-Received: by 10.14.220.135 with SMTP id o7mr13501046eep.3.1360434546697; Sat, 09 Feb 2013 10:29:06 -0800 (PST) Received: from mavbook.mavhome.dp.ua ([31.144.36.20]) by mx.google.com with ESMTPS id f47sm7929175eep.13.2013.02.09.10.29.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 09 Feb 2013 10:29:05 -0800 (PST) Sender: Alexander Motin Message-ID: <51169568.60402@FreeBSD.org> Date: Sat, 09 Feb 2013 20:28:56 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130125 Thunderbird/17.0.2 MIME-Version: 1.0 To: Joel Dahl Subject: Re: HEAD memsticks broken? [USB/CAM Problems?] References: <20130209073241.GN21730@jd.benders.se> <20130209092659.GO21730@jd.benders.se> <201302091115.24790.hselasky@c2i.net> In-Reply-To: <201302091115.24790.hselasky@c2i.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Hans Petter Selasky X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 09 Feb 2013 20:11:07 -0000 On 09.02.2013 12:15, Hans Petter Selasky wrote: > On Saturday 09 February 2013 10:26:59 Joel Dahl wrote: >> On 09-02-2013 8:32, Joel Dahl wrote: >>> Hi, >>> >>> I suspect something is broken with memsticks built from HEAD. I noticed >>> that I couldn't boot the latest HEAD (amd64) memstick snapshot on two >>> machines (Lenovo X220 and HP ProLiant ML350 G5). Trying snapshots from >>> the FreeBSD.org FTP or allbsd.org makes no difference. >> >> I compared output from booting RELENG_9 and HEAD: >> >> RELENG_9: >> >> ugen2.3: at usbus2 >> umass0: on >> usbus2 umass0: SCSI over Bulk-Only; quirks = 0x0100 >> umass0:4:0:-1: Attached to scbus4 >> da0 at umass-sim0 bus 0 scbus4 target 0 lun 0 >> da0: Removable Direct Access SCSI-2 device >> ??????????? da0: 40.000MB/s transfers >> da0: 1905MB (3903264 512 byte sectors: 255H 63S/T 24SC) >> (da0-umass-sim0:0:0:0): PREVENT ALLOW MEDIUM REMOVAL. CDB: 1e 0 0 0 1 0 >> (da0-umass-sim0:0:0:0): CAM status: SCSI Status Error >> (da0-umass-sim0:0:0:0): SCSI status: Check Condition >> (da0-umass-sim0:0:0:0): SCSI sense: No sense data present >> (da0-umass-sim0:0:0:0): Retrying command (per sense data) >> >> >> >> Root mount waiting for: usbus2 >> ugen2.4: at usbus2 >> Trying to mount root from ufs:/dev/ufs/FreeBSD_Install [ro,noatime]... >> Starting file system checks: >> /dev/ufs/FreeBSD_Install: FILE SYSTEM CLEAN; SKIPPING CHECKS >> /dev/ufs/FreeBSD_Install: clean, 43155 free (507 frags, 5331 blocks, 0.1% >> fragmentation) Mounting local file systems:. >> >> and it works. >> >> HEAD: >> >> ugen2.3: at usbus2 >> umass0: on >> usbus2 umass0: SCSI over Bulk-Only; quirks = 0x0100 >> umass0:5:0:-1: Attached to scbus5 >> da0 at umass-sim0 bus 0 scbus5 target 0 lun 0 >> da0: Removable Direct Access SCSI-0 device >> ?????????? da0: 40.000MB/s transfers >> da0: 3690MB (7557704 512 byte sectors: 255H 63S/T 470SC) >> (da0-umass-sim0:0:0:0): PREVENT ALLOW MEDIUM REMOVAL. CDB: 1e 0 0 0 1 0 >> (da0-umass-sim0:0:0:0): CAM status: SCSI Status Error >> (da0-umass-sim0:0:0:0): SCSI status: Check Condition >> (da0-umass-sim0:0:0:0): SCSI sense: No sense data present >> (da0-umass-sim0:0:0:0): Retrying command (per sense data) >> >> >> >> (da0-umass-sim0:0:0:0): Error 5, Retries exhausted >> (da0-umass-sim0:0:0:0): got CAM status 0x8c >> (da0-umass-sim0:0:0:0): fatal error, failed to attach to device >> (da0-umass-sim0:0:0:0): lost device - 0 outstanding, 4 refs >> (da0-umass-sim0:0:0:0): removing device entry >> ugen2.4: at usbus2 >> Trying to mount root from ufs:/dev/ufs/FreeBSD_Install [ro,noatime]... >> mountroot: waiting for device /dev/ufs/FreeBSD_Install ... >> Mounting from ufs:/dev/ufs/FreeBSD_Install failed with error 19. > > Hi, > > You can try to set the no-synchronize cache quirk in > sys/dev/usb/quirk/usb_quirk.c for your device. I'm not sure if it helps, but > else I suspect it is not an USB issue. How long ago that HEAD was built? Could you get full dmesg? I don't think that "PREVENT ALLOW MEDIUM REMOVAL" should cause device drop. "No sense data present" also doesn't look right. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Sat Feb 9 20:15:10 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id CABDD27C; Sat, 9 Feb 2013 20:15:10 +0000 (UTC) (envelope-from sendtomatt@gmail.com) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by mx1.freebsd.org (Postfix) with ESMTP id A2F50147; Sat, 9 Feb 2013 20:15:10 +0000 (UTC) Received: by mail-pb0-f44.google.com with SMTP id wz12so201450pbc.3 for ; Sat, 09 Feb 2013 12:15:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=RKvXNRPcYWKcuBPxy/tOz4M0k5dwUEKxXpNBJe++Awg=; b=dhYee/onyDLIJLYcOPJz3OXkExGwAUR1jD8lGWvOCbWYf8VbKdRWeeAJN6BRhKHO+6 78BCxEzBGpkFg8yD/cKNnuIKhUcrl0pyIA5aBgcODWDpm8FDsiPpLdujD2PTr42oNnKq UjyAMjIcFnWd0J1zCnqnT34SOBq8id841eZGx0PHN38eNTDG2iZSW+VzEJMfUBqtEYfp +reu1kPUch29ldk7iMIIKWPVJymlTM67SAYUbVFSq8ujLUSznw5RXJhs7+1DEDkt6hwm jcJe3KXOlkGC/a1WLNN+GBAntpuQDoG9RyWCdfqr0UAn+6sqdUIfdgKoM+ltm6RLUzp0 sTxQ== X-Received: by 10.66.81.231 with SMTP id d7mr28464986pay.27.1360434411550; Sat, 09 Feb 2013 10:26:51 -0800 (PST) Received: from flatline.local (70-36-223-239.dsl.dynamic.sonic.net. [70.36.223.239]) by mx.google.com with ESMTPS id xa2sm2155412pbc.23.2013.02.09.10.26.49 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 09 Feb 2013 10:26:50 -0800 (PST) Message-ID: <511694B0.4060805@gmail.com> Date: Sat, 09 Feb 2013 10:25:52 -0800 From: matt User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130202 Thunderbird/17.0.2 MIME-Version: 1.0 To: Johnny Eriksson Subject: Re: Intel 82574 issue reported on Slashdot References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Net , FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 09 Feb 2013 20:15:10 -0000 On 02/09/13 09:15, Johnny Eriksson wrote: >> In all honesty.. The blog post (and your email) are basically >> information free, they don't name names and provide no script >> or downloadable code that will allow end users to check if they >> are affected. > A link with a little bit more information: > > http://blog.krisk.org/2013/02/packets-of-death.html > >> Daniel O'Connor software and network engineer > --Johnny > _______________________________________________ > 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" > Did anyone check to see if the Intel announcement had a 2 at 0x47f? :) I do have a machine with these controllers that had a bridge "hang" in a very odd fashion a while back, but it didn't repeat. It wasn't a SuperMicro board, which is what some posters were saying were affected. I would imagine a large ping packet (as used to test MTU) should inoculate any affected interface if issued at boot, I don't think our padding lines up with the problem. Once an interface sees a packet with anything else at 0x47f, it's no longer affected, so there's a narrow window of vulnerability in affected NICs. Matt From owner-freebsd-current@FreeBSD.ORG Sat Feb 9 20:34:58 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 49336E56; Sat, 9 Feb 2013 20:34:58 +0000 (UTC) (envelope-from chagin.dmitry@gmail.com) Received: from mail-lb0-f173.google.com (mail-lb0-f173.google.com [209.85.217.173]) by mx1.freebsd.org (Postfix) with ESMTP id 6A1BB3F3; Sat, 9 Feb 2013 20:34:56 +0000 (UTC) Received: by mail-lb0-f173.google.com with SMTP id gf7so3816212lbb.18 for ; Sat, 09 Feb 2013 12:34:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:date:from:to:cc:subject:message-id:mime-version :content-type:content-disposition:user-agent; bh=ZUPvbvhA6ekNgThGQt9R80uDCTaT5SmH1EzR9EMMSQo=; b=sDLnwFflvnJFa5J6Ev9AwBavmAkwqD1zKKuZGrYeAoDnq8myhlmhO/89NWT2CSejGV 20HzKxEWwU5pn+ySOqW0ylCqHT6qpkrsT/gTV+18CKSObHdip+CwSGMR6LM3cMpeWyV1 y5xPL19kXKzZa3K6bYi65I8M3ojxnXBuJ4Hk7RcWvODjNr1cvFK/50g0STc++hBs0u8R vU6Tg36ux8Kx3ED48SS3JTxaGso7Mf96JNY32gJHK0XjeUn+DxETbgbufYm1dhbAY/7H rN/QkllVaSYPzMhs8UafLyfqpp8GcUSewwYYfJQG8OLeiXMOREShM2nqfEOrGbZFe7AC Exvw== X-Received: by 10.112.51.233 with SMTP id n9mr3819878lbo.47.1360432888261; Sat, 09 Feb 2013 10:01:28 -0800 (PST) Received: from dchagin.static.corbina.net (dchagin.static.corbina.ru. [78.107.232.239]) by mx.google.com with ESMTPS id fh4sm11318797lbb.7.2013.02.09.10.01.26 (version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 09 Feb 2013 10:01:27 -0800 (PST) Received: from dchagin.static.corbina.net (localhost [127.0.0.1]) by dchagin.static.corbina.net (8.14.6/8.14.6) with ESMTP id r19I1PYk001852; Sat, 9 Feb 2013 22:01:25 +0400 (MSK) (envelope-from dchagin@dchagin.static.corbina.net) Received: (from dchagin@localhost) by dchagin.static.corbina.net (8.14.6/8.14.6/Submit) id r19I1PRl001851; Sat, 9 Feb 2013 22:01:25 +0400 (MSK) (envelope-from dchagin) Date: Sat, 9 Feb 2013 22:01:25 +0400 From: Chagin Dmitry To: freebsd-usb@freebsd.org Subject: some usb troubles Message-ID: <20130209180124.GA1783@dchagin.static.corbina.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="G4iJoqBmSsgzjUCe" Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 09 Feb 2013 20:34:58 -0000 --G4iJoqBmSsgzjUCe Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi all, trying to run macbookpro10,1 on HEAD: 1) usb3.0 does not work at 9.1 and HEAD (r246587) 2) Between stable/9 and HEAD (r246587) we are lost uhid devices (external keyboard and mouse) and umass. dmesg on the same hw can find here: http://people.freebsd.org/~dchagin/macbookpro/dmesg.generic.stable9.txt http://people.freebsd.org/~dchagin/macbookpro/dmesg.generic.HEAD.txt pciconf: http://people.freebsd.org/~dchagin/macbookpro/pciconf.txt any help would be greatly apprecated. --=20 Have fun! chd --G4iJoqBmSsgzjUCe Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlEWjvQACgkQ0t2Tb3OO/O3/OACfbQaNVjx/n0ARg7u9ndXgdv5p XrgAoLriL9DpFKgXX08hwXXaoSOKu5ol =AZ2c -----END PGP SIGNATURE----- --G4iJoqBmSsgzjUCe-- From owner-freebsd-current@FreeBSD.ORG Sat Feb 9 21:47:23 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 4BC8F607 for ; Sat, 9 Feb 2013 21:47:23 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-ia0-x235.google.com (ia-in-x0235.1e100.net [IPv6:2607:f8b0:4001:c02::235]) by mx1.freebsd.org (Postfix) with ESMTP id 020769AC for ; Sat, 9 Feb 2013 21:47:22 +0000 (UTC) Received: by mail-ia0-f181.google.com with SMTP id l29so1752848iag.12 for ; Sat, 09 Feb 2013 13:47:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=/DsA9/vZGw+ZndXKP8u5WhKteo1KVTbQ9MkkHCp/muA=; b=cgJLobndqGib+XRhIhwGrNAzaRkxNeukg+sCh1LWdzKnNJqxKd58JgtHniaJRlRpg2 r57Ilzn/whlRX+8Ql++L5Koo9Ct8dS8EvdbfIE/ZlB2rVpMBYYSMmA5GtUTzLOHEyXPB UltIQ66sNJ0ODF8NGj2aJXkULrrH1WBOZGL/ibiOnz2Z/uhT0GVkUzDMNoGWFU5hdGM7 nI0oIi/h3/ipRpI4K6rPZyfvJCyfxUD5ziN/48+hq9nSti5b/0Wk1N77lZ9L2pHycJEJ jNQLCCy8aHVHM/H8DhSyatief7/CLN5uca+JeEW/nFYLjrPw/3lWTEaz6ec3preXw2i8 KIpw== X-Received: by 10.42.94.8 with SMTP id z8mr14112098icm.36.1360446441751; Sat, 09 Feb 2013 13:47:21 -0800 (PST) Received: from oddish ([66.11.160.25]) by mx.google.com with ESMTPS id bg10sm19877770igc.6.2013.02.09.13.47.19 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 09 Feb 2013 13:47:20 -0800 (PST) Date: Sat, 9 Feb 2013 16:47:15 -0500 From: Mark Johnston To: Matt Burke Subject: Re: [patch] Userland DTrace Message-ID: <20130209214715.GA1954@oddish> References: <51152216.9080905@icritical.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51152216.9080905@icritical.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 09 Feb 2013 21:47:23 -0000 On Fri, Feb 08, 2013 at 04:04:38PM +0000, Matt Burke wrote: > I've been spending some time trying to get the fasttrap provider to work > on FreeBSD without panicing. I believe I have succeeded, at least to the > point where it's no longer panicing. > > There were two panic causes. The first was > http://www.freebsd.org/cgi/query-pr.cgi?pr=165541 - the FreeBSD port of > fasttrap.c caused ftp_rcount to be left >0. To fix this I've got rid of > the early return and reverted to the opensolaris way. > > A second panic then showed up intermittently when fasttrap_pid_cleanup_cb > was run while something in userland had locks. Using sx_try_xlock calls > has stopped the panics and shouldn't affect operation AFAICT. I've run into this too. It can happen even when I'm not using DTrace since fasttrap.ko is always loaded on my system. The problem is that fasttrap_exec_exit() is called every time a process exits in this case; the caller acquires dtrace_lock, and the panic occurs when a callout thread tries to acquire the lock at the same time. > > This is against r246454. > > > Although this has fixed the panics for me, I'm finding a lot of stuff just > isn't actually working, with dtrace and the traced process just chewing > CPU. Truss on the dtrace shows a heck of a lot of ptrace() calls and I > have no idea what the target is doing... CPU time is split 2:1 > dtrace:target Another panic can occur with an INVARIANTS kernel if a DTrace victim process forks. I've supplied a patch which fixes this for me here: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/171360 > > > Also noteworthy is the LOR on the first time you try to use the fasttrap > provider: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/165479 > > The lock order there seems right, so I'm guessing "something else" must > have done it wrong first? How can I find out what the "something else" > is? > > > Thanks > > > --- a/sys/cddl/contrib/opensolaris/uts/common/dtrace/dtrace.c > +++ b/sys/cddl/contrib/opensolaris/uts/common/dtrace/dtrace.c > @@ -7536,9 +7536,23 @@ dtrace_unregister(dtrace_provider_id_t id) > return (EBUSY); > } > } else { > +#if defined(sun) > mutex_enter(&dtrace_provider_lock); > mutex_enter(&mod_lock); > mutex_enter(&dtrace_lock); > +#else > + if (sx_try_xlock(&dtrace_provider_lock) == 0) > + return (EBUSY); > + if (sx_try_xlock(&mod_lock) == 0) { > + mutex_exit(&dtrace_provider_lock); > + return (EBUSY); > + } > + if (sx_try_xlock(&dtrace_lock) == 0) { > + mutex_exit(&mod_lock); > + mutex_exit(&dtrace_provider_lock); > + return (EBUSY); > + } > +#endif > } > > /* > --- a/sys/cddl/contrib/opensolaris/uts/common/dtrace/fasttrap.c > +++ b/sys/cddl/contrib/opensolaris/uts/common/dtrace/fasttrap.c > @@ -1116,23 +1116,28 @@ fasttrap_pid_disable(void *arg, dtrace_id_t id, void *parg) > > ASSERT(id == probe->ftp_id); > > - mutex_enter(&provider->ftp_mtx); > - > /* > * We won't be able to acquire a /proc-esque lock on the process > * iff the process is dead and gone. In this case, we rely on the > * provider lock as a point of mutual exclusion to prevent other > * DTrace consumers from disabling this probe. > */ > - if ((p = pfind(probe->ftp_pid)) == NULL) { > - mutex_exit(&provider->ftp_mtx); > - return; > + > +#if defined(sun) > + if ((p = sprlock(probe->ftp_pid)) != NULL) { > + ASSERT(!(p->p_flag & SVFORK)); > + mutex_exit(&p->p_lock); > + } > +#else > + if ((p = pfind(probe->ftp_pid)) != NULL) { > + _PHOLD(p); > + PROC_UNLOCK(p); > } > -#ifdef __FreeBSD__ > - _PHOLD(p); > - PROC_UNLOCK(p); > #endif > > + mutex_enter(&provider->ftp_mtx); > + > + > /* > * Disable all the associated tracepoints (for fully enabled probes). > */ > @@ -1154,6 +1159,13 @@ fasttrap_pid_disable(void *arg, dtrace_id_t id, void *parg) > if (provider->ftp_retired && !provider->ftp_marked) > whack = provider->ftp_marked = 1; > mutex_exit(&provider->ftp_mtx); > + > +#if defined(sun) > + mutex_enter(&p->p_lock); > + sprunlock(p); > +#else > + PRELE(p); > +#endif > } else { > /* > * If the process is dead, we're just waiting for the > @@ -1167,9 +1179,6 @@ fasttrap_pid_disable(void *arg, dtrace_id_t id, void *parg) > if (whack) > fasttrap_pid_cleanup(); > > -#ifdef __FreeBSD__ > - PRELE(p); > -#endif > if (!probe->ftp_enabled) > return; > > > -- > Sorry for the following... > The information contained in this message is confidential and intended for the addressee only. If you have received this message in error, or there are any problems with its content, please contact the sender. > > iCritical is a trading name of Critical Software Ltd. Registered in England: 04909220. > Registered Office: IC2, Keele Science Park, Keele, Staffordshire, ST5 5NH. > > This message has been scanned for security threats by iCritical. www.icritical.com > > _______________________________________________ > 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 Sat Feb 9 22:23:19 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 12191A35 for ; Sat, 9 Feb 2013 22:23:19 +0000 (UTC) (envelope-from tomek.cedro@gmail.com) Received: from mail-qa0-f48.google.com (mail-qa0-f48.google.com [209.85.216.48]) by mx1.freebsd.org (Postfix) with ESMTP id CC53BAB7 for ; Sat, 9 Feb 2013 22:23:18 +0000 (UTC) Received: by mail-qa0-f48.google.com with SMTP id j8so755965qah.7 for ; Sat, 09 Feb 2013 14:23:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=HA6O9ZnmTJeWDjuTsmNrBBJsnfCG53/U/dAg2VamRcU=; b=lkCq5HOg/pYU7xQO4HrgNu7+VjmqE1rubvj8XVzWtcvChHWDa31Ix+XNd5TTielpNe 3LSqjdYO9eXjwL8j3EA3uw6Ec+Y4KLUb8lsCeY13QcXdXcl5hNTlA128w0FW4mJ2jqHb Wyf2/fDkXbDBqtOloqZZOro5513f6pItbJ7qbft9gGUtiUrzlxNJI7Lvztb7Wm3DVg8V roKdlRWmf2eKDO3j3q0/9TTIpcVZI2FyehDI5ef/57FlNKb1ZWrwP21xmKSJYHjdy7wg rfNyqEwYcYFe4tTv7FoT5ecIptcbcZziKF/zoECy6RkgWyh9d4DMVP9TM1+siBjnkPDJ Xr2Q== MIME-Version: 1.0 X-Received: by 10.224.177.8 with SMTP id bg8mr3613924qab.87.1360448592770; Sat, 09 Feb 2013 14:23:12 -0800 (PST) Sender: tomek.cedro@gmail.com Received: by 10.49.71.204 with HTTP; Sat, 9 Feb 2013 14:23:12 -0800 (PST) In-Reply-To: References: <51163E5B.7070602@zedat.fu-berlin.de> <20130209144457.GA2067@elch.exwg.net> Date: Sat, 9 Feb 2013 23:23:12 +0100 X-Google-Sender-Auth: mxIehZP08PB-9vu3vd2v_IzxGAU Message-ID: Subject: Re: Intel 82574 issue reported on Slashdot From: CeDeROM To: Christoph Moench-Tegeder Content-Type: text/plain; charset=UTF-8 Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 09 Feb 2013 22:23:19 -0000 On Sat, Feb 9, 2013 at 4:25 PM, CeDeROM wrote: > On Sat, Feb 9, 2013 at 3:44 PM, Christoph Moench-Tegeder > wrote: >> ## O. Hartmann (ohartman@zedat.fu-berlin.de): >>> We don't even have the tool tcpreplay in the ports mentioned in that BLOG. >> It's in net-mgmt/tcpreplay. > > And I managed to build mentioned Ostinato packet crafting utility with > no problem on my FreeBSD 9.1-RELEASE AMD64. If they provide package > and release (which I already asked from the authors) I will make a > port for this tool as well :-) There it goes http://www.freebsd.org/cgi/query-pr.cgi?pr=175993 have fun! :-) -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info From owner-freebsd-current@FreeBSD.ORG Sat Feb 9 22:25:54 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id BC8C4B63; Sat, 9 Feb 2013 22:25:54 +0000 (UTC) (envelope-from chagin.dmitry@gmail.com) Received: from mail-la0-x236.google.com (la-in-x0236.1e100.net [IPv6:2a00:1450:4010:c03::236]) by mx1.freebsd.org (Postfix) with ESMTP id 0DA6CAE0; Sat, 9 Feb 2013 22:25:53 +0000 (UTC) Received: by mail-la0-f54.google.com with SMTP id gw10so4865093lab.13 for ; Sat, 09 Feb 2013 14:25:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:date:from:to:cc:subject:message-id:mime-version :content-type:content-disposition:user-agent; bh=o4JvvFIJqtcJwyorFAby46yOzeuXPe4eL/MMkKxb674=; b=u33xKoXDoTUaqhKIFqf0Q40gClDxTM7C3r2iMyqgJ1cjGvfviaSikFHhWQwCMJ+sQz oe7pl9SwJzMj5ODIti0ivepfAYv/ou/lu/pKxelNWjIT+J5tz78clXbtYU97jmLvliRG nSrIfsT+uHOtV8G4n3GtApum/XSIdcgF2MW1fToYvvns9JNcPJ93tfR9AAk5lTLdKTUw rTKag73UnppUMJ2N/71nNrWP7NsIDiyGVOBRWf3ror0fbk4I8XVeDcySZm3vNwK943Bf ExMB/2a26l0K+BDliufjorXQ1LN/PVmtcmoixVYYRGQiiyD1r7bEHe4YnNDCJq4Aqtv7 0Cuw== X-Received: by 10.152.113.6 with SMTP id iu6mr8726917lab.43.1360448312639; Sat, 09 Feb 2013 14:18:32 -0800 (PST) Received: from dchagin.static.corbina.net (dchagin.static.corbina.ru. [78.107.232.239]) by mx.google.com with ESMTPS id f4sm2070512lbo.4.2013.02.09.14.18.31 (version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 09 Feb 2013 14:18:31 -0800 (PST) Sender: Dmitry Chagin Received: from dchagin.static.corbina.net (localhost [127.0.0.1]) by dchagin.static.corbina.net (8.14.6/8.14.6) with ESMTP id r19MIU1g003446; Sun, 10 Feb 2013 02:18:30 +0400 (MSK) (envelope-from dchagin@dchagin.static.corbina.net) Received: (from dchagin@localhost) by dchagin.static.corbina.net (8.14.6/8.14.6/Submit) id r19MIUR6003445; Sun, 10 Feb 2013 02:18:30 +0400 (MSK) (envelope-from dchagin) Date: Sun, 10 Feb 2013 02:18:29 +0400 From: Chagin Dmitry To: freebsd-usb@freebsd.org Subject: [dchagin@freebsd.org: some usb troubles] Message-ID: <20130209221829.GA3436@dchagin.static.corbina.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="y0ulUmNC+osPPQO6" Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 09 Feb 2013 22:25:54 -0000 --y0ulUmNC+osPPQO6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi all, trying to run HEAD on macbookpro10,1: 1) usb3.0 does not work at 9.1 and HEAD (r246587) 2) between stable/9 and HEAD (r246587) we are lost uhid devices (external keyboard and mouse) and umass. dmesg on the same hw can be find h= ere: http://people.freebsd.org/~dchagin/macbookpro/dmesg.generic.stable9.txt http://people.freebsd.org/~dchagin/macbookpro/dmesg.generic.HEAD.txt pciconf: http://people.freebsd.org/~dchagin/macbookpro/pciconf.txt any help would be greatly apprecated. --=20 Have fun! chd --y0ulUmNC+osPPQO6 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlEWyzUACgkQ0t2Tb3OO/O1bqwCgts3ORV/ZuV2yIELxXLSuSoAg f0sAnjEjuoRRtpQ27i+vbOOUsOBz0OS6 =uxut -----END PGP SIGNATURE----- --y0ulUmNC+osPPQO6-- From owner-freebsd-current@FreeBSD.ORG Sat Feb 9 22:29:47 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 40DA0CB5 for ; Sat, 9 Feb 2013 22:29:47 +0000 (UTC) (envelope-from andrey@zonov.org) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by mx1.freebsd.org (Postfix) with ESMTP id A333DB07 for ; Sat, 9 Feb 2013 22:29:46 +0000 (UTC) Received: by mail-lb0-f172.google.com with SMTP id n8so3851223lbj.3 for ; Sat, 09 Feb 2013 14:29:45 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:sender:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:x-enigmail-version:content-type :x-gm-message-state; bh=MJGHMAPwSlycQEKfVOZpX8x8Gu27YoWX1ZcaLlHxWo4=; b=nzOUCSYeNvkrfkYXw7Ex0q1M5oqNOkbzxxVaz4tU9Qx2AmnQBfqH5gEWIxIA8/CzrX k81Zio7au83SVzusItt6M7n6RIRWN6pdE05/z6RklaCfQ+6/BxiOedxbr5sm2I5IuX6P vaZI2XVGyaS6oopUtz3GSQKNbO38Ae94IgN3GSQwjj8XmFrmS4bBroZTxOH1dfiYeEbM fWZfqXK19qNMEbZgGpVM8WFEdsC428IzU6RZZbNZ265nQN5c78msOcBlDbSEsC7NboNm WPKSSASc8+GIY3EmNKMN8wybWvhEjU2h/fmdkiIJo81qYZYpRGDUMXOXH7j8zRxeP/Iz qsNg== X-Received: by 10.152.144.202 with SMTP id so10mr8852178lab.9.1360448985409; Sat, 09 Feb 2013 14:29:45 -0800 (PST) Received: from zont-osx.local (ppp95-165-158-215.pppoe.spdop.ru. [95.165.158.215]) by mx.google.com with ESMTPS id o2sm11504542lby.11.2013.02.09.14.29.43 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 09 Feb 2013 14:29:44 -0800 (PST) Sender: Andrey Zonov Message-ID: <5116CDD3.4000503@FreeBSD.org> Date: Sun, 10 Feb 2013 02:29:39 +0400 From: Andrey Zonov User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Matt Burke Subject: Re: [patch] Userland DTrace References: <51152216.9080905@icritical.com> In-Reply-To: <51152216.9080905@icritical.com> X-Enigmail-Version: 1.5 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2NUDRUTRELJOLVPGVIDEC" X-Gm-Message-State: ALoCoQkGDN9Nf0THPzVz5qaH2J5iVqEeB1SoK0RHR1udj29iZtT7jYKMOeJkJeD8KGugzsG+F7bx Cc: freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 09 Feb 2013 22:29:47 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2NUDRUTRELJOLVPGVIDEC Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2/8/13 8:04 PM, Matt Burke wrote: > I've been spending some time trying to get the fasttrap provider to wor= k > on FreeBSD without panicing. I believe I have succeeded, at least to th= e > point where it's no longer panicing. >=20 > There were two panic causes. The first was > http://www.freebsd.org/cgi/query-pr.cgi?pr=3D165541 - the FreeBSD port = of > fasttrap.c caused ftp_rcount to be left >0. To fix this I've got rid of= > the early return and reverted to the opensolaris way. >=20 > A second panic then showed up intermittently when fasttrap_pid_cleanup_= cb > was run while something in userland had locks. Using sx_try_xlock calls= > has stopped the panics and shouldn't affect operation AFAICT. >=20 > This is against r246454. >=20 >=20 > Although this has fixed the panics for me, I'm finding a lot of stuff j= ust > isn't actually working, with dtrace and the traced process just chewing= > CPU. Truss on the dtrace shows a heck of a lot of ptrace() calls and I > have no idea what the target is doing... CPU time is split 2:1 > dtrace:target >=20 Great! This fixes panics for me too, but I still cannot get something useful tracing and after detaching by ctrl+c my programs still segfaults.= Please look at one style comment below. >=20 > Also noteworthy is the LOR on the first time you try to use the fasttra= p > provider: http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dkern/165479 >=20 > The lock order there seems right, so I'm guessing "something else" must= > have done it wrong first? How can I find out what the "something else" > is? >=20 >=20 > Thanks >=20 >=20 > --- a/sys/cddl/contrib/opensolaris/uts/common/dtrace/dtrace.c > +++ b/sys/cddl/contrib/opensolaris/uts/common/dtrace/dtrace.c > @@ -7536,9 +7536,23 @@ dtrace_unregister(dtrace_provider_id_t id) > return (EBUSY); > } > } else { > +#if defined(sun) > mutex_enter(&dtrace_provider_lock); > mutex_enter(&mod_lock); > mutex_enter(&dtrace_lock); > +#else > + if (sx_try_xlock(&dtrace_provider_lock) =3D=3D 0) s/sx_try_xlock/mutex_tryenter/ Look at sys/cddl/compat/opensolaris/sys/mutex.h > + return (EBUSY); > + if (sx_try_xlock(&mod_lock) =3D=3D 0) { > + mutex_exit(&dtrace_provider_lock); > + return (EBUSY); > + } > + if (sx_try_xlock(&dtrace_lock) =3D=3D 0) { > + mutex_exit(&mod_lock); > + mutex_exit(&dtrace_provider_lock); > + return (EBUSY); > + } > +#endif > } > =20 > /* > --- a/sys/cddl/contrib/opensolaris/uts/common/dtrace/fasttrap.c > +++ b/sys/cddl/contrib/opensolaris/uts/common/dtrace/fasttrap.c > @@ -1116,23 +1116,28 @@ fasttrap_pid_disable(void *arg, dtrace_id_t id,= void *parg) > =20 > ASSERT(id =3D=3D probe->ftp_id); > =20 > - mutex_enter(&provider->ftp_mtx); > - > /* > * We won't be able to acquire a /proc-esque lock on the proces= s > * iff the process is dead and gone. In this case, we rely on t= he > * provider lock as a point of mutual exclusion to prevent othe= r > * DTrace consumers from disabling this probe. > */ > - if ((p =3D pfind(probe->ftp_pid)) =3D=3D NULL) { > - mutex_exit(&provider->ftp_mtx); > - return; > + > +#if defined(sun) > + if ((p =3D sprlock(probe->ftp_pid)) !=3D NULL) { > + ASSERT(!(p->p_flag & SVFORK)); > + mutex_exit(&p->p_lock); > + } > +#else > + if ((p =3D pfind(probe->ftp_pid)) !=3D NULL) { > + _PHOLD(p); > + PROC_UNLOCK(p); > } > -#ifdef __FreeBSD__ > - _PHOLD(p); > - PROC_UNLOCK(p); > #endif > =20 > + mutex_enter(&provider->ftp_mtx); > + > + > /* > * Disable all the associated tracepoints (for fully enabled pr= obes). > */ > @@ -1154,6 +1159,13 @@ fasttrap_pid_disable(void *arg, dtrace_id_t id, = void *parg) > if (provider->ftp_retired && !provider->ftp_marked) > whack =3D provider->ftp_marked =3D 1; > mutex_exit(&provider->ftp_mtx); > + > +#if defined(sun) > + mutex_enter(&p->p_lock); > + sprunlock(p); > +#else > + PRELE(p); > +#endif > } else { > /* > * If the process is dead, we're just waiting for the > @@ -1167,9 +1179,6 @@ fasttrap_pid_disable(void *arg, dtrace_id_t id, v= oid *parg) > if (whack) > fasttrap_pid_cleanup(); > =20 > -#ifdef __FreeBSD__ > - PRELE(p); > -#endif > if (!probe->ftp_enabled) > return; > =20 >=20 --=20 Andrey Zonov ------enig2NUDRUTRELJOLVPGVIDEC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJRFs3WAAoJEBWLemxX/CvT8jMH/0gNWX0R9dTzGVy20Ii0uRLT JoH4AuS8AaGZ+K4TP4BPPZ38ARnUfZMeM7jwzqCiXBuERgVa6LWC0k/uFkPIboCG Uwr0TMq9pCSGl+HqNVBG0gX2rHagh2UbCfl+xCAAnHpdWgO8sdB9tVfj+UEPGJDp eSsVwTQtSegqpR+t7VabBeBFhBs9TbmT8mvhLWd25JK4bSI+gGNrkhgRqvKZOi4b 5i41wLKXnBQhoPQYh6hazLFwXnYJU+ZK3HW35Ezix4kxPwrnzib++QlPOKGCpsWr 4rWuv94xzdAE2KVEG8a2ZGVznoJ1nrTBl0CSeJdazBnLard036E7X/XcR8mpoDE= =FQRp -----END PGP SIGNATURE----- ------enig2NUDRUTRELJOLVPGVIDEC-- From owner-freebsd-current@FreeBSD.ORG Sat Feb 9 22:37:06 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 62867FA2 for ; Sat, 9 Feb 2013 22:37:06 +0000 (UTC) (envelope-from andrey@zonov.org) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) by mx1.freebsd.org (Postfix) with ESMTP id DFA00B52 for ; Sat, 9 Feb 2013 22:37:05 +0000 (UTC) Received: by mail-la0-f43.google.com with SMTP id ek20so4865669lab.30 for ; Sat, 09 Feb 2013 14:37:04 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:sender:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:x-enigmail-version:content-type :x-gm-message-state; bh=i6/F18MpZDkVRZIdzRQ9y93MzgAObKlBDqHfAJfyNlY=; b=hf8x8ftTxZhzaSurWTLOAU2JI4OofCZkFjTtbTKn7krF9tk8eBAN3JpYLrhRbCOw/8 qtNWh1QJfC2GctBaJUQyvln6x4D79vaNrYFgQQS652V8axUSFKCfUgSR0IBynEvuf8ck 8+pop2YuozhlZzOm0DF+bwbPCIk2GFQovPKlTh1VfhvaHYmLrf9fgEvgdd8AQBouWUvC zIpgXW9x2bYhJhS8Va6PXltZfImw6n/jzvfVZNLaFQglxQD3TsGwjR6BJWSOSF/jlHH8 dcb4Wl60Z0ClT7UmbKSMKktWjRd1Cj7wnJWAhFDpOGFYvb0KmnGbPuxDxQzErZCxlu2x CDOQ== X-Received: by 10.152.144.138 with SMTP id sm10mr8648143lab.53.1360449424547; Sat, 09 Feb 2013 14:37:04 -0800 (PST) Received: from zont-osx.local (ppp95-165-158-215.pppoe.spdop.ru. [95.165.158.215]) by mx.google.com with ESMTPS id gm20sm3426031lab.7.2013.02.09.14.37.02 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 09 Feb 2013 14:37:03 -0800 (PST) Sender: Andrey Zonov Message-ID: <5116CF8D.4020606@FreeBSD.org> Date: Sun, 10 Feb 2013 02:37:01 +0400 From: Andrey Zonov User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Mark Johnston Subject: Re: [patch] Userland DTrace References: <51152216.9080905@icritical.com> <20130209214715.GA1954@oddish> In-Reply-To: <20130209214715.GA1954@oddish> X-Enigmail-Version: 1.5 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2AFCLWRXLXTLBWBRDKPLU" X-Gm-Message-State: ALoCoQmfh2pi9TwdOxYj7PINF8agUlh4eJ95gJESKkZJd0DQgisH2B2oFf/2Sbiq2Vf6hUFDkQlZ Cc: freebsd-current@FreeBSD.org, Matt Burke X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 09 Feb 2013 22:37:06 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2AFCLWRXLXTLBWBRDKPLU Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2/10/13 1:47 AM, Mark Johnston wrote: > On Fri, Feb 08, 2013 at 04:04:38PM +0000, Matt Burke wrote: >> I've been spending some time trying to get the fasttrap provider to wo= rk >> on FreeBSD without panicing. I believe I have succeeded, at least to t= he >> point where it's no longer panicing. >> >> There were two panic causes. The first was >> http://www.freebsd.org/cgi/query-pr.cgi?pr=3D165541 - the FreeBSD port= of >> fasttrap.c caused ftp_rcount to be left >0. To fix this I've got rid o= f >> the early return and reverted to the opensolaris way. >> >> A second panic then showed up intermittently when fasttrap_pid_cleanup= _cb >> was run while something in userland had locks. Using sx_try_xlock call= s >> has stopped the panics and shouldn't affect operation AFAICT. >=20 > I've run into this too. It can happen even when I'm not using DTrace > since fasttrap.ko is always loaded on my system. The problem is that > fasttrap_exec_exit() is called every time a process exits in this case;= > the caller acquires dtrace_lock, and the panic occurs when a callout > thread tries to acquire the lock at the same time. >=20 >> >> This is against r246454. >> >> >> Although this has fixed the panics for me, I'm finding a lot of stuff = just >> isn't actually working, with dtrace and the traced process just chewin= g >> CPU. Truss on the dtrace shows a heck of a lot of ptrace() calls and I= >> have no idea what the target is doing... CPU time is split 2:1 >> dtrace:target >=20 > Another panic can occur with an INVARIANTS kernel if a DTrace victim > process forks. I've supplied a patch which fixes this for me here: > http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dkern/171360 >=20 I think you have to carefully ping George, and if he won't answer go ahead with your patches. Someone has to take care of userland dtrace. --=20 Andrey Zonov ------enig2AFCLWRXLXTLBWBRDKPLU Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJRFs+NAAoJEBWLemxX/CvTpDIIALJLGt6V53ksDmgHLB8jp08Y SpV37mK3MK1hFshV5W7qin4nQSHXdp2LW/sqw/qwn2JzgRULBKO1CVzOSlHRZfYV eNwjQ7qWjzfyjDMm7h1VVNe4MvdVY0CxMeTwF5Hdp0UxzhJTW+tQEiYuO9T3g9by elNRfz8Zts9zl2YaP99XKL5QYzWC07yZN4eT+ceOmhXajAuYwC7h8sPsuwS2tgIH QuNnDILdNRgXvhDBqBE2fi2Lf1ZsJArw8OPv9l6JgfdTGW93piwlimZTMe5k8LEG vwVjZT/zTeoezHPQyB1rfE4m7S0LOJw0jHhaZQyFFsjfNiR3ygWSsg2vZ7vc2MA= =TcxV -----END PGP SIGNATURE----- ------enig2AFCLWRXLXTLBWBRDKPLU-- From owner-freebsd-current@FreeBSD.ORG Sat Feb 9 23:09:59 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3011A3F3; Sat, 9 Feb 2013 23:09:59 +0000 (UTC) (envelope-from joel@freebsd.org) Received: from mail.vnode.se (mail.vnode.se [62.119.52.80]) by mx1.freebsd.org (Postfix) with ESMTP id 9CEA6CEC; Sat, 9 Feb 2013 23:09:57 +0000 (UTC) Received: from mail.vnode.se (localhost [127.0.0.1]) by mail.vnode.se (Postfix) with ESMTP id 826C1E3F07A; Sun, 10 Feb 2013 00:09:50 +0100 (CET) X-Virus-Scanned: amavisd-new at vnode.se Received: from mail.vnode.se ([127.0.0.1]) by mail.vnode.se (mail.vnode.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jro1DxNJdj+y; Sun, 10 Feb 2013 00:09:48 +0100 (CET) Received: from jd.benders.se (jd.benders.se [212.247.52.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.vnode.se (Postfix) with ESMTPSA id 2141BE3F079; Sun, 10 Feb 2013 00:09:48 +0100 (CET) Date: Sun, 10 Feb 2013 00:09:39 +0100 From: Joel Dahl To: Alexander Motin Subject: Re: HEAD memsticks broken? [USB/CAM Problems?] Message-ID: <20130209230939.GQ21730@jd.benders.se> References: <20130209073241.GN21730@jd.benders.se> <20130209092659.GO21730@jd.benders.se> <201302091115.24790.hselasky@c2i.net> <51169568.60402@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51169568.60402@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@freebsd.org, Hans Petter Selasky X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 09 Feb 2013 23:09:59 -0000 On 09-02-2013 20:28, Alexander Motin wrote: > How long ago that HEAD was built? Could you get full dmesg? I don't > think that "PREVENT ALLOW MEDIUM REMOVAL" should cause device drop. "No > sense data present" also doesn't look right. As I mentioned earlier, I've tried several HEAD snapshots. This is booting a r246472 memstick. I currently have no way to get a full dmesg, but I have hand-typed the last parts below: usbus0: 480Mbps High Speed USB v2.0 usbus1: 5.0Gbps Super Speed USB v3.0 usbus2: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: <0x1033> at usbus1 uhub1: <0x1033 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 ses0 at ahciem0 bus 0 scbus3 target 0 lun 0 ses0: SEMB S-E-S 2.00 device ses0: SEMB SES Device ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ATA-8 SATA 2.x device ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 152627MB (312581808 512 byte sectors: 1H 63S/T 16383C) ada0: Previously was known as ad4 SMP: AP CPU #1 Launched! SMP: AP CPU #3 Launched! SMP: AP CPU #2 Launched! Timecounter "TSC-low" frequency 1395499430 Hz quality 1000 WARNING: WITNESS option enabled, expect reduced performance. uhub1: 4 ports with 4 removable, self powered Root mount waiting for: usbus2 usbus0 uhub0: 3 ports with 3 removable, self powered uhub2: 3 ports with 3 removable, self powered ugen0.2: at usbus0 uhub3: on usbus0 ugen2.2: at usbus2 uhub4: on usbus2 Root mount wating for: usbus2 usbus0 ugen0.4: at usbus0 ugen0.5: at usbus0 ugen2.3: at usbus2 umass0: on usbus2 umass0: SCSI over BUlk-Only; quirks = 0x0100 umass0:5:0:-1: Attached to scbus5 da0 at umass-sim0 bus 0 scbus5 target 0 lun 0 da0: Removable Direct Access SCSI-0 device da0: 40.000MB/s transfers da0: 3690MB (7557704 512 byte sectors: 255H 63S/T 470C) (da0:umass-sim0:0:0:0): PREVENT ALLOW MEDIUM REMOVAL. CDB: 1e 00 00 00 01 00 (da0:umass-sim0:0:0:0): CAM status: Auto-Sense Retrieval Failed (da0:umass-sim0:0:0:0): Error 5, Unretryable error (da0:umass-sim0:0:0:0): PREVENT ALLOW MEDIUM REMOVAL. CDB: 1e 00 00 00 01 00 (da0:umass-sim0:0:0:0): CAM status: Auto-Sense Retrieval Failed (da0:umass-sim0:0:0:0): Error 5, Unretryable error (da0:umass-sim0:0:0:0): PREVENT ALLOW MEDIUM REMOVAL. CDB: 1e 00 00 00 01 00 (da0:umass-sim0:0:0:0): CAM status: Auto-Sense Retrieval Failed (da0:umass-sim0:0:0:0): Error 5, Unretryable error (da0:umass-sim0:0:0:0): PREVENT ALLOW MEDIUM REMOVAL. CDB: 1e 00 00 00 01 00 (da0:umass-sim0:0:0:0): CAM status: Auto-Sense Retrieval Failed (da0:umass-sim0:0:0:0): Error 5, Unretryable error (da0:umass-sim0:0:0:0): PREVENT ALLOW MEDIUM REMOVAL. CDB: 1e 00 00 00 01 00 (da0:umass-sim0:0:0:0): CAM status: Auto-Sense Retrieval Failed (da0:umass-sim0:0:0:0): Error 5, Unretryable error (da0:umass-sim0:0:0:0): SYNCHRONIZE CACHE(10). CDB: 35 00 00 00 00 00 00 00 00 00 (da0:umass-sim0:0:0:0): CAM status: Auto-Sense Retrieval Failed (da0:umass-sim0:0:0:0): Error 5, Unretryable error (da0:umass-sim0:0:0:0): got CAM status 0x50 (da0:umass-sim0:0:0:0): fatal error, failed to attach to device (da0:umass-sim0:0:0:0): lost device - 0 outstanding, 4 refs (da0:umass-sim0:0:0:0): removing device entry Root mount waiting for: usbus2 ugen2.4: at usbus2 Trying to mount root from ufs:/dev/ufs/FreeBSD_Install [ro, noatime]... mountroot: waiting for device /dev/ufs/FreeBSD_Install ... Mounting from ufs:/dev/ufs/FreeBSD_Install failed with error 19. mountroot> I can probably take a couple of pictures of the entire dmesg, if that would be of any interest. -- Joel From owner-freebsd-current@FreeBSD.ORG Sat Feb 9 23:34:15 2013 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9D7049A3; Sat, 9 Feb 2013 23:34:15 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (garage.dawidek.net [91.121.88.72]) by mx1.freebsd.org (Postfix) with ESMTP id 5BAB8E0A; Sat, 9 Feb 2013 23:34:15 +0000 (UTC) Received: from localhost (89-73-195-149.dynamic.chello.pl [89.73.195.149]) by mail.dawidek.net (Postfix) with ESMTPSA id 652826E7; Sun, 10 Feb 2013 00:31:21 +0100 (CET) Date: Sun, 10 Feb 2013 00:35:00 +0100 From: Pawel Jakub Dawidek To: Andriy Gapon Subject: Re: geli(8) breaks after a couple hours of uptime Message-ID: <20130209233500.GH1375@garage.freebsd.pl> References: <20130207141833.GA15884@acme.spoerlein.net> <20130207153322.5c371beb@fabiankeil.de> <20130207180153.GX35868@acme.spoerlein.net> <20130208095709.6ae61cff@fabiankeil.de> <20130208114825.GY35868@acme.spoerlein.net> <5114F390.4010302@FreeBSD.org> <20130209140733.0b753c60@fabiankeil.de> <51166580.4080603@FreeBSD.org> <511672B5.5080300@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="KIzF6Cje4W/osXrF" Content-Disposition: inline In-Reply-To: <511672B5.5080300@FreeBSD.org> X-OS: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Eitan Adler , Andrey Zonov , current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 09 Feb 2013 23:34:15 -0000 --KIzF6Cje4W/osXrF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Feb 09, 2013 at 06:00:53PM +0200, Andriy Gapon wrote: > on 09/02/2013 17:04 Andrey Zonov said the following: > > On 2/9/13 5:07 PM, Fabian Keil wrote: > >> > >> This would at least prevent the segfault. > >> > >=20 > > I see two possibilities to get segfault: > > - no checking for result from memory allocation functions > > - too big stack > >=20 > > I have no found any broken memory allocation checking, but I found two > > big objects on the stack. One is buf[MAXPHYS] in eli_genkey_files() and > > another is passbuf[MAXPHYS] in eli_genkey_passphrase(). If we change > > these two to malloc(), then we can handle error from malloc(), print > > some useful message and prevent segfault. >=20 > I'd rather do what Kostik suggested and Fabian mentioned: instead of > mlockall(MCL_FUTURE) the code should mlock only the (explicitly designate= d) > buffers that can contain sensitive data. geli(8) almost exclusively deals with sensitive data. Even mlocking MAXPHYS would fail with current limits, but this is bad idea. With mlockall() I am sure I didn't miss anything - be it forgetting about mlocking some buffer or zeroing it before munlock. I'm also sure someone else who can modify geli(8) in the future won't miss anything too. geli(8) is relatively simple program, it doesn't allocate megabytes of memory for different pruposes and just needs few pages for sensitive data. As I said most of the memory it uses is for sensitive data. The obvious problem is allocating MAXPHYS on the stack. This has to be changed, especially that we may want to rise MAXPHYS in the future. Other than that I expect thing would be tuned properly so that geli(8) can work by default. I'm happy to use smaller buffers than MAXPHYS - keyfiles are far smaller usually than 128kB, so there shouldn't be any issue with this. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl --KIzF6Cje4W/osXrF Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlEW3SQACgkQForvXbEpPzS94ACgyYOtEyf28arovJda9f9lLXCr X+0An0ep1vEqv12/jn3ib532EKYNpsKy =VR+x -----END PGP SIGNATURE----- --KIzF6Cje4W/osXrF--