On Fri, Apr 07, 2006 at 07:54:08PM +0200, Takashi Iwai wrote: > 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? >
Yes. I can't think of anything else other than 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? I think currently x86_64 kernel does not boot if compiled for memory 48M or beyond. I think till 32M it works find. I have not looked into the code in great detail but I remember seeing something that code assumes that kernel code is in first 40MB of memory. -vivek
_______________________________________________ fastboot mailing list [email protected] https://lists.osdl.org/mailman/listinfo/fastboot
