Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1161139AbWHJSSy (ORCPT ); Thu, 10 Aug 2006 14:18:54 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1161149AbWHJSSy (ORCPT ); Thu, 10 Aug 2006 14:18:54 -0400 Received: from e5.ny.us.ibm.com ([32.97.182.145]:48549 "EHLO e5.ny.us.ibm.com") by vger.kernel.org with ESMTP id S1161139AbWHJSSx (ORCPT ); Thu, 10 Aug 2006 14:18:53 -0400 Date: Thu, 10 Aug 2006 14:18:25 -0400 From: Vivek Goyal To: "Eric W. Biederman" Cc: Don Zickus , fastboot@osdl.org, Horms , Jan Kratochvil , "H. Peter Anvin" , Magnus Damm , linux-kernel@vger.kernel.org Subject: Re: [Fastboot] [CFT] ELF Relocatable x86 and x86_64 bzImages Message-ID: <20060810181825.GD14732@in.ibm.com> Reply-To: vgoyal@in.ibm.com References: <20060804234327.GF16231@redhat.com> <20060807174439.GJ16231@redhat.com> <20060807235727.GM16231@redhat.com> <20060809200642.GD7861@redhat.com> <20060810131323.GB9888@in.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.11 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2246 Lines: 51 On Thu, Aug 10, 2006 at 11:05:22AM -0600, Eric W. Biederman wrote: > Vivek Goyal writes: > > > Apart from this I think something is still off on x86_64. I have not > > been able to make kdump work on x86_64. Second kernel simply hangs. > > Two different machines are showing different results. > > > > - On one machine, it seems to be stuck somewhere in decompress_kernel(). > > Serial console is not behaving properly even with earlyprintk(). Somehow > > I feel it is some bss corruption even after my changes. > > > > - Other machines seems to be going till start_kernel() and even after > > that (No messages on the console, all serial debugging) and then > > either it hangs or jumps back to BIOS. > > > > Will look more into it. > > Thanks. > > I'm a little disappointed but at this point it isn't a great surprise, > the code is early yet and hasn't had much testing or attention. > I wonder if I have missed something else silly. > > As for testing, can you use plain kexec to load the kernel at a > different address? I'm curious to know if it is something related > to the kexec on panic path or if it is just running at a different > location that is the problem. Yes. This seems to be minor stuff. Parameter segment seems to be getting stomped while I am doing decompression. Most probably should be coming from extra space calculations (32K etc) being done at run time to find out where should we shift the compressed image. Kexec works because parameter segment is being loaded below the compressed image and doest not get stomped over. :-) I just reserved memory at non 2MB aligned location 65MB@15MB so that kernel is loaded at 16MB and other smaller segments below the compressed image, then I can successfully booted into the kdump kernel. So basically kexec on panic path seems to be clean except stomping issue. May be bzImage program header should reflect right "MemSize" which takes into account extra memory space calculations. Thanks Vivek - 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/