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

[James Bottomley]

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


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/