grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Enable grub_cpu_idle for i386 to halt the CPU


From: Robert Millan
Subject: Re: [PATCH] Enable grub_cpu_idle for i386 to halt the CPU
Date: Tue, 12 Aug 2008 11:10:37 +0200
User-agent: Mutt/1.5.13 (2006-08-11)

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 via email to

[Prev in Thread] Current Thread [Next in Thread]