reboot.c and X86-64 architectures

reboot.c and X86-64 architectures

[Miles Fidelman]

Hello Folks,

Perhaps someone here can help me understand the behavior of the kernel reboot code.

I've recently migrated from running a 32bit kernel to a 64bit one
(specifically Debian Lenny 32bit environment to 2.6.32-5-xen-amd64 on
top of xen-4.0-amd64 hypervisor build).

This is a somewhat older, and apparently quirky, hardware box.  I've
found that the only way to reboot it, short of power cycling, is jumping
through the bios - using the "reboot=bios" kernel option at boot time
works just fine for an X86_32 kernel.  But... this doesn't work with the
64bit kernel.

Pouring through both the documentation and the code for
arch/x86/kernel/reboot.c yields the very specific admonition (in comments
describing command-line kernel options), that reboot=bios (Reboot by jumping
through the BIOS) only applies to X86_32 - and the case statements in the
code seem to align with the comment.

None of the other available command line options seem to work with my
hardware, which leads to two questions:

1. What's the logic behind this?  Why not enable a bios reboot for 64bit
kernels?  Anybody know the history?

2. Anybody know a workaround, short of patching and compiling a custom
kernel? Are there other paths through the reboot code that can invoke a bios
reboot?  (Note: None of the available command line options seem to work on
this particular box/bios combination, and kexec-reboot is not available
for this combination of kernel and hypervisor).

Thank you very much,

Miles Fidelman

-- 
In theory, there is no difference between theory and practice.
In practice, there is.   .... Yogi Berra

reboot.c and X86-64 architectures

[Jim Cromie]

On Tue, Apr 3, 2012 at 9:22 PM, Miles Fidelman
<mfidelman@meetinghouse.net> wrote:
>
> Hello Folks,
>
> Perhaps someone here can help me understand the behavior of the kernel reboot code.
>
> I've recently migrated from running a 32bit kernel to a 64bit one
> (specifically Debian Lenny 32bit environment to 2.6.32-5-xen-amd64 on
> top of xen-4.0-amd64 hypervisor build).
>
> This is a somewhat older, and apparently quirky, hardware box. ?I've
> found that the only way to reboot it, short of power cycling, is jumping
> through the bios - using the "reboot=bios" kernel option at boot time
> works just fine for an X86_32 kernel. ?But... this doesn't work with the
> 64bit kernel.
>
> Pouring through both the documentation and the code for
> arch/x86/kernel/reboot.c yields the very specific admonition (in comments
> describing command-line kernel options), that reboot=bios (Reboot by jumping
> through the BIOS) only applies to X86_32 - and the case statements in the
> code seem to align with the comment.
>
> None of the other available command line options seem to work with my
> hardware, which leads to two questions:
>
> 1. What's the logic behind this? ?Why not enable a bios reboot for 64bit
> kernels? ?Anybody know the history?
>
> 2. Anybody know a workaround, short of patching and compiling a custom
> kernel? Are there other paths through the reboot code that can invoke a bios
> reboot? ?(Note: None of the available command line options seem to work on
> this particular box/bios combination, and kexec-reboot is not available
> for this combination of kernel and hypervisor).
>

perhaps you should try a non-hypervisor kernel.
I have no experience with one, but it could be the issue.
Virtualization developers tend to have big fast modern boxes,
and as you say, yours isnt so modern.

It might be worth a bug report if it appears to be hypervisor related,
but you are on an old kernel too.  Is Lenny current, or is it Sarge ?
maybe a debian upgrade is easier than a current (3.3) kernel build,
but latter is pretty easy.


> Thank you very much,
>
> Miles Fidelman
>
> --
> In theory, there is no difference between theory and practice.
> In practice, there is. ? .... Yogi Berra
>
>
>
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

reboot.c and X86-64 architectures

[Miles Fidelman]

