Mike Houston wrote:
On Sun, 9 Dec 2007 23:42:15 +0100
Jean Delvare <[EMAIL PROTECTED]> wrote:
On Sun, 09 Dec 2007 16:12:25 -0500, Elvis Pranskevichus wrote:
This indeed looks like a broken ACPI BIOS since the
aforementioned commit touches only the PNP ACPI driver. I'm not
sure
Mike Houston wrote:
On Sun, 9 Dec 2007 23:42:15 +0100
Jean Delvare [EMAIL PROTECTED] wrote:
On Sun, 09 Dec 2007 16:12:25 -0500, Elvis Pranskevichus wrote:
This indeed looks like a broken ACPI BIOS since the
aforementioned commit touches only the PNP ACPI driver. I'm not
sure how
Ed Sweetman wrote:
Robert Hancock wrote:
Ed Sweetman wrote:
System is idle now, previously it was doing something i couldn't
halt at the time. I'm looking at "Local timer interrupts" in the
"Loc:" section of /proc/interrupts.
Across 1 second while the system is pretty mu
Robert Hancock wrote:
Ed Sweetman wrote:
System is idle now, previously it was doing something i couldn't halt
at the time. I'm looking at "Local timer interrupts" in the "Loc:"
section of /proc/interrupts.
Across 1 second while the system is pretty much idle, i still get
System is idle now, previously it was doing something i couldn't halt at
the time.
I'm looking at "Local timer interrupts" in the "Loc:" section of
/proc/interrupts.
Across 1 second while the system is pretty much idle, i still get 300
interrupts. My HZ variable is set to 300 in the kernel
Ed Sweetman wrote:
Robert Hancock wrote:
Ed Sweetman wrote:
System is idle now, previously it was doing something i couldn't
halt at the time. I'm looking at Local timer interrupts in the
Loc: section of /proc/interrupts.
Across 1 second while the system is pretty much idle, i still get
300
Robert Hancock wrote:
Ed Sweetman wrote:
System is idle now, previously it was doing something i couldn't halt
at the time. I'm looking at Local timer interrupts in the Loc:
section of /proc/interrupts.
Across 1 second while the system is pretty much idle, i still get 300
interrupts. My HZ
System is idle now, previously it was doing something i couldn't halt at
the time.
I'm looking at Local timer interrupts in the Loc: section of
/proc/interrupts.
Across 1 second while the system is pretty much idle, i still get 300
interrupts. My HZ variable is set to 300 in the kernel
I would think that they are compatible. I'm using 2.6.24-rc4-mm1 and I
dont get any output in dmesg regarding dynamic ticks being in use via
the pmtmr like in old posts i've seen online. I was wondering if this
output has been removed or if there is another way to determine if
dynticks are
I would think that they are compatible. I'm using 2.6.24-rc4-mm1 and I
dont get any output in dmesg regarding dynamic ticks being in use via
the pmtmr like in old posts i've seen online. I was wondering if this
output has been removed or if there is another way to determine if
dynticks are
the previous post i keep referring you to has a patch that was mangled
...here is the non-mangled version
--- ./linux-backup/arch/x86_64/kernel/cpufreq/Kconfig 2007-02-04
13:44:54.0 -0500
+++ ./linux-2.6.21-rc5-mm2/arch/x86_64/kernel/cpufreq/Kconfig
2007-05-17 18:13:07.0
Joshua Hoblitt wrote:
I think it's pretty clear that Dave and Daniel were both correct and
that ACPI_PROCESSOR is the correct dependency for multi-socket systems.
However, it's worth noting that this dependency seems to be unrelated to
SMP support. Ed Sweetman has reported that his single
Dave Jones wrote:
On Thu, May 17, 2007 at 05:40:31PM -0400, Ed Sweetman wrote:
> Here's a patch
(please inline patches so they can be quoted in replies).
having this as a tristate makes no sense, that code can't be modular.
Also, there's a gratuitous whitespace change, and the default sho
Ed Sweetman wrote:
Dave Jones wrote:
On Thu, May 17, 2007 at 02:13:42PM -0400, Len Brown wrote:
> > Index: linux/arch/i386/kernel/cpu/cpufreq/Kconfig
> > ===
> > --- linux.orig/arch/i386/kernel/c
Dave Jones wrote:
On Thu, May 17, 2007 at 02:13:42PM -0400, Len Brown wrote:
> > Index: linux/arch/i386/kernel/cpu/cpufreq/Kconfig
> > ===
> > --- linux.orig/arch/i386/kernel/cpu/cpufreq/Kconfig
> > +++
Pavel Machek wrote:
Hi!
powernow-k8 uses PSB BIOS tables to read frequency info on UP systems, but
on SMP it requires the acpi-processor driver. Kconfig should be updated
accordingly to avoid the issues that users are running into.
http://bugzilla.kernel.org/show_bug.cgi?id=8075
Pavel Machek wrote:
Hi!
powernow-k8 uses PSB BIOS tables to read frequency info on UP systems, but
on SMP it requires the acpi-processor driver. Kconfig should be updated
accordingly to avoid the issues that users are running into.
http://bugzilla.kernel.org/show_bug.cgi?id=8075
Dave Jones wrote:
On Thu, May 17, 2007 at 02:13:42PM -0400, Len Brown wrote:
Index: linux/arch/i386/kernel/cpu/cpufreq/Kconfig
===
--- linux.orig/arch/i386/kernel/cpu/cpufreq/Kconfig
+++
Ed Sweetman wrote:
Dave Jones wrote:
On Thu, May 17, 2007 at 02:13:42PM -0400, Len Brown wrote:
Index: linux/arch/i386/kernel/cpu/cpufreq/Kconfig
===
--- linux.orig/arch/i386/kernel/cpu/cpufreq/Kconfig
+++ linux/arch
Dave Jones wrote:
On Thu, May 17, 2007 at 05:40:31PM -0400, Ed Sweetman wrote:
Here's a patch
(please inline patches so they can be quoted in replies).
having this as a tristate makes no sense, that code can't be modular.
Also, there's a gratuitous whitespace change, and the default should
Joshua Hoblitt wrote:
I think it's pretty clear that Dave and Daniel were both correct and
that ACPI_PROCESSOR is the correct dependency for multi-socket systems.
However, it's worth noting that this dependency seems to be unrelated to
SMP support. Ed Sweetman has reported that his single
the previous post i keep referring you to has a patch that was mangled
...here is the non-mangled version
--- ./linux-backup/arch/x86_64/kernel/cpufreq/Kconfig 2007-02-04
13:44:54.0 -0500
+++ ./linux-2.6.21-rc5-mm2/arch/x86_64/kernel/cpufreq/Kconfig
2007-05-17 18:13:07.0
Daniel Drake wrote:
Joshua Hoblitt wrote:
I don't think this is quiet right either as Ed Sweetman has reported
that this issue doesn't occur on single socket/multi-core systems.
Where did he write that? In an off-list mail, Ed seemed to agree with
my patch.
Daniel
What i didn't agree
Daniel Drake wrote:
Ed Sweetman wrote:
Like i mentioned off list, the problem here is that cpu freq modules
dont depend (Kconfig) on CONFIG_ACPI_PROCESSOR, yet they do.
Not really. Firstly, some of the cpufreq modules *do* depend on
CONFIG_ACPI_PROCESSOR. Secondly, the ones that don't have
Joshua Hoblitt wrote:
On Wed, May 16, 2007 at 04:04:40PM -0400, Daniel Drake wrote:
Duane Griffin wrote:
On 16/05/07, Prakash Punnoor <[EMAIL PROTECTED]> wrote:
Maybe you want to give a hint in the p states driver help text?
I think a hint is the right thing to do,
Joshua Hoblitt wrote:
On Wed, May 16, 2007 at 04:04:40PM -0400, Daniel Drake wrote:
Duane Griffin wrote:
On 16/05/07, Prakash Punnoor [EMAIL PROTECTED] wrote:
Maybe you want to give a hint in the p states driver help text?
I think a hint is the right thing to do, but
Daniel Drake wrote:
Ed Sweetman wrote:
Like i mentioned off list, the problem here is that cpu freq modules
dont depend (Kconfig) on CONFIG_ACPI_PROCESSOR, yet they do.
Not really. Firstly, some of the cpufreq modules *do* depend on
CONFIG_ACPI_PROCESSOR. Secondly, the ones that don't have
Daniel Drake wrote:
Joshua Hoblitt wrote:
I don't think this is quiet right either as Ed Sweetman has reported
that this issue doesn't occur on single socket/multi-core systems.
Where did he write that? In an off-list mail, Ed seemed to agree with
my patch.
Daniel
What i didn't agree
Alistair John Strachan wrote:
On Thursday 04 January 2007 01:50, Ed Sweetman wrote:
Not sure what went on between 2.6.19-rc5-mm2 and 2.6.20-rc2-mm2 in
libata land but SMART is no longer available on my hdds. I'm assuming
this is not the intended behavior.
In case this is chipset specific
Mark Lord wrote:
Ed Sweetman wrote:
Not sure what went on between 2.6.19-rc5-mm2 and 2.6.20-rc2-mm2 in
libata land but SMART is no longer available on my hdds.
It's working for me with 2.6.20-rc3, ata_piix libata driver.
-ml
Well, not in the sata_nv libata driver. The only change I make
Mark Lord wrote:
Ed Sweetman wrote:
Not sure what went on between 2.6.19-rc5-mm2 and 2.6.20-rc2-mm2 in
libata land but SMART is no longer available on my hdds.
It's working for me with 2.6.20-rc3, ata_piix libata driver.
-ml
Well, not in the sata_nv libata driver. The only change I make
Alistair John Strachan wrote:
On Thursday 04 January 2007 01:50, Ed Sweetman wrote:
Not sure what went on between 2.6.19-rc5-mm2 and 2.6.20-rc2-mm2 in
libata land but SMART is no longer available on my hdds. I'm assuming
this is not the intended behavior.
In case this is chipset specific
Not sure what went on between 2.6.19-rc5-mm2 and 2.6.20-rc2-mm2 in
libata land but SMART is no longer available on my hdds. I'm assuming
this is not the intended behavior.
In case this is chipset specific, IDE interface: nVidia Corporation
CK804 Serial ATA Controller (rev f3)
I'm using
Not sure what went on between 2.6.19-rc5-mm2 and 2.6.20-rc2-mm2 in
libata land but SMART is no longer available on my hdds. I'm assuming
this is not the intended behavior.
In case this is chipset specific, IDE interface: nVidia Corporation
CK804 Serial ATA Controller (rev f3)
I'm using
Randy Dunlap wrote:
On Tue, 05 Dec 2006 21:46:54 -0500 Ed Sweetman wrote:
-ETOOMANYWORDS && -ENOPATCH, so here is one to consider.
Help text can also be added.
This is similar to what USB storage already does.
I provided a patch a couple weeks ago when I brought this topic up
Randy Dunlap wrote:
On Tue, 05 Dec 2006 21:46:54 -0500 Ed Sweetman wrote:
-ETOOMANYWORDS -ENOPATCH, so here is one to consider.
Help text can also be added. supply text
This is similar to what USB storage already does.
I provided a patch a couple weeks ago when I brought this topic up
Robert Hancock wrote:
Ed Sweetman wrote:
What's not a legitimate configuration is libata drivers, no low level
scsi drivers, no ide drivers and no sd,sr,sg drivers. Yet, that is
the configuration the kernel currently gives you. How is that more
correct than any of the 3 solutions I have
Robert Hancock wrote:
Ed Sweetman wrote:
Jeff Garzik wrote:
Bernard Pidoux wrote:
I am asking why need to compile the following modules while I do not
have any SCSI device ?
libata uses SCSI to provide a lot of infrastructure that it would
otherwise have to recreate. Also, using SCSI
Robert Hancock wrote:
Ed Sweetman wrote:
Jeff Garzik wrote:
Bernard Pidoux wrote:
I am asking why need to compile the following modules while I do not
have any SCSI device ?
libata uses SCSI to provide a lot of infrastructure that it would
otherwise have to recreate. Also, using SCSI
Robert Hancock wrote:
Ed Sweetman wrote:
What's not a legitimate configuration is libata drivers, no low level
scsi drivers, no ide drivers and no sd,sr,sg drivers. Yet, that is
the configuration the kernel currently gives you. How is that more
correct than any of the 3 solutions I have
Jeff Garzik wrote:
Bernard Pidoux wrote:
I am asking why need to compile the following modules while I do not
have any SCSI device ?
libata uses SCSI to provide a lot of infrastructure that it would
otherwise have to recreate. Also, using SCSI meant that it
automatically worked in existing
Jeff Garzik wrote:
Bernard Pidoux wrote:
I am asking why need to compile the following modules while I do not
have any SCSI device ?
libata uses SCSI to provide a lot of infrastructure that it would
otherwise have to recreate. Also, using SCSI meant that it
automatically worked in existing
42 matches
Mail list logo
