From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753133Ab1AYRUd (ORCPT ); Tue, 25 Jan 2011 12:20:33 -0500 Received: from cantor2.suse.de ([195.135.220.15]:58272 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751571Ab1AYRUc (ORCPT ); Tue, 25 Jan 2011 12:20:32 -0500 Subject: Re: [PATCH 0/2][concept RFC] x86: BIOS-save kernel log to disk upon panic From: James Bottomley To: "Ahmed S. Darwish" Cc: Tejun Heo , Ingo Molnar , "H. Peter Anvin" , Thomas Gleixner , Ingo Molnar , X86-ML , Tony Luck , Dave Jones , Andrew Morton , Randy Dunlap , Willy Tarreau , Willy Tarreau , Dirk Hohndel , Dirk.Hohndel@intel.com, IDE-ML , LKML , Linus Torvalds , Peter Zijlstra , =?ISO-8859-1?Q?Fr=E9d=E9ric?= Weisbecker , Borislav Petkov , Arjan van de Ven , Jeff Garzik In-Reply-To: <20110125170522.GA16285@laptop> References: <20110125134748.GA10051@laptop> <20110125140948.GA26762@elte.hu> <20110125153649.GA11386@laptop> <1295971355.4955.104.camel@mulgrave.site> <20110125170522.GA16285@laptop> Content-Type: text/plain; charset="UTF-8" Date: Tue, 25 Jan 2011 12:20:23 -0500 Message-ID: <1295976023.9693.8.camel@mulgrave.site> Mime-Version: 1.0 X-Mailer: Evolution 2.30.1.2 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 2011-01-25 at 19:05 +0200, Ahmed S. Darwish wrote: > Hi! > > On Tue, Jan 25, 2011 at 11:02:35AM -0500, James Bottomley wrote: > > On Tue, 2011-01-25 at 17:36 +0200, Ahmed S. Darwish wrote: > > > The complete __roadblock__ I'm currently facing though is restoring the disk > > > controllers to the state originally setup by the BIOS Power-on self-test (POST). > > > I hope such re-initialization is even technically feasible. > > > > > > Without such re-initialization, we'll just be risking the BIOS code exploding. > > > That was the case in the 5-minute hang described in the cover sheet (PATCH #0). > > > > So this is the bit that's not really technically feasible. BIOS tends > > to run storage devices in a very primitive way (so it takes basic > > settings, for example and sets the device up for one particular channel > > of access). When preparing the device for an operating system, we have > > to blow away all the bios stuff and put it into a more generally > > performant mode (this isn't just the storage per se, it's also the > > interrupt and routing). Unfortunately, currently, we don't bother to > > save the settings the BIOS was using, so there's no way to reinitialise > > the device back to bios without an effective reboot. > > > > My current x86 laptop includes the very common ATA PIIX controller. If I > dumped the PIC, IOAPIC, and disk controller state in a register file in a > safe area, and re-initialized these before giving control to the BIOS, can > this move the solution space from being not really technically feasible to > "quite possible"? So I'm sure it would be possible to reverse engineer and make work a solution for a given motherboard, ATA controller and BIOS ... but because you have to go all the way up the root of the PCI tree and into the interrupt controllers to do this, I don't really think it would ever be a usable generic solutions. I'd really look at the problem another way: Rather than trying to figure out how to put a storage subsystem back into bios, if we had a driver that never took a given device out of BIOS configuration, as in ran it through the suboptimal bios interface in-kernel, it would be ready to use the bios interface to dump with. The problem is that no-one wants that for their main disk ... however, it would be less of a problem if we dedicated, say, a USB controller and stick to this. James