Messages in this thread | | | Subject | Re: [Fastboot] Re: Announce: dumpfs v0.01 - common RAS output API | From | (Eric W. Biederman) | Date | 28 Jul 2004 19:56:47 -0600 |
| |
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/
| |