lkml.org 
[lkml]   [2004]   [Jul]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [Fastboot] Re: Announce: dumpfs v0.01 - common RAS output API
From
Date
Andrew Morton <akpm@osdl.org> writes:

> ebiederm@xmission.com (Eric W. Biederman) wrote:
> >
> > Andrew Morton <akpm@osdl.org> writes:
>
> OK. But some (most) of them will sleep, too. And we shouldn't sleep in a
> dead kernel.

Probably not. And that is legitimate...

> > I agree. However the gymnastics for doing that have not been worked out.
> > The drivers cannot clean up stuff yet, nor do we have a good way to run
> > in memory where DMA transfers on not ongoing.
>
> Don't we? The 16M of memory was allocated up-front at kexec load time[*],
> so nobody will be pointing DMA hardware at it. And the dump kernel won't
> be pointing DMA hardware at the crashed kernel's pages.

No but we will be running in the first 16M of memory. The 16M that
is allocated is currently used to hold a copy of the low 16M.

> > So for a first pass I think calling the shutdown methods make sense.
>
> Well. There aren't any.

Which makes them both safe and worthless. On the normal kexec path
they we will need to get them written though.

> > But the first pass is worth it (at least in the kexec tree) to sort out all
> > of the interface issues and catch the low hanging fruit.
>
> A significant proportion of kernel crashes happen from [soft]irq context,
> from which we cannot call shutdown methods. So we need to be able to bring
> up the dump kernel without having run driver shutdown functions anwyay..

Well if calling shutdown is not really usable, then I we had better
transition quickly beyond using it...

> [*] At least, I _assume_ the 16MB will be prereserved,
> physically-contiguous and wholly within ZONE_NORMAL. Is this wrong?

The problem is that we really won't be using it for running code out
of because of i386 kernel limitations. Unless someone can tell
my why 0 -16MB won't have DMA traffic in them. Or how to run a kernel
at an address other than 1MB.

I suspect we can play with the initial page tables and how virtual
addresses map to physical addresses and fairly simply generate a
relocatable kernel. I have not had a chance to investigate that
though. Once we have that it will be trivial to run out of the
reserved 16M and many of the practical problems melt away.

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

\
 
 \ /
  Last update: 2005-03-22 14:04    [W:0.104 / U:0.240 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site