Re: [PATCH 0/2][concept RFC] x86: BIOS-save kernel log to disk upon panic

From: James Bottomley <James.Bottomley@suse.de>
To: "Ahmed S. Darwish" <darwish.07@gmail.com>
Cc: "Tejun Heo" <tj@kernel.org>, "Ingo Molnar" <mingo@elte.hu>,
	"H. Peter Anvin" <hpa@zytor.com>,
	"Thomas Gleixner" <tglx@linutronix.de>,
	"Ingo Molnar" <mingo@redhat.com>, X86-ML <x86@kernel.org>,
	"Tony Luck" <tony.luck@intel.com>,
	"Dave Jones" <davej@redhat.com>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"Randy Dunlap" <rdunlap@xenotime.net>,
	"Willy Tarreau" <wtarreau@hera.kernel.org>,
	"Willy Tarreau" <w@1wt.eu>,
	"Dirk Hohndel" <hohndel@infradead.org>,
	Dirk.Hohndel@intel.com, IDE-ML <linux-ide@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	"Linus Torvalds" <torvalds@linux-foundation.org>,
	"Peter Zijlstra" <a.p.zijlstra@chello.nl>,
	"Frédéric Weisbecker" <fweisbec@gmail.com>,
	"Borislav Petkov" <bp@alien8.de>,
	"Arjan van de Ven" <arjan@infradead.org>,
	"Jeff Garzik" <jgarzik@pobox.com>
Subject: Re: [PATCH 0/2][concept RFC] x86: BIOS-save kernel log to disk upon panic
Date: Tue, 25 Jan 2011 12:20:23 -0500	[thread overview]
Message-ID: <1295976023.9693.8.camel@mulgrave.site> (raw)
In-Reply-To: <20110125170522.GA16285@laptop>

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