[PATCH] kdump: Fix for machine checkstop on DMA fault

Olof Johansson olof at lixom.net
Tue Mar 28 01:06:41 EST 2006


On Mon, Mar 27, 2006 at 04:04:58PM +1100, Michael Ellerman wrote:
> I disagree. In most cases the kdump kernel will be loaded by the boot
> scripts, so reserving TCE space then is ~= reserving it for the life of
> the first kernel. Given that TCE space is a scarce commodity I don't
> think reserving it in the first kernel is a viable option.

Well, hopefully the kdump kernel doesn't need as much table space as a
regular kernel, so the loss would be limited, but if you're willing to
do the reserve instead; that'd be better.

> What we should do is modify the second kernel so that instead of
> clearing the TCE tables it instead walks the tables and detects existing
> mappings, and then marks those as reserved so they're not overwritten.

Yep, that's exactly what my first proposal was.

> This should give us 100% safety from the second kernel reusing a mapping
> and copping a rogue DMA, and doesn't inflict any penalty on the first
> kernel. It does fall down if there's no TCE space left for a device when
> the second kernel comes up, but I think that's the best trade off.

Correct. The time it could be a disadvantage is when there's been a
driver bug that leaks mappings that causes the machine to go down (i.e.
into the kdump kernel). Whatever device has been leaking might not be
usable since the table will be 100% full.


-Olof



More information about the Linuxppc-dev mailing list