From owner-freebsd-arch@FreeBSD.ORG Sun Feb 12 01:00:15 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D2BCE106564A; Sun, 12 Feb 2012 01:00:12 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id B9DA18FC0A; Sun, 12 Feb 2012 01:00:11 +0000 (UTC) Received: by wgbdq11 with SMTP id dq11so3976495wgb.31 for ; Sat, 11 Feb 2012 17:00:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=LH1lmpB07kCouPG6H4q5iTRvBoBLFpLLXYAJi42nEkA=; b=c0u//52qjp1koR5Ws1ZppNkP3M/9BTjjK1TNLdFBOp/MBH3s3zT2/TnijOrAXlF1N7 VLPI7YwGrPX0Gjy1iNGLEdV/4YNBVMRcojh51d1O8N/7gID+uGKH+EHP6jn4/EyTHgfI 9uLQ2fuas6+GCzn0oLpt4/hCvli52+j+AzhtU= MIME-Version: 1.0 Received: by 10.216.135.76 with SMTP id t54mr4443109wei.14.1329008410877; Sat, 11 Feb 2012 17:00:10 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.175.136 with HTTP; Sat, 11 Feb 2012 17:00:10 -0800 (PST) In-Reply-To: <20120211144544.c91701d9.ray@ddteam.net> References: <95372FB3-406F-46C2-8684-4FDB672D9FCF@lassitu.de> <20120106214741.GB88161@alchemy.franken.de> <20120108130039.GG88161@alchemy.franken.de> <23477898-8D85-498C-8E30-192810BD68A8@lassitu.de> <20120111193738.GB44286@alchemy.franken.de> <66DDA0A2-F878-43FF-8824-54868F493B18@lassitu.de> <20120125221753.GA17821@alchemy.franken.de> <20120211111731.GE39861@alchemy.franken.de> <20120211144544.c91701d9.ray@ddteam.net> Date: Sat, 11 Feb 2012 17:00:10 -0800 X-Google-Sender-Auth: Ir3a3QmIR6v3Bqb_8Pdfz41zyaI Message-ID: From: Adrian Chadd To: Aleksandr Rybalko Content-Type: text/plain; charset=ISO-8859-1 Cc: Juli Mallett , Aleksandr Rybalko , FreeBSD-arch , Stefan Bethke , Marius Strobl Subject: Re: Extending sys/dev/mii X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Feb 2012 01:00:15 -0000 Hi Ray, Would you please attach the latest diffs: * to if_arge, to make it "work"; * to the mii API, if needed; * anything new - ie, the switch API, switch PHYs, etc. I'd like to try and finally bring some sanity to the hardcoded PHY mask handling in if_arge (and make it actually work for AR71xx and AR724x - where AR71xx has one shared MDIO bus between both MACs, but AR724x has two independent MDIO busses..) Adrian From owner-freebsd-arch@FreeBSD.ORG Sun Feb 12 01:16:10 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E3AFE1065670; Sun, 12 Feb 2012 01:16:10 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 900898FC0A; Sun, 12 Feb 2012 01:16:10 +0000 (UTC) Received: from [10.0.0.63] (63.imp.bsdimp.com [10.0.0.63]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id q1C1FsIZ012192 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Sat, 11 Feb 2012 18:15:58 -0700 (MST) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Sat, 11 Feb 2012 18:15:54 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: <95372FB3-406F-46C2-8684-4FDB672D9FCF@lassitu.de> <20120106214741.GB88161@alchemy.franken.de> <20120108130039.GG88161@alchemy.franken.de> <23477898-8D85-498C-8E30-192810BD68A8@lassitu.de> <20120111193738.GB44286@alchemy.franken.de> <66DDA0A2-F878-43FF-8824-54868F493B18@lassitu.de> <20120125221753.GA17821@alchemy.franken.de> <20120211111731.GE39861@alchemy.franken.de> <20120211144544.c91701d9.ray@ddteam.net> To: Adrian Chadd X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Sat, 11 Feb 2012 18:15:58 -0700 (MST) Cc: Aleksandr Rybalko , Stefan Bethke , Juli Mallett , FreeBSD-arch , Aleksandr Rybalko , Marius Strobl Subject: Re: Extending sys/dev/mii X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Feb 2012 01:16:11 -0000 On Feb 11, 2012, at 6:00 PM, Adrian Chadd wrote: > I'd like to try and finally bring some sanity to the hardcoded PHY > mask handling in if_arge (and make it actually work for AR71xx and > AR724x - where AR71xx has one shared MDIO bus between both MACs, but > AR724x has two independent MDIO busses..) FDT would do that... Warner From owner-freebsd-arch@FreeBSD.ORG Sun Feb 12 04:49:32 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 29D161065673; Sun, 12 Feb 2012 04:49:32 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id 4D71B8FC08; Sun, 12 Feb 2012 04:49:31 +0000 (UTC) Received: by wibhn14 with SMTP id hn14so4330938wib.13 for ; Sat, 11 Feb 2012 20:49:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=f3O1Ru++smXF2Ux+fRng7rL5DqYq6u767uBT3KGFoR4=; b=O2w2AXuakfDS6Es4/QhIdH/CYOx8QjQPK4a509MvZH998JXJEMgx6Ng0JNiIesMJil L/Io3p9eV29jv7kg2jbRD5CBs/2HJUClPiQ3C1ib5Sev+muJEbAZcCsFzfj4S3AQCUh7 ryF9a8PMeFNi7pp/tg4WJBxROSgiodXn+qXVE= MIME-Version: 1.0 Received: by 10.180.96.8 with SMTP id do8mr11293472wib.21.1329022170509; Sat, 11 Feb 2012 20:49:30 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.175.136 with HTTP; Sat, 11 Feb 2012 20:49:30 -0800 (PST) In-Reply-To: References: <95372FB3-406F-46C2-8684-4FDB672D9FCF@lassitu.de> <20120106214741.GB88161@alchemy.franken.de> <20120108130039.GG88161@alchemy.franken.de> <23477898-8D85-498C-8E30-192810BD68A8@lassitu.de> <20120111193738.GB44286@alchemy.franken.de> <66DDA0A2-F878-43FF-8824-54868F493B18@lassitu.de> <20120125221753.GA17821@alchemy.franken.de> <20120211111731.GE39861@alchemy.franken.de> <20120211144544.c91701d9.ray@ddteam.net> Date: Sat, 11 Feb 2012 20:49:30 -0800 X-Google-Sender-Auth: A_h20vjIgOt-jI9aejNUsUGERZw Message-ID: From: Adrian Chadd To: Warner Losh Content-Type: text/plain; charset=ISO-8859-1 Cc: Aleksandr Rybalko , Stefan Bethke , Juli Mallett , FreeBSD-arch , Aleksandr Rybalko , Marius Strobl Subject: Re: Extending sys/dev/mii X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Feb 2012 04:49:32 -0000 On 11 February 2012 17:15, Warner Losh wrote: > > On Feb 11, 2012, at 6:00 PM, Adrian Chadd wrote: >> I'd like to try and finally bring some sanity to the hardcoded PHY >> mask handling in if_arge (and make it actually work for AR71xx and >> AR724x - where AR71xx has one shared MDIO bus between both MACs, but >> AR724x has two independent MDIO busses..) > > FDT would do that... .. how would it bring sanity to the device driver? Right now the driver assumes that both arge0 and arge1 mdiobus are the same and uses the phymask setting to determine how/when to access registers (ie, trying to read/write from phy registers not in the phymask of argeX are denied.) It is one of the annoying issues with the AR7241 internal switch support as that switch hangs off of arge1's MII bus. It may make it easier to specify the configuration but it doesn't fix the fundamentally wrong assumption. The trouble in this whole mess (where FDT may help) is that phy's for arge0 may actually sit on arge1. So you can't probe/attach the miibus on arge0 until you've probe/attached arge1, so the arge1 MII registers can be tickled. Ray/Stefan/others: if anything, I'd like to try and bring sanity to this particular thorny issue in -HEAD before we worry about switch PHY devices. Adrian From owner-freebsd-arch@FreeBSD.ORG Sun Feb 12 05:02:37 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E6C5C106566B; Sun, 12 Feb 2012 05:02:37 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 776DE8FC13; Sun, 12 Feb 2012 05:02:37 +0000 (UTC) Received: from [10.0.0.63] (63.imp.bsdimp.com [10.0.0.63]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id q1C4x9Dn013587 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Sat, 11 Feb 2012 21:59:10 -0700 (MST) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Sat, 11 Feb 2012 21:59:08 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <58EA57DC-75DF-4813-BB03-FD27F2A49BA2@bsdimp.com> References: <95372FB3-406F-46C2-8684-4FDB672D9FCF@lassitu.de> <20120106214741.GB88161@alchemy.franken.de> <20120108130039.GG88161@alchemy.franken.de> <23477898-8D85-498C-8E30-192810BD68A8@lassitu.de> <20120111193738.GB44286@alchemy.franken.de> <66DDA0A2-F878-43FF-8824-54868F493B18@lassitu.de> <20120125221753.GA17821@alchemy.franken.de> <20120211111731.GE39861@alchemy.franken.de> <20120211144544.c91701d9.ray@ddteam.net> To: Adrian Chadd X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Sat, 11 Feb 2012 21:59:10 -0700 (MST) Cc: Aleksandr Rybalko , Stefan Bethke , Juli Mallett , FreeBSD-arch , Aleksandr Rybalko , Marius Strobl Subject: Re: Extending sys/dev/mii X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Feb 2012 05:02:38 -0000 On Feb 11, 2012, at 9:49 PM, Adrian Chadd wrote: > On 11 February 2012 17:15, Warner Losh wrote: >>=20 >> On Feb 11, 2012, at 6:00 PM, Adrian Chadd wrote: >>> I'd like to try and finally bring some sanity to the hardcoded PHY >>> mask handling in if_arge (and make it actually work for AR71xx and >>> AR724x - where AR71xx has one shared MDIO bus between both MACs, but >>> AR724x has two independent MDIO busses..) >>=20 >> FDT would do that... >=20 > .. how would it bring sanity to the device driver? FDT would encode the links between the MAC and the PHY. FDT is a = directed graph, not a tree, so you can have multiple paths to a device = node that follow different domains. > Right now the driver assumes that both arge0 and arge1 mdiobus are the > same and uses the phymask setting to determine how/when to access > registers (ie, trying to read/write from phy registers not in the > phymask of argeX are denied.) It is one of the annoying issues with > the AR7241 internal switch support as that switch hangs off of arge1's > MII bus. It would no longer need to do this, or make any assumptions at all. FDT = would tell it all. > It may make it easier to specify the configuration but it doesn't fix > the fundamentally wrong assumption. Nope. Bad assumptions would still need to be fixed. > The trouble in this whole mess (where FDT may help) is that phy's for > arge0 may actually sit on arge1. So you can't probe/attach the miibus > on arge0 until you've probe/attached arge1, so the arge1 MII registers > can be tickled. The PHYs don't sit on arge1. They sit on another device that the driver = bogusly assumes is tightly coupled to arge1, when in fact it isn't. > Ray/Stefan/others: if anything, I'd like to try and bring sanity to > this particular thorny issue in -HEAD before we worry about switch PHY > devices. Warner From owner-freebsd-arch@FreeBSD.ORG Sun Feb 12 05:06:32 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1308D106566B; Sun, 12 Feb 2012 05:06:32 +0000 (UTC) (envelope-from juli@clockworksquid.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 371A88FC12; Sun, 12 Feb 2012 05:06:30 +0000 (UTC) Received: by wgbdq11 with SMTP id dq11so4032349wgb.31 for ; Sat, 11 Feb 2012 21:06:30 -0800 (PST) Received: by 10.180.93.194 with SMTP id cw2mr17444333wib.0.1329023190252; Sat, 11 Feb 2012 21:06:30 -0800 (PST) MIME-Version: 1.0 Sender: juli@clockworksquid.com Received: by 10.227.209.78 with HTTP; Sat, 11 Feb 2012 21:06:10 -0800 (PST) In-Reply-To: <58EA57DC-75DF-4813-BB03-FD27F2A49BA2@bsdimp.com> References: <95372FB3-406F-46C2-8684-4FDB672D9FCF@lassitu.de> <20120106214741.GB88161@alchemy.franken.de> <20120108130039.GG88161@alchemy.franken.de> <23477898-8D85-498C-8E30-192810BD68A8@lassitu.de> <20120111193738.GB44286@alchemy.franken.de> <66DDA0A2-F878-43FF-8824-54868F493B18@lassitu.de> <20120125221753.GA17821@alchemy.franken.de> <20120211111731.GE39861@alchemy.franken.de> <20120211144544.c91701d9.ray@ddteam.net> <58EA57DC-75DF-4813-BB03-FD27F2A49BA2@bsdimp.com> From: Juli Mallett Date: Sat, 11 Feb 2012 21:06:10 -0800 X-Google-Sender-Auth: 39tzU6Y2Tq6YFhYWIIwm6BFApSo Message-ID: To: Warner Losh Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlBuE+ZSXhsaFUxu4j1loBqvOroEMQTtHWfTJkn30ljHzpaf9kS/+9VjmcK66egaCZSPlPB Cc: Adrian Chadd , Stefan Bethke , FreeBSD-arch , Aleksandr Rybalko , Aleksandr Rybalko , Marius Strobl Subject: Re: Extending sys/dev/mii X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Feb 2012 05:06:32 -0000 On Sat, Feb 11, 2012 at 20:59, Warner Losh wrote: >> The trouble in this whole mess (where FDT may help) is that phy's for >> arge0 may actually sit on arge1. So you can't probe/attach the miibus >> on arge0 until you've probe/attached arge1, so the arge1 MII registers >> can be tickled. > > The PHYs don't sit on arge1. =C2=A0They sit on another device that the dr= iver bogusly assumes is tightly coupled to arge1, when in fact it isn't. YES! Thank you! And even if it were tightly coupled in hardware, there's no reason our device tree needs to mirror that, FDT or not. Just break out an "arge controller" device, attach arge0 and arge1 to it, and let it manage the MDIO bus. No shortcomings, as far as I can tell. You can even be extra clever and say that the switch is attached to that device, not either of the arge devices, and that one of the arge devices happens to be connected to the switch's CPU/host port. But that's probably a bit much to ask for. From owner-freebsd-arch@FreeBSD.ORG Sun Feb 12 05:20:22 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1F6DD1065670; Sun, 12 Feb 2012 05:20:22 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by mx1.freebsd.org (Postfix) with ESMTP id 03AF28FC0C; Sun, 12 Feb 2012 05:20:20 +0000 (UTC) Received: by wgbgn7 with SMTP id gn7so1511997wgb.1 for ; Sat, 11 Feb 2012 21:20:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=FMdoAqv221Wgy2n/KyTdVGQ5F5+JJ2yHIky7/wjTvnU=; b=xv8qCEkmyFef6ns6+XlvdUwx17QLv4cRR+SVy888z/T9XZT/oZ9Eh3GEpZxi0QsEBn 1jQe8ccViNQW4gRx92aqy1AvHa0SItNQyak1/uPzW1hCA6TxQ48JB0FsY/2Wot5FhKCW 7D/mIK/26PSw9O2adAph3jduhIbVtXwd7mdJ0= MIME-Version: 1.0 Received: by 10.216.135.76 with SMTP id t54mr4620655wei.14.1329024020168; Sat, 11 Feb 2012 21:20:20 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.175.136 with HTTP; Sat, 11 Feb 2012 21:20:20 -0800 (PST) In-Reply-To: References: <95372FB3-406F-46C2-8684-4FDB672D9FCF@lassitu.de> <20120106214741.GB88161@alchemy.franken.de> <20120108130039.GG88161@alchemy.franken.de> <23477898-8D85-498C-8E30-192810BD68A8@lassitu.de> <20120111193738.GB44286@alchemy.franken.de> <66DDA0A2-F878-43FF-8824-54868F493B18@lassitu.de> <20120125221753.GA17821@alchemy.franken.de> <20120211111731.GE39861@alchemy.franken.de> <20120211144544.c91701d9.ray@ddteam.net> <58EA57DC-75DF-4813-BB03-FD27F2A49BA2@bsdimp.com> Date: Sat, 11 Feb 2012 21:20:20 -0800 X-Google-Sender-Auth: 5_IRdiHVAZ_MkHoQJH7nnGbDpdM Message-ID: From: Adrian Chadd To: Juli Mallett Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Aleksandr Rybalko , Stefan Bethke , FreeBSD-arch , Aleksandr Rybalko , Marius Strobl Subject: Re: Extending sys/dev/mii X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Feb 2012 05:20:22 -0000 On 11 February 2012 21:06, Juli Mallett wrote: >> The PHYs don't sit on arge1. =A0They sit on another device that the driv= er bogusly assumes is tightly coupled to arge1, when in fact it isn't. > > YES! =A0Thank you! =A0And even if it were tightly coupled in hardware, > there's no reason our device tree needs to mirror that, FDT or not. > Just break out an "arge controller" device, attach arge0 and arge1 to > it, and let it manage the MDIO bus. =A0No shortcomings, as far as I can > tell. =A0You can even be extra clever and say that the switch is > attached to that device, not either of the arge devices, and that one > of the arge devices happens to be connected to the switch's CPU/host > port. =A0But that's probably a bit much to ask for. I'm tempted to just go ahead and do this, and have: * argec: initial device probe/attach, handle mdio/miibus configuration * if_arge: child of argec (with all register accesses going via it), doing the rest of ethernet stuff .. then what, we have argec0/argec1 first probe/attach, then have if_arge0/if_arge1 probe/attach with the relevant miibus PHYs attach to wherever they need to? There'll need to be some kind of locking there so both the argecX and the if_argeX don't clash. Adrian From owner-freebsd-arch@FreeBSD.ORG Sun Feb 12 17:52:13 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E908F1065674; Sun, 12 Feb 2012 17:52:12 +0000 (UTC) (envelope-from ray@ddteam.net) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id ECE048FC0C; Sun, 12 Feb 2012 17:52:11 +0000 (UTC) Received: by eekb47 with SMTP id b47so1819081eek.13 for ; Sun, 12 Feb 2012 09:52:10 -0800 (PST) Received: by 10.14.94.200 with SMTP id n48mr4319219eef.48.1329069130786; Sun, 12 Feb 2012 09:52:10 -0800 (PST) Received: from rnote.ddteam.net (232-209-133-95.pool.ukrtel.net. [95.133.209.232]) by mx.google.com with ESMTPS id c16sm51181797eei.1.2012.02.12.09.52.08 (version=SSLv3 cipher=OTHER); Sun, 12 Feb 2012 09:52:09 -0800 (PST) Date: Sun, 12 Feb 2012 19:51:33 +0200 From: Aleksandr Rybalko To: Adrian Chadd Message-Id: <20120212195133.a2864582.ray@ddteam.net> In-Reply-To: References: <95372FB3-406F-46C2-8684-4FDB672D9FCF@lassitu.de> <20120106214741.GB88161@alchemy.franken.de> <20120108130039.GG88161@alchemy.franken.de> <23477898-8D85-498C-8E30-192810BD68A8@lassitu.de> <20120111193738.GB44286@alchemy.franken.de> <66DDA0A2-F878-43FF-8824-54868F493B18@lassitu.de> <20120125221753.GA17821@alchemy.franken.de> <20120211111731.GE39861@alchemy.franken.de> <20120211144544.c91701d9.ray@ddteam.net> X-Mailer: Sylpheed 3.1.2 (GTK+ 2.24.5; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQnDesAn4TpQcD1c09WMezfY5BKN2GIhbmZ9KkY7frLldcw8ssl/+yKHjjf9CaaJJKYk9h2p Cc: Juli Mallett , Aleksandr Rybalko , FreeBSD-arch , Stefan Bethke , Marius Strobl Subject: Re: Extending sys/dev/mii X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Feb 2012 17:52:13 -0000 On Sat, 11 Feb 2012 17:00:10 -0800 Adrian Chadd wrote: > Hi Ray, > > Would you please attach the latest diffs: > > * to if_arge, to make it "work"; > * to the mii API, if needed; > * anything new - ie, the switch API, switch PHYs, etc. > > I'd like to try and finally bring some sanity to the hardcoded PHY > mask handling in if_arge (and make it actually work for AR71xx and > AR724x - where AR71xx has one shared MDIO bus between both MACs, but > AR724x has two independent MDIO busses..) > > > > Adrian Hi Adrian, yes, of course, here it is: if_arge patch + white space cleanup: http://my.ddteam.net/files/2012-02-12_sys_mips_atheros.patch Switch Framework itself: http://my.ddteam.net/files/2012-02-12_switch_framework.patch sys/conf/files, as separate item, because my have a bit more difference: http://my.ddteam.net/files/2012-02-12_switch_framework_sys_conf_files.patch Just reminder, to enable it: 1. put "device switch" and driver into kernel config file, "device switch_ar8x16" for Atheros switch. 2. add hints (AR7240 for example): #------------------------------------------------ # No probe at all hint.miibus.0.phymask="0x00000000" hint.miibus.1.phymask="0x00000000" #hint.floatphy.0.at="miibus0" hint.floatphy.0.phyno=0 hint.floatphy.0.master="switch" # Find switch0 hint.floatphy.0.master_unit=0 hint.floatphy.0.master_phys=0x00000010 # Sense PHY4 hint.floatphy.0.flags=0x00000000 hint.floatphy.0.speed=100 # Switch attached to MDIO bus on arge0 hint.switch.0.at="miibus0" hint.switch.0.phyno=1 hint.ar8x16_switch.0.mii_mode=0x012603e2 hint.floatphy.1.at="miibus1" hint.floatphy.1.phyno=0 hint.floatphy.1.master="switch" # Find switch0 hint.floatphy.1.master_unit=0 hint.floatphy.1.master_phys=0x0000000f # Link Sensing PHY0-PHY3 hint.floatphy.1.flags=0x00000004 # "Link on any PHYs" | # "Static link speed" hint.floatphy.1.speed=1000 #------------------------------------------------ -- Aleksandr Rybalko From owner-freebsd-arch@FreeBSD.ORG Sun Feb 12 18:05:17 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 03BE1106566C; Sun, 12 Feb 2012 18:05:17 +0000 (UTC) (envelope-from ray@ddteam.net) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id E3A378FC15; Sun, 12 Feb 2012 18:05:15 +0000 (UTC) Received: by eaan10 with SMTP id n10so1758247eaa.13 for ; Sun, 12 Feb 2012 10:05:14 -0800 (PST) Received: by 10.213.17.9 with SMTP id q9mr318663eba.41.1329069914358; Sun, 12 Feb 2012 10:05:14 -0800 (PST) Received: from rnote.ddteam.net (232-209-133-95.pool.ukrtel.net. [95.133.209.232]) by mx.google.com with ESMTPS id a58sm51226649eeb.8.2012.02.12.10.05.12 (version=SSLv3 cipher=OTHER); Sun, 12 Feb 2012 10:05:13 -0800 (PST) Date: Sun, 12 Feb 2012 20:04:37 +0200 From: Aleksandr Rybalko To: Warner Losh Message-Id: <20120212200437.05c7677f.ray@ddteam.net> In-Reply-To: <58EA57DC-75DF-4813-BB03-FD27F2A49BA2@bsdimp.com> References: <95372FB3-406F-46C2-8684-4FDB672D9FCF@lassitu.de> <20120106214741.GB88161@alchemy.franken.de> <20120108130039.GG88161@alchemy.franken.de> <23477898-8D85-498C-8E30-192810BD68A8@lassitu.de> <20120111193738.GB44286@alchemy.franken.de> <66DDA0A2-F878-43FF-8824-54868F493B18@lassitu.de> <20120125221753.GA17821@alchemy.franken.de> <20120211111731.GE39861@alchemy.franken.de> <20120211144544.c91701d9.ray@ddteam.net> <58EA57DC-75DF-4813-BB03-FD27F2A49BA2@bsdimp.com> X-Mailer: Sylpheed 3.1.2 (GTK+ 2.24.5; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQltav0G7K21BPzukoorNu+6iz14eCkzaFopfIaB0DseeVQkapv5Nk3XU5/0IdBgZ8do9yuk Cc: Adrian Chadd , Stefan Bethke , Juli Mallett , FreeBSD-arch , Aleksandr Rybalko , Marius Strobl Subject: Re: Extending sys/dev/mii X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Feb 2012 18:05:17 -0000 On Sat, 11 Feb 2012 21:59:08 -0700 Warner Losh wrote: > > On Feb 11, 2012, at 9:49 PM, Adrian Chadd wrote: > > > On 11 February 2012 17:15, Warner Losh wrote: > >> > >> On Feb 11, 2012, at 6:00 PM, Adrian Chadd wrote: > >>> I'd like to try and finally bring some sanity to the hardcoded PHY > >>> mask handling in if_arge (and make it actually work for AR71xx and > >>> AR724x - where AR71xx has one shared MDIO bus between both MACs, > >>> but AR724x has two independent MDIO busses..) > >> > >> FDT would do that... > > > > .. how would it bring sanity to the device driver? > > FDT would encode the links between the MAC and the PHY. FDT is a > directed graph, not a tree, so you can have multiple paths to a > device node that follow different domains. FDT is good thing, but in D-Link devices which I already touch FDT present in bootloader only in one device IIRC (Marvell based NAS). Since we need hardcode it, there is no difference how we do it with FDT or with hints. But I agree that it will be step into future if we will support FDT in such things. > > > Right now the driver assumes that both arge0 and arge1 mdiobus are > > the same and uses the phymask setting to determine how/when to > > access registers (ie, trying to read/write from phy registers not > > in the phymask of argeX are denied.) It is one of the annoying > > issues with the AR7241 internal switch support as that switch hangs > > off of arge1's MII bus. > > It would no longer need to do this, or make any assumptions at all. > FDT would tell it all. > > > It may make it easier to specify the configuration but it doesn't > > fix the fundamentally wrong assumption. > > Nope. Bad assumptions would still need to be fixed. > > > The trouble in this whole mess (where FDT may help) is that phy's > > for arge0 may actually sit on arge1. So you can't probe/attach the > > miibus on arge0 until you've probe/attached arge1, so the arge1 MII > > registers can be tickled. > > The PHYs don't sit on arge1. They sit on another device that the > driver bogusly assumes is tightly coupled to arge1, when in fact it > isn't. At least for AR7240/AR7242, MDIO control registers lie in the middle of register space used by if_arge. > > > Ray/Stefan/others: if anything, I'd like to try and bring sanity to > > this particular thorny issue in -HEAD before we worry about switch > > PHY devices. > > Warner > -- Aleksandr Rybalko From owner-freebsd-arch@FreeBSD.ORG Sun Feb 12 18:30:52 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 39BED106566C; Sun, 12 Feb 2012 18:30:52 +0000 (UTC) (envelope-from juli@clockworksquid.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 473468FC1C; Sun, 12 Feb 2012 18:30:50 +0000 (UTC) Received: by wgbdq11 with SMTP id dq11so4334523wgb.31 for ; Sun, 12 Feb 2012 10:30:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.180.101.200 with SMTP id fi8mr19945602wib.20.1329071450147; Sun, 12 Feb 2012 10:30:50 -0800 (PST) Sender: juli@clockworksquid.com Received: by 10.227.209.78 with HTTP; Sun, 12 Feb 2012 10:30:50 -0800 (PST) Received: by 10.227.209.78 with HTTP; Sun, 12 Feb 2012 10:30:50 -0800 (PST) In-Reply-To: <20120212200437.05c7677f.ray@ddteam.net> References: <95372FB3-406F-46C2-8684-4FDB672D9FCF@lassitu.de> <20120106214741.GB88161@alchemy.franken.de> <20120108130039.GG88161@alchemy.franken.de> <23477898-8D85-498C-8E30-192810BD68A8@lassitu.de> <20120111193738.GB44286@alchemy.franken.de> <66DDA0A2-F878-43FF-8824-54868F493B18@lassitu.de> <20120125221753.GA17821@alchemy.franken.de> <20120211111731.GE39861@alchemy.franken.de> <20120211144544.c91701d9.ray@ddteam.net> <58EA57DC-75DF-4813-BB03-FD27F2A49BA2@bsdimp.com> <20120212200437.05c7677f.ray@ddteam.net> Date: Sun, 12 Feb 2012 10:30:50 -0800 X-Google-Sender-Auth: N208D9jop-uhLTPYFonF3rSJfm0 Message-ID: From: Juli Mallett To: Aleksandr Rybalko X-Gm-Message-State: ALoCoQn1QAXkf+A60urvr24xafOX8Gx13z55ynYNcXudomD/DqtECfo5uqzgcbGoCzfgFlsvCoGL Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Adrian Chadd , Stefan Bethke , Marius Strobl , Aleksandr Rybalko , FreeBSD-arch Subject: Re: Extending sys/dev/mii X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Feb 2012 18:30:52 -0000 > > The PHYs don't sit on arge1. They sit on another device that the > > driver bogusly assumes is tightly coupled to arge1, when in fact it > > isn't. > > At least for AR7240/AR7242, MDIO control registers lie in the middle of > register space used by if_arge. That's a fine electrical and address-oriented understanding, but that doesn't mean that a different functional conceptualization wouldn't lend itself better to implementation. Fidelity to the memory layout is a neat idea but not necessarily desirable or even reasonable. From owner-freebsd-arch@FreeBSD.ORG Sun Feb 12 18:39:27 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 53510106564A; Sun, 12 Feb 2012 18:39:27 +0000 (UTC) (envelope-from ray@ddteam.net) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 0F6FA8FC14; Sun, 12 Feb 2012 18:39:25 +0000 (UTC) Received: by eaan10 with SMTP id n10so1769233eaa.13 for ; Sun, 12 Feb 2012 10:39:25 -0800 (PST) Received: by 10.14.127.16 with SMTP id c16mr4389459eei.35.1329071965030; Sun, 12 Feb 2012 10:39:25 -0800 (PST) Received: from rnote.ddteam.net (232-209-133-95.pool.ukrtel.net. [95.133.209.232]) by mx.google.com with ESMTPS id c16sm51610448eei.1.2012.02.12.10.39.22 (version=SSLv3 cipher=OTHER); Sun, 12 Feb 2012 10:39:24 -0800 (PST) Date: Sun, 12 Feb 2012 20:38:48 +0200 From: Aleksandr Rybalko To: Juli Mallett Message-Id: <20120212203848.06e5d5f8.ray@ddteam.net> In-Reply-To: References: <95372FB3-406F-46C2-8684-4FDB672D9FCF@lassitu.de> <20120106214741.GB88161@alchemy.franken.de> <20120108130039.GG88161@alchemy.franken.de> <23477898-8D85-498C-8E30-192810BD68A8@lassitu.de> <20120111193738.GB44286@alchemy.franken.de> <66DDA0A2-F878-43FF-8824-54868F493B18@lassitu.de> <20120125221753.GA17821@alchemy.franken.de> <20120211111731.GE39861@alchemy.franken.de> <20120211144544.c91701d9.ray@ddteam.net> <58EA57DC-75DF-4813-BB03-FD27F2A49BA2@bsdimp.com> X-Mailer: Sylpheed 3.1.2 (GTK+ 2.24.5; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Gm-Message-State: ALoCoQkVpG0yTIoEbemEB5iRKmF0UIE9Hex0jl4JDhMN6409H9Z2LjPsy4CxTjxufLECUWSkIDP4 Cc: Adrian Chadd , Stefan Bethke , FreeBSD-arch , Aleksandr Rybalko , Marius Strobl Subject: Re: Extending sys/dev/mii X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Feb 2012 18:39:27 -0000 On Sat, 11 Feb 2012 21:06:10 -0800 Juli Mallett wrote: > On Sat, Feb 11, 2012 at 20:59, Warner Losh wrote: > >> The trouble in this whole mess (where FDT may help) is that phy's > >> for arge0 may actually sit on arge1. So you can't probe/attach the > >> miibus on arge0 until you've probe/attached arge1, so the arge1 > >> MII registers can be tickled. > > > > The PHYs don't sit on arge1.  They sit on another device that the > > driver bogusly assumes is tightly coupled to arge1, when in fact it > > isn't. > > YES! Thank you! And even if it were tightly coupled in hardware, > there's no reason our device tree needs to mirror that, FDT or not. > Just break out an "arge controller" device, attach arge0 and arge1 to > it, and let it manage the MDIO bus. No shortcomings, as far as I can > tell. You can even be extra clever and say that the switch is > attached to that device, not either of the arge devices, and that one > of the arge devices happens to be connected to the switch's CPU/host > port. But that's probably a bit much to ask for. Correct me if I say something wrong. We can make something like "arge controller", but: 1. We already have another driver with similar register set, it is if_et (dev/et) 2. Many MACs have external MDIO pins and for embedded world it is ok to connect MDIO controlled devices to single MDIO bus. So what we will do with other device? In some case it even can be different MACs (not yet seen that, but it's possible). Now in my device list I have devices that use bfe, arge, rt, octe MACs. IIRC octe0-octe2 for Octeons really single device with 3 paths, rt (Ralink RT305xF MAC) also can use two paths (not implemented yet). But arge, bfe and long list other MACs, which can be used in embedded devices, is really separate MACs (separate cores in SoC) which we must be able to handle w/o modification of existing driver. And since we have way to do that, why not to use that way? WBW -- Aleksandr Rybalko From owner-freebsd-arch@FreeBSD.ORG Sun Feb 12 20:24:20 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7DE111065756 for ; Sun, 12 Feb 2012 20:24:20 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id DF6DB8FC0A for ; Sun, 12 Feb 2012 20:24:19 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q1CKOEYR001716 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 12 Feb 2012 22:24:14 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q1CKODbF066159; Sun, 12 Feb 2012 22:24:13 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q1CKODqK066158; Sun, 12 Feb 2012 22:24:13 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 12 Feb 2012 22:24:13 +0200 From: Konstantin Belousov To: Ivan Klymenko Message-ID: <20120212202413.GC3283@deviant.kiev.zoral.com.ua> References: <20120203193719.GB3283@deviant.kiev.zoral.com.ua> <4f381dc3.4c300e0a.1364.429eSMTPIN_ADDED@mx.google.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="1obClpQfoaZhQ/bc" Content-Disposition: inline In-Reply-To: <4f381dc3.4c300e0a.1364.429eSMTPIN_ADDED@mx.google.com> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: arch@freebsd.org Subject: Re: Prefaulting for i/o buffers X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Feb 2012 20:24:20 -0000 --1obClpQfoaZhQ/bc Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Feb 12, 2012 at 10:14:56PM +0200, Ivan Klymenko wrote: > =F7 Fri, 3 Feb 2012 21:37:19 +0200 > Konstantin Belousov =D0=C9=DB=C5=D4: >=20 > > http://people.freebsd.org/~kib/misc/vm1.3.patch >=20 > I have FreeBSD 10.0-CURRENT #0 r231526M: Sat Feb 11 23:06:18 EET 2012 > ivan@nonamehost:/usr/obj/usr/src/sys/mk10 amd64 >=20 > my system is patched http://people.freebsd.org/~kib/drm/all.13.2.patch > (I do not know is the important point is whether or not) >=20 > When using this patch vm1.3.patch or 1.4 or 1.5 or ... including > http://people.freebsd.org/~kib/misc/vm1.9.patch the system works fine > in the console, but when loaded into a graphical environment - a system > gets of global lock (even the mouse cursor does not move) - only reset > helps >=20 > I'm using Gnome GUI + compiz... I cannot make anything with this report, since it obviously misses any data on the deadlock. BTW, I just put vm1.10 which allows buildworld over NFS to finish successfu= lly. --1obClpQfoaZhQ/bc Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk84H+0ACgkQC3+MBN1Mb4j8KwCgupKZ+wFz28gc3sqnRWSG4ffz zPIAoNv+M2zSnyhNo2gZDlQrdjAo3CWy =QyEo -----END PGP SIGNATURE----- --1obClpQfoaZhQ/bc-- From owner-freebsd-arch@FreeBSD.ORG Sun Feb 12 20:35:54 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3FB88106566B for ; Sun, 12 Feb 2012 20:35:54 +0000 (UTC) (envelope-from fidaj@ukr.net) Received: from fsm2.ukr.net (fsm2.ukr.net [195.214.192.121]) by mx1.freebsd.org (Postfix) with ESMTP id E5BFE8FC0C for ; Sun, 12 Feb 2012 20:35:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ukr.net; s=fsm; h=Content-Transfer-Encoding:Content-Type:Mime-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=AMLHhGc8cU1luhFOO6VTu9rECE/czyU2RXTMy/UdfA0=; b=GtiGoM1rxw2NPA15Eg1GGeq3uNIjH+P3OuRCdzhVqpZVC+OtFtxJQYBgfzi0v2edbUbNoNdz5+NcGpI+HrCTzWxT/TSnluxlIU7xqvD3jmzyhLdUY4vV8ZYziS6fzB1nvvGZ3jeCNIYNWUO50CHJhq3o4EG00/V1ErOGEt1XBiY=; Received: from [178.137.138.140] (helo=nonamehost.) by fsm2.ukr.net with esmtpsa ID 1Rwfp4-0001Ng-Am ; Sun, 12 Feb 2012 22:14:58 +0200 Date: Sun, 12 Feb 2012 22:14:56 +0200 From: Ivan Klymenko To: Konstantin Belousov Message-ID: <20120212221456.4938a3b4@nonamehost.> In-Reply-To: <20120203193719.GB3283@deviant.kiev.zoral.com.ua> References: <20120203193719.GB3283@deviant.kiev.zoral.com.ua> X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.6; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: arch@freebsd.org Subject: Re: Prefaulting for i/o buffers X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Feb 2012 20:35:54 -0000 =D0=92 Fri, 3 Feb 2012 21:37:19 +0200 Konstantin Belousov =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > http://people.freebsd.org/~kib/misc/vm1.3.patch I have FreeBSD 10.0-CURRENT #0 r231526M: Sat Feb 11 23:06:18 EET 2012 ivan@nonamehost:/usr/obj/usr/src/sys/mk10 amd64 my system is patched http://people.freebsd.org/~kib/drm/all.13.2.patch (I do not know is the important point is whether or not) When using this patch vm1.3.patch or 1.4 or 1.5 or ... including http://people.freebsd.org/~kib/misc/vm1.9.patch the system works fine in the console, but when loaded into a graphical environment - a system gets of global lock (even the mouse cursor does not move) - only reset helps I'm using Gnome GUI + compiz... From owner-freebsd-arch@FreeBSD.ORG Sun Feb 12 20:37:58 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 499EB106566B for ; Sun, 12 Feb 2012 20:37:58 +0000 (UTC) (envelope-from fidaj@ukr.net) Received: from fsm2.ukr.net (fsm2.ukr.net [195.214.192.121]) by mx1.freebsd.org (Postfix) with ESMTP id EB8618FC14 for ; Sun, 12 Feb 2012 20:37:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ukr.net; s=fsm; h=Content-Transfer-Encoding:Content-Type:Mime-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=imRPowSU+Ql3uveSPpKwm2pfa0low3dy8baR3X3cD4M=; b=wQJGjrPlIUwxW7eL9pSmzqRLxLMdMapuabm/D8YWf2n67kqw3Tzr62FMbXnnsBjtZ0pXwqCbaws3/eMSceGdrF7AfbMZhSGSaI4ab9MWxCKs0KFWAnTo2UVfldhjEUb3kNbjzzg7kI3N6tRe8ujcgtWfdL3wtIQBPTEl8X5aBKM=; Received: from [178.137.138.140] (helo=nonamehost.) by fsm2.ukr.net with esmtpsa ID 1RwgBI-0004Yl-H1 ; Sun, 12 Feb 2012 22:37:56 +0200 Date: Sun, 12 Feb 2012 22:37:54 +0200 From: Ivan Klymenko To: Konstantin Belousov Message-ID: <20120212223754.65828553@nonamehost.> In-Reply-To: <20120212202413.GC3283@deviant.kiev.zoral.com.ua> References: <20120203193719.GB3283@deviant.kiev.zoral.com.ua> <4f381dc3.4c300e0a.1364.429eSMTPIN_ADDED@mx.google.com> <20120212202413.GC3283@deviant.kiev.zoral.com.ua> X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.6; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: arch@freebsd.org Subject: Re: Prefaulting for i/o buffers X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Feb 2012 20:37:58 -0000 =D0=92 Sun, 12 Feb 2012 22:24:13 +0200 Konstantin Belousov =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > On Sun, Feb 12, 2012 at 10:14:56PM +0200, Ivan Klymenko wrote: > > =D0=92 Fri, 3 Feb 2012 21:37:19 +0200 > > Konstantin Belousov =D0=BF=D0=B8=D1=88=D0=B5=D1= =82: > >=20 > > > http://people.freebsd.org/~kib/misc/vm1.3.patch > >=20 > > I have FreeBSD 10.0-CURRENT #0 r231526M: Sat Feb 11 23:06:18 EET > > 2012 ivan@nonamehost:/usr/obj/usr/src/sys/mk10 amd64 > >=20 > > my system is patched > > http://people.freebsd.org/~kib/drm/all.13.2.patch (I do not know is > > the important point is whether or not) > >=20 > > When using this patch vm1.3.patch or 1.4 or 1.5 or ... including > > http://people.freebsd.org/~kib/misc/vm1.9.patch the system works > > fine in the console, but when loaded into a graphical environment - > > a system gets of global lock (even the mouse cursor does not move) > > - only reset helps > >=20 > > I'm using Gnome GUI + compiz... >=20 > I cannot make anything with this report, since it obviously misses any > data on the deadlock. Definitely yes :) but >=20 > BTW, I just put vm1.10 which allows buildworld over NFS to finish > successfully. my kernel config file is assembled with the options options KDB_TRACE options KDB # Enable kernel debugger support. options DDB also use the patch http://people.freebsd.org/ ~ kib/drm/all.13.2.patch where not yet implemented the transition to the console - how do I get at least some data using the break-to-debugger Ctrl + Alt + ESC? Thanks! From owner-freebsd-arch@FreeBSD.ORG Sun Feb 12 20:43:44 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 52A14106566B for ; Sun, 12 Feb 2012 20:43:44 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id BA8AA8FC0A for ; Sun, 12 Feb 2012 20:43:42 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q1CKhbLG014337 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 12 Feb 2012 22:43:37 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q1CKhb3V066260; Sun, 12 Feb 2012 22:43:37 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q1CKhb9V066259; Sun, 12 Feb 2012 22:43:37 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 12 Feb 2012 22:43:37 +0200 From: Konstantin Belousov To: Ivan Klymenko Message-ID: <20120212204337.GD3283@deviant.kiev.zoral.com.ua> References: <20120203193719.GB3283@deviant.kiev.zoral.com.ua> <4f381dc3.4c300e0a.1364.429eSMTPIN_ADDED@mx.google.com> <20120212202413.GC3283@deviant.kiev.zoral.com.ua> <4f382325.031d0e0a.194a.ffff93bbSMTPIN_ADDED@mx.google.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="I0l8kuPOEar4fhrJ" Content-Disposition: inline In-Reply-To: <4f382325.031d0e0a.194a.ffff93bbSMTPIN_ADDED@mx.google.com> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: arch@freebsd.org Subject: Re: Prefaulting for i/o buffers X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Feb 2012 20:43:44 -0000 --I0l8kuPOEar4fhrJ Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Feb 12, 2012 at 10:37:54PM +0200, Ivan Klymenko wrote: > =F7 Sun, 12 Feb 2012 22:24:13 +0200 > Konstantin Belousov =D0=C9=DB=C5=D4: >=20 > > On Sun, Feb 12, 2012 at 10:14:56PM +0200, Ivan Klymenko wrote: > > > =F7 Fri, 3 Feb 2012 21:37:19 +0200 > > > Konstantin Belousov =D0=C9=DB=C5=D4: > > >=20 > > > > http://people.freebsd.org/~kib/misc/vm1.3.patch > > >=20 > > > I have FreeBSD 10.0-CURRENT #0 r231526M: Sat Feb 11 23:06:18 EET > > > 2012 ivan@nonamehost:/usr/obj/usr/src/sys/mk10 amd64 > > >=20 > > > my system is patched > > > http://people.freebsd.org/~kib/drm/all.13.2.patch (I do not know is > > > the important point is whether or not) > > >=20 > > > When using this patch vm1.3.patch or 1.4 or 1.5 or ... including > > > http://people.freebsd.org/~kib/misc/vm1.9.patch the system works > > > fine in the console, but when loaded into a graphical environment - > > > a system gets of global lock (even the mouse cursor does not move) > > > - only reset helps > > >=20 > > > I'm using Gnome GUI + compiz... > >=20 > > I cannot make anything with this report, since it obviously misses any > > data on the deadlock. >=20 > Definitely yes :) but >=20 > >=20 > > BTW, I just put vm1.10 which allows buildworld over NFS to finish > > successfully. >=20 > my kernel config file is assembled with the options > options KDB_TRACE > options KDB # Enable kernel debugger support. > options DDB > also use the patch http://people.freebsd.org/ ~ kib/drm/all.13.2.patch > where not yet implemented the transition to the console - how do I get > at least some data using the break-to-debugger Ctrl + Alt + ESC? Switching the virtual consoles probably would not work on the deadlocked system anyway, since X server needs to process this operation regardless of the presence of KMS. The more important, but not yet realized premise of KMS is the ability to enter the kernel debugger on the graphical console without switching X session console. But this indeed not implemented. I suspect that the serial console, or software watchdog and some ddb script (see ddb(8)) are the only ways forward. --I0l8kuPOEar4fhrJ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk84JHkACgkQC3+MBN1Mb4jqjgCghHZ7koafxSaurlR9CA2bVQwP woEAnj9cqYz8ly8xuAbUXksABMesNOLU =IK5/ -----END PGP SIGNATURE----- --I0l8kuPOEar4fhrJ-- From owner-freebsd-arch@FreeBSD.ORG Sun Feb 12 20:53:22 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B8FAE10656D0 for ; Sun, 12 Feb 2012 20:53:22 +0000 (UTC) (envelope-from fidaj@ukr.net) Received: from fsm1.ukr.net (fsm1.ukr.net [195.214.192.120]) by mx1.freebsd.org (Postfix) with ESMTP id 666758FC14 for ; Sun, 12 Feb 2012 20:53:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ukr.net; s=fsm; h=Content-Transfer-Encoding:Content-Type:Mime-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=qtZEOr6we4uGzxHC3kbbVVCULfB/INvfAraWsmu41bg=; b=BLtYkT+gGnhGJCQzYF2qARNxQIueT0oCwNQEMNVmKwzZFGqNCzF1HnogXnArvrAB7rZOb0d/uz5ZgBmucONdHmHf/0RSBLQnMaXq6lv/y3pldIQfrzdbvA5gkvzTIvQTdtsVQc1nth1I37xTtt/+5LqD91T+qhYZWIYNBH9DdXE=; Received: from [178.137.138.140] (helo=nonamehost.) by fsm1.ukr.net with esmtpsa ID 1RwgQB-000ICD-5H ; Sun, 12 Feb 2012 22:53:19 +0200 Date: Sun, 12 Feb 2012 22:53:17 +0200 From: Ivan Klymenko To: Konstantin Belousov Message-ID: <20120212225317.05e77c3e@nonamehost.> In-Reply-To: <20120212204337.GD3283@deviant.kiev.zoral.com.ua> References: <20120203193719.GB3283@deviant.kiev.zoral.com.ua> <4f381dc3.4c300e0a.1364.429eSMTPIN_ADDED@mx.google.com> <20120212202413.GC3283@deviant.kiev.zoral.com.ua> <4f382325.031d0e0a.194a.ffff93bbSMTPIN_ADDED@mx.google.com> <20120212204337.GD3283@deviant.kiev.zoral.com.ua> X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.6; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: arch@freebsd.org Subject: Re: Prefaulting for i/o buffers X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Feb 2012 20:53:22 -0000 =D0=92 Sun, 12 Feb 2012 22:43:37 +0200 Konstantin Belousov =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > On Sun, Feb 12, 2012 at 10:37:54PM +0200, Ivan Klymenko wrote: > > =D0=92 Sun, 12 Feb 2012 22:24:13 +0200 > > Konstantin Belousov =D0=BF=D0=B8=D1=88=D0=B5=D1= =82: > >=20 > > > On Sun, Feb 12, 2012 at 10:14:56PM +0200, Ivan Klymenko wrote: > > > > =D0=92 Fri, 3 Feb 2012 21:37:19 +0200 > > > > Konstantin Belousov =D0=BF=D0=B8=D1=88=D0=B5= =D1=82: > > > >=20 > > > > > http://people.freebsd.org/~kib/misc/vm1.3.patch > > > >=20 > > > > I have FreeBSD 10.0-CURRENT #0 r231526M: Sat Feb 11 23:06:18 EET > > > > 2012 ivan@nonamehost:/usr/obj/usr/src/sys/mk10 amd64 > > > >=20 > > > > my system is patched > > > > http://people.freebsd.org/~kib/drm/all.13.2.patch (I do not > > > > know is the important point is whether or not) > > > >=20 > > > > When using this patch vm1.3.patch or 1.4 or 1.5 or ... including > > > > http://people.freebsd.org/~kib/misc/vm1.9.patch the system works > > > > fine in the console, but when loaded into a graphical > > > > environment - a system gets of global lock (even the mouse > > > > cursor does not move) > > > > - only reset helps > > > >=20 > > > > I'm using Gnome GUI + compiz... > > >=20 > > > I cannot make anything with this report, since it obviously > > > misses any data on the deadlock. > >=20 > > Definitely yes :) but > >=20 > > >=20 > > > BTW, I just put vm1.10 which allows buildworld over NFS to finish > > > successfully. > >=20 > > my kernel config file is assembled with the options > > options KDB_TRACE > > options KDB # Enable kernel debugger support. > > options DDB > > also use the patch http://people.freebsd.org/ ~ > > kib/drm/all.13.2.patch where not yet implemented the transition to > > the console - how do I get at least some data using the > > break-to-debugger Ctrl + Alt + ESC? >=20 > Switching the virtual consoles probably would not work on the > deadlocked system anyway, since X server needs to process this > operation regardless of the presence of KMS. The more important, but > not yet realized premise of KMS is the ability to enter the kernel > debugger on the graphical console without switching X session > console. But this indeed not implemented. >=20 > I suspect that the serial console, or software watchdog and some ddb > script (see ddb(8)) are the only ways forward. That is, should I try to add to the kernel configuration options SW_WATCHDOG and in /etc/rc.conf watchdogd_enable=3D"YES" and after global lock to happen - expect a miracle? :) because the other possibilities I have not ... From owner-freebsd-arch@FreeBSD.ORG Wed Feb 15 22:05:34 2012 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3F5671065670; Wed, 15 Feb 2012 22:05:34 +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 4664D8FC15; Wed, 15 Feb 2012 22:05:33 +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 XAA07298; Wed, 15 Feb 2012 23:51:42 +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 1RxmlK-00010d-9x; Wed, 15 Feb 2012 23:51:42 +0200 Message-ID: <4F3C28DD.1020003@FreeBSD.org> Date: Wed, 15 Feb 2012 23:51:25 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0) Gecko/20120202 Thunderbird/10.0 MIME-Version: 1.0 To: freebsd-arch@FreeBSD.org, gabor@FreeBSD.org X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=X-VIET-VPS Content-Transfer-Encoding: 7bit Cc: Subject: bsd/citrus iconv X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 22:05:34 -0000 Guys, maybe we could already start building bsd/citrus iconv and using it for something instead of just having it in the tree? Maybe initially without exposing the lib to anything outside the base system (ports), just using it for things in the base system like libkiconv... -- Andriy Gapon From owner-freebsd-arch@FreeBSD.ORG Wed Feb 15 22:28:09 2012 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B2B6C106564A; Wed, 15 Feb 2012 22:28:09 +0000 (UTC) (envelope-from gabor@FreeBSD.org) Received: from server.mypc.hu (server.mypc.hu [87.229.73.95]) by mx1.freebsd.org (Postfix) with ESMTP id 3622B8FC17; Wed, 15 Feb 2012 22:28:09 +0000 (UTC) Received: from server.mypc.hu (localhost [127.0.0.1]) by server.mypc.hu (Postfix) with ESMTP id 14DCD14E6D22; Wed, 15 Feb 2012 23:09:54 +0100 (CET) X-Virus-Scanned: amavisd-new at server.mypc.hu Received: from server.mypc.hu ([127.0.0.1]) by server.mypc.hu (server.mypc.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id RhzvfDVn87E4; Wed, 15 Feb 2012 23:09:52 +0100 (CET) Received: from [192.168.1.117] (catv-80-98-232-12.catv.broadband.hu [80.98.232.12]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by server.mypc.hu (Postfix) with ESMTPSA id 1007914E6CF4; Wed, 15 Feb 2012 23:09:52 +0100 (CET) Message-ID: <4F3C2D2D.5000402@FreeBSD.org> Date: Wed, 15 Feb 2012 23:09:49 +0100 From: Gabor Kovesdan User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0a2) Gecko/20111124 Thunderbird/10.0a2 MIME-Version: 1.0 To: Andriy Gapon References: <4F3C28DD.1020003@FreeBSD.org> In-Reply-To: <4F3C28DD.1020003@FreeBSD.org> Content-Type: text/plain; charset=x-viet-vps; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arch@FreeBSD.org Subject: Re: bsd/citrus iconv X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 22:28:09 -0000 On 2012.02.15. 22:51, Andriy Gapon wrote: > maybe we could already start building bsd/citrus iconv and using it for > something instead of just having it in the tree? > Maybe initially without exposing the lib to anything outside the base system > (ports), just using it for things in the base system like libkiconv... It would be nice but there are some known bugs in iconv, which I haven't addressed yet. I have it on my TODO list but at the moment I'm working on the regex code and I'd like to bring it to a good shape so that people can start to test it and provide feedback while I work on iconv. Also, it is not really possible to avoid exposing it. Configure scripts are quite diverse and some ports will fail with this implementation. This has to be investigated as well. The best would be to fix the problem and provide higher compatibility. So I definitely think it should be opt-in for some time more until I can address those problems. Or if there are volunteers I can give a list of known bugs / issues. Gabor From owner-freebsd-arch@FreeBSD.ORG Thu Feb 16 15:59:28 2012 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B0A3E106566C; Thu, 16 Feb 2012 15:59:28 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail09.syd.optusnet.com.au (mail09.syd.optusnet.com.au [211.29.132.190]) by mx1.freebsd.org (Postfix) with ESMTP id 39C4D8FC0A; Thu, 16 Feb 2012 15:59:27 +0000 (UTC) Received: from c211-30-171-136.carlnfd1.nsw.optusnet.com.au (c211-30-171-136.carlnfd1.nsw.optusnet.com.au [211.30.171.136]) by mail09.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id q1GFxNeh010456 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 17 Feb 2012 02:59:26 +1100 Date: Fri, 17 Feb 2012 02:59:23 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Giovanni Trematerra In-Reply-To: Message-ID: <20120217015048.H3388@besplex.bde.org> References: <20120208151251.J1853@besplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Thu, 16 Feb 2012 16:36:22 +0000 Cc: flo@FreeBSD.org, Kip Macy , John Baldwin , Peter Holm , Attilio Rao , Konstantin Belousov , bde@FreeBSD.org, freebsd-arch@FreeBSD.org, jilles@FreeBSD.org Subject: Re: [LAST ROUND] fifo/pipe merge code X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 15:59:28 -0000 On Wed, 8 Feb 2012, Giovanni Trematerra wrote: Sorry for the delay. > On Wed, Feb 8, 2012 at 6:49 AM, Bruce Evans wrote: >> On Tue, 7 Feb 2012, Giovanni Trematerra wrote: >> >> It looks quite good now. I see only a few minor style bugs: > ... > I updated the patch and I hope I fixed all the minor style bugs > that you pointed out. > > here the new one: > http://www.trematerra.net/patches/pipefifo_merge.4.4.patch It looks very good now. I only see very minor style bugs :-). I didn't think about its correctness again. diff --git a/sys/fs/fifofs/fifo_vnops.c b/sys/fs/fifofs/fifo_vnops.c index 94a2713..729e49c 100644 --- a/sys/fs/fifofs/fifo_vnops.c +++ b/sys/fs/fifofs/fifo_vnops.c % ... % /* % * This structure is associated with the FIFO vnode and stores % * the state associated with the FIFO. % * Notes about locking: % - * - fi_readsock and fi_writesock are invariant since init time. % + * - fi_pipe is invariant since init time. % * - fi_readers and fi_writers are vnode lock protected. % - * - fi_wgen is fif_mtx lock protected. % + * - fi_wgen is PIPE_MTX lock protected. Can you find a better name than PIPE_MTX here and in a comment later? PIPE_MTX is the name of the macro that is supposed to hide the details of the lock, starting with the lock's name. Using it in comments is like unhiding the details. Mutexes aren't the same as locks, and vnode.h is more careful to distinguish them. I adapted the following better wording from vnode.h. * - fi_readers and fi_writers are protected by the vnode lock. * - fi_wgen is protected by the pipe mutex. A full conversion to the vnode.h method would be more concise and say something like: * p - pipe lock * v - vnode lock and then put these letters in comments attached more directly to the fi_* declarations. 2 places in sys_pipe.c fail to use PIPE_MTX() to hide the details. % ... % diff --git a/sys/kern/sys_pipe.c b/sys/kern/sys_pipe.c % index 9edcb74..4a1d8f3 100644 % --- a/sys/kern/sys_pipe.c % +++ b/sys/kern/sys_pipe.c % /* % * Use this define if you want to disable *fancy* VM things. Expect an % * approx 30% decrease in transfer rate. This could be useful for % @@ -1329,29 +1397,28 @@ pipe_poll(fp, events, active_cred, td) % struct pipe *rpipe = fp->f_data; % struct pipe *wpipe; % int revents = 0; % + int levents; Variables with the same type should be declared on 1 line if possible, not as for rpipe and wpipe above. Initializations in declarations can make this hard to read, but are style bugs. Variables with the same type should be sorted. % #ifdef MAC % int error; % #endif % % - wpipe = rpipe->pipe_peer; % + wpipe = PIPE_PEER(rpipe); rpipe should be initialized like wpipe here. % PIPE_LOCK(rpipe); % #ifdef MAC % error = mac_pipe_check_poll(active_cred, rpipe->pipe_pair); % if (error) % goto locked_error; % #endif % - if (events & (POLLIN | POLLRDNORM)) % + if (fp->f_flag & FREAD && events & (POLLIN | POLLRDNORM)) % if ((rpipe->pipe_state & PIPE_DIRECTW) || % (rpipe->pipe_buffer.cnt > 0)) % revents |= events & (POLLIN | POLLRDNORM); % % - if (events & (POLLOUT | POLLWRNORM)) % - if (wpipe->pipe_present != PIPE_ACTIVE || % - (wpipe->pipe_state & PIPE_EOF) || % - (((wpipe->pipe_state & PIPE_DIRECTW) == 0) && % - ((wpipe->pipe_buffer.size - wpipe->pipe_buffer.cnt) >= PIPE_BUF || % - wpipe->pipe_buffer.size == 0))) % - revents |= events & (POLLOUT | POLLWRNORM); You changed the indentation when moving the above. It's not quite right here, but no need to change it, and some of the changes are regressions. % @@ -1361,15 +1428,22 @@ pipe_poll(fp, events, active_cred, td) % revents |= POLLHUP; % } % } % + if (fp->f_flag & FWRITE && events & (POLLOUT | POLLWRNORM)) % + if (wpipe->pipe_present != PIPE_ACTIVE || % + (wpipe->pipe_state & PIPE_EOF) || % + (((wpipe->pipe_state & PIPE_DIRECTW) == 0) && % + ((wpipe->pipe_buffer.size - wpipe->pipe_buffer.cnt) >= Now it is missing 4 spaces of indententation for the previous 2 lines... % + PIPE_BUF || wpipe->pipe_buffer.size == 0))) ... and has an extra 4 spaces for the previous 1 line. % + revents |= events & (POLLOUT | POLLWRNORM); Otherwise, this part of the patch is now readable :-). % ... % @@ -1625,7 +1708,7 @@ filt_pipedetach(struct knote *kn) % static int % filt_piperead(struct knote *kn, long hint) % { % - struct pipe *rpipe = kn->kn_fp->f_data; % + struct pipe *rpipe = (struct pipe *)kn->kn_hook; This cast shouldn't be added here or elsewhere. kn_hook has type `void *', so this cast is not needed in C, unlike in C++. % struct pipe *wpipe = rpipe->pipe_peer; % int ret; This file mostly has the consistently non-KNF style of initializing both rpipe and wpipe in their declarations. Bruce From owner-freebsd-arch@FreeBSD.ORG Thu Feb 16 22:26:07 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BA00A106566C; Thu, 16 Feb 2012 22:26:07 +0000 (UTC) (envelope-from giovanni.trematerra@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 073778FC13; Thu, 16 Feb 2012 22:26:06 +0000 (UTC) Received: by qaea17 with SMTP id a17so3319464qae.13 for ; Thu, 16 Feb 2012 14:26:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=F43XVx7cE3vZLueyPbiqpK5qghCe6KLrgfH+dKEY8Hw=; b=qXpVkYh7CX2BfZRwPhVnG4tDgT4ULXrm2xZ8pGeqVuh5bI1NF3Cehu7OzwCPyqkR9l RhrSCmkWA3Y86fE8+g/XP7po03gqORWV3+Jzu5psK/CwSQAsMue4IxbghcN5e16JoOJ/ BuvvEsVN6kKWWoRVZ9ubvdZRVGsTPw0mCxxG8= MIME-Version: 1.0 Received: by 10.229.135.85 with SMTP id m21mr2980771qct.26.1329431166247; Thu, 16 Feb 2012 14:26:06 -0800 (PST) Sender: giovanni.trematerra@gmail.com Received: by 10.229.214.139 with HTTP; Thu, 16 Feb 2012 14:26:06 -0800 (PST) In-Reply-To: <20120217015048.H3388@besplex.bde.org> References: <20120208151251.J1853@besplex.bde.org> <20120217015048.H3388@besplex.bde.org> Date: Thu, 16 Feb 2012 23:26:06 +0100 X-Google-Sender-Auth: JOoNqNQbsCPshaB5fWkF73LBH0Y Message-ID: From: Giovanni Trematerra To: freebsd-arch@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Kip Macy , Attilio Rao , Konstantin Belousov , jilles@freebsd.org Subject: Re: [LAST ROUND] fifo/pipe merge code X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 22:26:07 -0000 On Thu, Feb 16, 2012 at 4:59 PM, Bruce Evans wrote: > On Wed, 8 Feb 2012, Giovanni Trematerra wrote: > > Sorry for the delay. No problem, thanks to you for your time. > It looks very good now. =A0I only see very minor style bugs :-). =A0I > didn't think about its correctness again. Hopefully this is the last version that fix the remaining style bugs: http://www.trematerra.net/patches/pipefifo_merge.4.5.patch I would appreciate it if someone were to step up and commit this patch. Thank you. Below some comments of mine. > > diff --git a/sys/fs/fifofs/fifo_vnops.c b/sys/fs/fifofs/fifo_vnops.c > index 94a2713..729e49c 100644 > --- a/sys/fs/fifofs/fifo_vnops.c > +++ b/sys/fs/fifofs/fifo_vnops.c > % ... > % =A0/* > % =A0 * This structure is associated with the FIFO vnode and stores > % =A0 * the state associated with the FIFO. > % =A0 * Notes about locking: > % - * =A0 - fi_readsock and fi_writesock are invariant since init time. > % + * =A0 - fi_pipe is invariant since init time. > % =A0 * =A0 - fi_readers and fi_writers are vnode lock protected. > % - * =A0 - fi_wgen is fif_mtx lock protected. > % + * =A0 - fi_wgen is PIPE_MTX lock protected. > > Can you find a better name than PIPE_MTX here and in a comment later? > PIPE_MTX is the name of the macro that is supposed to hide the details > of the lock, starting with the lock's name. =A0Using it in comments is > like unhiding the details. =A0Mutexes aren't the same as locks, and vnode= .h is > more careful to distinguish them. =A0I adapted the following > better wording from vnode.h. > > =A0* =A0 - fi_readers and fi_writers are protected by the vnode lock. > =A0* =A0 - fi_wgen is protected by the pipe mutex. I used this wording. Thanks for the suggestion. > > 2 places in sys_pipe.c fail to use PIPE_MTX() to hide the details. > I'm going to fix this and other style bugs not related to my patch with a different one. > > % ... > % diff --git a/sys/kern/sys_pipe.c b/sys/kern/sys_pipe.c > % index 9edcb74..4a1d8f3 100644 > > % --- a/sys/kern/sys_pipe.c > % +++ b/sys/kern/sys_pipe.c > % =A0/* > % =A0 * Use this define if you want to disable *fancy* VM things. =A0Expe= ct an > % =A0 * approx 30% decrease in transfer rate. =A0This could be useful for > % @@ -1329,29 +1397,28 @@ pipe_poll(fp, events, active_cred, td) > % =A0 =A0 =A0 struct pipe *rpipe =3D fp->f_data; > % =A0 =A0 =A0 struct pipe *wpipe; > % =A0 =A0 =A0 int revents =3D 0; > % + =A0 =A0 int levents; > > Variables with the same type should be declared on 1 line if possible, > not as for rpipe and wpipe above. =A0Initializations in declarations can > make this hard to read, but are style bugs. > > Variables with the same type should be sorted. fixed. > > Otherwise, this part of the patch is now readable :-). The pipe_poll part of the patch should be readable now. I hope :) > > % ... > % @@ -1625,7 +1708,7 @@ filt_pipedetach(struct knote *kn) > % =A0static int > % =A0filt_piperead(struct knote *kn, long hint) > % =A0{ > % - =A0 =A0 struct pipe *rpipe =3D kn->kn_fp->f_data; > % + =A0 =A0 struct pipe *rpipe =3D (struct pipe *)kn->kn_hook; > > This cast shouldn't be added here or elsewhere. =A0kn_hook has type `void= *', > so this cast is not needed in C, unlike in C++. > > % =A0 =A0 =A0 struct pipe *wpipe =3D rpipe->pipe_peer; > % =A0 =A0 =A0 int ret; fixed. > > This file mostly has the consistently non-KNF style of initializing both > rpipe and wpipe in their declarations. > I'll try to fix with a different patch. -- Gianni From owner-freebsd-arch@FreeBSD.ORG Fri Feb 17 00:40:28 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EBF6A106566C for ; Fri, 17 Feb 2012 00:40:28 +0000 (UTC) (envelope-from matthewstory@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id A798A8FC0C for ; Fri, 17 Feb 2012 00:40:28 +0000 (UTC) Received: by vcmm1 with SMTP id m1so2817117vcm.13 for ; Thu, 16 Feb 2012 16:40:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=m5AR1Rl0qWy8JdVbc2qkwHnuO4+94xcBaKD42RUHyTs=; b=CLZ/70PpZE9r1FUtplf5biNsHkvs/ijGt/aVE24z7/RWRzSnJfy3UbS6AvzovxJ9gx Yo/36O2Y9hiuFOCL2EFPO6mfIzRpMsLSF/bUpG+yZOTyIMRt3GNhkpPMNuuOzHS/Vtqh tiKxjqiBJq+YiiA73i5oPAFlgq0L+yh4lDJ/M= MIME-Version: 1.0 Received: by 10.220.228.73 with SMTP id jd9mr2756737vcb.58.1329437366314; Thu, 16 Feb 2012 16:09:26 -0800 (PST) Received: by 10.52.21.84 with HTTP; Thu, 16 Feb 2012 16:09:26 -0800 (PST) Date: Thu, 16 Feb 2012 19:09:26 -0500 Message-ID: From: Matthew Story To: freebsd-arch@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Change to xargs to avoid orphaning of utility processes on signal|exit 255 from child X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 00:40:29 -0000 Apologies if this is the wrong list, I would like to submit a patch that changes the behavior of xargs(1) on signal to child utility process or child utility process exiting 255. The patch(es) is|are available here: http://axe0.blackskyresearch.net/patches/matt/xargs.no_orphan.patch.txt-- this version will apply to current xargs, and adds diagnostic information for exit 255|signal to utility, as required by POSIX (see PR165155). http://axe0.blackskyresearch.net/patches/matt/xargs.no_orphan.PR165155.patch.txt-- this version will apply on top of the patch in PR165155, as the errx calls in that patch need to be modified to warnx calls. I will happily provide a third option without diagnostics if that is useful independent of PR165155. Currently, if a child exits 255, or is terminated via signal, the xargs process exits immediately with exit status 1, with maxprocs > 1, this orphans all outstanding child processes: $ jot - 1 10 | time xargs -P2 -n1 sh -c 'echo "$1: $$"; sleep $1; [ $1 -eq 1 ] && kill $$; echo "$1: $$:done";' worker 1: 69752 2: 69753 1.00 real 0.00 user 0.00 sys $ 2: 69753:done $ # or ... $ jot - 1 10 | time xargs -P2 -n1 sh -c 'echo "$1: $$"; sleep $1; [ $1 -eq 1 ] && exit 255; echo "$1: $$:done";' worker 1: 70379 2: 70380 1.00 real 0.00 user 0.00 sys $ 2: 70380:done This behavior is expected per xargs(1): The xargs utility exits immediately (without processing any further input) if a command line cannot be assembled, utility cannot be invoked, an invocation of utility is terminated by a signal, or an invocation of utility exits with a value of 255. Per the POSIX specification, xargs is only required to stop processing input, and to exit 1-125, it is not exit immediately (utility here is the utility invoked by xargs, not xargs itself): If a command line meeting the specified requirements cannot be assembled, the utility cannot be invoked, an invocation of the utility is terminated by a signal, or an invocation of the utility exits with exit status 255, the *xargs* utility shall write a diagnostic message and exit without processing any remaining input. The patch preserves orphaning when the xargs process itself is terminated by signal, but augments the behavior when a child utility process is terminated by signal or exits 255 to wait for other existing child utilities until exiting 1. My reasoning for this (beyond orphaning nastiness) is that I always want to fail as soon as I know an operation is fatal, and then clean-up. By orphaning children, there is no reliable way to clean-up following use of the 255 exit code (or signal termination): $ # a contrived example forcing a race-condition, with a clean-up function. $ mkdir -p foo; jot - 1 10 | xargs -P5 -n1 sh -c 'sleep $1; touch foo/$1; exit 255;' worker || find foo -type f -delete $ # demonstration that cleanup is not possible $ sleep 5 && ls -l foo total 2 -rw-r--r-- 1 matt matt 0 Feb 16 19:01 2 -rw-r--r-- 1 matt matt 0 Feb 16 19:01 3 -rw-r--r-- 1 matt matt 0 Feb 16 19:01 4 -rw-r--r-- 1 matt matt 0 Feb 16 19:01 5 Following the patch, we get a nice and reliable cleanup, as we have no orphans: $ mkdir -p foo; jot - 1 10 | usr.bin/xargs/xargs -P5 -n1 sh -c 'sleep $1; touch foo/$1; exit 255;' worker || find foo -type f -delete xargs: sh: exited with status 255, aborting xargs: sh: exited with status 255, aborting xargs: sh: exited with status 255, aborting xargs: sh: exited with status 255, aborting xargs: sh: exited with status 255, aborting $ ls -l foo/ total 0 Please let me know what you think, I would very much like to see this patch make it's way into xargs as I find this short-circuit behavior nearly very usable, and it's only failing is that it orphans children unnecessarily, resulting in unpredictable behavior. -- regards, matt From owner-freebsd-arch@FreeBSD.ORG Fri Feb 17 10:16:36 2012 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 962BA1065706; Fri, 17 Feb 2012 10:16:36 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 172-17-150-251.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 745E3158F15; Fri, 17 Feb 2012 10:16:32 +0000 (UTC) Message-ID: <4F3E28FF.1060209@FreeBSD.org> Date: Fri, 17 Feb 2012 02:16:31 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:10.0.1) Gecko/20120213 Thunderbird/10.0.1 MIME-Version: 1.0 To: Don Lewis References: <201201082035.q08KZjL5024434@gw.catspoiler.org> In-Reply-To: <201201082035.q08KZjL5024434@gw.catspoiler.org> X-Enigmail-Version: 1.3.5 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: arch@FreeBSD.org Subject: Re: [patch] allow crash dumps to Linux swap partitions X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 10:16:36 -0000 On 01/08/2012 12:35, Don Lewis wrote: > I've got a machine that is set up to dual boot both FreeBSD and Linux. > It is also disk space impaired, so to make the best use possible of the > available space, I have FreeBSD set up to swap to the Linux swap > partition. Until now I haven't had working crash dumps because geom > didn't permit crash dumps to Linux swap partitions. This patch removes > that limitation. This could be useful for users of laptops who boot > multiple operating systems. So I gave this a try, and I'm getting this: GEOM_PART:dumpon: ioctl(DIOCSKERNELDUMP)P: artition 'ad0s4' not suitable for kernel dumps (wrong type?) Operation not supported by device /etc/rc: WARNING: unable to specify /dev/ad0s7 as a dump device I'm guessing that this is due to ad0s7 being in an extended partition. So I take it we have no support for dumping to logical partition? Doug -- It's always a long day; 86400 doesn't fit into a short. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-arch@FreeBSD.ORG Fri Feb 17 11:03:47 2012 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 972B7106566B; Fri, 17 Feb 2012 11:03:47 +0000 (UTC) (envelope-from ae@FreeBSD.org) Received: from mail.kirov.so-ups.ru (ns.kirov.so-ups.ru [178.74.170.1]) by mx1.freebsd.org (Postfix) with ESMTP id 3F72C8FC0A; Fri, 17 Feb 2012 11:03:47 +0000 (UTC) Received: from kas30pipe.localhost (localhost.kirov.so-ups.ru [127.0.0.1]) by mail.kirov.so-ups.ru (Postfix) with SMTP id 2DE45B8024; Fri, 17 Feb 2012 14:46:39 +0400 (MSK) Received: from kirov.so-ups.ru (unknown [172.21.81.1]) by mail.kirov.so-ups.ru (Postfix) with ESMTP id 28338B801F; Fri, 17 Feb 2012 14:46:39 +0400 (MSK) Received: by ns.kirov.so-ups.ru (Postfix, from userid 1010) id 107D7B8F76; Fri, 17 Feb 2012 14:46:39 +0400 (MSK) Received: from [127.0.0.1] (elsukov.kirov.oduur.so [10.118.3.52]) by ns.kirov.so-ups.ru (Postfix) with ESMTP id CAB9EB8F54; Fri, 17 Feb 2012 14:46:38 +0400 (MSK) Message-ID: <4F3E3009.8010702@FreeBSD.org> Date: Fri, 17 Feb 2012 14:46:33 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla Thunderbird 1.5 (FreeBSD/20051231) MIME-Version: 1.0 To: Doug Barton References: <201201082035.q08KZjL5024434@gw.catspoiler.org> <4F3E28FF.1060209@FreeBSD.org> In-Reply-To: <4F3E28FF.1060209@FreeBSD.org> X-Enigmail-Version: 1.3.5 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig51CEAA1217BF4EFA1EA4EF6D" X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0284], KAS30/Release X-SpamTest-Info: Not protected Cc: arch@FreeBSD.org, Don Lewis Subject: Re: [patch] allow crash dumps to Linux swap partitions X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 11:03:47 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig51CEAA1217BF4EFA1EA4EF6D Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable On 17.02.2012 14:16, Doug Barton wrote: > So I gave this a try, and I'm getting this: >=20 >=20 > GEOM_PART:dumpon: ioctl(DIOCSKERNELDUMP)P: artition 'ad0s4' not > suitable for kernel dumps (wrong type?) > Operation not supported by device > /etc/rc: WARNING: unable to specify /dev/ad0s7 as a dump device >=20 > I'm guessing that this is due to ad0s7 being in an extended partition. > So I take it we have no support for dumping to logical partition? EBR scheme serves logical partitions. Your extended partition is ad0s4, EBR's consumer is attached to MBR's ad0s4 provider. ad0s7 is EBR's provid= er. When you are trying to configure ad0s7 as dump device, GEOM_PART asks EBR= scheme: is kernel dump allowed or not? After r230064 it answers that dumping is a= llowed to partition with type DOSPTYP_386BSD and DOSPTYP_LINSWP. But, since ad0s= 7 has parent provider it forwards this request to MBR's ad0s4. MBR scheme also allows dumping only to the same partition types. But ad0s4 partition has type DOSPTYP_EXT. And you got this error message.= --=20 WBR, Andrey V. Elsukov --------------enig51CEAA1217BF4EFA1EA4EF6D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) iQEcBAEBAgAGBQJPPjAOAAoJEAHF6gQQyKF6rxUH/1vEbjc7m2snE2HQlMTi1bRu ZRrR7sW3ZJAR5Prng2lZIWzGiaLj9wE/Tjr9lhBZYn0DiShzA/1eBCeSnVCjQ92J PmOfZPF+LqqxuyA/snF+Hg9hSYtZI89wb7Z9FDckXmrGuc0uMdgxX9uOhaTeVyNq vh0+YvKpcuTUQbssauBqrSnJVfL3i1W785qrwRNdCHee5lPfY28s/5rhqO5IZraE 39UIqtnDD5XAl7ZoT+YWwXyX9H3gRCksZMhMwJ6No1PrTsIitMa+0m+VFgRqXJxR nE1lWG+C3rW7DtecAsfthsldnblfZe6YS1tpkOofSc5NV4jm60mYvbZZF5VveAI= =sA+M -----END PGP SIGNATURE----- --------------enig51CEAA1217BF4EFA1EA4EF6D-- From owner-freebsd-arch@FreeBSD.ORG Fri Feb 17 11:07:50 2012 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 006D6106566C; Fri, 17 Feb 2012 11:07:50 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 172-17-150-251.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id B006D14EBFD; Fri, 17 Feb 2012 11:07:49 +0000 (UTC) Message-ID: <4F3E3505.1090207@FreeBSD.org> Date: Fri, 17 Feb 2012 03:07:49 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:10.0.1) Gecko/20120213 Thunderbird/10.0.1 MIME-Version: 1.0 To: "Andrey V. Elsukov" References: <201201082035.q08KZjL5024434@gw.catspoiler.org> <4F3E28FF.1060209@FreeBSD.org> <4F3E3009.8010702@FreeBSD.org> In-Reply-To: <4F3E3009.8010702@FreeBSD.org> X-Enigmail-Version: 1.3.5 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: arch@FreeBSD.org, Don Lewis Subject: Re: [patch] allow crash dumps to Linux swap partitions X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 11:07:50 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 02/17/2012 02:46, Andrey V. Elsukov wrote: > On 17.02.2012 14:16, Doug Barton wrote: >> So I gave this a try, and I'm getting this: >> >> >> GEOM_PART:dumpon: ioctl(DIOCSKERNELDUMP)P: artition 'ad0s4' not >> suitable for kernel dumps (wrong type?) Operation not supported >> by device /etc/rc: WARNING: unable to specify /dev/ad0s7 as a >> dump device >> >> I'm guessing that this is due to ad0s7 being in an extended >> partition. So I take it we have no support for dumping to logical >> partition? > > EBR scheme serves logical partitions. Your extended partition is > ad0s4, EBR's consumer is attached to MBR's ad0s4 provider. ad0s7 is > EBR's provider. > > When you are trying to configure ad0s7 as dump device, GEOM_PART > asks EBR scheme: is kernel dump allowed or not? After r230064 it > answers that dumping is allowed to partition with type > DOSPTYP_386BSD and DOSPTYP_LINSWP. But, since ad0s7 has parent > provider it forwards this request to MBR's ad0s4. MBR scheme also > allows dumping only to the same partition types. But ad0s4 > partition has type DOSPTYP_EXT. And you got this error message. Right, I assumed something like this from the mixture of ad0s4 and ad0s7 in the error message, but thanks for the detailed explanation. So that leads me to my next question ... can this be fixed? Doug - -- It's always a long day; 86400 doesn't fit into a short. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iQEcBAEBCAAGBQJPPjUFAAoJEFzGhvEaGryEahcH/jkKPxskhq6wTTG27t1RWZti xxh5DBIz8y2gyX0HkTDV3bXneBvCDDUAgswFBUbFfzm1uF+6dshvnbv9tv0oxWq9 MnqQzD+W9xdgbsnBuLIKhEcGv0a2QcRUd+PmvTI7Rbx/aPU+Q6W1Fj7FFm9sFP7s +H9YdHq8E23tb9iI3Ym1ILJeyobqLQaUKARuKWwnVFzIqbwGpnn4N80CKoyTrZCL 8LLzOy32lsxuzKENVNfW2/MosJJvbmVGOLSqBpRwWN5IhLpkkcofmwrPiGT5fz2a fmRkQTtryM1sW6oislZ8TrgCZhbi/Lpmh6lunCVBAaV9KJJIRYE17/GErfqgt8w= =3Bhe -----END PGP SIGNATURE----- From owner-freebsd-arch@FreeBSD.ORG Fri Feb 17 11:25:04 2012 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4A50B106566C; Fri, 17 Feb 2012 11:25:04 +0000 (UTC) (envelope-from ae@FreeBSD.org) Received: from mail.kirov.so-ups.ru (ns.kirov.so-ups.ru [178.74.170.1]) by mx1.freebsd.org (Postfix) with ESMTP id D79228FC0C; Fri, 17 Feb 2012 11:25:03 +0000 (UTC) Received: from kas30pipe.localhost (localhost.kirov.so-ups.ru [127.0.0.1]) by mail.kirov.so-ups.ru (Postfix) with SMTP id C5ACEB8024; Fri, 17 Feb 2012 15:25:02 +0400 (MSK) Received: from kirov.so-ups.ru (unknown [172.21.81.1]) by mail.kirov.so-ups.ru (Postfix) with ESMTP id C012AB801F; Fri, 17 Feb 2012 15:25:02 +0400 (MSK) Received: by ns.kirov.so-ups.ru (Postfix, from userid 1010) id BABF0B8F75; Fri, 17 Feb 2012 15:25:02 +0400 (MSK) Received: from [127.0.0.1] (elsukov.kirov.oduur.so [10.118.3.52]) by ns.kirov.so-ups.ru (Postfix) with ESMTP id 858E3B8F6E; Fri, 17 Feb 2012 15:25:02 +0400 (MSK) Message-ID: <4F3E3907.8020201@FreeBSD.org> Date: Fri, 17 Feb 2012 15:24:55 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla Thunderbird 1.5 (FreeBSD/20051231) MIME-Version: 1.0 To: Doug Barton References: <201201082035.q08KZjL5024434@gw.catspoiler.org> <4F3E28FF.1060209@FreeBSD.org> <4F3E3009.8010702@FreeBSD.org> <4F3E3505.1090207@FreeBSD.org> In-Reply-To: <4F3E3505.1090207@FreeBSD.org> X-Enigmail-Version: 1.3.5 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig04762AE17501311541A379F7" X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0284], KAS30/Release X-SpamTest-Info: Not protected Cc: arch@FreeBSD.org, Don Lewis Subject: Re: [patch] allow crash dumps to Linux swap partitions X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 11:25:04 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig04762AE17501311541A379F7 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable On 17.02.2012 15:07, Doug Barton wrote: >> allows dumping only to the same partition types. But ad0s4 >> partition has type DOSPTYP_EXT. And you got this error message. >=20 > Right, I assumed something like this from the mixture of ad0s4 and > ad0s7 in the error message, but thanks for the detailed explanation. >=20 > So that leads me to my next question ... can this be fixed? I see two ways to fix this: 1. We can allow dumping to the MBR partition with type "ebr". This also will allow foot shooting for some users. 2. We can revert r230064 EBR's part, because it doesn't work. --=20 WBR, Andrey V. Elsukov --------------enig04762AE17501311541A379F7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) iQEcBAEBAgAGBQJPPjkOAAoJEAHF6gQQyKF6PUAIAIKdvKfpqbsY8TmNhaGAnVRA lPR1+foB3PbclrxtkW87X1FiZt3iWEYbWqmyfnEl8Qg3KYau2ld+iD8Gu5m9bZTa 4ZTEapLmOQYUMX5NovKxhCfDXv+BY0QNjYuBdi88avJWGCLPAZHsbpzmRWSFinon pAy4cTVH3ZxVtSGaYf6SyBMaVD1PgEPgsCABqjCqw4gOptqsq+s1tJDBoJLDzrGG nzIrAO6DC/ENR57K79pYc8Z2o+65E9Z19inesHj7VtkVikJKE19Zg5bDo8PfihM1 lZaxz13up3r2lZytv6krAlLiahMFt5FhF16noe0fXMSEppfqgXqKkFyweLxdEbU= =d03Q -----END PGP SIGNATURE----- --------------enig04762AE17501311541A379F7-- From owner-freebsd-arch@FreeBSD.ORG Fri Feb 17 12:41:58 2012 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6C6EF106564A; Fri, 17 Feb 2012 12:41:58 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 108848FC17; Fri, 17 Feb 2012 12:41:57 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 40C0A6D09; Fri, 17 Feb 2012 12:41:56 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 00CAC868F; Fri, 17 Feb 2012 13:41:55 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: "Andrey V. Elsukov" References: <201201082035.q08KZjL5024434@gw.catspoiler.org> <4F3E28FF.1060209@FreeBSD.org> <4F3E3009.8010702@FreeBSD.org> <4F3E3505.1090207@FreeBSD.org> <4F3E3907.8020201@FreeBSD.org> Date: Fri, 17 Feb 2012 13:41:55 +0100 In-Reply-To: <4F3E3907.8020201@FreeBSD.org> (Andrey V. Elsukov's message of "Fri, 17 Feb 2012 15:24:55 +0400") Message-ID: <86d39dd430.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: arch@FreeBSD.org, Don Lewis , Doug Barton Subject: Re: [patch] allow crash dumps to Linux swap partitions X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 12:41:58 -0000 "Andrey V. Elsukov" writes: > I see two ways to fix this: > 1. We can allow dumping to the MBR partition with type "ebr". > This also will allow foot shooting for some users. > > 2. We can revert r230064 EBR's part, because it doesn't work. The problem is that the question being asked ("is dumping allowed?") is too simplistic. There are actually two questions: "is dumping to this partition allowed?" and "is dumping to a sub-partition of this partition allowed?" The first question only applies to the actual device passed to swapon(2) - in dougb's case, ad0s7 - while the second only applies to its ancestors in the geom hierarchy - in dougb's case, ad0s4 and ad0. Fixing this properly requires a KPI / KBI change, though. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Fri Feb 17 15:56:45 2012 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 75307106568E; Fri, 17 Feb 2012 15:56: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 6E3438FC1F; Fri, 17 Feb 2012 15:56:43 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (beta-e.starpoint.kiev.ua [212.40.38.102]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id RAA09200; Fri, 17 Feb 2012 17:56:42 +0200 (EET) (envelope-from avg@FreeBSD.org) Message-ID: <4F3E78BA.4060203@FreeBSD.org> Date: Fri, 17 Feb 2012 17:56:42 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0) Gecko/20120206 Thunderbird/10.0 MIME-Version: 1.0 To: Gabor Kovesdan References: <4F3C28DD.1020003@FreeBSD.org> <4F3C2D2D.5000402@FreeBSD.org> In-Reply-To: <4F3C2D2D.5000402@FreeBSD.org> X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-arch@FreeBSD.org Subject: Re: bsd/citrus iconv X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 15:56:45 -0000 on 16/02/2012 00:09 Gabor Kovesdan said the following: > Also, it is not really possible to avoid exposing it. Replying only to this for the moment. ... I am not sure why. If we don't install any of its headers and install its library as e.g. libbsdiconv.so, then it's perfectly usable by the libraries/executables in the base system that were specifically compiled to use this library and it's quite well hidden from the rest. -- Andriy Gapon From owner-freebsd-arch@FreeBSD.ORG Fri Feb 17 16:00:48 2012 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 528431065670; Fri, 17 Feb 2012 16:00:48 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 0A8968FC14; Fri, 17 Feb 2012 16:00:47 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 058866DE8; Fri, 17 Feb 2012 16:00:47 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id D17F986B0; Fri, 17 Feb 2012 17:00:46 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Andriy Gapon References: <4F3C28DD.1020003@FreeBSD.org> <4F3C2D2D.5000402@FreeBSD.org> <4F3E78BA.4060203@FreeBSD.org> Date: Fri, 17 Feb 2012 17:00:46 +0100 In-Reply-To: <4F3E78BA.4060203@FreeBSD.org> (Andriy Gapon's message of "Fri, 17 Feb 2012 17:56:42 +0200") Message-ID: <864nupcuvl.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Gabor Kovesdan , freebsd-arch@FreeBSD.org Subject: Re: bsd/citrus iconv X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 16:00:48 -0000 Andriy Gapon writes: > Gabor Kovesdan writes: > > Also, it is not really possible to avoid exposing it. > ... I am not sure why. If we don't install any of its headers and instal= l its > library as e.g. libbsdiconv.so, then it's perfectly usable by the > libraries/executables in the base system that were specifically compiled = to use > this library and it's quite well hidden from the rest. It's not a separate library - if you enable it, it's compiled into libc. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Fri Feb 17 16:09:14 2012 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 61E1F106566C; Fri, 17 Feb 2012 16:09:14 +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 7C8D98FC17; Fri, 17 Feb 2012 16:09:13 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (beta-e.starpoint.kiev.ua [212.40.38.102]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id SAA09297; Fri, 17 Feb 2012 18:07:55 +0200 (EET) (envelope-from avg@FreeBSD.org) Message-ID: <4F3E7B5A.20103@FreeBSD.org> Date: Fri, 17 Feb 2012 18:07:54 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0) Gecko/20120206 Thunderbird/10.0 MIME-Version: 1.0 To: =?UTF-8?B?RGFnLUVybGluZyBTbcO4cmdyYXY=?= References: <4F3C28DD.1020003@FreeBSD.org> <4F3C2D2D.5000402@FreeBSD.org> <4F3E78BA.4060203@FreeBSD.org> <864nupcuvl.fsf@ds4.des.no> In-Reply-To: <864nupcuvl.fsf@ds4.des.no> X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: Gabor Kovesdan , freebsd-arch@FreeBSD.org Subject: Re: bsd/citrus iconv X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 16:09:14 -0000 on 17/02/2012 18:00 Dag-Erling Smørgrav said the following: > Andriy Gapon writes: >> Gabor Kovesdan writes: >>> Also, it is not really possible to avoid exposing it. >> ... I am not sure why. If we don't install any of its headers and install its >> library as e.g. libbsdiconv.so, then it's perfectly usable by the >> libraries/executables in the base system that were specifically compiled to use >> this library and it's quite well hidden from the rest. > > It's not a separate library - if you enable it, it's compiled into libc. But nothing precludes it from being a separate library in principle? There is even src/lib/libiconv, it's just not connected to the build. -- Andriy Gapon From owner-freebsd-arch@FreeBSD.ORG Fri Feb 17 16:19:59 2012 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 080A8106567E; Fri, 17 Feb 2012 16:19:59 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id B8FD38FC0A; Fri, 17 Feb 2012 16:19:58 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id F1AF16E03; Fri, 17 Feb 2012 16:19:57 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id D73E286B3; Fri, 17 Feb 2012 17:19:57 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Andriy Gapon References: <4F3C28DD.1020003@FreeBSD.org> <4F3C2D2D.5000402@FreeBSD.org> <4F3E78BA.4060203@FreeBSD.org> <864nupcuvl.fsf@ds4.des.no> <4F3E7B5A.20103@FreeBSD.org> Date: Fri, 17 Feb 2012 17:19:57 +0100 In-Reply-To: <4F3E7B5A.20103@FreeBSD.org> (Andriy Gapon's message of "Fri, 17 Feb 2012 18:07:54 +0200") Message-ID: <86zkchbff6.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Gabor Kovesdan , freebsd-arch@FreeBSD.org Subject: Re: bsd/citrus iconv X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 16:19:59 -0000 Andriy Gapon writes: > But nothing precludes it from being a separate library in principle? > There is even src/lib/libiconv, it's just not connected to the build. You're right - for some reason, I thought src/lib/libiconv was just a Makefile for GNU libiconv. However, it would be a lot of work for relatively little gain, which would then have to be backed out when citrus went "live". Gabor, do you have a list of known issues? DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Fri Feb 17 18:45:08 2012 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 98A2B106566B; Fri, 17 Feb 2012 18:45:08 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (gw.catspoiler.org [75.1.14.242]) by mx1.freebsd.org (Postfix) with ESMTP id 756648FC14; Fri, 17 Feb 2012 18:45:08 +0000 (UTC) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id q1HIj1vP011584; Fri, 17 Feb 2012 10:45:05 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <201202171845.q1HIj1vP011584@gw.catspoiler.org> Date: Fri, 17 Feb 2012 10:45:01 -0800 (PST) From: Don Lewis To: dougb@FreeBSD.org In-Reply-To: <4F3E28FF.1060209@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: arch@FreeBSD.org Subject: Re: [patch] allow crash dumps to Linux swap partitions X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 18:45:08 -0000 On 17 Feb, Doug Barton wrote: > On 01/08/2012 12:35, Don Lewis wrote: >> I've got a machine that is set up to dual boot both FreeBSD and Linux. >> It is also disk space impaired, so to make the best use possible of the >> available space, I have FreeBSD set up to swap to the Linux swap >> partition. Until now I haven't had working crash dumps because geom >> didn't permit crash dumps to Linux swap partitions. This patch removes >> that limitation. This could be useful for users of laptops who boot >> multiple operating systems. > > > So I gave this a try, and I'm getting this: > > > GEOM_PART:dumpon: ioctl(DIOCSKERNELDUMP)P: artition 'ad0s4' not > suitable for kernel dumps (wrong type?) > Operation not supported by device > /etc/rc: WARNING: unable to specify /dev/ad0s7 as a dump device > > I'm guessing that this is due to ad0s7 being in an extended partition. > So I take it we have no support for dumping to logical partition? I made the same change to g_part_ebr.c that I made to g_part_mbr.c but I didn't have a way of testing it because I don't have any drives with extended partitions. Is the partition type 0x82? Maybe there's another problem in g_part_ebr_dumpto(). It's probably never been exercised before. From owner-freebsd-arch@FreeBSD.ORG Fri Feb 17 18:57:43 2012 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6A1521065670; Fri, 17 Feb 2012 18:57:43 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (gw.catspoiler.org [75.1.14.242]) by mx1.freebsd.org (Postfix) with ESMTP id 4A4578FC08; Fri, 17 Feb 2012 18:57:43 +0000 (UTC) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id q1HIvZcC011615; Fri, 17 Feb 2012 10:57:39 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <201202171857.q1HIvZcC011615@gw.catspoiler.org> Date: Fri, 17 Feb 2012 10:57:35 -0800 (PST) From: Don Lewis To: ae@FreeBSD.org In-Reply-To: <4F3E3009.8010702@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: arch@FreeBSD.org, dougb@FreeBSD.org Subject: Re: [patch] allow crash dumps to Linux swap partitions X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 18:57:43 -0000 On 17 Feb, Andrey V. Elsukov wrote: > On 17.02.2012 14:16, Doug Barton wrote: >> So I gave this a try, and I'm getting this: >> >> >> GEOM_PART:dumpon: ioctl(DIOCSKERNELDUMP)P: artition 'ad0s4' not >> suitable for kernel dumps (wrong type?) >> Operation not supported by device >> /etc/rc: WARNING: unable to specify /dev/ad0s7 as a dump device >> >> I'm guessing that this is due to ad0s7 being in an extended partition. >> So I take it we have no support for dumping to logical partition? > > EBR scheme serves logical partitions. Your extended partition is ad0s4, > EBR's consumer is attached to MBR's ad0s4 provider. ad0s7 is EBR's provider. > > When you are trying to configure ad0s7 as dump device, GEOM_PART asks EBR scheme: > is kernel dump allowed or not? After r230064 it answers that dumping is allowed > to partition with type DOSPTYP_386BSD and DOSPTYP_LINSWP. But, since ad0s7 has > parent provider it forwards this request to MBR's ad0s4. > MBR scheme also allows dumping only to the same partition types. > But ad0s4 partition has type DOSPTYP_EXT. And you got this error message. Is it possible to detect whether a request has been forwarded? I think there is also the possibility of foot shooting in the DOSPTYP_386BSD case and it would be nice to fix that as well. From owner-freebsd-arch@FreeBSD.ORG Fri Feb 17 19:42:44 2012 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CE01910656D6; Fri, 17 Feb 2012 19:42:44 +0000 (UTC) (envelope-from gabor@FreeBSD.org) Received: from server.mypc.hu (server.mypc.hu [87.229.73.95]) by mx1.freebsd.org (Postfix) with ESMTP id 4D1808FC0A; Fri, 17 Feb 2012 19:42:44 +0000 (UTC) Received: from server.mypc.hu (localhost [127.0.0.1]) by server.mypc.hu (Postfix) with ESMTP id 6A82814E6D7C; Fri, 17 Feb 2012 20:42:43 +0100 (CET) X-Virus-Scanned: amavisd-new at server.mypc.hu Received: from server.mypc.hu ([127.0.0.1]) by server.mypc.hu (server.mypc.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id rGJoW8ZYMHvk; Fri, 17 Feb 2012 20:42:41 +0100 (CET) Received: from [84.224.127.230] (netacc-gpn-4-127-230.pool.telenor.hu [84.224.127.230]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by server.mypc.hu (Postfix) with ESMTPSA id A8F0014E6D3C; Fri, 17 Feb 2012 20:42:40 +0100 (CET) Message-ID: <4F3EADB5.7060008@FreeBSD.org> Date: Fri, 17 Feb 2012 20:42:45 +0100 From: Gabor Kovesdan User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: =?UTF-8?B?RGFnLUVybGluZyBTbcO4cmdyYXY=?= References: <4F3C28DD.1020003@FreeBSD.org> <4F3C2D2D.5000402@FreeBSD.org> <4F3E78BA.4060203@FreeBSD.org> <864nupcuvl.fsf@ds4.des.no> <4F3E7B5A.20103@FreeBSD.org> <86zkchbff6.fsf@ds4.des.no> In-Reply-To: <86zkchbff6.fsf@ds4.des.no> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: Andriy Gapon , freebsd-arch@FreeBSD.org Subject: Re: bsd/citrus iconv X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 19:42:44 -0000 Em 17-02-2012 17:19, Dag-Erling Smørgrav escreveu: > Andriy Gapon writes: >> But nothing precludes it from being a separate library in principle? >> There is even src/lib/libiconv, it's just not connected to the build. > You're right - for some reason, I thought src/lib/libiconv was just a > Makefile for GNU libiconv. POSIX requires iconv() to be in libc. However, a glue Makefile was provided there for testing purposes. > > However, it would be a lot of work for relatively little gain, which > would then have to be backed out when citrus went "live". Not that much work, I think. We have to just enable to build that library and install the header with a different name. The base iconv.h is designed to support builds for GNU libiconv but in practice there may be problems with that. > > Gabor, do you have a list of known issues? 1, iconv() does not correctly return the number of non-identical conversions. 2, lang/gcc* build problems (potentially related to iconv.h including stdbool.h and iconv() being defined as a macro) 3, mutt-devel fails to build. It uses the above check where bsd iconv returns 1, while GNU returns 0: | #include | int main() | { | iconv_t cd; | char buf[4]; | char *ob; | size_t obl; | ob = buf, obl = sizeof(buf); | return ((cd = iconv_open("UTF-8", "UTF-8")) != (iconv_t)(-1)&& | (iconv(cd, 0, 0,&ob,&obl) || | !(ob == buf&& obl == sizeof(buf)) || | iconv_close(cd))); | } 4, Check and fix locking in citrus_mapper.c. 5, (not strictly a problem) Citrus iconv has been designed to be modular and extensible. So it uses dynamically loadable modules extensively, at two abstraction levels. However, it is not that practically useful because (1) probably it won't be further extended as Unicode is becoming standard and probably there won't be shiny new encodings and (2) even if it is extended, it is totally fine to require a complete rebuild. So it would be probably better to just link all of that stuff to libc. It would spare the overhead of modularity and clean up a bunch of .so files that are installed currently if iconv is enabled. Gabor From owner-freebsd-arch@FreeBSD.ORG Sat Feb 18 01:54:34 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 58016106564A for ; Sat, 18 Feb 2012 01:54:34 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id BE8EB8FC12 for ; Sat, 18 Feb 2012 01:54:33 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q1I1sS8J049813 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 18 Feb 2012 03:54:28 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q1I1sS95028375; Sat, 18 Feb 2012 03:54:28 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q1I1sSRp028374; Sat, 18 Feb 2012 03:54:28 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 18 Feb 2012 03:54:28 +0200 From: Konstantin Belousov To: current@freebsd.org Message-ID: <20120218015428.GC3283@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="JMrA1WY6/TNbGulc" Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: arch@freebsd.org Subject: Last call: removing the INT_MAX limit on max i/o size X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Feb 2012 01:54:34 -0000 --JMrA1WY6/TNbGulc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline This is a notification to allow you to comment on the patch before the commit. I will commit the latest version of the patch to remove the limitation of the maximal i/o size for read/write syscalls to INT_MAX in the beginning of the next week. The change is available at http://people.freebsd.org/~kib/misc/uio_resid.10.patch various versions of it were discussed with Bruce Evance and David Schultz. Patch does not enable SSIZE_MAX-sized i/o by default, hiding this under debug.iosize_max_clamp sysctl. Effectively, the patch becomes the pass to change various ints into ssize_t. --JMrA1WY6/TNbGulc Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk8/BNQACgkQC3+MBN1Mb4hfJwCg1th8GR3D9wM0GLOuwUN2DQgX xaQAmwYaZXeITcS+EnpPFCrUcBK1T1XU =CG1z -----END PGP SIGNATURE----- --JMrA1WY6/TNbGulc-- From owner-freebsd-arch@FreeBSD.ORG Sat Feb 18 08:02:09 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 650E21065673; Sat, 18 Feb 2012 08:02:09 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 556238FC12; Sat, 18 Feb 2012 08:02:09 +0000 (UTC) Received: by elvis.mu.org (Postfix, from userid 1192) id 3C5361A3C4D; Fri, 17 Feb 2012 23:46:56 -0800 (PST) Date: Fri, 17 Feb 2012 23:46:56 -0800 From: Alfred Perlstein To: Konstantin Belousov Message-ID: <20120218074655.GF31998@elvis.mu.org> References: <20120218015428.GC3283@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120218015428.GC3283@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.4.2.3i Cc: arch@freebsd.org, current@freebsd.org Subject: Re: Last call: removing the INT_MAX limit on max i/o size X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Feb 2012 08:02:09 -0000 * Konstantin Belousov [120217 17:54] wrote: > This is a notification to allow you to comment on the patch before the > commit. > > I will commit the latest version of the patch to remove the limitation > of the maximal i/o size for read/write syscalls to INT_MAX in the > beginning of the next week. > > The change is available at > http://people.freebsd.org/~kib/misc/uio_resid.10.patch > various versions of it were discussed with Bruce Evance and David Schultz. > > Patch does not enable SSIZE_MAX-sized i/o by default, hiding this under > debug.iosize_max_clamp sysctl. Effectively, the patch becomes the pass > to change various ints into ssize_t. I always wonder if it's worth defining a type for this, resid_t or something, therefor you could use some tricks to generate warnings when it's cast to a type that normally would not generate warnings but could cause some loss or issue otherwise. Probably not. -- - Alfred Perlstein .- VMOA #5191, 03 vmax, 92 gs500, 85 ch250, 07 zx10 .- FreeBSD committer From owner-freebsd-arch@FreeBSD.ORG Sat Feb 18 08:43:39 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7F956106564A; Sat, 18 Feb 2012 08:43:39 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 6ED1E8FC0C; Sat, 18 Feb 2012 08:43:39 +0000 (UTC) Received: by elvis.mu.org (Postfix, from userid 1192) id EC4601A3C4D; Sat, 18 Feb 2012 00:43:38 -0800 (PST) Date: Sat, 18 Feb 2012 00:43:38 -0800 From: Alfred Perlstein To: Poul-Henning Kamp Message-ID: <20120218084338.GG31998@elvis.mu.org> References: <20120218074655.GF31998@elvis.mu.org> <20791.1329554045@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20791.1329554045@critter.freebsd.dk> User-Agent: Mutt/1.4.2.3i Cc: Konstantin Belousov , arch@freebsd.org, current@freebsd.org Subject: Re: Last call: removing the INT_MAX limit on max i/o size X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Feb 2012 08:43:39 -0000 * Poul-Henning Kamp [120218 00:34] wrote: > In message <20120218074655.GF31998@elvis.mu.org>, Alfred Perlstein writes: > > >I always wonder if it's worth defining a type for this, resid_t or > >something, > > Wouldn't that naturally be size_t ? I think that makes sense. I was thinking along the lines of making sure that functions that take a resid_t aren't actually being passed the wrong ssize_t, but really that's probably too much fence and just would obfuscate things. -- - Alfred Perlstein .- VMOA #5191, 03 vmax, 92 gs500, 85 ch250, 07 zx10 .- FreeBSD committer From owner-freebsd-arch@FreeBSD.ORG Sat Feb 18 08:52:09 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 394551065674; Sat, 18 Feb 2012 08:52:09 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id C15A28FC08; Sat, 18 Feb 2012 08:52:08 +0000 (UTC) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 8AF575DA8; Sat, 18 Feb 2012 08:34:05 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.5/8.14.5) with ESMTP id q1I8Y5jT020792; Sat, 18 Feb 2012 08:34:05 GMT (envelope-from phk@phk.freebsd.dk) To: Alfred Perlstein From: "Poul-Henning Kamp" In-Reply-To: Your message of "Fri, 17 Feb 2012 23:46:56 PST." <20120218074655.GF31998@elvis.mu.org> Content-Type: text/plain; charset=ISO-8859-1 Date: Sat, 18 Feb 2012 08:34:05 +0000 Message-ID: <20791.1329554045@critter.freebsd.dk> Cc: Konstantin Belousov , arch@freebsd.org, current@freebsd.org Subject: Re: Last call: removing the INT_MAX limit on max i/o size X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Feb 2012 08:52:09 -0000 In message <20120218074655.GF31998@elvis.mu.org>, Alfred Perlstein writes: >I always wonder if it's worth defining a type for this, resid_t or >something, Wouldn't that naturally be size_t ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Sat Feb 18 16:22:17 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DD421106566B; Sat, 18 Feb 2012 16:22:17 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe01.c2i.net [212.247.154.2]) by mx1.freebsd.org (Postfix) with ESMTP id C903E8FC0C; Sat, 18 Feb 2012 16:22:16 +0000 (UTC) X-T2-Spam-Status: No, hits=-1.0 required=5.0 tests=ALL_TRUSTED Received: from [176.74.208.111] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe01.swip.net (CommuniGate Pro SMTP 5.4.2) with ESMTPA id 243371014; Sat, 18 Feb 2012 17:22:14 +0100 From: Hans Petter Selasky To: freebsd-usb@freebsd.org Date: Sat, 18 Feb 2012 17:20:27 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.3-PRERELEASE; KDE/4.4.5; amd64; ; ) References: In-Reply-To: X-Face: 'mmZ:T{)),Oru^0c+/}w'`gU1$ubmG?lp!=R4Wy\ELYo2)@'UZ24N@d2+AyewRX}mAm; Yp |U[@, _z/([?1bCfM{_"B<.J>mICJCHAzzGHI{y7{%JVz%R~yJHIji`y>Y}k1C4TfysrsUI -%GU9V5]iUZF&nRn9mJ'?&>O MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201202181720.27135.hselasky@c2i.net> Cc: Kostik Belousov , Adrian Chadd , freebsd-arch@freebsd.org, Robert Millan Subject: Re: Exclude USB drivers from main kernel image? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Feb 2012 16:22:18 -0000 On Saturday 18 February 2012 14:07:18 Robert Millan wrote: > Hi, > > If I recall correctly from the /etc/devd/usb.conf discussion, decision > was taken not to exclude USB drivers from main kernel image (and leave > it to devd to auto-load them) because of timing in the 9.0 release > cycle. > > Now that 9.0 is released, would it make sense to do this change in > HEAD and make the kernel image about ~290 kiBs smaller? Attached patch > does this for all USB drivers that can be handled by devd (except ukbd > and umass for obvious reasons). > > Note that a very similar change has already been tested for several > months in Debian GNU/kFreeBSD kernels, with no observable ill effects. Hi, The /etc/devd/usb.conf is regularly updated, though not automatically. It should auto-load most kind of devices. Only additional case that comes to mind is that USB serial console will not be active until devd has executed, if that is enabled. Your patch looks OK. Adding ARCH @ Instead of commenting out, I would just remove those lines. --HPS From owner-freebsd-arch@FreeBSD.ORG Sat Feb 18 17:50:18 2012 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id E2A97106564A; Sat, 18 Feb 2012 17:50:18 +0000 (UTC) (envelope-from ae@FreeBSD.org) Received: from [127.0.0.1] (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 5B0FE15106E; Sat, 18 Feb 2012 17:50:16 +0000 (UTC) Message-ID: <4F3FE4D2.4090803@FreeBSD.org> Date: Sat, 18 Feb 2012 21:50:10 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20120105 Thunderbird/9.0 MIME-Version: 1.0 To: Don Lewis References: <201202171857.q1HIvZcC011615@gw.catspoiler.org> In-Reply-To: <201202171857.q1HIvZcC011615@gw.catspoiler.org> X-Enigmail-Version: undefined OpenPGP: id=10C8A17A Content-Type: multipart/mixed; boundary="------------060705090304070700000607" Cc: arch@FreeBSD.org, dougb@FreeBSD.org Subject: Re: [patch] allow crash dumps to Linux swap partitions X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Feb 2012 17:50:19 -0000 This is a multi-part message in MIME format. --------------060705090304070700000607 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit On 17.02.2012 22:57, Don Lewis wrote: >> MBR scheme also allows dumping only to the same partition types. >> But ad0s4 partition has type DOSPTYP_EXT. And you got this error message. > > Is it possible to detect whether a request has been forwarded? I think > there is also the possibility of foot shooting in the DOSPTYP_386BSD > case and it would be nice to fix that as well. Hi, I think we can check bp->bio_from field, something like that (not tested): -- WBR, Andrey V. Elsukov --------------060705090304070700000607 Content-Type: text/plain; name="kerneldump.diff" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="kerneldump.diff" Index: head/sys/geom/part/g_part.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- head/sys/geom/part/g_part.c (revision 231895) +++ head/sys/geom/part/g_part.c (working copy) @@ -2113,9 +2193,14 @@ g_part_start(struct bio *bp) /* * Check that the partition is suitable for kernel * dumps. Typically only swap partitions should be - * used. + * used. If request goes from the nested scheme we + * allow dumping, because nested scheme allowed that. */ - if (!G_PART_DUMPTO(table, entry)) { + if (table->gpt_depth =3D=3D 0 && + bp->bio_from !=3D NULL && + bp->bio_from->geom->class !=3D &g_part_class) { + /* FALLTHROUGH */ + } else if (G_PART_DUMPTO(table, entry) =3D=3D 0) { g_io_deliver(bp, ENODEV); printf("GEOM_PART: Partition '%s' not suitable" " for kernel dumps (wrong type?)\n", --------------060705090304070700000607-- From owner-freebsd-arch@FreeBSD.ORG Sat Feb 18 17:52:59 2012 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 1D126106564A; Sat, 18 Feb 2012 17:52:59 +0000 (UTC) (envelope-from ae@FreeBSD.org) Received: from [127.0.0.1] (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 1446714E88B; Sat, 18 Feb 2012 17:52:50 +0000 (UTC) Message-ID: <4F3FE56D.3030706@FreeBSD.org> Date: Sat, 18 Feb 2012 21:52:45 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20120105 Thunderbird/9.0 MIME-Version: 1.0 To: Don Lewis References: <201202171857.q1HIvZcC011615@gw.catspoiler.org> <4F3FE4D2.4090803@FreeBSD.org> In-Reply-To: <4F3FE4D2.4090803@FreeBSD.org> X-Enigmail-Version: undefined OpenPGP: id=10C8A17A Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit Cc: arch@FreeBSD.org, dougb@FreeBSD.org Subject: Re: [patch] allow crash dumps to Linux swap partitions X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Feb 2012 17:52:59 -0000 On 18.02.2012 21:50, Andrey V. Elsukov wrote: > + bp->bio_from->geom->class != &g_part_class) { Of course, here should be "bp->bio_from->geom->class == &g_part_class". -- WBR, Andrey V. Elsukov From owner-freebsd-arch@FreeBSD.ORG Sat Feb 18 21:22:11 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F1E75106566B; Sat, 18 Feb 2012 21:22:11 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 213B18FC1C; Sat, 18 Feb 2012 21:22:10 +0000 (UTC) Received: by bkcjg1 with SMTP id jg1so5176370bkc.13 for ; Sat, 18 Feb 2012 13:22:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:subject:references:x-comment-to:sender:date:in-reply-to :message-id:user-agent:mime-version:content-type; bh=AYzxStlQ9pjU3r6CsNRbGAsGqG6qLF0UwM66gn0enNc=; b=kAC+sntgADq20MYz2kJCJDbpD6HCBf0HugFIFexKD98ItxreMIGPATRWCaglTQf/1t lrhSQ6vOGvfhJm7IowsnLihNPj14z71G0UdunyKGTrT0fqbNmKpIJguChIGYJWHw90sN +l63z+c4OgSfZo7nDGz9MY4XixCIkNbvbjQIY= Received: by 10.204.129.208 with SMTP id p16mr6534331bks.131.1329600128557; Sat, 18 Feb 2012 13:22:08 -0800 (PST) Received: from localhost ([95.69.173.122]) by mx.google.com with ESMTPS id ey8sm29979528bkb.1.2012.02.18.13.22.05 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 18 Feb 2012 13:22:06 -0800 (PST) From: Mikolaj Golub To: Kostik Belousov References: <86sjjobzmn.fsf@kopusha.home.net> <86fwfnti5t.fsf@kopusha.home.net> <20120112215106.GC31224@deviant.kiev.zoral.com.ua> <86hazntwmu.fsf@kopusha.home.net> <20120123031238.GL31224@deviant.kiev.zoral.com.ua> X-Comment-To: Kostik Belousov Sender: Mikolaj Golub Date: Sat, 18 Feb 2012 23:22:03 +0200 In-Reply-To: <20120123031238.GL31224@deviant.kiev.zoral.com.ua> (Kostik Belousov's message of "Mon, 23 Jan 2012 05:12:38 +0200") Message-ID: <86zkcfu9ac.fsf@kopusha.home.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "Robert N. M. Watson" , freebsd-arch@freebsd.org Subject: Re: unix domain sockets on nullfs(5) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Feb 2012 21:22:12 -0000 On Mon, 23 Jan 2012 05:12:38 +0200 Kostik Belousov wrote: KB> On Sun, Jan 22, 2012 at 08:33:45PM +0200, Mikolaj Golub wrote: >> >> There was a bug in my patch: for vop_unpdetach it wanted the vnode to be >> exclusively locked, while it was called from the context (uipc_detach) where >> the vnode is not locked. >> >> It looks it is OK that the vnode is not locked here: the operation is to null >> vp->v_socket, and currently the only place where it is concurently accessed is >> in unp_connect(), and it is protected by the linkage lock. >> >> So I updated my patch to have "= = =" for unpdetach vp. >> >> http://people.freebsd.org/~trociny/VOP_UNP.2.patch >> >> >> On Thu, 12 Jan 2012 23:51:06 +0200 Kostik Belousov wrote: >> >> KB> On Thu, Jan 12, 2012 at 09:39:53PM +0000, Robert N. M. Watson wrote: >> >> >> >> I still find myself worried by the fact that unp->unp_vnode points at the >> >> nullfs vnode rather than the underlying vnode, but haven't yet managed to >> >> identify any actual bugs that would result. I'll continue pondering it >> >> over the weekend :-). >> >> KB> I think I know what could go wrong there, but due to other bug, this >> KB> wrongness cannot be realized now. >> >> KB> Issue is that for the forced unmount, the unp_vnode is reclaimed, so that >> KB> the unix domain sockets code references freed memory after reclaim. >> >> Just to have this clear, as I understand this problem with reclaim is >> orthogonal to the initial issue and would also exist without my patch too? KB> Yes. >> >> Could you please tell what is the other bug? I see that after force unmount, >> in vflush() we call vgonel() for every vnode, and vgonel() does VOP_CLOSE(), >> VOP_INACTIVE(), VOP_RECLAIM(), sets v_type = VBAD, but vnode's usecount is not >> decreased so if a node was active it may not be freed when vdropl() is called. KB> The lack of the cleanup in the reclamation code. >> >> Was the usecount supposed to be dropped somewere in this path (when >> VOP_CLOSE() is called?) and this is the bug you mean or it is something else? KB> No, usecount must not be dropped. The hold count counts the owners of KB> the pointer to the vnode, preventing the freeing of the struct vnode KB> itself. Usecount is to avoid non-forced unmounts from reclaiming the KB> vnode. >> >> Currently the usecount (for both VREG and VSOCK) is deacreased when the >> process finaly closes the discriptor. >> >> KB> Probably, some helper should provided by uipc_usrreq, called from VOP_RECLAIM() >> KB> implementations for VSOCK types of vnodes. >> >> I would not be very happy with adding the helper to every fs's VOP_RECLAIM() >> implementation :-). Couldn't it be somevere in the common code, e.g. in >> vflush()? Here is the patch I tried: >> >> http://people.freebsd.org/~trociny/vsock_reclaim.patch KB> Not in the vflush(). I think vgonel() would be better place. After collecting all suggestions and additional testing I have got this patch set: http://people.freebsd.org/~trociny/unp_prepare_reclaim.1.patch http://people.freebsd.org/~trociny/unp_connect.LOCKSHARED.1.patch http://people.freebsd.org/~trociny/VOP_UNP.3.patch It has survived some bind/connect/force umount stress testing revealing only some issues that are also observed without patching. -- Mikolaj Golub From owner-freebsd-arch@FreeBSD.ORG Sat Feb 18 21:50:10 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 469DE106564A; Sat, 18 Feb 2012 21:50:10 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 8A2028FC15; Sat, 18 Feb 2012 21:50:09 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q1ILo48q043034 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 18 Feb 2012 23:50:04 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q1ILo3rk044140; Sat, 18 Feb 2012 23:50:03 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q1ILo31H044139; Sat, 18 Feb 2012 23:50:03 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 18 Feb 2012 23:50:03 +0200 From: Konstantin Belousov To: Mikolaj Golub Message-ID: <20120218215003.GM3283@deviant.kiev.zoral.com.ua> References: <86sjjobzmn.fsf@kopusha.home.net> <86fwfnti5t.fsf@kopusha.home.net> <20120112215106.GC31224@deviant.kiev.zoral.com.ua> <86hazntwmu.fsf@kopusha.home.net> <20120123031238.GL31224@deviant.kiev.zoral.com.ua> <86zkcfu9ac.fsf@kopusha.home.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="B1ozxjQqW1UYvlaJ" Content-Disposition: inline In-Reply-To: <86zkcfu9ac.fsf@kopusha.home.net> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: "Robert N. M. Watson" , freebsd-arch@freebsd.org Subject: Re: unix domain sockets on nullfs(5) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Feb 2012 21:50:10 -0000 --B1ozxjQqW1UYvlaJ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Feb 18, 2012 at 11:22:03PM +0200, Mikolaj Golub wrote: > After collecting all suggestions and additional testing I have got this p= atch > set: >=20 > http://people.freebsd.org/~trociny/unp_prepare_reclaim.1.patch Including unpcb.h into vfs_subr.c looks too extreme. Put the prototype into vnode.h, possibly renaming the function to vfs_unp_reclaim. > http://people.freebsd.org/~trociny/unp_connect.LOCKSHARED.1.patch > http://people.freebsd.org/~trociny/VOP_UNP.3.patch I has a painting suggestion there, call the vops VOP_UNP_DETACH etc, otherwise it takes too much reading to understand that it is not undetach. >=20 > It has survived some bind/connect/force umount stress testing revealing o= nly > some issues that are also observed without patching. What are the issues ? --B1ozxjQqW1UYvlaJ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk9AHQsACgkQC3+MBN1Mb4iZJQCg4UsFrZQCYVWuwIsyqxUHkBOF XoMAoMuVocnMre7LjNVmNXLLf4RYdNGa =e0BQ -----END PGP SIGNATURE----- --B1ozxjQqW1UYvlaJ-- From owner-freebsd-arch@FreeBSD.ORG Sat Feb 18 22:27:12 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E971B1065674; Sat, 18 Feb 2012 22:27:12 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 102088FC1B; Sat, 18 Feb 2012 22:27:11 +0000 (UTC) Received: by bkcjg1 with SMTP id jg1so5198440bkc.13 for ; Sat, 18 Feb 2012 14:27:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:subject:references:x-comment-to:sender:date:in-reply-to :message-id:user-agent:mime-version:content-type; bh=iKUbzntieTJP5C7Bckj6iWNyS1dJa1+wmJl7VO+EVTQ=; b=qnRfJbyIzKFMhqG/urYMj7haALimskhfWJ59Q1vvu7GPFsXxplK0aIXtptQUvTVOUK vrS6uSMx35O2OBURPFn8tHzlfyqmekUMqIdGtcr1aau8wbI85zPrIdwg4NLz4XDV101L 5FiKC8Y5qygD9M4S1fGjYVv/y6mx9MDv8FU/I= Received: by 10.204.151.207 with SMTP id d15mr6691133bkw.27.1329604030728; Sat, 18 Feb 2012 14:27:10 -0800 (PST) Received: from localhost ([95.69.173.122]) by mx.google.com with ESMTPS id y9sm30159678bkw.5.2012.02.18.14.27.08 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 18 Feb 2012 14:27:09 -0800 (PST) From: Mikolaj Golub To: Konstantin Belousov References: <86sjjobzmn.fsf@kopusha.home.net> <86fwfnti5t.fsf@kopusha.home.net> <20120112215106.GC31224@deviant.kiev.zoral.com.ua> <86hazntwmu.fsf@kopusha.home.net> <20120123031238.GL31224@deviant.kiev.zoral.com.ua> <86zkcfu9ac.fsf@kopusha.home.net> <20120218215003.GM3283@deviant.kiev.zoral.com.ua> X-Comment-To: Konstantin Belousov Sender: Mikolaj Golub Date: Sun, 19 Feb 2012 00:27:06 +0200 In-Reply-To: <20120218215003.GM3283@deviant.kiev.zoral.com.ua> (Konstantin Belousov's message of "Sat, 18 Feb 2012 23:50:03 +0200") Message-ID: <86vcn3u69x.fsf@kopusha.home.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "Robert N. M. Watson" , freebsd-arch@freebsd.org Subject: Re: unix domain sockets on nullfs(5) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Feb 2012 22:27:13 -0000 On Sat, 18 Feb 2012 23:50:03 +0200 Konstantin Belousov wrote: KB> On Sat, Feb 18, 2012 at 11:22:03PM +0200, Mikolaj Golub wrote: >> After collecting all suggestions and additional testing I have got this patch >> set: >> >> http://people.freebsd.org/~trociny/unp_prepare_reclaim.1.patch KB> Including unpcb.h into vfs_subr.c looks too extreme. Put the prototype KB> into vnode.h, possibly renaming the function to vfs_unp_reclaim. >> http://people.freebsd.org/~trociny/unp_connect.LOCKSHARED.1.patch >> http://people.freebsd.org/~trociny/VOP_UNP.3.patch KB> I has a painting suggestion there, call the vops VOP_UNP_DETACH etc, KB> otherwise it takes too much reading to understand that it is not undetach. Thanks, will do both. >> >> It has survived some bind/connect/force umount stress testing revealing only >> some issues that are also observed without patching. KB> What are the issues ? I triggered this assert: #9 0x80a678cc in panic (fmt=0x80fcbba0 "sofree: so_comp populated") at /home/golub/freebsd/git/freebsd/sys/kern/kern_shutdown.c:633 #10 0x80ada1da in sofree (so=0x8c71b820) at /home/golub/freebsd/git/freebsd/sys/kern/uipc_socket.c:638 #11 0x80adbab6 in soclose (so=0x8c71b820) at /home/golub/freebsd/git/freebsd/sys/kern/uipc_socket.c:741 #12 0x80abe3e9 in soo_close (fp=0x89fb5cb0, td=0x8ad9db80) at /home/golub/freebsd/git/freebsd/sys/kern/sys_socket.c:294 #13 0x80a26c13 in _fdrop (fp=0x89fb5cb0, td=0x8ad9db80) at file.h:310 #14 0x80a29640 in closef (fp=0x89fb5cb0, td=0x8ad9db80) at /home/golub/freebsd/git/freebsd/sys/kern/kern_descrip.c:2246 #15 0x80a29a09 in kern_close (td=0x8ad9db80, fd=3) at /home/golub/freebsd/git/freebsd/sys/kern/kern_descrip.c:1232 #16 0x80a29baa in sys_close (td=0x8ad9db80, uap=0xdef62cec) at /home/golub/freebsd/git/freebsd/sys/kern/kern_descrip.c:1178 #17 0x80deca20 in syscall (frame=0xdef62d28) at subr_syscall.c:135 #18 0x80dd5ce1 in Xint0x80_syscall () at /home/golub/freebsd/git/freebsd/sys/i386/i386/exception.s:266 (kgdb) fr 10 #10 0x80ada1da in sofree (so=0x8c71b820) at /home/golub/freebsd/git/freebsd/sys/kern/uipc_socket.c:638 638 KASSERT((TAILQ_EMPTY(&so->so_incomp)), ("sofree: so_comp populated")); (kgdb) l 633 (so->so_qstate & SQ_INCOMP) == 0, 634 ("sofree: so_head == NULL, but still SQ_COMP(%d) or SQ_INCOMP(%d)", 635 so->so_qstate & SQ_COMP, so->so_qstate & SQ_INCOMP)); 636 if (so->so_options & SO_ACCEPTCONN) { 637 KASSERT((TAILQ_EMPTY(&so->so_comp)), ("sofree: so_comp populated")); 638 KASSERT((TAILQ_EMPTY(&so->so_incomp)), ("sofree: so_comp populated")); 639 } 640 SOCK_UNLOCK(so); 641 ACCEPT_UNLOCK(); 642 (BTW, the panic message should be: "sofree: so_incomp populated".) The test was to run bind/listen/accept/umount -f/close (with some variations) loop in one thread and connect/close in several others. I was able to trigger it for nullfs and was not able for ufs. I have not looked close at it yet, just checked that the same panic is observed on a kernel without my modifications. Another issue is a socket leak observed when running the above test: after the test stale sockets remain: kopusha:~% sockstat|grep test ? ? ? ? stream /mnt/upper/test.sock ? ? ? ? stream /mnt/lower/test.sock ? ? ? ? stream /mnt/upper/test.sock I am going to investigate this more some day. -- Mikolaj Golub