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?
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
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 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 deeper
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
for the
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 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
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
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
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
> 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,
> 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
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
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 instable or
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
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, routinely
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 was
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 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, 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:
warning:
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 *desktops* use
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
like
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, since
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
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
30 matches
Mail list logo