Jim Cromie wrote:
> On Tue, Apr 3, 2012 at 9:22 PM, Miles Fidelman
> <mfidelman@meetinghouse.net>  wrote:
>> Hello Folks,
>>
>> Perhaps someone here can help me understand the behavior of the kernel reboot code.
>>
>> I've recently migrated from running a 32bit kernel to a 64bit one
>> (specifically Debian Lenny 32bit environment to 2.6.32-5-xen-amd64 on
>> top of xen-4.0-amd64 hypervisor build).
>>
>> This is a somewhat older, and apparently quirky, hardware box.  I've
>> found that the only way to reboot it, short of power cycling, is jumping
>> through the bios - using the "reboot=bios" kernel option at boot time
>> works just fine for an X86_32 kernel.  But... this doesn't work with the
>> 64bit kernel.
>>
>> Pouring through both the documentation and the code for
>> arch/x86/kernel/reboot.c yields the very specific admonition (in comments
>> describing command-line kernel options), that reboot=bios (Reboot by jumping
>> through the BIOS) only applies to X86_32 - and the case statements in the
>> code seem to align with the comment.
>>
>> None of the other available command line options seem to work with my
>> hardware, which leads to two questions:
>>
>> 1. What's the logic behind this?  Why not enable a bios reboot for 64bit
>> kernels?  Anybody know the history?
>>
>> 2. Anybody know a workaround, short of patching and compiling a custom
>> kernel? Are there other paths through the reboot code that can invoke a bios
>> reboot?  (Note: None of the available command line options seem to work on
>> this particular box/bios combination, and kexec-reboot is not available
>> for this combination of kernel and hypervisor).
>>
> perhaps you should try a non-hypervisor kernel.
> I have no experience with one, but it could be the issue.
> Virtualization developers tend to have big fast modern boxes,
> and as you say, yours isnt so modern.

It's not related to the hypervisor - I've tried.

It's related specifically to the quirks of this particular machine/bios 
combination.  At this point, it's more an itch I'm trying to scratch, 
this is a sandbox machine under my desk, not one of our production boxes 
- it's easy enough to shutdown then hit the power button.

But... it really raises the question:  Why does the reboot.c code only 
support reboot=bios (switch to real mode, set up a few memory locations, 
jump into the bios) for X86_32, and not for X86_64.  The hardware and 
bios don't change when loading a 64-bit kernel, or am I missing something?

SOMEBODY wrote that code.  SOMEBODY should know the logic.  But... I've 
drawn a blank so far.

Miles Fidelman



-- 
In theory, there is no difference between theory and practice.
In practice, there is.   .... Yogi Berra

reboot.c and X86-64 architectures

[Srivatsa S. Bhat]

On 04/04/2012 07:18 PM, Miles Fidelman wrote:

> Jim Cromie wrote:
>> On Tue, Apr 3, 2012 at 9:22 PM, Miles Fidelman
>> <mfidelman@meetinghouse.net>  wrote:
>>> Hello Folks,
>>>
>>> Perhaps someone here can help me understand the behavior of the kernel reboot code.
>>>
>>> I've recently migrated from running a 32bit kernel to a 64bit one
>>> (specifically Debian Lenny 32bit environment to 2.6.32-5-xen-amd64 on
>>> top of xen-4.0-amd64 hypervisor build).
>>>
>>> This is a somewhat older, and apparently quirky, hardware box.  I've
>>> found that the only way to reboot it, short of power cycling, is jumping
>>> through the bios - using the "reboot=bios" kernel option at boot time
>>> works just fine for an X86_32 kernel.  But... this doesn't work with the
>>> 64bit kernel.
>>>
>>> Pouring through both the documentation and the code for
>>> arch/x86/kernel/reboot.c yields the very specific admonition (in comments
>>> describing command-line kernel options), that reboot=bios (Reboot by jumping
>>> through the BIOS) only applies to X86_32 - and the case statements in the
>>> code seem to align with the comment.
>>>
>>> None of the other available command line options seem to work with my
>>> hardware, which leads to two questions:
>>>
>>> 1. What's the logic behind this?  Why not enable a bios reboot for 64bit
>>> kernels?  Anybody know the history?
>>>
>>> 2. Anybody know a workaround, short of patching and compiling a custom
>>> kernel? Are there other paths through the reboot code that can invoke a bios
>>> reboot?  (Note: None of the available command line options seem to work on
>>> this particular box/bios combination, and kexec-reboot is not available
>>> for this combination of kernel and hypervisor).
>>>
>> perhaps you should try a non-hypervisor kernel.
>> I have no experience with one, but it could be the issue.
>> Virtualization developers tend to have big fast modern boxes,
>> and as you say, yours isnt so modern.
> 
> It's not related to the hypervisor - I've tried.
> 
> It's related specifically to the quirks of this particular machine/bios 
> combination.  At this point, it's more an itch I'm trying to scratch, 
> this is a sandbox machine under my desk, not one of our production boxes 
> - it's easy enough to shutdown then hit the power button.
> 
> But... it really raises the question:  Why does the reboot.c code only 
> support reboot=bios (switch to real mode, set up a few memory locations, 
> jump into the bios) for X86_32, and not for X86_64.  The hardware and 
> bios don't change when loading a 64-bit kernel, or am I missing something?
> 
> SOMEBODY wrote that code.  SOMEBODY should know the logic.  But... I've 
> drawn a blank so far.
> 


