On Mon, 2005-08-08 at 14:01 +0200, Andi Kleen wrote:
> > Some BIOSes do not lock SMM, and you *could* turn it off at the chipset
> > level.
>
> Doing so would be wasteful though. Both AMD and Intel CPUs need SMM code
> for the deeper C* sleep states.
>
Wouldn't it be useful for !CONFIG_PM? Many
On Mon, Aug 08, 2005 at 09:47:54AM -0700, Tim Hockin wrote:
> On Mon, Aug 08, 2005 at 02:01:25PM +0200, Andi Kleen wrote:
> > > Some BIOSes do not lock SMM, and you *could* turn it off at the chipset
> > > level.
> >
> > Doing so would be wasteful though. Both AMD and Intel CPUs need SMM code
> >
On Mon, Aug 08, 2005 at 02:01:25PM +0200, Andi Kleen wrote:
> > Some BIOSes do not lock SMM, and you *could* turn it off at the chipset
> > level.
>
> Doing so would be wasteful though. Both AMD and Intel CPUs need SMM code
> for the deeper C* sleep states.
Really? I'm not too familiar with the
> Some BIOSes do not lock SMM, and you *could* turn it off at the chipset
> level.
Doing so would be wasteful though. Both AMD and Intel CPUs need SMM code
for the deeper C* sleep states.
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [
On Sun, Aug 07, 2005 at 02:51:19PM -0400, Lee Revell wrote:
> > It's most likely bad SMM code in the BIOS that blocks the CPU too long
> > and is triggered in idle. You can verify that by using idle=poll
> > (not recommended for production, just for testing) and see if it goes away.
> >
>
> WTF,
On Sun, Aug 07, 2005 at 02:46:50PM -0400, Erick Turnquist wrote:
> > Some BIOSes do not lock SMM, and you *could* turn it off at the chipset
> > level.
>
> I don't see anything about SMM in my BIOS configuration even with the
> advanced options enabled... Turning it off at the chipset level sounds
On Sun, 7 Aug 2005, Lee Revell wrote:
> > It's most likely bad SMM code in the BIOS that blocks the CPU too long
> > and is triggered in idle. You can verify that by using idle=poll
> > (not recommended for production, just for testing) and see if it goes away.
> >
>
> WTF, since when do *deskto
On Sun, 2005-08-07 at 13:36 +0200, Andi Kleen wrote:
> Erick Turnquist <[EMAIL PROTECTED]> writes:
>
> > Hi, I'm running an Athlon64 X2 4400+ (a dual core model) with an
> > nVidia GeForce 6800 Ultra on a Gigabyte GA-K8NXP-SLI motherboard and
> > getting nasty messages like these in my dmesg:
> >
> Some BIOSes do not lock SMM, and you *could* turn it off at the chipset
> level.
I don't see anything about SMM in my BIOS configuration even with the
advanced options enabled... Turning it off at the chipset level sounds
like a hardware hack - is it?
The gettimeofday patch for 2.6.13-rc3 won't
On Sun, Aug 07, 2005 at 01:36:01PM +0200, Andi Kleen wrote:
> Erick Turnquist <[EMAIL PROTECTED]> writes:
>
> > Hi, I'm running an Athlon64 X2 4400+ (a dual core model) with an
> > nVidia GeForce 6800 Ultra on a Gigabyte GA-K8NXP-SLI motherboard and
> > getting nasty messages like these in my dmes
> It's most likely bad SMM code in the BIOS that blocks the CPU too long
> and is triggered in idle.
Might a BIOS flash help, or is this something that's there to stay?
> No way to fix this, but you can work around it with very new kernels
> by compiling with a lower HZ than 1000.
Actually, it
On Sun, Aug 07, 2005 at 02:29:16PM +, Parag Warudkar wrote:
> > No way to fix this, but you can work around it with very new kernels
> > by compiling with a lower HZ than 1000.
>
> John Stultz's timeofday patches seem to fix this lost ticks issue. You might
> want to try them.
>
> (I too, r
> No way to fix this, but you can work around it with very new kernels
> by compiling with a lower HZ than 1000.
John Stultz's timeofday patches seem to fix this lost ticks issue. You might
want to try them.
(I too, routinely get "lost ticks - rip is at acpi_processor_idle" messages
which vani
Erick Turnquist <[EMAIL PROTECTED]> writes:
> Hi, I'm running an Athlon64 X2 4400+ (a dual core model) with an
> nVidia GeForce 6800 Ultra on a Gigabyte GA-K8NXP-SLI motherboard and
> getting nasty messages like these in my dmesg:
>
> warning: many lost ticks.
> Your time source seems to be insta
Hi, I'm running an Athlon64 X2 4400+ (a dual core model) with an
nVidia GeForce 6800 Ultra on a Gigabyte GA-K8NXP-SLI motherboard and
getting nasty messages like these in my dmesg:
warning: many lost ticks.
Your time source seems to be instable or some driver is hogging interupts
rip default_idle+
15 matches
Mail list logo
