From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 11 21:05:55 2013 Return-Path: <owner-freebsd-hackers@FreeBSD.ORG> Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 11CD778B; Thu, 11 Jul 2013 21:05:55 +0000 (UTC) (envelope-from artemb@gmail.com) Received: from mail-vb0-x233.google.com (mail-vb0-x233.google.com [IPv6:2607:f8b0:400c:c02::233]) by mx1.freebsd.org (Postfix) with ESMTP id B3E021615; Thu, 11 Jul 2013 21:05:54 +0000 (UTC) Received: by mail-vb0-f51.google.com with SMTP id x17so972156vbf.10 for <multiple recipients>; Thu, 11 Jul 2013 14:05:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=6DJDIHcM4e+E+/ldB0EKEZdKpy6sbN3lbYxzYjRxIBQ=; b=FynDpLjnB8QzTL3Q7rt4Olhz7dbg65Pox4et4kt0iYYfTyZsuBTUeMXnmmO1fTHp+h EJkFWk37qlm0W4L4LVlwW4z7d1weDYcPm6bZr3XhqmBTdNjDAFgvFBzQImz4cNxzdX6q FsMe4vGdVg9tTEitQtp+nCZTcrqq2egBDRF/mAl1hNwxkd5xFTl2+H4BgWdEjmC/p0CN 1tfJQ1JpEQqYUSAF0AExSdvH8Av/FbJUY2NDul8iCrTTuTsJGpY+pN4KKvqITcY27+wY rbUN2Kh94FcHZromGU5Hpv+WViQdMeNIHVPEbkEw1FDl9pnNuu3XHuwxvTOzV+19Bwoa J+tg== MIME-Version: 1.0 X-Received: by 10.58.109.5 with SMTP id ho5mr23114592veb.10.1373576754201; Thu, 11 Jul 2013 14:05:54 -0700 (PDT) Sender: artemb@gmail.com Received: by 10.221.41.6 with HTTP; Thu, 11 Jul 2013 14:05:54 -0700 (PDT) In-Reply-To: <EC032F13-AF97-4A1D-8772-02EF92613DA7@turbofuzz.com> References: <FDEEB55D-823B-4899-8EEC-7F5306D91F5B@elischer.org> <9890DFF1-892A-4DCA-9E33-B70681154F43@mail.turbofuzz.com> <4F0DFAB7-D6D5-4068-A543-C9DF885D1A7D@dragondata.com> <51DEC0E8.7010305@freebsd.org> <EC032F13-AF97-4A1D-8772-02EF92613DA7@turbofuzz.com> Date: Thu, 11 Jul 2013 14:05:54 -0700 X-Google-Sender-Auth: 6ymocqv92c92wVSetc9aLt1d6GM Message-ID: <CAFqOu6j299gbsWh22fTnbKZUFZBVuwwV6M5bcJdH+m+CWDin9g@mail.gmail.com> Subject: Re: Kernel dumps [was Re: possible changes from Panzura] From: Artem Belevich <art@freebsd.org> To: "Jordan K. Hubbard" <jordan.hubbard@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: hackers@freebsd.org, Kevin Day <toasty@dragondata.com> X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list 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: Thu, 11 Jul 2013 21:05:55 -0000 On Thu, Jul 11, 2013 at 12:52 PM, Jordan K. Hubbard < jordan.hubbard@gmail.com> wrote: > > On Jul 11, 2013, at 7:27 AM, Julian Elischer <julian@freebsd.org> wrote: > > > I could imagine that we could stash away a vimage stack just for this > purpose. > > yould set it up on boot and leave it detached until you need it. > > > > you just need to switch the interfaces over to the new stack on panic > and put them into 'poll' mode. > > That sounds like a rather clever solution to this problem (OS X doesn't > support vimage, despite repeated attempts on my part to change that). > > It would probably work for most of the crashes, but will not work in few interesting classes of failure. Using in-kernel stack implicitly assumes that your memory allocator still works as both the stack and the interface driver will need to get their mbufs and other data somewhere. Alas it's those unusual cases that are hardest to debug and where you really do want debugger or coredump to work. Back at my previous work we did it 'embedded system way'. Interface driver provided dumb functions to re-init device, send a frame and poll for received frame. All that without using system malloc. There was a dumb malloc that gave few chunks of memory from static buffer to gzip, but the rest of the code was independent of any kernel facilities. We had simple ARP/IP/UDP/TFTP(+gzip) implementation to upload compressed image of physical memory to a specified server. Overall it worked pretty well. Considering that this approach pretty much puts core dump outside of kernel, I wonder if we could start some sort of reverse BTX loader on crash. Instead of downloading the kernel it would upload the core. This way we should be able to produce the core in a fairly generic way on any system where we can use PXE for network I/O. The idea may be a non-starter as I have no clue whether it's possible to use PXE once kernel had booted and took control of NIC hardware. --Artem