From: srivatsa.bhat@linux.vnet.ibm.com (Srivatsa S. Bhat)
To: kernelnewbies@lists.kernelnewbies.org
Subject: reboot.c and X86-64 architectures
Date: Thu, 05 Apr 2012 11:24:59 +0530 [thread overview]
Message-ID: <4F7D33B3.6010505@linux.vnet.ibm.com> (raw)
In-Reply-To: <4F7C5134.6040801@meetinghouse.net>
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
next prev parent reply other threads:[~2012-04-05 5:54 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <S1753510Ab2DBRUx/20120402172053Z+301@vger.kernel.org>
2012-04-02 17:49 ` QUESTION: reboot.c and X86-64 architectures Miles Fidelman
2012-04-04 3:22 ` Miles Fidelman
2012-04-04 13:34 ` Jim Cromie
2012-04-04 13:48 ` Miles Fidelman
2012-04-05 5:54 ` Srivatsa S. Bhat [this message]
2012-04-05 12:58 ` Miles Fidelman
2012-04-05 13:28 ` Srivatsa S. Bhat
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4F7D33B3.6010505@linux.vnet.ibm.com \
--to=srivatsa.bhat@linux.vnet.ibm.com \
--cc=kernelnewbies@lists.kernelnewbies.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.