> From: Andy Lutomirski
> On Thu, Oct 1, 2020 at 1:43 PM Chang S. Bae wrote:
> > "xstate.disable=0x6000" will disable AMX on a system that has AMX
> > compiled into XFEATURE_MASK_USER_SUPPORTED.
> Can we please use words for this? Perhaps:
> xstate.disable=amx,zmm
Yes, I think it is reaso
> From: Randy Dunlap
> What do these bitmasks look like? what do the bits mean?
> Where does a user find this info?
The XSAVE state component bitmaps are detailed in
the Intel Software Developer's Manual, volume 1, Chapter 13:
"Managing State using the XSAVE Feature Set".
http://intel.com/sd
> From: Andy Lutomirski
> > diff --git a/arch/x86/kernel/fpu/core.c b/arch/x86/kernel/fpu/core.c
> > @@ -518,3 +518,40 @@ int fpu__exception_code(struct fpu *fpu, int trap_nr)
..
> > +bool xfirstuse_event_handler(struct fpu *fpu)
> > +{
> > + bool handled = false;
> > + u64 event_mas
>
> From: Andy Lutomirski
>
> > + /*
> > +* The caller may be under interrupt disabled condition. Ensure
> > interrupt
> > +* allowance before the memory allocation, which may involve with
> > page faults.
> > +*/
> > + local_irq_enable();
> ... you can't
@vger.kernel.org; sta...@vger.kernel.org
Cc: Gustavo A. R. Silva ; Prarit Bhargava
; Brown, Len ; Sasha Levin
; linux...@vger.kernel.org
Subject: [PATCH AUTOSEL 5.2 82/94] tools/power turbostat: fix file descriptor
leaks
From: "Gustavo A. R. Silva"
[ Upstream commit 605736c6929d541c78a85dffae4d33
> please add a new helper function topology_max_dies() and retrieve it from
> that.
I'll do this for Rui -- since his patch is in my x86 branch,
and it is already (very early) Saturday morning for him:-)
FYI, there were a couple of other small changes I made to that branch
in response to list
-
From: Brice Goglin [mailto:brice.gog...@inria.fr]
Sent: Sunday, February 24, 2019 5:04 AM
To: Len Brown ; x...@kernel.org
Cc: linux-kernel@vger.kernel.org; Brown, Len ;
linux-...@vger.kernel.org; Like Xu
Subject: Re: [PATCH 03/11] x86 topology: Add CPUID.1F multi-die/package support
Le 19/02
Yes, this can be scheduled to be deleted.
>> +if CONFIG_SCHED_BOOK and CONFIG_SCHED_DRAWER are selected, respectively.
>>
>> CONFIG_SCHED_BOOK and CONFIG_DRAWER are currently only used on s390,
>> where
>fwiw:CONFIG_SCHED_DRAWER
Heh. Seems that every line of update to a .txt files uncovers two lines of
existing
>> @@ -461,7 +463,7 @@ static bool match_llc(struct cpuinfo_x86 *c, struct
>> cpuinfo_x86 *o)
>>*/
>> static bool match_die(struct cpuinfo_x86 *c, struct cpuinfo_x86 *o)
>> {
>> -if (c->>phys_proc_id == o->>phys_proc_id)
>> +if (c->>cpu_die_id == o->>cpu_die_id)
>> ret
Thanks for the comments, Kan,
>> diff --git a/Documentation/cputopology.txt
>> b/Documentation/cputopology.txt index 287213b4517b..7dd2ae3df233
>> 100644
>> --- a/Documentation/cputopology.txt
>> +++ b/Documentation/cputopology.txt
>> @@ -56,6 +56,16 @@ core_siblings_list:
>> human-readable
We disabled CPUID-based TSC calibration on SKX in December for several reasons.
If you still have it enabled, you need this patch:
commit b511203093489eb1829cb4de86e8214752205ac6
x86/tsc: Fix erroneous TSC rate on Skylake Xeon
If you are referring to another platform that has CPUID-TSC calibr
You just did it:-)
-Original Message-
From: Matt Turner [mailto:matts...@gmail.com]
Sent: Saturday, April 07, 2018 6:25 PM
To: Brown, Len
Cc: Thomas Gleixner ; Ingo Molnar ; H.
Peter Anvin ; Borislav Petkov ; LKML
; x...@kernel.org; Matt Turner
Subject: Re: [PATCH 1/2] tools/power
Acked-by: Len Brown
-Original Message-
From: Colin King [mailto:colin.k...@canonical.com]
Sent: Wednesday, May 17, 2017 8:52 AM
To: Brown, Len
Cc: kernel-janit...@vger.kernel.org; linux-kernel@vger.kernel.org
Subject: [PATCH] tools/power x86_energy_perf_policy: fix resource leak on
> On Saturday, March 04, 2017 06:36:29 PM Len Brown wrote:
> > Applied -- Thanks!
>
> I guess I should include this into fixes too?
>
> Or are you going to send a pull request with it to me?
When I apply it, you don't have to.
I have a couple of other fixes being tested on my turbostat branch no
> + crystal_khz = 24000;/* 25.0 MHz */
I guess I prefer no comment over an incorrect comment.
> -Original Message-
> From: rcoch...@linutronix.de [mailto:rcoch...@linutronix.de]
> Sent: Tuesday, April 05, 2016 12:30 AM
> To: Brown, Len
> Cc: Gortmaker, Paul (Wind River); linux-kernel@vger.kernel.org; Len Brown;
> linux...@vger.kernel.org
> Subject: Re: [PATC
The first idle driver to register with cpuidle wins.
intel_idle should always get the opportunity
to probe and register before acpi_idle (processor_idle.c)
When intel_idle was allowed to be modular,
some distros build their kernel and loaded modules
such that acpi_idle could probe first. In such
> > >
> > > -acpi_status acpi_hw_read(u32 *value, struct acpi_generic_address
> *reg)
> > > +acpi_status acpi_hw_read(u32 *value, struct acpi_generic_address *
> reg)
> >
> > The second argument * style appears the opposite of normal style
> > and a different style than the first argument * style.
> By BIOS (1.2.3 on a Dell XPS 13 9350) seems to want to enable C1E
> auto-promotion (ugh!), which results in this difference across
> suspend/resume according to turbostat:
>
> -cpu3: MSR_IA32_POWER_CTL: 0x0024005d (C1E auto-promotion: DISabled)
> +cpu3: MSR_IA32_POWER_CTL: 0x0024005f (C1E auto-p
> >> [0.00] tsc: PIT calibration matches HPET. 2 loops
> >> [0.00] tsc: Detected 2399.975 MHz processor
> >> [0.090897] TSC deadline timer enabled
> >> [1.960034] tsc: Refined TSC clocksource calibration: 2400.007 MHz
> turbostat version 4.10 10 Dec, 2015 - Len Brown
> CPU
+adrian
> [0.00] tsc: PIT calibration matches HPET. 2 loops
> [0.00] tsc: Detected 2399.975 MHz processor
> [0.090897] TSC deadline timer enabled
> [1.960034] tsc: Refined TSC clocksource calibration: 2400.007 MHz
> [1.960039] clocksource: tsc: mask: 0x
> Lenovo Ideapad S10-3t hangs coming out of S3 with intel_idle.
> The two workaround that seem to help are "intel_idle.max_cstate=0"
> or "nohz=off highres=off".
>
> At a first glance quirk_tigerpoint_bm_sts() seemed promising, but
> even when moved to early_resume it didn't do anything.
>
> I ha
try booting upstream with "cpu_init_udelay=1".
If it works, then it actually implicates this commit:
a9bcaa02a5104ace6a9d9e4a9cd9192a9e7744d6
("x86/smpboot: Remove SIPI delays from cpu_up()")
Unfortunately the commit message for that on is erroneous --
"cpu_init_udelay=1" is actually a NO-OP,
> I did the revert in linux-stable (last tag being v4.3-rc4) gave a revert
> description so it would be applied.
>
> built and tested. Result: did not help, still missing the second core.
Same result here.
upstream failed to bring up CPU #1 on 5/5 boots
Revert "x86/smpboot: Remove APIC.wa
> > > You have similar hardware:
> > >
> > > Shane:
> > >
> > > smpboot: CPU0: Intel(R) Core(TM)2 CPU 6400 @ 2.13GHz (fam:
> 06,
> > model: 0f, stepping: 06)
> > >
> > > Donald:
> > >
> > > CPU : Intel Core 2 CPU 6600 @ 2.4GHz
> > >
> > > I think I can get ahold of a core2 6xxx box tomorr
> > You have similar hardware:
> >
> > Shane:
> >
> > smpboot: CPU0: Intel(R) Core(TM)2 CPU 6400 @ 2.13GHz (fam: 06,
> model: 0f, stepping: 06)
> >
> > Donald:
> >
> > CPU : Intel Core 2 CPU 6600 @ 2.4GHz
> >
> > I think I can get ahold of a core2 6xxx box tomorrow.
Intel(R) Core(TM)2 CP
> > > Did you try reverting the "x86/smpboot: Remove
> APIC.wait_for_init_deassert
> > > and atomic init_deasserted" patch?
> >
> > Yes, please let me know if reverting that patch helps you too.
>
> How? Please send a patch or git cmd(s).I have the
> git/stable/linux-stable.git on my PC
Donald, Shane,
Thanks for reporting this.
> > I also tried suggested /vmlinuz-4.3.0-rc3 parameter in grub:
> > "cpu_init_udelay=1"
> > which did not help getting missing CPU back online.
right, if the issue is caused by the patch below,
that cmdline will not help.
> Did you try rever
2015 1:27 PM
> To: r...@rjwysocki.net
> Cc: Dmitry Torokhov; Douglas Anderson; pa...@ucw.cz; Brown, Len;
> gre...@linuxfoundation.org; linux...@vger.kernel.org; linux-
> ker...@vger.kernel.org
> Subject: [PATCH] power: print function name of callbacks
>
> The printouts writen t
> Who does enter suspend to ram multiple times a second? Only android
One significant customer for fast suspend/resume
is sufficient to justify Linux supporting fast suspend/resume.
> Can you run android on mainline kernel? No
This is something we need to work together to help fix.
thanks,
-Len
> -Original Message-
> From: Austin S Hemmelgarn [mailto:ahferro...@gmail.com]
> Sent: Wednesday, July 15, 2015 10:07 AM
> To: Pavel Machek; Len Brown
> Cc: r...@rjwysocki.net; linux...@vger.kernel.org; linux-
> ker...@vger.kernel.org; Brown, Len
> Subject: Re: [PAT
> This driver only knows how to handle counters, though. I'm not sure
> whether all of the MSRs that turbostat needs are counters.
turbostat --debug
dumps a lot of configuration MSRs that are not counters.
"--debug" is not an obscure option, it is the only way that
the turbostat is used by advan
> -Original Message-
> From: Prarit Bhargava [mailto:pra...@redhat.com]
> Sent: Friday, May 22, 2015 6:30 PM
> To: Brown, Len
> Cc: linux-kernel@vger.kernel.org; linux...@vger.kernel.org; Semin, Andrey
> Subject: Re: [PATCH 2/2] turbostat, add set_base_cpu()
>
>
> +void set_base_cpu(void)
> +{
> + int cpu;
> +
> + for (cpu = 0; cpu <= topo.max_cpu_num; ++cpu) {
> + if (cpu_is_not_present(cpu))
> + continue;
> + base_cpu = cpu;
> + break;
> + }
> +
> + if (base_cpu == -1)
> +
> I think that turbostat could do some of its work without being
> root if we had a driver like this.
Note that turbostat can be run as non-root this way:
# setcap cap_sys_rawio=ep ./turbostat
# chmod +r /dev/cpu/*/msr
For the debug case, there are a number of MSRs that turbostat must access,
so
> What's the cutoff for 'modern hardware' - which CPUs stopped requiring
> the delay?
This is the topic of ongoing research, and I'm not ready to send
the patch setting a new default until I've heard back from a few more HW people.
Every system I've tested appears to work with delay 0.
Were I to
ISTR that I got interrupted when working on that one
and never got back to it. Also, I think I had a puzzling
power measurement result -- like I had measured a power benefit,
and then i couldn't find a benefit. (No matter, should be a perf
benefit even if ISO power)
Next week I should have acces
Davidlohr,
Thanks for the note.
Ideally (on Linux in general, and on servers, in particular) we strive
for the performance impact of power saving features to be small enough
to be considered in "measurement noise".
Your report for 160 core Westmere AIM numbers being hit at 10-25%
shows 15% measu
> [0.840668] intel_idle: lapic_timer_reliable_states 0x2
vs.
> [0.877528] intel_idle: lapic_timer_reliable_states 0x
This means CPUID.ARAT is set for the new board, and not set
for the old board. You can observe that also in /proc/cpuinfo flags
where you will likely also find a vi
> > I'd be interested in the acpi_idle output above for both the
> > new and old boards to see if they are exporting different states
> > on the two boards.
>
> Could be ; I can probably get access to the newer one again too, if
> that will be useful.
yes, please.
> >
> > dmidecode isn't useful
> I've got an eval board with a 1.7GHz Avaton/C2000 that hangs at boot
> shortly after the idle driver registration -- typically 1/2 dozen
> dmesg lines later, around rtc init, or net stack init.
Paul,
Please boot the failing board with "intel_idle.max_cstate=0"
to disable intel_idle entirely, and
> And your point is?
It is a bad idea for an individual CPU to track the C-state
of another CPU, which can change the cycle after it was checked.
We know it is a bad idea because we used to do it,
until we realized code here can easily impact the
performance critical path.
In general, it is the O
> Right now (on ARM at least but I imagine this is pretty universal), the
> biggest impact on information accuracy for a CPU depends on what the
> other CPUs are doing. The most obvious example is cluster power down.
> For a cluster to be powered down, all the CPUs sharing this cluster must
> also
> How about naming it as PM_SLEEP_FS_SYNC (and similarly in the sysfs
> files
> and variable names as well). Just to avoid confusion with
> "synchronous/async".
good point -- thanks!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...
> > + depends on PM_SLEEP
>
> this is actually a suspend specific feature, and it should depends on
> SUSPEND instead?
yup, will update.
thanks,
-Len
Reviewed-by: Len Brown
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
> >> Pulled, thanks Tony!
> >>
> >> Len, are you fine with this route [tip:x86/ras tree] for the
> >> drivers/acpi/apei/einj.c changes?
> >
> > Yes, the RAS guys basically own that code.
>
> These patches also got picked up by Rafael and are in his ACPI tree
> too. I think the patches were applie
+rafael
> Pulled, thanks Tony!
>
> Len, are you fine with this route [tip:x86/ras tree] for the
> drivers/acpi/apei/einj.c changes?
Yes, the RAS guys basically own that code.
thanks,
-Len
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ma
> > - idle = pm_idle;
> > if (!idle)
>
> Hm, if I'm not mistaken idle will uninitialized at this point, so this
> could quite likely lead to a crash.
thanks,
will fix.
-Len
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the b
> diff --git a/drivers/idle/intel_idle.c b/drivers/idle/intel_idle.c index
> e872617..b0f6b4c 100644
> --- a/drivers/idle/intel_idle.c
> +++ b/drivers/idle/intel_idle.c
> @@ -413,6 +413,7 @@ static const struct x86_cpu_id intel_idle_ids[] = {
> ICPU(0x2a, idle_cpu_snb),
> ICPU(0x2d
>> evxfevnt-0091 [00] enable: Transition to
>ACPI mode successful
>> khelper used greatest stack depth: 3144 bytes left
>> net_namespace: 304 bytes
>> NET: Registered protocol family 16
>> ACPI: bus type pci registered
>> khelper used greatest stack depth: 3032 bytes left
>> PCI: P
Thanks Hugh.
-Len
>-Original Message-
>From: Hugh Dickins [mailto:[EMAIL PROTECTED]
>Sent: Monday, August 27, 2007 11:05 AM
>To: Linus Torvalds
>Cc: Andrew Morton; Brown, Len; linux-kernel@vger.kernel.org
>Subject: [PATCH] reverse CONFIG_ACPI_PROC_EVENT default
>
>On Tue, Aug 21, 2007 at 07:22:51PM +0400, Alexey Starikovskiy wrote:
>> Yes, that is the proper solution with a single drawback:
>> it touches ACPICA dual-licensed code and would take ages to commit,
>> and Len would probably ask you to give permission to
>re-license it under
>> BSD.
>
>The latt
The last time I tried to remove this code,
we discovered that people were using it to query
the lid (button) status.
-Len
>-Original Message-
>From: Richard Hughes [mailto:[EMAIL PROTECTED]
>Sent: Thursday, July 12, 2007 6:26 AM
>To: Zhang, Rui
>Cc: Henne; Arjan van de
>Asides from git-bisect failing me again[1], what gives with this file?
it supports output switching, which didn't make it into 2.6.21 --
probably will be 2.6.22.
-Len
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majo
>Hi Andrew,
>
> I think the following isn't on purpose but the IBM Thinkpad acpi
> extras default to y in Kconfig. The patch below fixes it:
>
> Signed-off-by: <[EMAIL PROTECTED]>
>
>
>--- drivers/acpi/Kconfig.orig 2005-09-09 09:46:26.0 +0200
>+++ drivers/acpi/Kconfig 2005-09-
>"Brown, Len" <[EMAIL PROTECTED]> wrote:
>>
>> I saw lots of transient battery issues from 2.6.13-rc3
>> until 2.6.13-rc6, but the ones I followed went away
>> as of 2.6.13 final. Do you have your eye on others
>> besides 4980?
>
>Not sp
>Just booted a 2.6.13 compiled with UP, ACPI, APIC, LAPIC,
>sensor modules
>with "nolapic noapic acpi=off".
Huh, I don't see I don't see the processor module checking
for acpi_disabled anyplace...
I assume the oops goes away when you
do not boot with "acpi=off"?
> The processor module was sti
>There are a few bugs which I'd identified as arising from the acpi tree
>while it was in -mm. Is this patch likely to drag them into mainline?
>
>They include:
>
>
>http://bugzilla.kernel.org/show_bug.cgi?id=4977
>Summary: ACPI 20050708 fails on HP RX2600 platform
This was filed agai
>-Original Message-
>From: [EMAIL PROTECTED]
>[mailto:[EMAIL PROTECTED] On Behalf Of Jan De Luyck
>Sent: Monday, September 05, 2005 9:17 AM
>To: linux-kernel@vger.kernel.org
>Subject: Re: Kernel 2.6.13 repeated ACPI events?
>
>I'm seeing repeated ACPI events too, but of the battery kind
>As for the inability to log in, this bug may be relevant,
>given I also had
>that problem:
>
>https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=166422
>
>There are fixes in the pipeline for util-linux audit
>interaction in Fedora as
>well. I know because I reported those too ;)
>
>> afte
>> > Please then try the latest ACPI patch here:
>> >
>http://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/patches
>/release/2.6.13/acpi-20050902-2.6.13.diff.gz
>> > It should apply to vanilla 2.6.13 with a reject in ia64/Kconfig
>> > that you can ignore.
>> >
>> > If this works, then we
>Brown, Len wrote:
>>>>[ 279.662960] [] wait_for_completion+0xa4/0x110
>>
>>
>> possibly a missing interrupt?
>>
>>
>>>CONFIG_ACPI=y
>>
>>
>> any difference if booted with "acpi=off" or "acpi=noirq&qu
> > [ 279.662960] [] wait_for_completion+0xa4/0x110
possibly a missing interrupt?
> CONFIG_ACPI=y
any difference if booted with "acpi=off" or "acpi=noirq"?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo inf
>How can we handle it, if we do not even know that it failed?
>How should the user recognize something is broken?
We probably shouldn't have used the word "fail" here.
I expect the IO and MSR accesses will always "succeed",
but they may not always have the exact effect the OS requested.
I think
>Patch tested and works fine here. You should probably make a
>note in the bugzilla so we don't get a conflicting merge
>from the ACPI folks.
One might also consider that it would be a good idea to
send patches that break ACPI files to the ACPI maintainer
and [EMAIL PROTECTED] before sending th
applied to acpi test tree.
thanks,
-Len
>-Original Message-
>From: Venkatesh Pallipadi [mailto:[EMAIL PROTECTED]
>Sent: Friday, August 26, 2005 8:11 PM
>To: Andrew Morton
>Cc: linux-kernel; Brown, Len
>Subject: [PATCH] acpi-cpufreq: Remove P-state read after a
>P-
>Subject: 2.6.13-rc: ACPI_INTERPRETER=y, PCI=n compile error
>
>I got the following compile error in 2.6.13-rc6-mm2, but it
>seems to be
>a problem coming from Linus' tree introduced by the
> [ACPI] S3 resume: avoid kmalloc() might_sleep oops symptom
>patch:
>
><-- snip -->
>
>...
> LD
>What happened to those cleanups I sent to you in Ottawa?
Don't worry, they're in my to-akpm quilt series.
I just haven't committed/exported them yet -- as the 2.6.13
functional stuff is taking priority over cleanups for 2.6.14.
thanks,
-Len
-
To unsubscribe from this list: send the line "unsub
>So I guess I'll just have to revert the ACPI change that
>caused drivers to do request_irq/free_irq. I'd prefer it
>if the ACPI people did that revert themselves, though.
If that is what you want, I'll be happy to do it.
If one believes that suspend/resume is working on a large number of
system
>Len, Kevin confirms that the below patch fixes the above regression for
>him. Should we merge it now?
Yes.
It is in my to-linus git tree.
thanks,
-Len
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
>Sorry in taking so long to track this down. I just got motivated
>today.
>
>I have a VIA SMP system and somewhere between 2.6.12-rc3 and 2.6.12
>the USB mouse started moving around really slowly. Anyway, it turns
>out that the attached patch (against 2.6.13-rc3-git8) fixes
>the problem.
>
>Let m
>> I'm open to suggestions on how to approach this transition.
>> I can make ACPI_PROC a static build option -- what else
>> can I do to ease the transition in this, our stable release?
>
>Well I don't know how awkward this would be from an
>implementation POV, but can we just leave the legacy
>
>Len Brown <[EMAIL PROTECTED]> wrote:
>> I deleted /proc/acpi/button on purpose,
>> did you have a use for those files?
>
>Can we put it back, please?
of course.
>We cannot go ripping out stuff which applications and users
>are currently using without quite a lot of preparation.
Agreed. Altho
I agree that the value of _LID can be usefult to user-space
and I'll be sure it is restored as a property of the lid device
under sysfs -- available as a simple file read like it
was under /proc.
thanks,
-Len
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
>>>Trouble? Why would USB do DMA unless there was a device activity?
>>
>>
>> look here:
>> http://www.google.com/search?hl=en&q=usb+selective+suspend
>>
>> Linux is working on it too, but it is in development.
>
>Somehow I didn't ask that right... The stuff on selective disable is
>interesti
>On Sat, Jul 23, 2005 at 02:29:24AM +0200, Pavel Machek wrote:
>> > Is it necessary to do free_irq for suspend? Shouldn't disable_irq
>> > be enough?
>>
>> Due to recent changes in ACPI, yes, it is neccessary.
>
>What if some other driver is sharing the IRQ, and requires IRQs to be
>enabled for th
>>>Digging up this patch from last month regarding C2
>>>on a AMD K7 implies
>>>that the whole blame can be put on kernel acpi:
>>>
>>>http://marc.theaimsgroup.com/?l=linux-kernel&m=111933745131301&w=2
The current Linus tree includes generic ACPI support
for deep C-states on SMP machines. (deep
yes, this approach is valid.
I've done the exact same measurements for 100HZ vs 1000HZ.
For currently shipping laptops, I didn't see a significant
difference.,
Note that the quality of the instrumentation on
the battery can vary widely, and so if you really
want the best numbers you need to start
>On a HT system, why does ACPI recognize CPU0 and CPU1, refer
>to them as such in dmesg
This is the Linux CPU number. ie the namespace where 0
is the boot processor and the others are numbered in
the order that they were started.
> and then call them CPU1 and CPU2 in
>/proc/acpi/processor?
The
>>>Question one, are there other actions to consider?
>>
>>
>> Yes.
>> Speaking for ACPI C3 state, note that DMA also
>> wakes up the CPU -- even if there was no device interrupt.
>> (aka, "the trouble with USB")
>
>Trouble? Why would USB do DMA unless there was a device activity?
look here:
h
>I was thinking about variable tick times, and I can think of three
>classes of action needing CPU attention.
>- device interrupts, which occur at no predictable time but would pull
>the CPU out of a HLT or low power state.
>- process sleeps of various kinds, which have a known time of
>occure
Hi Linus,
Please pull from:
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/lenb/linux-2.6.git/
for a single patch that removes some recently added
debugging console messages.
thanks!
-Len
ec.c | 17 +++--
1 files changed, 3 insertions(+), 14 deletions(-)
commit 668d74c04c
>Still it would be nice to let people know what to do if they
>have problems with
>these changes. Many people don't run -rc kernels and even more people
>don't run -mm, so they have no idea that there are known
>regressions ...
I hope the broader exposure will break the EC patch on
another ma
>Len, ACPI people - can we fix this regression, please?
>
>Rafael even pinpoints exactly which patches are causing the
>problem, so why didn't they get reverted before sending them off to me?
Linus,
I'm sorry it was in '-rc3' -- that is as soon as I could
muster the bk->git transition. Now that
>That's an APIC bug.
>When Intel originally released the APIC (some
>thirteen years ago) they stated it should be used as a source of the
timer
>interrupt instead of the 8254. There is no excuse for changing the
>behaviour after so many years. So if you are on a broken system, you
may
>want to wo
>Of course using APIC internal timers is generally the best idea on SMP,
>but they may have had reasons to avoid them (it's not an ISA interrupt,
so
>it could have been simply out of question in the initial design).
Best? No.
Local APIC timers are based on a clock which on many processors will
S
>acpi_ec-0217 [04] acpi_ec_leave_burst_mo: --->status fail
>
>on the console, and then the machine is hung hard.
2.6.13-rc3 x86_64 failed, but
2.6.13-rc2 x86_64 worked
And both of these revisions in the i386 kernel still work?
>+evxfevnt-0203 [07] acpi_enable_event : Could not enable
po
>@Len:
>ACPI=y and ACPI_BOOT=n seems to be a legal configuration (with
>X86_HT=y), but it breaks into pieces if you try the compilation.
yeah, don't do that:-)
I'm sorry I didn't push the patch to delete CONFIG_ACPI_BOOT earlier.
For now, just enable them both.
thanks,
-Len
-
To unsubscribe from
90 matches
Mail list logo
