resource map" already. Otherwise, you will need to change the
kernel for this to work.
Chandru, thanks for coding this up.
Bob Montgomery
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
AM between
the GART and the ACPI Tables. So that all looks good.
Then the next LOAD is also at 2400 with a 0 in the size fields.
I haven't had a chance to check the code yet.
Bob Montgomery
___
kexec mailing list
kexec@lists.infradead.org
http:/
in the kexec'd
kdump kernel. By disabling the CPU-side accesses within the GART, which
does persist through the kexec of the kdump kernel, the kdump kernel is
prevented from interacting with the GART during accesses to the dump
memory areas which include the address range of the GART apertu
On Tue, 2008-09-23 at 02:29 +, Eric W. Biederman wrote:
> Bob Montgomery <[EMAIL PROTECTED]> writes:
> > And that leads to the Kdump IO Rule:
> >
> > The primary kernel is responsible for setting up any necessary
> > conditions to allow the kdu
h kernel area. Kdump IOs will go to IO
buffers allocated by the kdump kernel, remapped by the Intel
IOMMU to those same addresses (iova equals physical address
within the Crash kernel area).
This all assumes no virtual machine stuff
On Fri, 2008-09-05 at 15:12 +, Vivek Goyal wrote:
> Nice summary Bob. Few thoughts.
>
> - So until and unless one is reserving memory for crashkernel above 4G,
> there is no need for initializing the IOMMU in second kernel (At this
> moment I am not too worried about need of isolation in seco
nd I don't need any IOMMU address translation
capability.
If the original kernel had been using swiotlb, then there's really no
issue, because any leftover DMAs are just writing to the old bounce
buffers anyway, and there's no driver left waiting to call
dma_unmap_single to copy
GartIO */
>
> This is an interesting one. When I looked at this years ago I had the
> feeling that if we did this we could actually always use a 2G Aperture
> at a fixed address, and require going through the gart for all of lowmem.
During discussi
On Tue, 2008-07-08 at 13:28 +, Vivek Goyal wrote:
> On Mon, Jul 07, 2008 at 05:08:06PM -0600, Bob Montgomery wrote:
> > We maintain a 2.6.18 derived kernel.
> > When testing kdump on a new AMD Family 10h (16) processor, once in the
> > kdump kernel, a read from either
mp
kernels, but I wonder if it would have prevented access to that memory
area by having it be excluded from the /proc/vmcore list of areas??
Thanks for any insights,
Bob Montgomery
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
10 matches
Mail list logo
