Date: Tue, 6 May 2003 08:33:58 -0700
From: Andrew Morton <akpm@digeo.com>
To: Steven Cole <elenstev@mesatop.com>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, ebiederm@xmission.com
Subject: Re: 2.5.69-mm1
Message-Id: <20030506083358.348edb4d.akpm@digeo.com>
In-Reply-To: <1052231590.2166.141.camel@spc9.esa.lanl.gov>
References: <20030504231650.75881288.akpm@digeo.com>
	<1052231590.2166.141.camel@spc9.esa.lanl.gov>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1038
Lines: 25

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 ;)


-
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/