On Sun, 2003-05-11 at 17:26, Eric W. Biederman wrote:
> This is my next round of kexec inspired kernel patches.
>
> kexec seems good at reproducing what are otherwise almost
> inaccessible corner cases in the kernel reboot/initialization code paths.
>
> Also available at:
> http://www.xmission.com/~ebiederm/files/kexec/
Eric,
Good news: I have tried your patchset on a 2-way system, and kexec
worked.
Mixed news: I didn't get any console output after the last printk in
kexec ("Starting new kernel"), nor did I get any console output during
the reboot. Other than that, the system rebooted fine and went
multi-user (complete with graphical login and networking). Strange.
I've got two other systems to test this on, and I'll report when I have
results. I have attached my .config and lspci output for the system I
used.
I have also loaded your patch set into OSDL's on-line patch manager.
The patch stack I used can be found here:
APIC changes:
http://www.osdl.org/cgi-bin/plm?module=patch_info&patch_id=1842
i8259 changes:
http://www.osdl.org/cgi-bin/plm?module=patch_info&patch_id=1843
reboot on BSP:
http://www.osdl.org/cgi-bin/plm?module=patch_info&patch_id=1844
hwfixes & x86kexec:
http://www.osdl.org/cgi-bin/plm?module=patch_info&patch_id=1845
For the lazy among us, I have also uploaded a combined patch for 2.5.69
that includes the four previous patches in one:
http://www.osdl.org/cgi-bin/plm?module=patch_info&patch_id=1846
Regards,
Andy
Andy Pfiffer <[email protected]> writes:
> On Sun, 2003-05-11 at 17:26, Eric W. Biederman wrote:
> > This is my next round of kexec inspired kernel patches.
> >
> > kexec seems good at reproducing what are otherwise almost
> > inaccessible corner cases in the kernel reboot/initialization code paths.
> >
> > Also available at:
> > http://www.xmission.com/~ebiederm/files/kexec/
>
> Eric,
>
> Good news: I have tried your patchset on a 2-way system, and kexec
> worked.
>
> Mixed news: I didn't get any console output after the last printk in
> kexec ("Starting new kernel"), nor did I get any console output during
> the reboot. Other than that, the system rebooted fine and went
> multi-user (complete with graphical login and networking). Strange.
Very strange as nothing fundamental changed.
The only thing I did was inline use_mm into kexec piece. And
to make the cpu shutdown code safe from an interrupt context.
> I've got two other systems to test this on, and I'll report when I have
> results. I have attached my .config and lspci output for the system I
> used.
>
> I have also loaded your patch set into OSDL's on-line patch manager.
> The patch stack I used can be found here:
>
> APIC changes:
> http://www.osdl.org/cgi-bin/plm?module=patch_info&patch_id=1842
>
> i8259 changes:
> http://www.osdl.org/cgi-bin/plm?module=patch_info&patch_id=1843
>
> reboot on BSP:
> http://www.osdl.org/cgi-bin/plm?module=patch_info&patch_id=1844
>
> hwfixes & x86kexec:
> http://www.osdl.org/cgi-bin/plm?module=patch_info&patch_id=1845
>
> For the lazy among us, I have also uploaded a combined patch for 2.5.69
> that includes the four previous patches in one:
> http://www.osdl.org/cgi-bin/plm?module=patch_info&patch_id=1846
And Andrew has it in 2.5.69-mm4 and is busy pestering me about compile
errors. There needs to be an updated version where all of the
appropriate functions have the noreturn attribute. Hopefully
I can do a thorough job this weekend, and create some updated patches.
Eric
[email protected] (Eric W. Biederman) wrote:
>
> And Andrew has it in 2.5.69-mm4 and is busy pestering me about compile
> errors.
I'm like that.
I've dropped out a lot of the NORET stuff. It generates warnings on all
other architectures, because their machine_restart, machine_halt and
machine_power_off definitions don't have necessary attributes and don't
have the while(1); at the end.
Andrew Morton <[email protected]> writes:
> [email protected] (Eric W. Biederman) wrote:
> >
> > And Andrew has it in 2.5.69-mm4 and is busy pestering me about compile
> > errors.
>
> I'm like that.
And I appreciate it. This was mostly an observation there was
something reminding me to get back and fix the issue.
> I've dropped out a lot of the NORET stuff. It generates warnings on all
> other architectures, because their machine_restart, machine_halt and
> machine_power_off definitions don't have necessary attributes and don't
> have the while(1); at the end.
Yes there is a big const correctness type problem here.
First for machine_restart it is 100% correct. And at least sys_reboot
assumes that machine_restart will not return, even before my patch.
And I don't know of a case where it makes sense for machine_halt and
machine_power_off to return. Hence I deliberately made those cases
the same. Especially as every real implementation I traced does not
return. It is only the stupid cases like on x86 where we don't do
anything that these routines actually return.
In the context of my patch stop_this_cpu needs to be marked noreturn.
As long as the fundamental routines get marked I don't expect to see
a lot of routines getting a while(1); I admit stop_apics also
needs a while(1); but only because gcc cannot trace it.
And since this also generates warnings on other architectures
it looks like someone (me) needs to go through the various
architectures and add a bunch of noreturn attributes to
the appropriate functions.
The basic question is for documenting and enforcing the noreturn
dependency. Is it more of a help or a hindrance to use gcc noreturn
tag?
And while I am pretty certain this is the correct thing to do I
should break this out from the reboot_on_bsp patch. With the
other architectures involved this is enough of a separate issue that a
second set of patches is needed to maintain this cleanly.
Eric
Von Andy Pfiffer:
> Mixed news: I didn't get any console output after the last printk in
> kexec ("Starting new kernel"), nor did I get any console output during
> the reboot. Other than that, the system rebooted fine and went
> multi-user (complete with graphical login and networking). Strange.
Same problem here, config attached.
Machine is a K6-233, 128 MB RAM, 440T(?)X board, Award BIOS.
Eike
[email protected] (Eric W. Biederman) wrote:
>
> Is it more of a help or a hindrance to use gcc noreturn
> tag?
It seems to be a significant hassle - it propagates all over the place and
makes one curse. It's like retroconstification, as you say.
I'd be inclined to leave the function prototypes as-is and stick a
commented while(1); in those places which actually need it, frankly.