From mboxrd@z Thu Jan 1 00:00:00 1970 From: "H. Peter Anvin" Subject: Re: [PATCH 0/2][concept RFC] x86: BIOS-save kernel log to disk upon panic Date: Tue, 25 Jan 2011 09:36:21 -0800 Message-ID: <4D3F0A15.2070703@zytor.com> References: <20110125134748.GA10051@laptop> <20110125140948.GA26762@elte.hu> <20110125153649.GA11386@laptop> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Return-path: Received: from terminus.zytor.com ([198.137.202.10]:59317 "EHLO mail.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752890Ab1AYRjz (ORCPT ); Tue, 25 Jan 2011 12:39:55 -0500 In-Reply-To: Sender: linux-ide-owner@vger.kernel.org List-Id: linux-ide@vger.kernel.org To: Tony Luck Cc: "Ahmed S. Darwish" , Ingo Molnar , Thomas Gleixner , Ingo Molnar , X86-ML , Dave Jones , Andrew Morton , Randy Dunlap , Willy Tarreau , Willy Tarreau , Dirk Hohndel , Dirk.Hohndel@intel.com, IDE-ML , LKML , Linus Torvalds , Peter Zijlstra , =?UTF-8?B?RnLDqWTDqXJpYyBXZWlzYmVja2Vy?= , Borislav Petkov , Arjan van de Ven On 01/25/2011 09:32 AM, Tony Luck wrote: > > Using swap space as a dump area has a long and established tradition > going back to the early roots of Unix - so I don't think that it is all that > hacky. I think that modern systems even write some magic at the start > of the swap partition that you could use to verify that you were writing to > the correct spot ... and it should be easy to retrieve your dumped data > before the swap gets re-enabled by the new kernel after the reboot. > [Perhaps the new kernel could do this automatically if it finds some > signature that your code leaves in the swap area so it could stuff the data > into my /dev/pstore filesystem?] > > One more "is this bit of the BIOS code safe" concern that I have is that > you'll be using the "write" path of the INT 0x13 code ... which isn't the > path that is tested by booting ... it *ought* to be OK - but untested paths > in BIOS seem to be broken paths all too often. > It's not just that, it's that you're going through it *after the kernel has run*. The kernel has wrecked the state of the system -- the disk hardware, the PCI hierarchy, the interrupt system -- as far as the BIOS is concerned. It is no longer safe to trust the BIOS to use your hardware, especially not for writing. So what is the solution? We have to carry our own disk driver for the emergency. In other words, we're very quickly starting to make something that looks a whole lot like kexec/kdump. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf.