* reboot.c and X86-64 architectures [not found] <4F79E6BE.4030302@meetinghouse.net> @ 2012-04-04 3:22 ` Miles Fidelman 2012-04-04 13:34 ` Jim Cromie 0 siblings, 1 reply; 6+ messages in thread From: Miles Fidelman @ 2012-04-04 3:22 UTC (permalink / raw) To: kernelnewbies 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* reboot.c and X86-64 architectures 2012-04-04 3:22 ` reboot.c and X86-64 architectures Miles Fidelman @ 2012-04-04 13:34 ` Jim Cromie 2012-04-04 13:48 ` Miles Fidelman 0 siblings, 1 reply; 6+ messages in thread From: Jim Cromie @ 2012-04-04 13:34 UTC (permalink / raw) To: kernelnewbies 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* reboot.c and X86-64 architectures 2012-04-04 13:34 ` Jim Cromie @ 2012-04-04 13:48 ` Miles Fidelman 2012-04-05 5:54 ` Srivatsa S. Bhat 0 siblings, 1 reply; 6+ messages in thread From: Miles Fidelman @ 2012-04-04 13:48 UTC (permalink / raw) To: kernelnewbies 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* reboot.c and X86-64 architectures 2012-04-04 13:48 ` Miles Fidelman @ 2012-04-05 5:54 ` Srivatsa S. Bhat 2012-04-05 12:58 ` Miles Fidelman 0 siblings, 1 reply; 6+ messages in thread From: Srivatsa S. Bhat @ 2012-04-05 5:54 UTC (permalink / raw) To: kernelnewbies 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* reboot.c and X86-64 architectures 2012-04-05 5:54 ` Srivatsa S. Bhat @ 2012-04-05 12:58 ` Miles Fidelman 2012-04-05 13:28 ` Srivatsa S. Bhat 0 siblings, 1 reply; 6+ messages in thread From: Miles Fidelman @ 2012-04-05 12:58 UTC (permalink / raw) To: kernelnewbies 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* reboot.c and X86-64 architectures 2012-04-05 12:58 ` Miles Fidelman @ 2012-04-05 13:28 ` Srivatsa S. Bhat 0 siblings, 0 replies; 6+ messages in thread From: Srivatsa S. Bhat @ 2012-04-05 13:28 UTC (permalink / raw) To: kernelnewbies 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2012-04-05 13:28 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <4F79E6BE.4030302@meetinghouse.net>
2012-04-04 3:22 ` reboot.c and X86-64 architectures Miles Fidelman
2012-04-04 13:34 ` Jim Cromie
2012-04-04 13:48 ` Miles Fidelman
2012-04-05 5:54 ` Srivatsa S. Bhat
2012-04-05 12:58 ` Miles Fidelman
2012-04-05 13:28 ` Srivatsa S. Bhat
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).