To: Andrew Morton <akpm@digeo.com>
Cc: Steven Cole <elenstev@mesatop.com>, linux-kernel@vger.kernel.org,
       linux-mm@kvack.org
Subject: Re: 2.5.69-mm1
References: <20030504231650.75881288.akpm@digeo.com>
	<1052231590.2166.141.camel@spc9.esa.lanl.gov>
	<20030506083358.348edb4d.akpm@digeo.com>
From: ebiederm@xmission.com (Eric W. Biederman)
Date: 06 May 2003 09:36:38 -0600
In-Reply-To: <20030506083358.348edb4d.akpm@digeo.com>
Message-ID: <m17k949jeh.fsf@frodo.biederman.org>
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
Content-Length: 1249
Lines: 25

Andrew Morton <akpm@digeo.com> writes:

> Steven Cole <elenstev@mesatop.com> wrote:
> >
> > I have one machine for testing which is running X, and a kexec reboot
> >  glitches the video system when initiated from runlevel 5.  Kexec works fine
> >  from runlevel 3.
> 
> Yes, there are a lot of driver issues with kexec.  Device drivers will assume
> that the hardware is in the state which the BIOS left behind.
> 
> In this case, the Linus device driver's shutdown functions are obviously not
> leaving the card in a pristine state.  A lot of drivers _do_ do this
> correctly.  But some don't.
> 
> It seems that kexec is really supposed to be invoked from run level 1.  ie:
> you run all your system's shutdown scripts before switching.  If you'd done
> that then you wouldn't have been running X and all would be well.
> 
> do-kexec.sh is for the very impatient ;)

The biggest issue with kexec when you are in X is that nothing
tells X to shutdown.  So you have to at least shutdown X manually.

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/