All of lore.kernel.org
 help / color / mirror / Atom feed
From: Robert Millan <rmh@aybabtu.com>
To: The development of GRUB 2 <grub-devel@gnu.org>
Subject: Re: [PATCH] Enable grub_cpu_idle for i386 to halt the CPU
Date: Tue, 12 Aug 2008 11:10:37 +0200	[thread overview]
Message-ID: <20080812091037.GC381@thorin> (raw)
In-Reply-To: <20080812030708.GB16592@spacedout.fries.net>

On Mon, Aug 11, 2008 at 10:07:08PM -0500, David Fries wrote:
> Enable grub_cpu_idle for i386 to halt the CPU and modify the menu code
> to make use of it.  This will save power when booting.
> Or maybe I should say it will keep the CPU from running so hot when
> the timer is counting down.
> 
> It isn't safe to call halt in protected mode as interrupts are
> disabled.  I assume it is becaus the interrupts handlers aren't setup
> to work in protected mode.  But interrupts are enabled in real mode,
> and the timer is running, so the only two things of interest in the
> menu countdown is time has elapsed or a key is pressed, which both
> produce interrupts and are checked.  I assume any other call to
> grub_cpu_idle will have an interrupt or the timer to wake it up.
> 
> As grub_cpu_idle is exported instead of inline, some of the utility
> programs failed to compile because the symbol wasn't defined.  I
> created util/user-stub.c for common stub functions instead of adding
> it to multiple utility program source files.


Hi David,

I'm sorry that you already went on to provide a patch, but the problem is
not that.

The problem is that on some platforms (like coreboot), the firmware won't
setup any IDT for us, and so we need to do this ourselves before we use hlt.

So the solution is to initialize the IDT (so that we won't get a cpu fault),
and enable IRQ0 (so that hlt won't stall).

Would you be willing to provide a patch that does that?

> +void
> +grub_cpu_idle ()
> +{
> +  struct timespec req={0,1};
> +  nanosleep (&req, NULL);
> +}

grub_cpu_idle is intended to be a (cpu-independant) primitive, not a stub for
nanosleep.

We already have code for sleeping, but it doesn't put the CPU to rest, these
are two different things.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."



  reply	other threads:[~2008-08-12  9:12 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-08-12  3:07 [PATCH] Enable grub_cpu_idle for i386 to halt the CPU David Fries
2008-08-12  9:10 ` Robert Millan [this message]
2008-08-12 10:47   ` Robert Millan
2008-08-16  3:11   ` David Fries
2008-08-16 12:33     ` Robert Millan
2008-08-16 14:44       ` David Fries
2008-08-17 15:04         ` Robert Millan
2008-08-13  9:34 ` Marco Gerards

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=20080812091037.GC381@thorin \
    --to=rmh@aybabtu.com \
    --cc=grub-devel@gnu.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.