That is not what I'm suggesting. I wish I knew a better way
to put myself in your shoes and explain this from your context
without repeating myself.
I'm not talking about DMA'ing into a fixed region and copying
into user address.
There is just this (say) 4MB area that the current kernel thinks
is reserved/already allocated. When the recovery kernel comes up
it thinks its booted with just this 4MB of memory, quickly performs
the writeout of the dump to disk (which in the case of lkcd
happens straight from the kernel, _unlike_ MCL which needs
filesystems mounted and drives this from user space), and
then reboots itself the normal way (i.e. not via kexec).
So while the recovery kernel is running in a very constrained
way, it is not _meant_ to be dealing with user-space workloads
etc - just a disk writeout and a prompt reboot.
And there is no need to change drivers, buffer mgmt etc in any
of this. There is no explicit limitation on where to or not to
DMA from.
It is simply what Eric was suggesting, minus the need to build
the recovery kernel to be able to run from different physical
addresses.
That's about all !
Does this make things any clearer ?
> You might as well add the quiesce
> function, it's probably easier to do.
Yes if that can be done for all drivers, well and good.
> And it doesn't help if you DMA to static memory
> addresses.
Again I'm not suggesting we DMA into static memory addresses.
Quite the reverse actually.
The point was that this scheme wouldn't help in the cases where
DMA is happening to static memory addresses.
>
> I, too, would like a simpler solution. I just don't think
this is it.
This wasn't even intended to be a full solution as Eric
has already observed.
I think we must quiesce the devices. Just that for the
cases that this isn't happening yet, we are a little
better off than having nothing all all.
Regards
Suparna
-- Suparna Bhattacharya (suparna@in.ibm.com) Linux Technology Center IBM Software Labs, India- 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/