kexec has been marked experimental for a year now and all
of the serious kernel side problems have been worked through. So it
is time (if not past time) to remove the experimental mark.
---
arch/x86_64/Kconfig | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/arch/x86_64/Kconfig b/arch/x86_64/Kconfig
index 756fa38..1adba0f 100644
--- a/arch/x86_64/Kconfig
+++ b/arch/x86_64/Kconfig
@@ -481,8 +481,7 @@ config X86_MCE_AMD
the DRAM Error Threshold.
config KEXEC
- bool "kexec system call (EXPERIMENTAL)"
- depends on EXPERIMENTAL
+ bool "kexec system call"
help
kexec is a system call that implements the ability to shutdown your
current kernel, and to start another kernel. It is like a reboot
--
1.4.2.rc3.g7e18e-dirty
kexec has been marked experimental for a year now and all
of the serious problems have been worked through. So it
is time (if not past time) to remove the experimental mark.
Signed-off-by: Eric W. Biederman <[email protected]>
---
This time with a Signed-off-by line.
arch/x86_64/Kconfig | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/arch/x86_64/Kconfig b/arch/x86_64/Kconfig
index 756fa38..1adba0f 100644
--- a/arch/x86_64/Kconfig
+++ b/arch/x86_64/Kconfig
@@ -481,8 +481,7 @@ config X86_MCE_AMD
the DRAM Error Threshold.
config KEXEC
- bool "kexec system call (EXPERIMENTAL)"
- depends on EXPERIMENTAL
+ bool "kexec system call"
help
kexec is a system call that implements the ability to shutdown your
current kernel, and to start another kernel. It is like a reboot
--
1.4.2.rc3.g7e18e-dirty
On Wednesday 06 September 2006 18:55, Eric W. Biederman wrote:
>
> kexec has been marked experimental for a year now and all
> of the serious problems have been worked through. So it
> is time (if not past time) to remove the experimental mark.
>
Hmm, I personally have some doubts it is really not experimental
(not because of the kexec code itself, but because of all the other drivers
that still break)
But applied for now.
-Andi
Andi Kleen <[email protected]> writes:
> On Wednesday 06 September 2006 18:55, Eric W. Biederman wrote:
>>
>> kexec has been marked experimental for a year now and all
>> of the serious problems have been worked through. So it
>> is time (if not past time) to remove the experimental mark.
>>
>
> Hmm, I personally have some doubts it is really not experimental
> (not because of the kexec code itself, but because of all the other drivers
> that still break)
That is a reasonable viewpoint. Although by that a lot more of the kernel
deserves to be marked experimental.
On the perverse side of the sentiment taking off experimental may increase
our number of testers and get the bugs fixed faster :)
> But applied for now.
Thanks.
Eric
On Wed, 2006-09-06 at 21:22 +0200, Andi Kleen wrote:
> On Wednesday 06 September 2006 18:55, Eric W. Biederman wrote:
> >
> > kexec has been marked experimental for a year now and all
> > of the serious problems have been worked through. So it
> > is time (if not past time) to remove the experimental mark.
> >
>
> Hmm, I personally have some doubts it is really not experimental
> (not because of the kexec code itself, but because of all the other drivers
> that still break)
What drivers does kexec break?
-piet
>
> But applied for now.
>
> -Andi
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Piet Delaney Phone: (408) 200-5256
Blue Lane Technologies Fax: (408) 200-5299
10450 Bubb Rd.
Cupertino, Ca. 95014 Email: [email protected]
Piet Delaney <[email protected]> writes:
> On Wed, 2006-09-06 at 21:22 +0200, Andi Kleen wrote:
>> On Wednesday 06 September 2006 18:55, Eric W. Biederman wrote:
>> >
>> > kexec has been marked experimental for a year now and all
>> > of the serious problems have been worked through. So it
>> > is time (if not past time) to remove the experimental mark.
>> >
>>
>> Hmm, I personally have some doubts it is really not experimental
>> (not because of the kexec code itself, but because of all the other drivers
>> that still break)
>
> What drivers does kexec break?
Kexec doesn't break any drivers. kexec exposes bugs in driver initialization
handling, when drivers on not robust.
The normal kexec case should be quite simple to handle and because we cleanup
just like a reboot, the difference is that we don't ask the BIOS to reset us
first.
The kexec on panic case is painful, because drivers in the original kernel are
not stopped or shutdown, and so the secondary kernel gets to initialize drivers
from an essentially random state.
Eric
On Wed, 2006-09-06 at 14:15 -0600, Eric W. Biederman wrote:
> Andi Kleen <[email protected]> writes:
>
> > On Wednesday 06 September 2006 18:55, Eric W. Biederman wrote:
> >>
> >> kexec has been marked experimental for a year now and all
> >> of the serious problems have been worked through. So it
> >> is time (if not past time) to remove the experimental mark.
> >>
> >
> > Hmm, I personally have some doubts it is really not experimental
> > (not because of the kexec code itself, but because of all the other drivers
> > that still break)
>
> That is a reasonable viewpoint. Although by that a lot more of the kernel
> deserves to be marked experimental.
>
> On the perverse side of the sentiment taking off experimental may increase
> our number of testers and get the bugs fixed faster :)
I take it that for using kexec to boot a kdump kernel and then
rebooting the primary kernel that there are a few drivers in
the dumping kernel that wouldn't work but they aren't likely
to be used. Ie: it's "just" a hardware initialization issue
on kernels booted with kexec.
-piet
>
> > But applied for now.
>
> Thanks.
>
> Eric
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Piet Delaney Phone: (408) 200-5256
Blue Lane Technologies Fax: (408) 200-5299
10450 Bubb Rd.
Cupertino, Ca. 95014 Email: [email protected]
Piet Delaney <[email protected]> writes:
> On Wed, 2006-09-06 at 14:15 -0600, Eric W. Biederman wrote:
>> Andi Kleen <[email protected]> writes:
>>
>> > On Wednesday 06 September 2006 18:55, Eric W. Biederman wrote:
>> >>
>> >> kexec has been marked experimental for a year now and all
>> >> of the serious problems have been worked through. So it
>> >> is time (if not past time) to remove the experimental mark.
>> >>
>> >
>> > Hmm, I personally have some doubts it is really not experimental
>> > (not because of the kexec code itself, but because of all the other drivers
>> > that still break)
>>
>> That is a reasonable viewpoint. Although by that a lot more of the kernel
>> deserves to be marked experimental.
>>
>> On the perverse side of the sentiment taking off experimental may increase
>> our number of testers and get the bugs fixed faster :)
>
> I take it that for using kexec to boot a kdump kernel and then
> rebooting the primary kernel that there are a few drivers in
> the dumping kernel that wouldn't work but they aren't likely
> to be used. Ie: it's "just" a hardware initialization issue
> on kernels booted with kexec.
Yes. The only place you are likely to observe the driver
initialization problems are kernels booted with kexec. But there
are other rare scenarios that can yield challenging boot driver
initialization scenarios. I know soft booting from windows used
to be one of them.
As for the kdump kernel usually you won't load (or build in) any
drivers you don't intend to use. If the drivers actually get loaded
even if you aren't using them you could have problems.
Eric
On Thu, 2006-09-07 at 00:55 -0600, Eric W. Biederman wrote:
> Piet Delaney <[email protected]> writes:
>
> > On Wed, 2006-09-06 at 14:15 -0600, Eric W. Biederman wrote:
> >> Andi Kleen <[email protected]> writes:
> >>
> >> > On Wednesday 06 September 2006 18:55, Eric W. Biederman wrote:
> >> >>
> >> >> kexec has been marked experimental for a year now and all
> >> >> of the serious problems have been worked through. So it
> >> >> is time (if not past time) to remove the experimental mark.
> >> >>
> >> >
> >> > Hmm, I personally have some doubts it is really not experimental
> >> > (not because of the kexec code itself, but because of all the other drivers
> >> > that still break)
> >>
> >> That is a reasonable viewpoint. Although by that a lot more of the kernel
> >> deserves to be marked experimental.
> >>
> >> On the perverse side of the sentiment taking off experimental may increase
> >> our number of testers and get the bugs fixed faster :)
> >
> > I take it that for using kexec to boot a kdump kernel and then
> > rebooting the primary kernel that there are a few drivers in
> > the dumping kernel that wouldn't work but they aren't likely
> > to be used. Ie: it's "just" a hardware initialization issue
> > on kernels booted with kexec.
>
> Yes. The only place you are likely to observe the driver
> initialization problems are kernels booted with kexec. But there
> are other rare scenarios that can yield challenging boot driver
> initialization scenarios. I know soft booting from windows used
> to be one of them.
>
> As for the kdump kernel usually you won't load (or build in) any
> drivers you don't intend to use. If the drivers actually get loaded
> even if you aren't using them you could have problems.
Thanks for the tip, I'll make sure my dumping kernel only
has drivers necessary to make the kernel core file configured.
-piet
>
> Eric
--
Piet Delaney Phone: (408) 200-5256
Blue Lane Technologies Fax: (408) 200-5299
10450 Bubb Rd.
Cupertino, Ca. 95014 Email: [email protected]