Date: Fri, 16 Nov 2012 00:56:28 -0800 (PST) From: "white.heron white" <white.heron@yahoo.com> To: "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org> Subject: Build and Release automation with Perl. Message-ID: <1353056188.15906.YahooMailNeo@web110712.mail.gq1.yahoo.com>
next in thread | raw e-mail | index | archive | help
Dear All,=0A=0AI am keen to know if you have any guideline for Build and Re= lease Automation with Perl Language.=0AI am interested to drill down furthe= r to explore this field. Kindly advised. Thanks.=0A=A0=0ARegards,=0A=0A=0AM= T TAJUDIN From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 16 12:30:15 2012 Return-Path: <owner-freebsd-hackers@FreeBSD.ORG> Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 32922614; Fri, 16 Nov 2012 12:30:15 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id 70E5B8FC12; Fri, 16 Nov 2012 12:30:13 +0000 (UTC) Received: by mail-lb0-f182.google.com with SMTP id gg13so2644434lbb.13 for <multiple recipients>; Fri, 16 Nov 2012 04:30:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=x6pkarpIu2txHyeISNTYtEBC+DnhdRw5xk3vxEBjZxM=; b=RfIIjb5KwUdlvGlI3O55P7+AVJm9b10Lvx4OsPMORCkXhf9DZG1FnPFzK/XsxYfc/7 1HVtg/Zm6+dne31XPKhBptCtWJW7Ddt3luXnuFSVVJ6XN5fmKnBS4vH9jU3nvNrhJKTn BQDqSVn/vD6N/UkFaD5WcQs1tdvu1lqbsy/PR05/4MFlZr+M6JsIEv5hOCtaTeS7OvdA 89Gp5A/YjVWsN+1vhsMeEDvcB8MdDjwfyNGqsBDEn4pIgUC0oB9o9IyEcXxxAyX3F0Gh PSq/GT3mC29lUXQMcuK+JrUw/GdoKGOrZ3MAUQvnJghb7U1ez1x/SuFSdFXpgvzjM4uL d9/Q== MIME-Version: 1.0 Received: by 10.152.132.3 with SMTP id oq3mr4072246lab.18.1353069013097; Fri, 16 Nov 2012 04:30:13 -0800 (PST) Sender: asmrookie@gmail.com Received: by 10.112.134.5 with HTTP; Fri, 16 Nov 2012 04:30:12 -0800 (PST) In-Reply-To: <50A5F12C.1050902@FreeBSD.org> References: <CAFMmRNwb_rxYXHGtXgtcyVUJnFDx5PSeMmA_crBbeV_rtzL9Cg@mail.gmail.com> <50A5F12C.1050902@FreeBSD.org> Date: Fri, 16 Nov 2012 12:30:12 +0000 X-Google-Sender-Auth: M9DuE0VU4l0D4k-H-XsHXG100Lo Message-ID: <CAJ-FndAB+7KRAE91L9634eXgzqgrizwtwCBC7AAg+0EX89TEBQ@mail.gmail.com> Subject: Re: stop_cpus_hard when multiple CPUs are panicking from an NMI From: Attilio Rao <attilio@freebsd.org> To: Andriy Gapon <avg@freebsd.org> Content-Type: text/plain; charset=UTF-8 Cc: freebsd-hackers@freebsd.org, Ryan Stone <rysto32@gmail.com> X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: attilio@FreeBSD.org List-Id: Technical Discussions relating to FreeBSD <freebsd-hackers.freebsd.org> List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-hackers>, <mailto:freebsd-hackers-request@freebsd.org?subject=unsubscribe> List-Archive: <http://lists.freebsd.org/pipermail/freebsd-hackers>; List-Post: <mailto:freebsd-hackers@freebsd.org> List-Help: <mailto:freebsd-hackers-request@freebsd.org?subject=help> List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-hackers>, <mailto:freebsd-hackers-request@freebsd.org?subject=subscribe> X-List-Received-Date: Fri, 16 Nov 2012 12:30:15 -0000 On Fri, Nov 16, 2012 at 7:54 AM, Andriy Gapon <avg@freebsd.org> wrote: > on 16/11/2012 00:58 Ryan Stone said the following: >> At work we have some custom watchdog hardware that sends an NMI upon >> expiry. We've modified the kernel to panic when it receives the watchdog >> NMI. I've been trying the "stop_scheduler_on_panic" mode, and I've >> discovered that when my watchdog expires, the system gets completely >> wedged. After some digging, I've discovered is that I have multiple CPUs >> getting the watchdog NMI and trying to panic concurrently. One of the CPUs >> wins, and the rest spin forever in this code: >> >> /* >> * We don't want multiple CPU's to panic at the same time, so we >> * use panic_cpu as a simple spinlock. We have to keep checking >> * panic_cpu if we are spinning in case the panic on the first >> * CPU is canceled. >> */ >> if (panic_cpu != PCPU_GET(cpuid)) >> while (atomic_cmpset_int(&panic_cpu, NOCPU, >> PCPU_GET(cpuid)) == 0) >> while (panic_cpu != NOCPU) >> ; /* nothing */ >> >> The system wedges when stop_cpus_hard() is called, which sends NMIs to all >> of the other CPUs and waits for them to acknowledge that they are stopped >> before returning. However the CPU will not deliver an NMI to a CPU that is >> already handling an NMI, so the other CPUs that got a watchdog NMI and are >> spinning will never go into the NMI handler and acknowledge that they are >> stopped. > > I thought about this issue and fixed (in my tree) in a different way: > http://people.freebsd.org/~avg/cpu_stop-race.diff > > The need for spinlock_enter in the patch in not entirely clear. > The main idea is that a CPU which calls cpu_stop and loses a race should > voluntary enter cpustop_handler. > I am also not sure about MI-cleanness of this patch. It is similar to what I propose but with some differences: - It is not clean from MI perspective - I don't think we need to treact it specially, I would just unconditionally stop all the CPUs entering in the "spinlock zone", making the patch simpler. So I guess you are really fine with the proposal I made? Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1353056188.15906.YahooMailNeo>