> As far as I can see, the kernel doesn't behave as it would be, IMO,
> normal. I do have HPETs and Linux detects them without any
> need for hpet=force (HPET is registered for clockevents), but keeps
> LAPIC as the only option for dynticks. It looks like timing devices are
> rated and then only
Richard Harman wrote:
I think I may have a monkey wrench to throw into this, I finally got
around to testing the C1E patch, and the port80 patch. End result:
port80 patch has zero effect on this laptop, and the C1E patch makes
it stable.
Stating that your system is "stable" is not very
On Sun, 30 Dec 2007 08:36:26 -0500
Richard Harman <[EMAIL PROTECTED]> wrote:
> The C1E patch, which permits the lapic to function *does* make my
> system stable. My previous method of testing (using USB peripherals)
> and checking /proc/interrupts for ERRor interrupts so far hasn't
> caused the
Eduard-Gabriel Munteanu wrote:
On Sun, 30 Dec 2007 15:57:59 -0500
Richard Harman <[EMAIL PROTECTED]> wrote:
I think I may have a monkey wrench to throw into this, I finally got
around to testing the C1E patch, and the port80 patch. End result:
port80 patch has zero effect on this laptop,
On Sun, 30 Dec 2007 15:57:59 -0500
Richard Harman <[EMAIL PROTECTED]> wrote:
> I think I may have a monkey wrench to throw into this, I finally got
> around to testing the C1E patch, and the port80 patch. End result:
> port80 patch has zero effect on this laptop, and the C1E patch makes
> it
On Sun, 30 Dec 2007 15:42:17 +0100
Andi Kleen <[EMAIL PROTECTED]> wrote:
> Eduard-Gabriel Munteanu <[EMAIL PROTECTED]> writes:
> >
> > Other kernel developers, as discussed previously in this thread, are
> > working on a HPET-driven dynticks (as opposed to the current
> > LAPIC-driven one), but
Eduard-Gabriel Munteanu wrote:
On Sun, 30 Dec 2007 03:49:21 +0200
Note that this problem is only related to AMD64 multi-core laptops. As
far as I can see, devs might not invest much coding effort into this
and instead say "Go buy an Intel laptop!", as this really is a hardware
quirk. And if
On 29-12-07 10:09, Richard Harman wrote:
Anyway, I'm extremely open to getting to the bottom of working around
the quirks on this hardware. If I havn't mentioned it previously, this
laptop is an HP dv6408nr, with an amd turion tl-56 cpu and nVidia MCP51
chipset.
What can I do to help? It
Eduard-Gabriel Munteanu <[EMAIL PROTECTED]> writes:
>
> Other kernel developers, as discussed previously in this thread, are
> working on a HPET-driven dynticks (as opposed to the current
> LAPIC-driven one), but the change isn't that easy to make.
No, actually HPET based dyntick has been
* Islam Amer <[EMAIL PROTECTED]> wrote:
> Sorry, pressed send too soon. here is the line in dmesg:
>
> Compaq Presario v6000: using alternate I/O delay port
>
> Thanks, please tell me if you need anymore info.
thanks Islam for testing this. I've added your DMI strings to x86.git,
so v2.6.25
On Sun, 30 Dec 2007 03:49:21 +0200
Islam Amer <[EMAIL PROTECTED]> wrote:
> So what I understand now is that AMD C1E state saves battery like
> dynticks, so we don't need dynticks ?
No, it's not true.
C1E currently saves more power than dynticks just
because these platforms do not support higher
On Sun, 30 Dec 2007 03:49:21 +0200
Islam Amer [EMAIL PROTECTED] wrote:
So what I understand now is that AMD C1E state saves battery like
dynticks, so we don't need dynticks ?
No, it's not true.
C1E currently saves more power than dynticks just
because these platforms do not support higher
* Islam Amer [EMAIL PROTECTED] wrote:
Sorry, pressed send too soon. here is the line in dmesg:
Compaq Presario v6000: using alternate I/O delay port
Thanks, please tell me if you need anymore info.
thanks Islam for testing this. I've added your DMI strings to x86.git,
so v2.6.25 should
Eduard-Gabriel Munteanu [EMAIL PROTECTED] writes:
Other kernel developers, as discussed previously in this thread, are
working on a HPET-driven dynticks (as opposed to the current
LAPIC-driven one), but the change isn't that easy to make.
No, actually HPET based dyntick has been implemented
On 29-12-07 10:09, Richard Harman wrote:
Anyway, I'm extremely open to getting to the bottom of working around
the quirks on this hardware. If I havn't mentioned it previously, this
laptop is an HP dv6408nr, with an amd turion tl-56 cpu and nVidia MCP51
chipset.
What can I do to help? It
Eduard-Gabriel Munteanu wrote:
On Sun, 30 Dec 2007 03:49:21 +0200
Note that this problem is only related to AMD64 multi-core laptops. As
far as I can see, devs might not invest much coding effort into this
and instead say Go buy an Intel laptop!, as this really is a hardware
quirk. And if Andi
On Sun, 30 Dec 2007 15:42:17 +0100
Andi Kleen [EMAIL PROTECTED] wrote:
Eduard-Gabriel Munteanu [EMAIL PROTECTED] writes:
Other kernel developers, as discussed previously in this thread, are
working on a HPET-driven dynticks (as opposed to the current
LAPIC-driven one), but the change
On Sun, 30 Dec 2007 15:57:59 -0500
Richard Harman [EMAIL PROTECTED] wrote:
I think I may have a monkey wrench to throw into this, I finally got
around to testing the C1E patch, and the port80 patch. End result:
port80 patch has zero effect on this laptop, and the C1E patch makes
it stable.
Eduard-Gabriel Munteanu wrote:
On Sun, 30 Dec 2007 15:57:59 -0500
Richard Harman [EMAIL PROTECTED] wrote:
I think I may have a monkey wrench to throw into this, I finally got
around to testing the C1E patch, and the port80 patch. End result:
port80 patch has zero effect on this laptop, and
On Sun, 30 Dec 2007 08:36:26 -0500
Richard Harman [EMAIL PROTECTED] wrote:
The C1E patch, which permits the lapic to function *does* make my
system stable. My previous method of testing (using USB peripherals)
and checking /proc/interrupts for ERRor interrupts so far hasn't
caused the system
Richard Harman wrote:
I think I may have a monkey wrench to throw into this, I finally got
around to testing the C1E patch, and the port80 patch. End result:
port80 patch has zero effect on this laptop, and the C1E patch makes
it stable.
Stating that your system is stable is not very
As far as I can see, the kernel doesn't behave as it would be, IMO,
normal. I do have HPETs and Linux detects them without any
need for hpet=force (HPET is registered for clockevents), but keeps
LAPIC as the only option for dynticks. It looks like timing devices are
rated and then only one of
On 30-12-07 02:49, Islam Amer wrote:
Glad I could be of help.
Sure please go ahead, I will keep testing this patch with upcoming git
kernels, and report any problems.
Thanks. I'll see if Linus wants it for 2.6.24 still. Could be minimal enough.
So what I understand now is that AMD C1E
Glad I could be of help.
Sure please go ahead, I will keep testing this patch with upcoming git
kernels, and report any problems.
So what I understand now is that AMD C1E state saves battery like
dynticks, so we don't need dynticks ?
On Sun, 2007-12-30 at 02:38 +0100, Rene Herman wrote:
> On
On 29-12-07 23:28, Islam Amer wrote:
Thanks for the detailed response.
I thought I had gotten to the bottom of my problems when I found that
udev workaround, I guess I was naive.
I did the two tests you described and they predictably caused the hard
hangs. I needed to run the port80 program
Sorry, pressed send too soon. here is the line in dmesg:
Compaq Presario v6000: using alternate I/O delay port
Thanks, please tell me if you need anymore info.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More
Thanks for the detailed response.
I thought I had gotten to the bottom of my problems when I found that
udev workaround, I guess I was naive.
I did the two tests you described and they predictably caused the hard
hangs. I needed to run the port80 program only once to get the hard
hang.
The
Islam Amer wrote:
Hello.
I was interested in getting dynticks to work on my compaq presario v6000
to help with the 1 hour thirty minutes battery time, but after this
discussion I lost interest.
I too had the early boot time hang, and found it was udev triggering the
bug.
This early boot time
Hello.
I was interested in getting dynticks to work on my compaq presario v6000
to help with the 1 hour thirty minutes battery time, but after this
discussion I lost interest.
I too had the early boot time hang, and found it was udev triggering the
bug.
Changing the /etc/init.d/udev script so
On Sat, 29 Dec 2007 04:09:41 -0500
Richard Harman <[EMAIL PROTECTED]> wrote:
> Right now, with your patch and the 'noirqdebug' option or disabling
> nohz the system appears to be stable. This laptop otherwise locks up
> trying to configure apic/lapic, or locks up solid later with NO
> oops/bug
Eduard-Gabriel Munteanu wrote:
On Fri, 28 Dec 2007 13:57:57 -0500
Richard Harman <[EMAIL PROTECTED]> wrote:
I just saw this thread online from someone else who was having
problems with an HP laptop -- I believe my laptop falls into this
category.
The laptop is currently running Fedora Core
Eduard-Gabriel Munteanu wrote:
On Fri, 28 Dec 2007 13:57:57 -0500
Richard Harman [EMAIL PROTECTED] wrote:
I just saw this thread online from someone else who was having
problems with an HP laptop -- I believe my laptop falls into this
category.
The laptop is currently running Fedora Core 8,
On Sat, 29 Dec 2007 04:09:41 -0500
Richard Harman [EMAIL PROTECTED] wrote:
Right now, with your patch and the 'noirqdebug' option or disabling
nohz the system appears to be stable. This laptop otherwise locks up
trying to configure apic/lapic, or locks up solid later with NO
oops/bug and
Hello.
I was interested in getting dynticks to work on my compaq presario v6000
to help with the 1 hour thirty minutes battery time, but after this
discussion I lost interest.
I too had the early boot time hang, and found it was udev triggering the
bug.
Changing the /etc/init.d/udev script so
Islam Amer wrote:
Hello.
I was interested in getting dynticks to work on my compaq presario v6000
to help with the 1 hour thirty minutes battery time, but after this
discussion I lost interest.
I too had the early boot time hang, and found it was udev triggering the
bug.
This early boot time
Thanks for the detailed response.
I thought I had gotten to the bottom of my problems when I found that
udev workaround, I guess I was naive.
I did the two tests you described and they predictably caused the hard
hangs. I needed to run the port80 program only once to get the hard
hang.
The
Sorry, pressed send too soon. here is the line in dmesg:
Compaq Presario v6000: using alternate I/O delay port
Thanks, please tell me if you need anymore info.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo
On 29-12-07 23:28, Islam Amer wrote:
Thanks for the detailed response.
I thought I had gotten to the bottom of my problems when I found that
udev workaround, I guess I was naive.
I did the two tests you described and they predictably caused the hard
hangs. I needed to run the port80 program
Glad I could be of help.
Sure please go ahead, I will keep testing this patch with upcoming git
kernels, and report any problems.
So what I understand now is that AMD C1E state saves battery like
dynticks, so we don't need dynticks ?
On Sun, 2007-12-30 at 02:38 +0100, Rene Herman wrote:
On
On 30-12-07 02:49, Islam Amer wrote:
Glad I could be of help.
Sure please go ahead, I will keep testing this patch with upcoming git
kernels, and report any problems.
Thanks. I'll see if Linus wants it for 2.6.24 still. Could be minimal enough.
So what I understand now is that AMD C1E
On Fri, 28 Dec 2007 13:57:57 -0500
Richard Harman <[EMAIL PROTECTED]> wrote:
> I just saw this thread online from someone else who was having
> problems with an HP laptop -- I believe my laptop falls into this
> category.
>
> The laptop is currently running Fedora Core 8, but I couldn't figure
>
On Fri, 28 Dec 2007 13:57:57 -0500
Richard Harman [EMAIL PROTECTED] wrote:
I just saw this thread online from someone else who was having
problems with an HP laptop -- I believe my laptop falls into this
category.
The laptop is currently running Fedora Core 8, but I couldn't figure
out
On Tue, 18 Dec 2007 15:43:52 +
Pavel Machek <[EMAIL PROTECTED]> wrote:
> On Fri 2007-12-14 00:47:10, Eduard-Gabriel Munteanu wrote:
>
> > +static int __cpuinit force_amd_c1e(char *str) {
>
> { on new line, please.
>
> > + disable_amd_c1e = 0;
> > + return 1;
> > +}
Sorry, I know it's
On Fri 2007-12-14 00:47:10, Eduard-Gabriel Munteanu wrote:
> Some multiprocessor 64-bit AMD systems don't allow the user to disable
> the C1E C-state. The kernel detects C1E and marks the LAPIC as
> broken, thereby disabling dynticks. This patch adds an option to
> disable C1E when detected. It
On Fri 2007-12-14 00:47:10, Eduard-Gabriel Munteanu wrote:
Some multiprocessor 64-bit AMD systems don't allow the user to disable
the C1E C-state. The kernel detects C1E and marks the LAPIC as
broken, thereby disabling dynticks. This patch adds an option to
disable C1E when detected. It also
On Tue, 18 Dec 2007 15:43:52 +
Pavel Machek [EMAIL PROTECTED] wrote:
On Fri 2007-12-14 00:47:10, Eduard-Gabriel Munteanu wrote:
+static int __cpuinit force_amd_c1e(char *str) {
{ on new line, please.
+ disable_amd_c1e = 0;
+ return 1;
+}
Sorry, I know it's a bad habit.
On Sun, 16 Dec 2007 06:29:57 -0800 (PST)
[EMAIL PROTECTED] wrote:
> On Dec 15, 2:20 am, Eduard-Gabriel Munteanu
> <[EMAIL PROTECTED]> wrote:
> > On Fri, 14 Dec 2007 17:35:13 -0500
> >
> > But maybe someone with access to such hardware can tell us what
> > happens: does he get C2/C3 power states
On Sun, 16 Dec 2007 06:29:57 -0800 (PST)
[EMAIL PROTECTED] wrote:
On Dec 15, 2:20 am, Eduard-Gabriel Munteanu
[EMAIL PROTECTED] wrote:
On Fri, 14 Dec 2007 17:35:13 -0500
But maybe someone with access to such hardware can tell us what
happens: does he get C2/C3 power states under such
On Fri, Dec 14, 2007 at 05:35:13PM -0500, Chuck Ebbert wrote:
> On 12/14/2007 05:17 AM, Andi Kleen wrote:
> >> so do whatever is necessary to enable dynticks.
> >
> > dynticks' main purpose is to save power, but C1e saves more power.
> > Disabling C1e for dynticks would be a fairly useless
On Fri, Dec 14, 2007 at 05:35:13PM -0500, Chuck Ebbert wrote:
On 12/14/2007 05:17 AM, Andi Kleen wrote:
so do whatever is necessary to enable dynticks.
dynticks' main purpose is to save power, but C1e saves more power.
Disabling C1e for dynticks would be a fairly useless default
trade
On Fri, 14 Dec 2007 17:35:13 -0500
Chuck Ebbert <[EMAIL PROTECTED]> wrote:
> On 12/14/2007 05:17 AM, Andi Kleen wrote:
> >> so do whatever is necessary to enable dynticks.
> >
> > dynticks' main purpose is to save power, but C1e saves more power.
> > Disabling C1e for dynticks would be a fairly
On 12/14/2007 05:17 AM, Andi Kleen wrote:
>> so do whatever is necessary to enable dynticks.
>
> dynticks' main purpose is to save power, but C1e saves more power.
> Disabling C1e for dynticks would be a fairly useless default
> trade off.
>
What about machines where the BIOS has disabled C1e
> Well, that would interfere with the acpi-idle code.
How so? idle notifiers should work for acpi idle too.
> Anyway the idle notifiers is a pretty artificial interface which is on
> my get rid of it list anyway.
The original use cases were:
- Accounting for idle time with stopped counters in
Thanks to both of you for shedding some light on this matter. I'll look
into HPET-related efforts; it looks like a better solution than my
patch.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
On Fri, 14 Dec 2007, Andi Kleen wrote:
> > magically in the SMM code. To work around this is we would need to add
> > the broadcast notification to the halt(), safe_halt(), pm_idle_halt()
> > variants which float around in the kernel and make this conditional on
> > the C1E detection. That's
On Fri, 14 Dec 2007, Andi Kleen wrote:
> > LAPIC is seemingly disabled (C1E detection code does this), but
>
> It should only disable the LAPIC timer, but not the full use of the
> LAPIC.
That's what it does. The LAPIC timer is invalidated and registered as
a per CPU broadcast dummy source
> magically in the SMM code. To work around this is we would need to add
> the broadcast notification to the halt(), safe_halt(), pm_idle_halt()
> variants which float around in the kernel and make this conditional on
> the C1E detection. That's nasty, but it seems the only solution for
> now.
On
On Fri, 14 Dec 2007, Eduard-Gabriel Munteanu wrote:
> LAPIC is seemingly disabled (C1E detection code does this), but
> clockevents still tries to use it, instead of relying on HPET.
It relies on HPET. The LAPIC is just used as a mechanism which allows
us to broadcast the tick to both cores.
>
> LAPIC is seemingly disabled (C1E detection code does this), but
It should only disable the LAPIC timer, but not the full use of the
LAPIC.
-Andi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
On Fri, 14 Dec 2007 13:20:48 +0100
Andi Kleen <[EMAIL PROTECTED]> wrote:
> AMD doesn't support states deeper than C1 on multi core currently, so
> in general they don't matter much right now.
Thanks for the info, I wasn't aware of this.
> The better solution there is to use HPET instead.
On Fri, Dec 14, 2007 at 03:41:06PM +0200, Eduard-Gabriel Munteanu wrote:
> On Fri, 14 Dec 2007 11:17:21 +0100
> Andi Kleen <[EMAIL PROTECTED]> wrote:
>
> > >so do whatever is necessary to enable dynticks.
> >
> > dynticks' main purpose is to save power, but C1e saves more power.
> > Disabling
On Fri, 14 Dec 2007 11:17:21 +0100
Andi Kleen <[EMAIL PROTECTED]> wrote:
> >so do whatever is necessary to enable dynticks.
>
> dynticks' main purpose is to save power, but C1e saves more power.
> Disabling C1e for dynticks would be a fairly useless default
> trade off.
I see. Also, AMD specs
>so do whatever is necessary to enable dynticks.
dynticks' main purpose is to save power, but C1e saves more power.
Disabling C1e for dynticks would be a fairly useless default
trade off.
-Andi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message
On Thu, 13 Dec 2007 23:58:50 +0100
Johannes Weiner <[EMAIL PROTECTED]> wrote:
> I would find this way more readable:
>
> if (lo & ENABLE_C1E_MASK) {
> #ifdef CONFIG_X86_AMD_C1E_WORKAROUND
> if (disable_amd_c1e) {
> ...
> #else
> return 1;
>
On Thu, 13 Dec 2007 23:33:07 +0100
Andi Kleen <[EMAIL PROTECTED]> wrote:
> The description/option is not correct. The mainline kernel never
> disables C1e. Some distribution kernels and Xen do, perhaps you're
> confusing this with them.
>
> You would rather need a "force_disable_c1e" option if
On Thu, 13 Dec 2007 23:58:50 +0100
Johannes Weiner [EMAIL PROTECTED] wrote:
I would find this way more readable:
if (lo ENABLE_C1E_MASK) {
#ifdef CONFIG_X86_AMD_C1E_WORKAROUND
if (disable_amd_c1e) {
...
#else
return 1;
#endif
On Thu, 13 Dec 2007 23:33:07 +0100
Andi Kleen [EMAIL PROTECTED] wrote:
The description/option is not correct. The mainline kernel never
disables C1e. Some distribution kernels and Xen do, perhaps you're
confusing this with them.
You would rather need a force_disable_c1e option if anything.
so do whatever is necessary to enable dynticks.
dynticks' main purpose is to save power, but C1e saves more power.
Disabling C1e for dynticks would be a fairly useless default
trade off.
-Andi
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to
On Fri, 14 Dec 2007 11:17:21 +0100
Andi Kleen [EMAIL PROTECTED] wrote:
so do whatever is necessary to enable dynticks.
dynticks' main purpose is to save power, but C1e saves more power.
Disabling C1e for dynticks would be a fairly useless default
trade off.
I see. Also, AMD specs say that
On Fri, Dec 14, 2007 at 03:41:06PM +0200, Eduard-Gabriel Munteanu wrote:
On Fri, 14 Dec 2007 11:17:21 +0100
Andi Kleen [EMAIL PROTECTED] wrote:
so do whatever is necessary to enable dynticks.
dynticks' main purpose is to save power, but C1e saves more power.
Disabling C1e for
On Fri, 14 Dec 2007 13:20:48 +0100
Andi Kleen [EMAIL PROTECTED] wrote:
AMD doesn't support states deeper than C1 on multi core currently, so
in general they don't matter much right now.
Thanks for the info, I wasn't aware of this.
The better solution there is to use HPET instead. Newer
magically in the SMM code. To work around this is we would need to add
the broadcast notification to the halt(), safe_halt(), pm_idle_halt()
variants which float around in the kernel and make this conditional on
the C1E detection. That's nasty, but it seems the only solution for
now.
On
On Fri, 14 Dec 2007, Eduard-Gabriel Munteanu wrote:
LAPIC is seemingly disabled (C1E detection code does this), but
clockevents still tries to use it, instead of relying on HPET.
It relies on HPET. The LAPIC is just used as a mechanism which allows
us to broadcast the tick to both cores.
LAPIC is seemingly disabled (C1E detection code does this), but
It should only disable the LAPIC timer, but not the full use of the
LAPIC.
-Andi
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
On Fri, 14 Dec 2007, Andi Kleen wrote:
LAPIC is seemingly disabled (C1E detection code does this), but
It should only disable the LAPIC timer, but not the full use of the
LAPIC.
That's what it does. The LAPIC timer is invalidated and registered as
a per CPU broadcast dummy source
On Fri, 14 Dec 2007, Andi Kleen wrote:
magically in the SMM code. To work around this is we would need to add
the broadcast notification to the halt(), safe_halt(), pm_idle_halt()
variants which float around in the kernel and make this conditional on
the C1E detection. That's nasty, but
Thanks to both of you for shedding some light on this matter. I'll look
into HPET-related efforts; it looks like a better solution than my
patch.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Well, that would interfere with the acpi-idle code.
How so? idle notifiers should work for acpi idle too.
Anyway the idle notifiers is a pretty artificial interface which is on
my get rid of it list anyway.
The original use cases were:
- Accounting for idle time with stopped counters in
On 12/14/2007 05:17 AM, Andi Kleen wrote:
so do whatever is necessary to enable dynticks.
dynticks' main purpose is to save power, but C1e saves more power.
Disabling C1e for dynticks would be a fairly useless default
trade off.
What about machines where the BIOS has disabled C1e on CPU
On Fri, 14 Dec 2007 17:35:13 -0500
Chuck Ebbert [EMAIL PROTECTED] wrote:
On 12/14/2007 05:17 AM, Andi Kleen wrote:
so do whatever is necessary to enable dynticks.
dynticks' main purpose is to save power, but C1e saves more power.
Disabling C1e for dynticks would be a fairly useless
Hello Eduard-Gabriel,
You write:
> + dynamic ticks to work. It's safe to enable this option even if
> + your system doesn't have an AMD CPU (there are no side-effects if
> + such a CPU isn't detected).
It's definitely not safe. There are the computers with totally broken
Hi,
Eduard-Gabriel Munteanu <[EMAIL PROTECTED]> writes:
> diff --git a/arch/x86/kernel/setup_64.c b/arch/x86/kernel/setup_64.c
> index 30d94d1..15556a0 100644
> --- a/arch/x86/kernel/setup_64.c
> +++ b/arch/x86/kernel/setup_64.c
> @@ -583,6 +583,17 @@ static void __init amd_detect_cmp(struct
Eduard-Gabriel Munteanu <[EMAIL PROTECTED]> writes:
>
> + force_amd_c1e [KNL,SMP,HW,BUGS=X86-64]
> + Don't disable C1E on AMD systems even if this means
The description/option is not correct. The mainline kernel never disables C1e.
Some distribution kernels and Xen do,
Some multiprocessor 64-bit AMD systems don't allow the user to disable
the C1E C-state. The kernel detects C1E and marks the LAPIC as
broken, thereby disabling dynticks. This patch adds an option to
disable C1E when detected. It also allows the user to enable this
processor feature even if that
Some multiprocessor 64-bit AMD systems don't allow the user to disable
the C1E C-state. The kernel detects C1E and marks the LAPIC as
broken, thereby disabling dynticks. This patch adds an option to
disable C1E when detected. It also allows the user to enable this
processor feature even if that
Some multiprocessor 64-bit AMD systems don't allow the user to disable
the C1E C-state. The kernel detects C1E and marks the LAPIC as
broken, thereby disabling dynticks. This patch adds an option to
disable C1E when detected. It also allows the user to enable this
processor feature even if that
Some multiprocessor 64-bit AMD systems don't allow the user to disable
the C1E C-state. The kernel detects C1E and marks the LAPIC as
broken, thereby disabling dynticks. This patch adds an option to
disable C1E when detected. It also allows the user to enable this
processor feature even if that
Eduard-Gabriel Munteanu [EMAIL PROTECTED] writes:
+ force_amd_c1e [KNL,SMP,HW,BUGS=X86-64]
+ Don't disable C1E on AMD systems even if this means
The description/option is not correct. The mainline kernel never disables C1e.
Some distribution kernels and Xen do,
Hi,
Eduard-Gabriel Munteanu [EMAIL PROTECTED] writes:
diff --git a/arch/x86/kernel/setup_64.c b/arch/x86/kernel/setup_64.c
index 30d94d1..15556a0 100644
--- a/arch/x86/kernel/setup_64.c
+++ b/arch/x86/kernel/setup_64.c
@@ -583,6 +583,17 @@ static void __init amd_detect_cmp(struct
Hello Eduard-Gabriel,
You write:
+ dynamic ticks to work. It's safe to enable this option even if
+ your system doesn't have an AMD CPU (there are no side-effects if
+ such a CPU isn't detected).
It's definitely not safe. There are the computers with totally broken
BIOSes,
90 matches
Mail list logo
