From owner-freebsd-hackers@freebsd.org Mon Oct 12 20:11:21 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5F91EA11490 for ; Mon, 12 Oct 2015 20:11:21 +0000 (UTC) (envelope-from gsuryacse7k@gmail.com) Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1EA60138A for ; Mon, 12 Oct 2015 20:11:21 +0000 (UTC) (envelope-from gsuryacse7k@gmail.com) Received: by vkha6 with SMTP id a6so35328921vkh.2 for ; Mon, 12 Oct 2015 13:11:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=Z1HmQq7lNJavRePwo1jjlS6HQyxRemSqPrfqKCa+p0Y=; b=zBVsAAkCm87eruDTb0vxjAfgj7vLunBUOHFUM/WusVg7KeEti6Ag5IaYKhw65JCLro 8jrK/j4s/k22QzVV289PO0EGajNAQXrFo2BJ5N2FcK6ARi2baBbbW55hqbnfayoAvjY2 m4Sk5ur5ajbRJpoPL553RZlrM6XpQvbafWlUY5xI3CGvrVeXCyA/RIX5yLtVx/EhZBhX iTqwd7GNMOOcRhYdIQVHSc99RU04VVGMfkfSOwzPrk6dfY+SVM6SrKTw5Ci/QvrPZsta lA6Sash2bgyGlWGWMzqL5FcnBfN007cgXft+9bYAhnrI42yfjNN5ENVO4H/qZuSnnOrQ keYw== MIME-Version: 1.0 X-Received: by 10.31.60.145 with SMTP id j139mr19767357vka.89.1444680680026; Mon, 12 Oct 2015 13:11:20 -0700 (PDT) Received: by 10.103.26.3 with HTTP; Mon, 12 Oct 2015 13:11:19 -0700 (PDT) Date: Mon, 12 Oct 2015 16:11:19 -0400 Message-ID: Subject: kernel pages superpage promotion/demotion From: suresh gumpula To: "freebsd-hackers@freebsd.org" X-Mailman-Approved-At: Mon, 12 Oct 2015 20:39:17 +0000 Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2015 20:11:21 -0000 Hi, I understand that user space VM map pages dynamically promoted/demoted to super page if the kernel thinks that it gains the performance. The question is , does this apply to kernel map pages too ? And is it possible to write protect kernel address space VA with pmap_protect(9). Since the protection is per 4k page, I see this routine tries to demote to 4k page. Or this is only for user space maps to support mprotect(2) and gdb watchpoints. Do we have any other API to write protect kernel addresses which come from UMA zone allocations ? Could some one with VM expertise please comment on this ? Thanks Suresh From owner-freebsd-hackers@freebsd.org Mon Oct 12 22:43:50 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 81318A11F29 for ; Mon, 12 Oct 2015 22:43:50 +0000 (UTC) (envelope-from alan.l.cox@gmail.com) Received: from mail-yk0-x232.google.com (mail-yk0-x232.google.com [IPv6:2607:f8b0:4002:c07::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 426011BF8 for ; Mon, 12 Oct 2015 22:43:50 +0000 (UTC) (envelope-from alan.l.cox@gmail.com) Received: by ykec126 with SMTP id c126so323063yke.2 for ; Mon, 12 Oct 2015 15:43:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=E+Iy/Zs5wZkYFeSFyOOoSZs9S8mA2JI7qaUdRunSIPU=; b=En4eTPFH9p+TXjT3trRrpdQUYX1+fuCrMwPAfkVbiZx3JZN1ZJdpmU4MtgxHLQnDJ8 h7tiYViZyCdUovDJpTOQJ/cE1g+PYH+KOYmuNBlEfkMCj9oVyE0WzCGCtfaQiy9P7bmo UqIHX6ygw8Q/hQImuGK5N/9W3DyufDybcq86JatTm1kwqgeHDf5KcSkBP90gsfW5pyw3 pMmVo/OtkjIhz0POg3p2q29BHA972W2sz42oNfn/mmBlyCHQk+H28HOMPKIPXIepP3mv 9++DWFCeqNgES8zqSrEzNP3DbTABRILuPyVl7UMCw0Er6fb9km40pYy9aeDAomCb5rkc WVyA== MIME-Version: 1.0 X-Received: by 10.129.99.139 with SMTP id x133mr24477438ywb.66.1444689829351; Mon, 12 Oct 2015 15:43:49 -0700 (PDT) Received: by 10.37.105.215 with HTTP; Mon, 12 Oct 2015 15:43:49 -0700 (PDT) Reply-To: alc@freebsd.org In-Reply-To: References: Date: Mon, 12 Oct 2015 17:43:49 -0500 Message-ID: Subject: Re: kernel pages superpage promotion/demotion From: Alan Cox To: suresh gumpula Cc: "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2015 22:43:50 -0000 On Mon, Oct 12, 2015 at 3:11 PM, suresh gumpula wrote: > Hi, > I understand that user space VM map pages dynamically > promoted/demoted to super page > if the kernel thinks that it gains the performance. > The question is , does this apply to kernel map pages too ? > > Yes, it applies to memory allocated for UMA zones, malloc(9), and contigmalloc(9). > And is it possible to write protect kernel address space VA with > pmap_protect(9). Since the protection is per 4k page, I see this > routine tries to demote to 4k page. > Or this is only for user space maps to support mprotect(2) and gdb > watchpoints. > Do we have any other API to write protect kernel addresses which come from > UMA zone allocations ? > > No. Can you please try to describe what are you trying to do at a higher level? From owner-freebsd-hackers@freebsd.org Mon Oct 12 23:39:05 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BA1D3A12A4C for ; Mon, 12 Oct 2015 23:39:05 +0000 (UTC) (envelope-from gsuryacse7k@gmail.com) Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com [IPv6:2607:f8b0:400c:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 75C981D1A; Mon, 12 Oct 2015 23:39:05 +0000 (UTC) (envelope-from gsuryacse7k@gmail.com) Received: by vkat63 with SMTP id t63so723626vka.1; Mon, 12 Oct 2015 16:39:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=SKPuu/ZVlRLr1PFJX7dhLmoxNwQF2yOr63cnHkGZhkg=; b=x5HH/mnyVPHdXjINtX5QymRLlPeghOTNxHERR34NAlWZa3qY81aT+blJtX4fwnMiDf vBtCf0Vv1g0JJnuShzkD1opkaVci6gMTTn2W/9zElNucctTP4vikq6Fvfkxt/Kp8/Yul vdqq7rYsQ85uiDj6rwRMbNRq1QSvvNKHLwhO2ZcJaz7ElrQiGgAodVwYWAu9p7DiNdsT djdJuVB3HvGWPbbkynvw5I9REvj3wXBcEahCXrf9tr8NpoGBcH/npEQOOV5WWJUYU7Rz yfA9xwchBs52noZVMB0SuwFpsg2GO+Z6rA4s3S3racZgIyFn3F2FQ+2ZFh403U/jaicl QcsA== MIME-Version: 1.0 X-Received: by 10.31.49.67 with SMTP id x64mr19937005vkx.133.1444693144154; Mon, 12 Oct 2015 16:39:04 -0700 (PDT) Received: by 10.103.26.3 with HTTP; Mon, 12 Oct 2015 16:39:04 -0700 (PDT) In-Reply-To: References: Date: Mon, 12 Oct 2015 19:39:04 -0400 Message-ID: Subject: Re: kernel pages superpage promotion/demotion From: suresh gumpula To: alc@freebsd.org Cc: "freebsd-hackers@freebsd.org" X-Mailman-Approved-At: Mon, 12 Oct 2015 23:55:17 +0000 Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2015 23:39:05 -0000 Thanks a lot for quick reply Alan. The super page promotion/demotion of kernel allocations is done in 9.1 also I assume . Please confirm. Regarding write protection, I am trying to chase a corruption of uma zone allocation, so I was looking at pmap_protect(9). And thinking of using something like pmap_protect(kernel_pmap, sva , eva, VMPROT_READ); to write protect sva to eva of a zone allocation return address. So can pmap_protect(9) be used for this purpose ? Thanks Suresh On Mon, Oct 12, 2015 at 6:43 PM, Alan Cox wrote: > > > On Mon, Oct 12, 2015 at 3:11 PM, suresh gumpula > wrote: > >> Hi, >> I understand that user space VM map pages dynamically >> promoted/demoted to super page >> if the kernel thinks that it gains the performance. >> The question is , does this apply to kernel map pages too ? >> >> > > Yes, it applies to memory allocated for UMA zones, malloc(9), and > contigmalloc(9). > > > >> And is it possible to write protect kernel address space VA with >> pmap_protect(9). Since the protection is per 4k page, I see this >> routine tries to demote to 4k page. >> Or this is only for user space maps to support mprotect(2) and gdb >> watchpoints. >> Do we have any other API to write protect kernel addresses which come from >> UMA zone allocations ? >> >> > > No. > > Can you please try to describe what are you trying to do at a higher > level? > From owner-freebsd-hackers@freebsd.org Tue Oct 13 00:02:54 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C8B7F9D1231 for ; Tue, 13 Oct 2015 00:02:54 +0000 (UTC) (envelope-from alc@rice.edu) Received: from pp1.rice.edu (proofpoint1.mail.rice.edu [128.42.201.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9E306D2A; Tue, 13 Oct 2015 00:02:53 +0000 (UTC) (envelope-from alc@rice.edu) Received: from pps.filterd (pp1.rice.edu [127.0.0.1]) by pp1.rice.edu (8.15.0.59/8.15.0.59) with SMTP id t9CNwkb8013517; Mon, 12 Oct 2015 19:02:47 -0500 Received: from mh11.mail.rice.edu (mh11.mail.rice.edu [128.42.199.30]) by pp1.rice.edu with ESMTP id 1xgny700rm-1; Mon, 12 Oct 2015 19:02:47 -0500 X-Virus-Scanned: by amavis-2.7.0 at mh11.mail.rice.edu, auth channel Received: from 108-254-203-201.lightspeed.hstntx.sbcglobal.net (108-254-203-201.lightspeed.hstntx.sbcglobal.net [108.254.203.201]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: alc) by mh11.mail.rice.edu (Postfix) with ESMTPSA id D5ADC4C025A; Mon, 12 Oct 2015 19:02:46 -0500 (CDT) Subject: Re: kernel pages superpage promotion/demotion To: suresh gumpula , alc@freebsd.org References: Cc: "freebsd-hackers@freebsd.org" From: Alan Cox Message-ID: <561C4A26.4000408@rice.edu> Date: Mon, 12 Oct 2015 19:02:46 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 kscore.is_bulkscore=0 kscore.compositescore=1 compositescore=0.9 suspectscore=3 malwarescore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 rbsscore=0.9 spamscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1507310000 definitions=main-1510120291 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2015 00:02:54 -0000 On 10/12/2015 18:39, suresh gumpula wrote: > Thanks a lot for quick reply Alan. > The super page promotion/demotion of kernel allocations is done in > 9.1 also I assume . Please confirm. > Yes. > Regarding write protection, I am trying to chase a corruption of uma > zone allocation, so I was looking at pmap_protect(9). > And thinking of using something like pmap_protect(kernel_pmap, sva , > eva, VMPROT_READ); to write protect sva to eva of a zone allocation > return address. > So can pmap_protect(9) be used for this purpose ? > Yes. However, you can't reenable write access, or in general upgrade access, with pmap_protect(). You'll need to use pmap_kextract(), PHYS_TO_VM_PAGE(), and pmap_enter() to recreate the mapping with write access. > > > > On Mon, Oct 12, 2015 at 6:43 PM, Alan Cox > wrote: > > > > On Mon, Oct 12, 2015 at 3:11 PM, suresh gumpula > > wrote: > > Hi, > I understand that user space VM map pages dynamically > promoted/demoted to super page > if the kernel thinks that it gains the performance. > The question is , does this apply to kernel map pages > too ? > > > > Yes, it applies to memory allocated for UMA zones, malloc(9), and > contigmalloc(9). > > > > And is it possible to write protect kernel address space VA with > pmap_protect(9). Since the protection is per 4k page, I > see this > routine tries to demote to 4k page. > Or this is only for user space maps to support mprotect(2) > and gdb > watchpoints. > Do we have any other API to write protect kernel addresses > which come from > UMA zone allocations ? > > > > No. > > Can you please try to describe what are you trying to do at a > higher level? > > From owner-freebsd-hackers@freebsd.org Tue Oct 13 00:42:31 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BC7509D1DE6 for ; Tue, 13 Oct 2015 00:42:31 +0000 (UTC) (envelope-from gsuryacse7k@gmail.com) Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7688EEB; Tue, 13 Oct 2015 00:42:31 +0000 (UTC) (envelope-from gsuryacse7k@gmail.com) Received: by vkaw128 with SMTP id w128so1342268vka.0; Mon, 12 Oct 2015 17:42:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6ea77exxnU0jLx5qd7wD08kusZoh4V8yr8QvqxfW+DE=; b=ujXGk0+vTu8zrhL4GLfS03xwA0gyPb9lxZp0Dqcg14OS2ilP3LHyQpdMIoMYSvI00u CODMH22ceKz6VoAyg1ARoPq1DeaVPoMKjE1mL7Emn3NHjSqdOWQ1N6V1V8ZKG1P0+G17 ZtmvIGKLIb0U7VJRCHtlQ2rIa3rMWloSdDMb1TmSHWh+J+O8azcXhHESTaDJvgQvmC4W ax1An3FYLsi60FtAenKK8C4m/CCmdgDbuVUV8iA3FlsUHEXvx1fQth+3viPhQS+xbmdZ 01Sn52QEIB94pGMnIbHQ2J/zwnYTG3C8K/SvbF01jkXcvBxH9LVxsNwwYfiNOdMK3V/S 3QPA== MIME-Version: 1.0 X-Received: by 10.31.60.145 with SMTP id j139mr20237991vka.89.1444696950513; Mon, 12 Oct 2015 17:42:30 -0700 (PDT) Received: by 10.103.26.3 with HTTP; Mon, 12 Oct 2015 17:42:30 -0700 (PDT) In-Reply-To: <561C4A26.4000408@rice.edu> References: <561C4A26.4000408@rice.edu> Date: Mon, 12 Oct 2015 20:42:30 -0400 Message-ID: Subject: Re: kernel pages superpage promotion/demotion From: suresh gumpula To: Alan Cox Cc: alc@freebsd.org, "freebsd-hackers@freebsd.org" X-Mailman-Approved-At: Tue, 13 Oct 2015 01:04:58 +0000 Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2015 00:42:31 -0000 Thanks so much for the quick reply and inputs Alan. Thanks Suresh On Mon, Oct 12, 2015 at 8:02 PM, Alan Cox wrote: > On 10/12/2015 18:39, suresh gumpula wrote: > > Thanks a lot for quick reply Alan. > The super page promotion/demotion of kernel allocations is done in 9.1 > also I assume . Please confirm. > > > Yes. > > Regarding write protection, I am trying to chase a corruption of uma zone > allocation, so I was looking at pmap_protect(9). > And thinking of using something like pmap_protect(kernel_pmap, sva , eva, > VMPROT_READ); to write protect sva to eva of a zone allocation return > address. > So can pmap_protect(9) be used for this purpose ? > > > Yes. However, you can't reenable write access, or in general upgrade > access, with pmap_protect(). You'll need to use pmap_kextract(), > PHYS_TO_VM_PAGE(), and pmap_enter() to recreate the mapping with write > access. > > > > > On Mon, Oct 12, 2015 at 6:43 PM, Alan Cox wrote: > >> >> >> On Mon, Oct 12, 2015 at 3:11 PM, suresh gumpula < >> gsuryacse7k@gmail.com> wrote: >> >>> Hi, >>> I understand that user space VM map pages dynamically >>> promoted/demoted to super page >>> if the kernel thinks that it gains the performance. >>> The question is , does this apply to kernel map pages too ? >>> >>> >> >> Yes, it applies to memory allocated for UMA zones, malloc(9), and >> contigmalloc(9). >> >> >> >>> And is it possible to write protect kernel address space VA with >>> pmap_protect(9). Since the protection is per 4k page, I see this >>> routine tries to demote to 4k page. >>> Or this is only for user space maps to support mprotect(2) and gdb >>> watchpoints. >>> Do we have any other API to write protect kernel addresses which come >>> from >>> UMA zone allocations ? >>> >>> >> >> No. >> >> Can you please try to describe what are you trying to do at a higher >> level? >> > > > From owner-freebsd-hackers@freebsd.org Tue Oct 13 13:28:08 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 534F4A12167 for ; Tue, 13 Oct 2015 13:28:08 +0000 (UTC) (envelope-from pjalaber@gmail.com) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 19453ABD; Tue, 13 Oct 2015 13:28:08 +0000 (UTC) (envelope-from pjalaber@gmail.com) Received: by oihr205 with SMTP id r205so9309521oih.3; Tue, 13 Oct 2015 06:28:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8dTNnEE/VRPy+pyWMRb0HTs5hVCrtzFVwfxf2dUZH6Q=; b=i3jFseIbGNBKI8a9DkuGF/zTP4Sk+kl4oSewlpkQ+xNjJo4nWFjqcOC/Isq2ETeJqZ xHzAgr53evo4shOD+o4s/ZR+mw/fqqfIrQTrBitbRnjOFUOT5BcQCuaimudhOaTeN43L q5ByEBceKVDaN4YIchuIYcwQf6T8FmGGxtXnBWsg2EZ5LHlnInDvQ08Ac85uqwKpNIj2 fb4PgyIHylCtuCAvq7uT5xxqgUSZIjK7lhIhu1N+36Jl3ICY/4KJRWrkb7w3erfLZUSQ aKFy92yPqvmyOLeU6afNJZmJtjpaS6Tn1oyOdG5sa1rlcvmkBE/nYSfYvWNK3DlQ7ER4 SIOw== MIME-Version: 1.0 X-Received: by 10.202.60.137 with SMTP id j131mr8072602oia.12.1444742887245; Tue, 13 Oct 2015 06:28:07 -0700 (PDT) Received: by 10.202.87.88 with HTTP; Tue, 13 Oct 2015 06:28:07 -0700 (PDT) In-Reply-To: References: <2768515.JZVZhYiQVE@ralph.baldwin.cx> <1902697.ny7xAkAVI4@ralph.baldwin.cx> Date: Tue, 13 Oct 2015 15:28:07 +0200 Message-ID: Subject: Re: adaptive rwlock deadlock From: Philippe Jalaber To: John Baldwin Cc: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2015 13:28:08 -0000 I am able to reproduce the freeze with a simple kernel module modcrash.c. It freezes with a Freebsd 9.3 and 10.0 VM, but not with a Freebsd 10.1, 10.2 or 11.0 VM. It also freezes on a VIA appliance running Freebsd 9.3 and 10.2. All freezes can be reproduced with one or more cpus. Here the modcrash.c source code. Just comment the #define CRASHME (which moves a pause call) and it does not freeze any more. Please note that you can't klunload the module, it crashes the system. Philippe #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include static void modcrash_attach(void); static void modcrash_detach(void); static void modcrash_thread1(void *); static void modcrash_thread2(void *); static void modcrash_thread3(void *); struct thread *thread1_td, *thread2_td, *thread3_td; static struct rwlock inplock; RW_SYSINIT(inplock, &inplock, "inplock"); static struct rwlock glock; RW_SYSINIT(glock, &glock, "glock"); static int volatile global_busy = 0; #define MILLISECONDS(ms) ((hz/1000)*(ms)) static void modcrash_attach(void) { if ( kthread_add(modcrash_thread1, NULL, NULL, &thread1_td, 0, 0, "modcrash1") != 0 ) printf("error\n"); if ( kthread_add(modcrash_thread2, NULL, NULL, &thread2_td, 0, 0, "modcrash2") != 0 ) printf("error\n"); if ( kthread_add(modcrash_thread3, NULL, NULL, &thread3_td, 0, 0, "modcrash3") != 0 ) printf("error\n"); } static void modcrash_detach(void) { } static void modcrash_thread1(void *arg) { int busy; printf("thread 1 running\n"); while ( 1 ) { rw_wlock(&inplock); do { rw_rlock(&glock); busy = global_busy; if ( busy ) { rw_runlock(&glock); } } while ( busy ); rw_runlock(&glock); rw_wunlock(&inplock); pause("thread 1", MILLISECONDS(10)); } kthread_exit(); } static void modcrash_thread2(void *arg) { int busy; printf("thread 2 running\n"); while ( 1 ) { rw_wlock(&glock); if ( (random() & 1) == 0 ) { global_busy = 1; busy = 1; } else { busy = 0; } rw_wunlock(&glock); #define CRASHME #ifdef CRASHME pause("thread 2", MILLISECONDS(10)); #endif if ( busy ) { rw_wlock(&glock); global_busy = 0; rw_wunlock(&glock); } #ifndef CRASHME pause("thread 2", MILLISECONDS(10)); #endif } kthread_exit(); } static void modcrash_thread3(void *context) { printf("thread 3 running\n"); while ( 1 ) { rw_wlock(&inplock); rw_wunlock(&inplock); pause("thread 3", MILLISECONDS(10)); } kthread_exit(); } static int modcrashmodevent(module_t mod, int type, void *data) { switch (type) { case MOD_LOAD: modcrash_attach(); break; case MOD_UNLOAD: modcrash_detach(); break; default: return EOPNOTSUPP; } return 0; } static moduledata_t modcrash_mod = { "modcrash", modcrashmodevent, 0 }; DECLARE_MODULE(modcrash, modcrash_mod, SI_SUB_PSEUDO, SI_ORDER_ANY); MODULE_VERSION(modcrash, 1); 2015-08-06 10:09 GMT+02:00 Philippe Jalaber : > 2015-08-05 17:41 GMT+02:00 John Baldwin : > >> On Wednesday, August 05, 2015 04:27:53 PM Philippe Jalaber wrote: >> > 2015-08-04 22:10 GMT+02:00 John Baldwin : >> > >> > > On Tuesday, July 07, 2015 12:10:19 PM Philippe Jalaber wrote: >> > > > Hi, >> > > > >> > > > I am facing a strange problem using the network stack and adaptive >> > > rwlocks >> > > > running Freebsd 9.3. >> > > > Basically I can reproduce the problem with 3 threads: >> > > > >> > > > 1) thread 1 has taken the rwlock of structure inpcb in exclusive >> mode in >> > > > tcp_input.c. This thread also runs my own code and repeatedly takes >> a >> > > > rwlock (called g_rwlock) in shared mode and releases it, until a >> shared >> > > > object is marked not "busy" any more: >> > > > >> > > > rwlock(inp_lock); >> > > > .... >> > > > do { // thread is active waiting in the loop >> > > > rlock(g_rwlock); >> > > > o = find(); >> > > > if ( o == NULL ) >> > > > break; >> > > > busy = o.busy; >> > > > if (o != NULL && busy) >> > > > runlock(g_rwlock); >> > > > } while ( busy ); >> > > > >> > > > if ( o != NULL ) >> > > > { >> > > > // do something with o >> > > > .... >> > > > } >> > > > runlock(g_rwlock); >> > > > .... >> > > > >> > > > 2) thread 2 wants to set the shared object as "ready". So it tries >> to >> > > take >> > > > g_rwlock in exclusive mode and is blocked in >> _rw_wlock_hard@kern_rwlock.c >> > > :815 >> > > > "turnstile_wait(ts, rw_owner(rw), TS_EXCLUSIVE_QUEUE)" because >> thread 1 >> > > has >> > > > already taken it in shared mode: >> > > > >> > > > wlock(g_rwlock); >> > > > o = find(); >> > > > if ( o != NULL ) >> > > > o.busy = 1; >> > > > wunlock(g_rwlock); >> > > > >> > > > // o is busy so work on it without any lock >> > > > .... >> > > > >> > > > wlock(g_rwlock); // thread is blocked here >> > > > o.busy = 0; >> > > > maybe_delete(o); >> > > > wunlock(g_rwlock); >> > > > >> > > > 3) thread 3 spins on the same inpcb rwlock than thread 1 in >> > > > _rw_wlock_hard@kern_rwlock.c:721 "while ((struct >> > > > thread*)RW_OWNER(rw->rw_lock) == owner && TD_IS_RUNNING(owner)) " >> > > > >> > > > >> > > > My target machine has two cpus. >> > > > Thread 1 is pinned to cpu 0. >> > > > Thread 2 and Thread 3 are pinned to cpu 1. >> > > > Thread 1 and Thread 2 have a priority of 28. >> > > > Thread 3 has a priority of 127 >> > > > >> > > > Now what seems to happen is that when thread 1 calls >> runlock(g_rwlock), >> > > it >> > > > calls turnstile_broadcast@kern_rwlock.c:650, but thread 2 never >> regains >> > > > control because thread 3 is spinning on the inpcb rwlock. Also the >> > > > condition TD_IS_RUNNING(owner) is always true because thread 1 is >> active >> > > > waiting in a loop. So the 3 threads deadlock. >> > > > Note that if I compile the kernel without adaptive rwlocks it works >> > > without >> > > > any problem. >> > > > A workaround is to add a call to "sched_relinquish(curthread)" in >> thread >> > > 1 >> > > > in the loop just after the call to runlock. >> > > >> > > It sounds like we are not forcing a preemption on CPU 1 in this case >> via >> > > sched_add(). >> > > >> > > For SCHED_4BSD you could try the 'FULL_PREEMPTION' kernel option. >> > > For ULE you can adjust 'preempt_thresh' on the fly, though I think the >> > > default setting should actually still work. >> > > >> > > Can you use KTR or some such to determine if IPI_PREEMPT is being >> sent by >> > > CPU 0 to CPU 1 in this case? >> > > >> > > > I am also wondering about the code in _rw_runlock after >> > > > "turnstile_broadcast(ts, queue)". Isn't the flag >> RW_LOCK_WRITE_WAITERS >> > > > definitely lost if the other thread which is blocked in >> turnstile_wait >> > > > never regains control ? >> > > >> > > All the write waiters are awakened by a broadcast (as opposed to a >> signal >> > > operation). They are on the run queue, not on the turnstile queue >> anymore, >> > > so there aren't any write waiters left (the bit only tracks if there >> are >> > > waiters on the turnstile). >> > > >> > > -- >> > > John Baldwin >> > > >> > >> > I Use ULE scheduler. >> > Here's the KTR output using ktrdump on a vmcore after watchdog. >> > >> > 75447 ipi_selected: cpu: 1 ipi: fc >> > 75446 stop_cpus() with 252 type >> > 75445 ipi_cpu: cpu: 1 ipi: 2 >> > 75444 ipi_cpu: cpu: 1 ipi: 2 >> > 75443 ipi_cpu: cpu: 1 ipi: 2 >> > 75442 ipi_cpu: cpu: 1 ipi: 2 >> > 75441 ipi_cpu: cpu: 1 ipi: 2 >> > .... >> > 3862 ipi_cpu: cpu: 1 ipi: 2 >> > 3861 ipi_cpu: cpu: 1 ipi: 2 >> > 3860 ipi_cpu: cpu: 1 ipi: 2 >> > 3859 ipi_cpu: cpu: 1 ipi: 2 >> > 3858 ipi_cpu: cpu: 1 ipi: 2 >> > 3857 ipi_selected: cpu: 1 ipi: f3 >> > 3856 ipi_cpu: cpu: 1 ipi: 2 >> > 3855 ipi_cpu: cpu: 1 ipi: 2 >> > 3854 ipi_cpu: cpu: 1 ipi: 2 >> > 3853 ipi_selected: cpu: 0 ipi: f3 >> > 3852 ipi_cpu: cpu: 1 ipi: 2 >> > 3851 ipi_selected: cpu: 1 ipi: f3 >> > 3850 ipi_cpu: cpu: 1 ipi: 2 >> > 3849 ipi_cpu: cpu: 1 ipi: 2 >> > 3848 ipi_selected: cpu: 0 ipi: f3 >> > 3847 ipi_cpu: cpu: 1 ipi: 2 >> > 3846 ipi_cpu: cpu: 1 ipi: 2 >> > 3845 ipi_cpu: cpu: 1 ipi: 2 >> > 3844 ipi_cpu: cpu: 1 ipi: 2 >> > 3843 ipi_cpu: cpu: 1 ipi: 2 >> > 3842 ipi_cpu: cpu: 1 ipi: 2 >> > 3841 ipi_cpu: cpu: 1 ipi: 2 >> > 3840 ipi_cpu: cpu: 1 ipi: 2 >> > 3839 ipi_cpu: cpu: 1 ipi: 2 >> > 3838 ipi_cpu: cpu: 1 ipi: 2 >> > 3837 ipi_cpu: cpu: 1 ipi: 2 >> > 3836 ipi_cpu: cpu: 1 ipi: 2 >> > 3835 ipi_cpu: cpu: 0 ipi: 1 >> > 3834 ipi_cpu: cpu: 0 ipi: 1 >> > 3833 ipi_cpu: cpu: 0 ipi: 1 >> > 3832 ipi_cpu: cpu: 0 ipi: 1 >> > 3831 ipi_cpu: cpu: 0 ipi: 1 >> > 3830 ipi_cpu: cpu: 0 ipi: 1 >> >> Unfortunately this has a lot of other noise. Can you add some >> traces specifically in sched_ule in tdq_notify to note that it >> is deciding to notify a CPU due to scheduling a thread? >> >> -- >> John Baldwin >> > > OK. Here's the patch I have used in tdq_notify on Freebsd 9.3: > > --- kern/sched_ule.c 2015-08-06 09:03:49.000000000 +0200 > +++ kern/sched_ule.c 2015-08-06 09:03:38.000000000 +0200 > @@ -1020,6 +1020,7 @@ > return; > } > tdq->tdq_ipipending = 1; > + CTR3(KTR_SMP, "%s: cpu: %d IPI_PREEMPT=%x", __func__, cpu, > IPI_PREEMPT); > ipi_cpu(cpu, IPI_PREEMPT); > } > > Please find the output of ktrdump in attachment. > The last IPI_PREEMPT sent is at index #9424. Hope it helps. > > > From owner-freebsd-hackers@freebsd.org Wed Oct 14 18:51:37 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6AAA8A13D10 for ; Wed, 14 Oct 2015 18:51:37 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 26CFE10DF for ; Wed, 14 Oct 2015 18:51:37 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by qkht68 with SMTP id t68so26774944qkh.3 for ; Wed, 14 Oct 2015 11:51:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=468P8C/ZPzqe4Z/hLz4UpsnHWT4NxquaY6yTIUv5Ctg=; b=Sm7lEKAD7AUqPR7ux8EaU6akomz3YOAeB1Ck/wpWf9nN47/tAHiljIcvjGaULusm0z M88fcwSyhQh33iRIS5Kbr0i/wgmlqBylfBXxq1vrjPbydrVtZ8uJJPPg3J45A3ylH1YX 4c21cB66XwQT8v7qZjf3yYouORfhKNYmjjlGB79T/5SWc4bOx8dlVXpiiju8jRAFbvjT Kg+/MhST2sz/Kqjmg3x6BKNHbQK0CWifJOfalO4vknf2qt6doAha0DMR2WNPIaqZ4dRT F0R8fXR2Lnt8hQs0spdb+wr6SsJXWsGgwEbRbuh5z4mMQqtfomn94XWKPmXvqNu4y5zw hUIQ== MIME-Version: 1.0 X-Received: by 10.55.22.162 with SMTP id 34mr6359210qkw.3.1444848696204; Wed, 14 Oct 2015 11:51:36 -0700 (PDT) Received: by 10.140.88.180 with HTTP; Wed, 14 Oct 2015 11:51:36 -0700 (PDT) In-Reply-To: <20151008093355.GS2257@kib.kiev.ua> References: <20151008072444.GO2257@kib.kiev.ua> <20151008080621.GP2257@kib.kiev.ua> <20151008093355.GS2257@kib.kiev.ua> Date: Wed, 14 Oct 2015 11:51:36 -0700 Message-ID: Subject: Re: Comparing behavior of test-fesetenv.c on AMD Opterons and Intel Xeons: running FNSTENV on Opteron -- should it zero out __x87.__other? From: NGie Cooper To: Konstantin Belousov Cc: "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2015 18:51:37 -0000 On Thu, Oct 8, 2015 at 2:33 AM, Konstantin Belousov wrote: > On Thu, Oct 08, 2015 at 02:14:12AM -0700, Garrett Cooper wrote: >> >> > On Oct 8, 2015, at 01:06, Konstantin Belousov wrote: >> > >> >> On Thu, Oct 08, 2015 at 12:38:15AM -0700, Garrett Cooper wrote: >> >> ... >> >> >> Hi kib! >> >> >> >> Ok -- that's what my gut was telling me when I was reading the spec, but I needed a second opinion. Interesting how Intel leaves the __other field alone and AMD [opterons] don't ;/.. >> > >> > Your statement does not make any sense. Re-read what I tell above. >> > The __other field is not written by code, the code does not change >> > by the matter of being run on Intel or AMD processors. It just happens >> > so that on one of your system the stack are seems to be zero, while on >> > another, it does not. >> >> I thought __other corresponded to C0-C3 based on my read of the spec -- is that incorrect? > > What are C0-C3 you reference ? I can only think about condition code > bits from the FPU status word which have that names, but the word is put > into the __status field of fenv_t. You're right. The __other field points to other registers in the FPU. __status covers what both the AMD64 and Intel x64 specs refer to as `C0-C3'. > And, what spec did you read ? I posted links to the specs in my original email. Unfortunately I didn't fully rewrite the bug report so where they factored into it in my original email was unfortunately lost: 1. http://support.amd.com/TechDocs/26569_APM_v5.pdf 2. http://www.intel.com/Assets/en_US/PDF/manual/253666.pdf Thanks! -NGie From owner-freebsd-hackers@freebsd.org Thu Oct 15 07:33:29 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 06CA5A15D9B for ; Thu, 15 Oct 2015 07:33:29 +0000 (UTC) (envelope-from ayankumarh@gmail.com) Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 86AA011CB for ; Thu, 15 Oct 2015 07:33:28 +0000 (UTC) (envelope-from ayankumarh@gmail.com) Received: by lfaz124 with SMTP id z124so23397662lfa.1 for ; Thu, 15 Oct 2015 00:33:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=v8iHQiIYiagg+Lcw8UG+jTwPj372y8PPzo6imtNCgjQ=; b=vnxXLY9jS2Ksz9wu1iuWQKLH1H0XHbjZYCHMn3qhjVK23JOt7TgQZpVb79y03bVJ6P Q15DeHzRbM/zB/Efh8POsPRBT25WJhXSfYfrzVLd2FRWjr3fdP7j0E+27iCNlwc9TEJu KGgIN87aQGZILEaW0I/MC68Cf+ddC1UWUEtUM8kYQNyg0KbPQeXdJ6OTr6+t1yf3MsXV 3uWR/WUN2hNhI6H/kM5t7wr3UeCMxz4Hhx/qqObBXQUOHokDqMAaksDLln8g68g72W+5 DaSbh1OhZB4jnMQDL0LxKXX17uxVuiHeRKu/Wa8GZikeTlPScmgAnnvntv4kieINAyu5 kA1A== MIME-Version: 1.0 X-Received: by 10.25.28.81 with SMTP id c78mr2395644lfc.29.1444894406225; Thu, 15 Oct 2015 00:33:26 -0700 (PDT) Received: by 10.25.156.18 with HTTP; Thu, 15 Oct 2015 00:33:26 -0700 (PDT) In-Reply-To: References: Date: Thu, 15 Oct 2015 13:03:26 +0530 Message-ID: Subject: Fwd: Kernel boots, then does not allow root login. From: AYAN KUMAR HALDER To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Mailman-Approved-At: Thu, 15 Oct 2015 11:46:03 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 07:33:29 -0000 Hi All, I am using freebsd kernel for ARM based custom SOC. The kernel boots and asks for login access. When I type root, it does not accept and repeatedly asks for login access. I was trying to figure out if it was related to getty process. I looked into the etc/etc.arm/ttys and found the following entries:- ttyu0 "/usr/libexec/getty 3wire" vt100 onifconsole secure ttyu1 "/usr/libexec/getty 3wire" vt100 onifconsole secure This looked OK for me. Further, I got lost. I am a newbie and this is my first query to the community, so please let me know if I have posted on wrong forum. Regards, Ayan Kumar Halder From owner-freebsd-hackers@freebsd.org Thu Oct 15 15:29:00 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A0207A1535A for ; Thu, 15 Oct 2015 15:29:00 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from mx1.scaleengine.net (mx1.scaleengine.net [209.51.186.6]) by mx1.freebsd.org (Postfix) with ESMTP id 7E562C35 for ; Thu, 15 Oct 2015 15:29:00 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from [10.1.1.2] (unknown [10.1.1.2]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 46D59D407 for ; Thu, 15 Oct 2015 15:28:59 +0000 (UTC) Subject: Re: Fwd: Kernel boots, then does not allow root login. To: freebsd-hackers@freebsd.org References: From: Allan Jude X-Enigmail-Draft-Status: N1110 Message-ID: <561FC649.4010600@freebsd.org> Date: Thu, 15 Oct 2015 11:29:13 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="pPHHBTcXFrFArSWUF006NVpi2t5D1LnDE" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 15:29:00 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --pPHHBTcXFrFArSWUF006NVpi2t5D1LnDE Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 2015-10-15 03:33, AYAN KUMAR HALDER wrote: > Hi All, >=20 > I am using freebsd kernel for ARM based custom SOC. The kernel boots > and asks for login access. > When I type root, it does not accept and repeatedly asks for login acce= ss. > I was trying to figure out if it was related to getty process. I > looked into the etc/etc.arm/ttys and found the following entries:- >=20 > ttyu0 "/usr/libexec/getty 3wire" vt100 onifconsole secure >=20 > ttyu1 "/usr/libexec/getty 3wire" vt100 onifconsole secure >=20 > This looked OK for me. Further, I got lost. >=20 > I am a newbie and this is my first query to the community, so please > let me know if I have posted on wrong forum. >=20 > Regards, > Ayan Kumar Halder > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.o= rg" >=20 Are you using one of the pre-built default images? The root password should be "root" There should also be a freebsd user, with the password freebsd. --=20 Allan Jude --pPHHBTcXFrFArSWUF006NVpi2t5D1LnDE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQIcBAEBAgAGBQJWH8ZPAAoJEBmVNT4SmAt+7OcP/RIXUMtqys/Xf1P+zVRI23am LNzmYYnbBVmgWvpArPfVywKQMZra+Yz6wKZ5lRjF+rZ5Ua3t1OTo+UEnO628ixmu Nj1cU+MVIce8MM/cXE/vnUDQOMm4u5OLDmAXVwyjFtk8wIiX8WWWNxK4hZxZ3nif IspzDOisQhUSi3yKx7hBsgso6BHvOSRJThbZi/DdnFkDoo89L5ROxXKVQsnNv22w 9mnpDWk0Y1DBpSnIaA1dSGcbvJtn477vAqnDVceGFimAZsBLw77+4fPhHbowQUAP M83e5KI7wyJc69YzC8wLuW/qPi8CAsvUCjriGLgFQMkfyCcGIg7W6dfc3qapbNXh 6MIa7A+wqem6SkDqFJ7x206mPb59hY/rQVxjR2LlLfcEha7CeBv7Fo46NiAp0UGP r7kJ9RUuK0xypNX+NBCgScMZVx+C0p+5PtOvzIQxz5PmmVAqgTadZNBkL0Uz3eoK GRH5iRF5WKYjest9FrZK67iMlKE2JjKnOm43zJ1+LTsVOSwiB2guS+gb1TOnxJgi 0G1hjHd0xl54bfFJ4yzDBOKO8VgdScoUF1v5hguTGsx7i61Np3amBjirvOLdiWLf 3iPj28u4CxZKhC/yVDV5L9yH9zeTurtXckEqM+mL4v94qr/XD0DySnVpZebBnTwE oUUZYI3Bhsfkh4bENHlY =O1YC -----END PGP SIGNATURE----- --pPHHBTcXFrFArSWUF006NVpi2t5D1LnDE-- From owner-freebsd-hackers@freebsd.org Fri Oct 16 15:30:46 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B4773A16EEE for ; Fri, 16 Oct 2015 15:30:46 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from mail.metricspace.net (207-172-209-83.c3-0.arl-ubr1.sbo-arl.ma.static.cable.rcn.com [207.172.209.83]) by mx1.freebsd.org (Postfix) with ESMTP id 90E94C10 for ; Fri, 16 Oct 2015 15:30:46 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from [IPv6:2001:470:1f11:617:ea2a:eaff:fe21:e067] (unknown [IPv6:2001:470:1f11:617:ea2a:eaff:fe21:e067]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: eric) by mail.metricspace.net (Postfix) with ESMTPSA id 7678E1B7B for ; Fri, 16 Oct 2015 15:30:45 +0000 (UTC) To: "freebsd-hackers@freebsd.org" From: Eric McCorkle Subject: EFI/ZFS Update: successful tests, need more complex vdevs Message-ID: <56211825.3080403@metricspace.net> Date: Fri, 16 Oct 2015 11:30:45 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2015 15:30:46 -0000 Hi, I've received a few successful test reports for EFI/ZFS, on both ZFS and UFS systems. I have personally been using it for some time in a GRUB + loader.efi setup. I have a fairly minor test result for loader.efi. I have confirmed that "nextboot -k" works fine. In general, I need testing on ZFS setups with more complex vdevs (l2arc, intent logs, mirroring, striping, raidz, etc.) I myself have a new raidz pool I can use (it's running FreeBSD 10, though, so I'll need to backport the patch). I've also got some laptops coming that I can use. From owner-freebsd-hackers@freebsd.org Fri Oct 16 16:06:03 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 71655A165A6 for ; Fri, 16 Oct 2015 16:06:03 +0000 (UTC) (envelope-from feld@FreeBSD.org) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4885A1AB4 for ; Fri, 16 Oct 2015 16:06:03 +0000 (UTC) (envelope-from feld@FreeBSD.org) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 85D2B20844 for ; Fri, 16 Oct 2015 12:06:01 -0400 (EDT) Received: from web3 ([10.202.2.213]) by compute5.internal (MEProxy); Fri, 16 Oct 2015 12:06:01 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=dN7Kioy9eGQNt1l Bcysa4IkU8gY=; b=AJ6IUm/jOoxPYlVzVRMRB0Xw7nihtXOe9WCR79BnYoqXis4 AqX+T19bnmMWBuYNiBu1pMIpWnRxxhRtUDVeoAmrtCDu096LUf7atVaLdHiYhp9b qrr38d6EQRTxn5q5UML92AN9WV2VdGAOjI9tmeXoofATIjyx34n6ptg66hEs= Received: by web3.nyi.internal (Postfix, from userid 99) id 4BDBF11101C; Fri, 16 Oct 2015 12:06:01 -0400 (EDT) Message-Id: <1445011561.1233840.412174489.688C5822@webmail.messagingengine.com> X-Sasl-Enc: dSD1SdLLWDCvnSxW39Tluk1pP1Ns4PS3dhY9QYBkJwr9 1445011561 From: Mark Felder To: Cyril Vechera , dougb@FreeBSD.org, freebsd-hackers@freebsd.org, freebsd-rc@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-25d3ec43 Subject: Re: rc(8) parallel tasks Date: Fri, 16 Oct 2015 11:06:01 -0500 In-Reply-To: <560EAC05.6050308@jet9.net> References: <560EAC05.6050308@jet9.net> X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2015 16:06:03 -0000 On Fri, Oct 2, 2015, at 11:08, Cyril Vechera wrote: > Hi there. > > We've got a small launcher script (~250 loc) for parallel services > start/stop etc. It is used on our embedded systems and our users > containers. And I've done a proof of concept for implanting it to the > FreeBSD's standard /etc/rc for execution starting scripts in parallel. > It gave me a boot time reduction of rc part from 27 to 7 seconds, mostly > on eliminating jams for network or other long-latency resources waiting. > > The launcher is written in pure POSIX shell and uses FIFOs (named pipes) > as a mutexes for synchronization. So it is embedded into /etc/rc and > /etc/rc.d preserving rc.subr preloading. As a primary requirement, it > guarantees topological order (strict partial order) defined by > dependencies. It requires only POSIX shell, FreeBSD or Linux kernel, > mkfifo and a writeable file system. Due to last requirement, it can be > run on the late stage or should be supplied by some kinf of writtable > fs, ie tmpfs. The FreeBSD-integrated version uses standard rcorder > annotations (REQUIRE, BEFORE and PROVIDE) and there's no need to change > rc.d scripts > > It's not a full init replacement or a kind of services supervision tool. > It only starts or invokes a group of scripts in parallel with resolving > and assuring execution in dependencies order. > > Please take a look at the script and patch set for FreeBSD: > > https://github.com/cvss/jet9-multitask-init/blob/master/jet9-multitask-init > https://github.com/cvss/jet9-multitask-init/tree/master/examples/freebsd > > Your first link is a 404, but this looks really nice! -- Mark Felder ports-secteam member feld@FreeBSD.org From owner-freebsd-hackers@freebsd.org Fri Oct 16 18:47:27 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0BAABA17E4A; Fri, 16 Oct 2015 18:47:27 +0000 (UTC) (envelope-from cv@jet9.net) Received: from mail1.ssnab.net (mail1.ssnab.net [85.143.179.24]) by mx1.freebsd.org (Postfix) with ESMTP id 81A55795; Fri, 16 Oct 2015 18:47:25 +0000 (UTC) (envelope-from cv@jet9.net) Received: from inc.ru (localhost [127.0.0.1]) by mail1.ssnab.net (Postfix) with SMTP id E004EC0A39; Fri, 16 Oct 2015 21:37:27 +0300 (MSK) X-Antispam-passed: yes X-Antispam: yes Received: from [95.27.88.77] (account cv@serversnab.ru HELO new-cv.home) by inc.ru (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 24040011; Fri, 16 Oct 2015 21:37:27 +0300 Message-ID: <562143E7.3030104@jet9.net> Date: Fri, 16 Oct 2015 21:37:27 +0300 From: Cyril Vechera User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130330 Thunderbird/17.0.5 MIME-Version: 1.0 To: Mark Felder CC: marck@rinet.ru, freebsd-hackers@freebsd.org, freebsd-rc@freebsd.org Subject: Re: rc(8) parallel tasks References: <560EAC05.6050308@jet9.net> <1445011561.1233840.412174489.688C5822@webmail.messagingengine.com> In-Reply-To: <1445011561.1233840.412174489.688C5822@webmail.messagingengine.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 16 Oct 2015 19:13:08 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2015 18:47:27 -0000 On 10/16/2015 07:06 PM, Mark Felder wrote: > On Fri, Oct 2, 2015, at 11:08, Cyril Vechera wrote: >> Hi there. >> >> We've got a small launcher script (~250 loc) for parallel services >> start/stop etc. It is used on our embedded systems and our users >> containers. And I've done a proof of concept for implanting it to the >> FreeBSD's standard /etc/rc for execution starting scripts in parallel. >> It gave me a boot time reduction of rc part from 27 to 7 seconds, mostly >> on eliminating jams for network or other long-latency resources waiting. >> >> The launcher is written in pure POSIX shell and uses FIFOs (named pipes) >> as a mutexes for synchronization. So it is embedded into /etc/rc and >> /etc/rc.d preserving rc.subr preloading. As a primary requirement, it >> guarantees topological order (strict partial order) defined by >> dependencies. It requires only POSIX shell, FreeBSD or Linux kernel, >> mkfifo and a writeable file system. Due to last requirement, it can be >> run on the late stage or should be supplied by some kinf of writtable >> fs, ie tmpfs. The FreeBSD-integrated version uses standard rcorder >> annotations (REQUIRE, BEFORE and PROVIDE) and there's no need to change >> rc.d scripts >> >> It's not a full init replacement or a kind of services supervision tool. >> It only starts or invokes a group of scripts in parallel with resolving >> and assuring execution in dependencies order. >> >> Please take a look at the script and patch set for FreeBSD: >> >> https://github.com/cvss/jet9-multitask-init/blob/master/jet9-multitask-init >> https://github.com/cvss/jet9-multitask-init/tree/master/examples/freebsd >> >> > Your first link is a 404, but this looks really nice! In the last commit (v1.3.0) I've renamed 'jet9-multitask-init' to 'jet9-multitask-flow' to avoid confusion with naming, because it's not as it seems, from name, an init replacement, but just a parallel task launcher. And now the actual repository URL is https://github.com/cvss/jet9-multitask-flow In this commit I've complete the FreeBSD compatibility. Now a script or dependency name can include minuses `-` and dots `.` (the first stone I stumbled over was ftp-proxy). And I've cleaned up the main script code https://github.com/cvss/jet9-multitask-flow/jet9-multitask-flow and have split it to more functions that can be redefined. So it's now easier to rewrite dependency extraction for FreeBSD rc-scripts - current implementation is too rough and takes three 'awk' runs for each rc-script. The last is not only time loss, but as DMarck mentioned before, using awk restricts parallel rc to be run only after FILESYSTEMS stage is done. Maybe it would be better to add to the rcorder(8) some new option to dump the gathered dependencies in tsort-compatible listing and insert them directly to flow execution plan. I've also added rc.conf variable `rc_parallel` to turn on and off parallel execution. There's a risk to discover an incomplete dependency annotations in some rc-scripts that earlier were masked by serial execution. I've done some checks by enabling as much rc.conf variables as possible to start more rc-scripts, and didn't found any error. But it looks too good to be true and I'm afraid that it's just to poor testing. I think if some ordering conflict will be found, it could be worked-around with introducing a white-list for script names that must be run only in sequentially. So it remained first to check if it really works in different conditions. -- Cyril Vechera From owner-freebsd-hackers@freebsd.org Fri Oct 16 22:14:10 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 84DE1A16037; Fri, 16 Oct 2015 22:14:10 +0000 (UTC) (envelope-from Mark.Martinec+freebsd@ijs.si) Received: from mail.ijs.si (mail.ijs.si [IPv6:2001:1470:ff80::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2EFA5ED5; Fri, 16 Oct 2015 22:14:09 +0000 (UTC) (envelope-from Mark.Martinec+freebsd@ijs.si) Received: from amavis-ori.ijs.si (localhost [IPv6:::1]) by mail.ijs.si (Postfix) with ESMTP id 3nd1wY64LJzKm; Sat, 17 Oct 2015 00:14:05 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ijs.si; h= user-agent:message-id:references:in-reply-to:organization :subject:subject:from:from:date:date:content-transfer-encoding :content-type:content-type:mime-version:received:received :received:received; s=jakla4; t=1445033642; x=1447625643; bh=zmt pQaUSTtZbXPjXmo0pGW/UaQGoOZdU2ncQOebgH+I=; b=hgnuVkSnLhPM/pd52qZ OeCwWdHT5SMLYkvrKw3+20NDI5n0wljRlnerVsHSGfIuQUXOw9HwgEWbGThle6Ae uUA1/ZS/dNEKObEHQF3phBKnMfAyOtre4BS/j1Xq1wIdKhcWvMO7lrCV50qJFaCt n7ZNGSaKWG6DCyUIN7yLukjc= X-Virus-Scanned: amavisd-new at ijs.si Received: from mail.ijs.si ([IPv6:::1]) by amavis-ori.ijs.si (mail.ijs.si [IPv6:::1]) (amavisd-new, port 10026) with LMTP id uyPcUiMYkl6h; Sat, 17 Oct 2015 00:14:02 +0200 (CEST) Received: from mildred.ijs.si (mailbox.ijs.si [IPv6:2001:1470:ff80::143:1]) by mail.ijs.si (Postfix) with ESMTP id 3nd1wT2pw2zKl; Sat, 17 Oct 2015 00:14:01 +0200 (CEST) Received: from nabiralnik.ijs.si (nabiralnik.ijs.si [IPv6:2001:1470:ff80::80:16]) by mildred.ijs.si (Postfix) with ESMTP id 3nd1wT1Jr7zwf; Sat, 17 Oct 2015 00:14:01 +0200 (CEST) Received: from sleepy.ijs.si (2001:1470:ff80:e001::1:1) by nabiralnik.ijs.si with HTTP (HTTP/1.1 POST); Sat, 17 Oct 2015 00:14:01 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Sat, 17 Oct 2015 00:14:01 +0200 From: Mark Martinec To: freebsd-hackers@freebsd.org, freebsd-rc@freebsd.org Cc: Cyril Vechera Subject: Re: rc(8) parallel tasks Organization: Jozef Stefan Institute In-Reply-To: <562143E7.3030104@jet9.net> References: <560EAC05.6050308@jet9.net> <1445011561.1233840.412174489.688C5822@webmail.messagingengine.com> <562143E7.3030104@jet9.net> Message-ID: <2c307d32ddd8ed582ac496d56a75c3e4@mailbox.ijs.si> X-Sender: Mark.Martinec+freebsd@ijs.si User-Agent: Roundcube Webmail/1.1.3 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2015 22:14:10 -0000 Tried a today's git checkout on one of our small virtual 10.2 boxes with not many services. The installation is almost trivial and a reboot went without any problems. Time for a reboot was shrunk by about 10 seconds (which is understandable with a small number of services). Very good, almost too good to be true for such fairly small and non-intrusive piece of shell/awk scripting - thanks! Mark 2015-10-16 20:37, Cyril Vechera wrote: > On 10/16/2015 07:06 PM, Mark Felder wrote: >> On Fri, Oct 2, 2015, at 11:08, Cyril Vechera wrote: >>> Hi there. >>> >>> We've got a small launcher script (~250 loc) for parallel services >>> start/stop etc. It is used on our embedded systems and our users >>> containers. And I've done a proof of concept for implanting it to the >>> FreeBSD's standard /etc/rc for execution starting scripts in >>> parallel. >>> It gave me a boot time reduction of rc part from 27 to 7 seconds, >>> mostly >>> on eliminating jams for network or other long-latency resources >>> waiting. >>> >>> The launcher is written in pure POSIX shell and uses FIFOs (named >>> pipes) >>> as a mutexes for synchronization. So it is embedded into /etc/rc and >>> /etc/rc.d preserving rc.subr preloading. As a primary requirement, it >>> guarantees topological order (strict partial order) defined by >>> dependencies. It requires only POSIX shell, FreeBSD or Linux kernel, >>> mkfifo and a writeable file system. Due to last requirement, it can >>> be >>> run on the late stage or should be supplied by some kinf of writtable >>> fs, ie tmpfs. The FreeBSD-integrated version uses standard rcorder >>> annotations (REQUIRE, BEFORE and PROVIDE) and there's no need to >>> change >>> rc.d scripts >>> >>> It's not a full init replacement or a kind of services supervision >>> tool. >>> It only starts or invokes a group of scripts in parallel with >>> resolving >>> and assuring execution in dependencies order. >>> >>> Please take a look at the script and patch set for FreeBSD: >>> >>> https://github.com/cvss/jet9-multitask-init/blob/master/jet9-multitask-init >>> https://github.com/cvss/jet9-multitask-init/tree/master/examples/freebsd >>> >>> >> Your first link is a 404, but this looks really nice! > > In the last commit (v1.3.0) I've renamed 'jet9-multitask-init' to > 'jet9-multitask-flow' to avoid confusion with naming, because it's not > as it seems, from name, an init replacement, but just a parallel task > launcher. And now the actual repository URL is > https://github.com/cvss/jet9-multitask-flow > > In this commit I've complete the FreeBSD compatibility. Now a script > or dependency name can include minuses `-` and dots `.` (the first > stone I stumbled over was ftp-proxy). And I've cleaned up the main > script code > https://github.com/cvss/jet9-multitask-flow/jet9-multitask-flow and > have split it to more functions that can be redefined. So it's now > easier to rewrite dependency extraction for FreeBSD rc-scripts - > current implementation is too rough and takes three 'awk' runs for > each rc-script. The last is not only time loss, but as DMarck > mentioned before, using awk restricts parallel rc to be run only after > FILESYSTEMS stage is done. Maybe it would be better to add to the > rcorder(8) some new option to dump the gathered dependencies in > tsort-compatible listing and insert them directly to flow execution > plan. > > I've also added rc.conf variable `rc_parallel` to turn on and off > parallel execution. There's a risk to discover an incomplete > dependency annotations in some rc-scripts that earlier were masked by > serial execution. I've done some checks by enabling as much rc.conf > variables as possible to start more rc-scripts, and didn't found any > error. But it looks too good to be true and I'm afraid that it's just > to poor testing. I think if some ordering conflict will be found, it > could be worked-around with introducing a white-list for script names > that must be run only in sequentially. > > So it remained first to check if it really works in different > conditions. From owner-freebsd-hackers@freebsd.org Sat Oct 17 16:51:51 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CE6F2A17469 for ; Sat, 17 Oct 2015 16:51:51 +0000 (UTC) (envelope-from jmaloney@pcbsd.org) Received: from barracuda.ixsystems.com (mail.ixsystems.com [69.198.165.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.ixsystems.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AA919262 for ; Sat, 17 Oct 2015 16:51:50 +0000 (UTC) (envelope-from jmaloney@pcbsd.org) X-ASG-Debug-ID: 1445100708-08ca040e8500ac0002-P5m3U7 Received: from [10.0.1.52] (ip72-209-160-49.ks.ks.cox.net [72.209.160.49]) by barracuda.ixsystems.com with ESMTP id 9rwhUfuqU8pY9Df2 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 17 Oct 2015 09:51:49 -0700 (PDT) X-Barracuda-Envelope-From: jmaloney@pcbsd.org X-Barracuda-AUTH-User: jmaloney@pcbsd.org X-Barracuda-Apparent-Source-IP: 72.209.160.49 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\)) Subject: Re: EFI/ZFS Update: successful tests, need more complex vdevs From: Joe Maloney X-ASG-Orig-Subj: Re: EFI/ZFS Update: successful tests, need more complex vdevs In-Reply-To: <56211825.3080403@metricspace.net> Date: Sat, 17 Oct 2015 11:51:47 -0500 Cc: "freebsd-hackers@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: <21B8A793-CAC2-4A8F-9B31-BC8DA9ED29A9@pcbsd.org> References: <56211825.3080403@metricspace.net> To: Eric McCorkle X-Mailer: Apple Mail (2.3094) X-Barracuda-Connect: ip72-209-160-49.ks.ks.cox.net[72.209.160.49] X-Barracuda-Start-Time: 1445100709 X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA X-Barracuda-URL: https://10.2.0.41:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at ixsystems.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=8.0 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.23579 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Oct 2015 16:51:51 -0000 Hi Eric, PCBSD is using your patch in it=E2=80=99s latest October image, and = it=E2=80=99s working great. NextBSD has it as well. Joe Maloney > On Oct 16, 2015, at 10:30 AM, Eric McCorkle = wrote: >=20 > Hi, >=20 > I've received a few successful test reports for EFI/ZFS, on both ZFS = and UFS systems. I have personally been using it for some time in a = GRUB + loader.efi setup. >=20 > I have a fairly minor test result for loader.efi. I have confirmed = that "nextboot -k" works fine. >=20 > In general, I need testing on ZFS setups with more complex vdevs = (l2arc, intent logs, mirroring, striping, raidz, etc.) >=20 > I myself have a new raidz pool I can use (it's running FreeBSD 10, = though, so I'll need to backport the patch). I've also got some laptops = coming that I can use. > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to = "freebsd-hackers-unsubscribe@freebsd.org"