At Fri, 7 Apr 2006 13:24:21 -0400, Vivek Goyal wrote: > > On Wed, Apr 05, 2006 at 09:28:18PM +0200, Takashi Iwai wrote: > > Hi, > > > > I've got a bug report of SLES10-beta about non-working kdump on > > a x86-64 machine. It seems because of the ACPI tables overlapping the > > default [EMAIL PROTECTED] crash region: > > > > % cat /proc/iomem > > .... > > 0100000-0266ffff : System RAM > > 00100000-002d32a3 : Kernel code > > 002d32a4-003ac0f7 : Kernel data > > 02670000-026d5fff : ACPI Tables > > 026d6000-026fffff : ACPI Non-volatile Storage > > 02700000-efffffff : System RAM > > ... > > > > > That's interesting. I always assumed that 16MB to 80MB can be safely > reserved. Generally I have seen that ACPI tables are mapped at high > addresses.
Yeah, there is always an exception :) > > The crash region itself can be changed via boot option to another > > offset. But kexec refuses to load since the address doesn't match > > with the pre-built kdump kernel using PHYS_START=16M. > > Here is another reason for having relocatable kernel. So, no general solution except for a kernel rebuild? BTW, I tried [EMAIL PROTECTED] with a x86-64 kdump kernel using PHYS_START=48M on my test machine (that has a normal APCI table localtion). It didn't work by some reason, just rebooted. Any clue? > > What would be a workaround for such a problem? > > It seems that the ACPI location cannot be changed easily, and we don't > > want to rebuild a kernel as much as possible just for a single > > case... > > Roughly first 3.7 MB is being used by first kernel's code and data. You > can try resrving memory from 5MB to 38MB ([EMAIL PROTECTED]) and see > if second kernel is able to boot in 32MB of memory. Kexec should still be > able to load the second kernel as 16MB is within reserved region. That sounds feasible. I'll ask them to give it a try. Thanks! Takashi
_______________________________________________ fastboot mailing list [email protected] https://lists.osdl.org/mailman/listinfo/fastboot