I suggest you post this issue on lkml, with CC to the authors/maintainers
of the code, which would be the following list, as per get_maintainer.pl:

Thomas Gleixner <tglx@linutronix.de>
Ingo Molnar <mingo@redhat.com>
"H. Peter Anvin" <hpa@zytor.com>
x86 at kernel.org
Peter Chubb <peter.chubb@nicta.com.au>
Michael D Labriola <michael.d.labriola@gmail.com>
Matthew Garrett <mjg@redhat.com>
linux-kernel at vger.kernel.org

 
Regards,
Srivatsa S. Bhat

reboot.c and X86-64 architectures

[Miles Fidelman]

Srivatsa,

Thanks very much.  Two follow-up questions, if I might...

Srivatsa S. Bhat wrote:
> On 04/04/2012 07:18 PM, Miles Fidelman wrote:
>>
>> Perhaps someone here can help me understand the behavior of the kernel reboot code.
>>
>
> I suggest you post this issue on lkml, with CC to the authors/maintainers
> of the code, which would be the following list, as per get_maintainer.pl:
>
> Thomas Gleixner<tglx@linutronix.de>
> Ingo Molnar<mingo@redhat.com>
> "H. Peter Anvin"<hpa@zytor.com>
> x86 at kernel.org
> Peter Chubb<peter.chubb@nicta.com.au>
> Michael D Labriola<michael.d.labriola@gmail.com>
> Matthew Garrett<mjg@redhat.com>
> linux-kernel at vger.kernel.org

I posted this to linux-kernel a few days ago, and didn't receive any 
replies.  Or is lkml a different list?

And... what is get_maintainer.pl?  Or perhaps where does it run is a 
more accurate question, what it does is pretty obvious from the name :-)

Thanks again,

Miles Fidelman


-- 
In theory, there is no difference between theory and practice.
In practice, there is.   .... Yogi Berra

reboot.c and X86-64 architectures

[Srivatsa S. Bhat]

On 04/05/2012 06:28 PM, Miles Fidelman wrote:

> Srivatsa,
> 
> Thanks very much.  Two follow-up questions, if I might...
> 


Sure!

> Srivatsa S. Bhat wrote:
>> On 04/04/2012 07:18 PM, Miles Fidelman wrote:
>>>
>>> Perhaps someone here can help me understand the behavior of the
>>> kernel reboot code.
>>>
>>
>> I suggest you post this issue on lkml, with CC to the authors/maintainers
>> of the code, which would be the following list, as per get_maintainer.pl:
>>
>> Thomas Gleixner<tglx@linutronix.de>
>> Ingo Molnar<mingo@redhat.com>
>> "H. Peter Anvin"<hpa@zytor.com>
>> x86 at kernel.org
>> Peter Chubb<peter.chubb@nicta.com.au>
>> Michael D Labriola<michael.d.labriola@gmail.com>
>> Matthew Garrett<mjg@redhat.com>
>> linux-kernel at vger.kernel.org
> 
> I posted this to linux-kernel a few days ago, and didn't receive any
> replies.  Or is lkml a different list?
>


Possibly because the right people might not have noticed the issue.
Or maybe they are quite busy at the moment... It is reasonable to wait for
a week before trying again.

If you don't get any replies by a week, try reposting the issue with a more
appropriate subject. (After all, people skim emails by their subject lines ;-)).
Seriously speaking, you are facing a problem, so it would probably be better
to rewrite the subject like a bug/problem report than just a question.

Also add enough relevant info in the subject itself (without cluttering
it of course), to get interested people to read your email. (Look at some of
the other bug reports that float around lkml to see how to do it.)

> And... what is get_maintainer.pl?  Or perhaps where does it run is a
> more accurate question, what it does is pretty obvious from the name :-)
> 


get_maintainer.pl is a script in the scripts/ directory in the kernel source.
Usually, when submitting patches, we run this script from the root of the kernel
source tree. It gives the  list of maintainers or kernel developers who have
contributed most to the code, who are relevant to the patch in question.
Then the patch is mailed to these people and the appropriate mailing lists.

Eg: $cd linux
    $./scripts/get_maintainer.pl <patch_file>

To get the kernel developers associated with a particular file instead of a
patch, use the --file option.

$cd linux
$./scripts/get_maintainer.pl --file arch/x86/kernel/reboot*

[This is the output I posted in my previous mail :-)]
 
Regards,
Srivatsa S. Bhat