Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 12 Apr 2002 14:06:39 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 12 Apr 2002 14:06:39 -0400 Received: from ebiederm.dsl.xmission.com ([166.70.28.69]:36163 "EHLO frodo.biederman.org") by vger.kernel.org with ESMTP id ; Fri, 12 Apr 2002 14:06:38 -0400 To: suparna@in.ibm.com Cc: "Martin J. Bligh" , linux-kernel@vger.kernel.org Subject: Re: Faster reboots (and a better way of taking crashdumps?) In-Reply-To: <1759496962.1018114339@[10.10.2.3]> <3CB1A9A8.1155722E@in.ibm.com> <20020409205636.A1234@in.ibm.com> <20020411192649.A1947@in.ibm.com> <20020412201950.A1443@in.ibm.com> From: ebiederm@xmission.com (Eric W. Biederman) Date: 12 Apr 2002 11:59:35 -0600 Message-ID: Lines: 49 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Suparna Bhattacharya writes: > OK. The crash with bootimg implementation was known to have occasional > difficulties when boot got triggered (via panic) while in X -- sometimes > having the console messed up, and on some occasions even hangs. > How's been your experience - no problems in kexec'ing from X, > anytime ? So far I haven't tried it from X. Most of my test machines don't have video. When working on a good machine you should be able to return the video to the state you got it. I'm not quite certain how to handle the crash dump case. > That would be machine_kexec, and the kimage struct, right ? > So far looks ok, though I haven't looked at it critically. One thing that > that I require was a way to pass information across boots - > maybe that could be done through command line parameters to the new > kernel. A command line work work. You can arbitrary segments so you can pass anything that is needed from the user space side. > > Version 2.0 is an early beta. Some idiot yanked EM_486 and a couple > > of other symbols out of elf.h from glibc. Despite the ELF spec says > > EM_486 at least should be there. In any case that is just a debugging > > bit and you can safely disable those. Or do a make -k and compile the > > kexec piece, but not the kparam, which isn't really relevant. > > I commented out the EM_486 check from the kexec code, and it built > cleanly. I was able to boot a 2-way system with it, though it seemed > to take a while, perhaps more so because I didn't seem to be getting > any of the bootup/startup messages on my console. In one case there were > some INIT respawning messages that came up. Not sure the fact that > I'm using a serial console matters. A serial console is my usual test case, so that shouldn't affect anything. I'm glad that it worked. For the speed difference my hunch is perhaps you didn't specify your normal kernel command line on the command line. Usually I do something like: kexec bzImage root=xxx console=ttyS0,9600 blah, blah, blah. Mostly kexec is supposed to be the simple test client instead of a full fledged interface. Eric - 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/