From owner-freebsd-current@FreeBSD.ORG Sun Feb 28 21:20:50 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 77116106566B; Sun, 28 Feb 2010 21:20:50 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-iw0-f191.google.com (mail-iw0-f191.google.com [209.85.223.191]) by mx1.freebsd.org (Postfix) with ESMTP id 2DB898FC0A; Sun, 28 Feb 2010 21:20:49 +0000 (UTC) Received: by iwn29 with SMTP id 29so1131496iwn.27 for ; Sun, 28 Feb 2010 13:20:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=lockZp6nWrO3mhBj1OEvZqzxZDw0sNboD/Oc4B9PYeQ=; b=HpSMw9B4XuxOAumPJrL41PAj+CKpfyvnD6NMCCj/wvX20/XAob526NYlpocps6Rv+Z /nCFCq6+CmyXXnkmt9orQhMccpKnFL1bK/FER5XEb5P1g0kcNpKTW2hP7GuUTs3mgTwl mYQp5KFa9ENKijPxWcuoItbdwdqMZwDvPC1oA= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=OySWWGdq1SQDgssWrjIvxNHjVN0j7VA+Kln5TtnJTdpl10bFturkNH1uVYcL7acaMT /O5n/ddB0nd7V/t+UWOyxWIEOLSOzKNckUib7ooNcvhnBce7sJ22Cl1Mwa9NNXl8PzCb noBxh+XHHfeUl0E/ffVudFAfMu5Qib68oizLU= MIME-Version: 1.0 Sender: asmrookie@gmail.com Received: by 10.231.156.205 with SMTP id y13mr281593ibw.27.1267392046374; Sun, 28 Feb 2010 13:20:46 -0800 (PST) In-Reply-To: References: Date: Sun, 28 Feb 2010 22:20:46 +0100 X-Google-Sender-Auth: feaa5dea36cd527b Message-ID: <3bbf2fe11002281320l3bb91c1t6865666672565530@mail.gmail.com> From: Attilio Rao To: Andrew Brampton Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: minidump fails on SMP machines X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Feb 2010 21:20:50 -0000 2010/2/28 Andrew Brampton : > Hello, > > When many interrupts are firing on my amd64 SMP machine, and a panic > occurs, dump will fail with the error "Attempt to write outside dump > device boundaries". This problem has been discussed before[1][2], and > I even filled a PR about it last year[3]. > > From what I understand the reason this occurs is because interrupts > are not disabled on all cores during the dump. There was even a TODO > comment about this in kern_shutdown.c > =C2=A0414 =C2=A0 =C2=A0 =C2=A0 =C2=A0/* XXX This doesn't disable interrup= ts any more. =C2=A0Reconsider? */ > =C2=A0415 =C2=A0 =C2=A0 =C2=A0 =C2=A0splhigh(); > > However, looking at my FreeBSD 8.0 and HEAD source, these two lines > were removed by commit r196198 by attilio. Now that commit seems to > deal with disabling interrupts on other cores, but perhaps not > specifically to fix this bug. So my question is, should this dump bug > now be fixed? Or should the XXX comment been left in? Or is the dump > bug caused by something else? I would appreciate this problem being > fixed, as it causes me a lot of headaches when trying to debug my > kernel module :(. So, I didn't look in big detail to your problem, but specifically, spinlock_enter() just disable the interrupts on the machine it runs on. If you want to handle also the APs case you need to install an IPI or maybe you can do this with a rendezvous points. Said that, please also note that the place where spinlock_enter() is called now is too late wrt dumping -- I assume physical dump to happen far earlier than the spinlock_exit(). Thanks, Attilio --=20 Peace can only be achieved by understanding - A. Einstein