linux-acpi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* 2.6.16rc5 'found' an extra CPU.
@ 2006-03-01 22:46 Dave Jones
  2006-03-01 23:03 ` Dave Jones
  0 siblings, 1 reply; 33+ messages in thread
From: Dave Jones @ 2006-03-01 22:46 UTC (permalink / raw)
  To: linux-kernel; +Cc: linux-acpi

This amused me.

(17:43:34:davej@nemesis:~)$ ll /proc/acpi/processor/
total 0
dr-xr-xr-x 2 root root 0 Mar  1 17:43 CPU1/
dr-xr-xr-x 2 root root 0 Mar  1 17:43 CPU2/
dr-xr-xr-x 2 root root 0 Mar  1 17:43 CPU3/
(17:43:36:davej@nemesis:~)$

As cool as a 3-way x86-64 sounds, it's really only got 2.

Two of these..

vendor_id       : AuthenticAMD
cpu family      : 15
model           : 5
model name      : AMD Opteron(tm) Processor 244
stepping        : 8
cpu MHz         : 1789.412
cache size      : 1024 KB
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext lm 3dnowext 3dnow
bogomips        : 3578.59
TLB size        : 1024 4K pages
clflush size    : 64
cache_alignment : 64
address sizes   : 40 bits physical, 48 bits virtual
power management: ts ttp


(17:45:21:davej@nemesis:~)$ cat /proc/acpi/processor/CPU*/info
processor id:            0
acpi id:                 1
bus mastering control:   no
power management:        no
throttling control:      yes
limit interface:         yes
processor id:            1
acpi id:                 2
bus mastering control:   no
power management:        no
throttling control:      no
limit interface:         no
processor id:            255
acpi id:                 3
bus mastering control:   no
power management:        no
throttling control:      no
limit interface:         no

I guess the '255' has confused something.

This made my 'bug of the day' :)

		Dave


^ permalink raw reply	[flat|nested] 33+ messages in thread
* RE: 2.6.16rc5 'found' an extra CPU.
@ 2006-03-01 23:01 Moore, Robert
  0 siblings, 0 replies; 33+ messages in thread
From: Moore, Robert @ 2006-03-01 23:01 UTC (permalink / raw)
  To: Dave Jones, linux-kernel; +Cc: linux-acpi

This may be the "ACPI core", dedicated to running the ACPI interpreter.

:-)



> -----Original Message-----
> From: linux-acpi-owner@vger.kernel.org [mailto:linux-acpi-
> owner@vger.kernel.org] On Behalf Of Dave Jones
> Sent: Wednesday, March 01, 2006 2:47 PM
> To: linux-kernel@vger.kernel.org
> Cc: linux-acpi@vger.kernel.org
> Subject: 2.6.16rc5 'found' an extra CPU.
> 
> This amused me.
> 
> (17:43:34:davej@nemesis:~)$ ll /proc/acpi/processor/
> total 0
> dr-xr-xr-x 2 root root 0 Mar  1 17:43 CPU1/
> dr-xr-xr-x 2 root root 0 Mar  1 17:43 CPU2/
> dr-xr-xr-x 2 root root 0 Mar  1 17:43 CPU3/
> (17:43:36:davej@nemesis:~)$
> 
> As cool as a 3-way x86-64 sounds, it's really only got 2.
> 
> Two of these..
> 
> vendor_id       : AuthenticAMD
> cpu family      : 15
> model           : 5
> model name      : AMD Opteron(tm) Processor 244
> stepping        : 8
> cpu MHz         : 1789.412
> cache size      : 1024 KB
> fpu             : yes
> fpu_exception   : yes
> cpuid level     : 1
> wp              : yes
> flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca
> cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext lm 3dnowext
> 3dnow
> bogomips        : 3578.59
> TLB size        : 1024 4K pages
> clflush size    : 64
> cache_alignment : 64
> address sizes   : 40 bits physical, 48 bits virtual
> power management: ts ttp
> 
> 
> (17:45:21:davej@nemesis:~)$ cat /proc/acpi/processor/CPU*/info
> processor id:            0
> acpi id:                 1
> bus mastering control:   no
> power management:        no
> throttling control:      yes
> limit interface:         yes
> processor id:            1
> acpi id:                 2
> bus mastering control:   no
> power management:        no
> throttling control:      no
> limit interface:         no
> processor id:            255
> acpi id:                 3
> bus mastering control:   no
> power management:        no
> throttling control:      no
> limit interface:         no
> 
> I guess the '255' has confused something.
> 
> This made my 'bug of the day' :)
> 
> 		Dave
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-acpi"
in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 33+ messages in thread
* Re: 2.6.16rc5 'found' an extra CPU.
@ 2006-03-02  0:55 Chuck Ebbert
  2006-03-02  1:09 ` Dave Jones
  0 siblings, 1 reply; 33+ messages in thread
From: Chuck Ebbert @ 2006-03-02  0:55 UTC (permalink / raw)
  To: Dave Jones; +Cc: linux-kernel, linux-acpi, Andi Kleen

In-Reply-To: <20060301230317.GF1440@redhat.com>

On Wed, 1 Mar 2006 18:03:17, Dave Jones wrote:

> (17:59:38:davej@nemesis:~)$ cat /sys/devices/system/cpu/cpu0/topology/core_siblings
> 00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000001
> (17:59:47:davej@nemesis:~)$ cat /sys/devices/system/cpu/cpu1/topology/core_siblings
> 00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000002
> 
> Neither of these CPUs are HT / dual-core, so shouldn't these be the same ?

Those are bitmaps. 1 => only bit 0 is set => CPU 0 is all alone.

Did you really build a 256-CPU SMP kernel or is ACPI ignoring CONFIG_NR_CPUS
or something?


-- 
Chuck
"The sleet in Crete falls neatly in the street."


^ permalink raw reply	[flat|nested] 33+ messages in thread
* RE: 2.6.16rc5 'found' an extra CPU.
@ 2006-03-02  5:49 Brown, Len
  2006-03-02  9:33 ` Romano Giannetti
                   ` (2 more replies)
  0 siblings, 3 replies; 33+ messages in thread
From: Brown, Len @ 2006-03-02  5:49 UTC (permalink / raw)
  To: Dave Jones, Raj, Ashok; +Cc: Andi Kleen, linux-kernel, linux-acpi


>sysfs gets it right.
>
>(23:11:01:davej@nemesis:~)$ ls /sys/devices/system/cpu/
>cpu0/  cpu1/
>(23:11:07:davej@nemesis:~)$ ls /proc/acpi/processor/
>CPU1/  CPU2/  CPU3/

This is because the BIOS has three "Processor" objects in the DSDT.

As I've mentioned before, /proc/acpi/*/* should not exist.
Internal ACPI BIOS names "CPU1, CPU1, CPU3" in this case
are actually arbitray 4-character strings, and should
never be exposed to the user in the file-system.

sysfs with cpu0, cpu1 -- predictable strings for objects --
gets it right, and is the direction we are going.

I'm afraid that even after we get this stuff out of /proc
and into sysfs where it belongs, we'll have to leave /proc/acpi around
for a while b/c unfortunately people are under the impression
that the path names there actually mean something and
they can actually count on them -- which they can't.

-Len

^ permalink raw reply	[flat|nested] 33+ messages in thread
* RE: 2.6.16rc5 'found' an extra CPU.
@ 2006-03-02 17:30 Brown, Len
  0 siblings, 0 replies; 33+ messages in thread
From: Brown, Len @ 2006-03-02 17:30 UTC (permalink / raw)
  To: Andi Kleen
  Cc: Dave Jones, Raj, Ashok, linux-kernel, linux-acpi, Mochel, Patrick


>On Thursday 02 March 2006 06:49, Brown, Len wrote:
>
>> I'm afraid that even after we get this stuff out of /proc
>> and into sysfs where it belongs, we'll have to leave 
>/proc/acpi around
>> for a while b/c unfortunately people are under the impression
>> that the path names there actually mean something and
>> they can actually count on them -- which they can't.
>
>But they should. Once you provide an interface here you 
>have to provide it essentially forever. Or at least if you really
>change it use a very long deprecation period, but even that 
>is a bad thing to do to users.

The 4-character strings in the path names (eg "CPU0") are _arbitrary_.
They come _directly_ from the BIOS source code and depend
on whatever mood the BIOS writer was in that day.
For this reason, users _can't_ count on these strings
and these path-names being consistent across platforms.

Yes, this is a horrible design.
Yes, I want to delete it in favor of sysfs as soon as possible,
Patrick has a big patch set in development to get that ball rolling.
Yes, users kick and scream whenever you change something they can see
and thus it takes a long time.

-Len

^ permalink raw reply	[flat|nested] 33+ messages in thread
* RE: 2.6.16rc5 'found' an extra CPU.
@ 2006-03-02 17:34 Brown, Len
  0 siblings, 0 replies; 33+ messages in thread
From: Brown, Len @ 2006-03-02 17:34 UTC (permalink / raw)
  Cc: Dave Jones, Raj, Ashok, Andi Kleen, linux-kernel, linux-acpi


>I have a dual core + HT platform. I disabled HT to have the 
>same situation as Dave.
>
>ACPI DSDT dump shows 4 objects in \_PR scope as below.
>
>    Scope (\_PR)
>    {
>        Processor (CPU0, 0x01, 0x00000410, 0x06) {}
>        Processor (CPU1, 0x02, 0x00000410, 0x06) {}
>        Processor (CPU2, 0x03, 0x00000410, 0x06) {}
>        Processor (CPU3, 0x04, 0x00000410, 0x06) {}
>    }
>
>Only 2 are marked enabled in the ACPI MADT..
>
>From boot log
>
>ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
>Processor #0 15:4 APIC version 20
>ACPI: LAPIC (acpi_id[0x03] lapic_id[0x02] enabled)
>Processor #2 15:4 APIC version 20
>ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] disabled)
>ACPI: LAPIC (acpi_id[0x04] lapic_id[0x03] disabled)
>
>But proc/acpi/processor also lists just 2 entries.

We were certainly on safer ground when we used
to completely ignore disabled entries.

-Len

^ permalink raw reply	[flat|nested] 33+ messages in thread
* RE: 2.6.16rc5 'found' an extra CPU.
@ 2006-03-02 19:16 Brown, Len
  0 siblings, 0 replies; 33+ messages in thread
From: Brown, Len @ 2006-03-02 19:16 UTC (permalink / raw)
  To: Romano Giannetti, Zwane Mwaikambo
  Cc: Dave Jones, Raj, Ashok, Andi Kleen, linux-kernel, linux-acpi

> /proc/acpi/processor/CPU0/throttling 

Yes, the generic layer should expose throttling.
But before it does so, it needs to learn that T-states
have very different implications from P-states.

Indeed it is a bug in the current architecture that
P-states are exposed by cpufreq on some systems,
and T-states are exposed on other systems, and
they are treated like they are the same.

It is also bug that T-states are exposed
on some systems, while ACPI is simultaneously
assuming exclusive access to them for thermal throttling.

-Len

^ permalink raw reply	[flat|nested] 33+ messages in thread
* RE: 2.6.16rc5 'found' an extra CPU.
@ 2006-03-02 19:18 Brown, Len
  0 siblings, 0 replies; 33+ messages in thread
From: Brown, Len @ 2006-03-02 19:18 UTC (permalink / raw)
  Cc: Dave Jones, Raj, Ashok, Andi Kleen, linux-kernel, linux-acpi

 
>I have a dual core + HT platform. I disabled HT to have the 
>same situation as Dave.
>
>ACPI DSDT dump shows 4 objects in \_PR scope as below.
>
>    Scope (\_PR)
>    {
>        Processor (CPU0, 0x01, 0x00000410, 0x06) {}
>        Processor (CPU1, 0x02, 0x00000410, 0x06) {}
>        Processor (CPU2, 0x03, 0x00000410, 0x06) {}
>        Processor (CPU3, 0x04, 0x00000410, 0x06) {}
>    }
>
>Only 2 are marked enabled in the ACPI MADT..
>
>From boot log
>
>ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
>Processor #0 15:4 APIC version 20
>ACPI: LAPIC (acpi_id[0x03] lapic_id[0x02] enabled)
>Processor #2 15:4 APIC version 20
>ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] disabled)
>ACPI: LAPIC (acpi_id[0x04] lapic_id[0x03] disabled)
>
>But proc/acpi/processor also lists just 2 entries.
>
>[root@araj-sfield-2 tmp]# ls /proc/acpi/processor/
>CPU0  CPU2


This system looks totally correct to me.
Do you see something wrong with it?

-Len

^ permalink raw reply	[flat|nested] 33+ messages in thread
* RE: 2.6.16rc5 'found' an extra CPU.
@ 2006-03-02 19:26 Brown, Len
  2006-03-02 19:31 ` Dave Jones
  2006-03-02 19:33 ` Andi Kleen
  0 siblings, 2 replies; 33+ messages in thread
From: Brown, Len @ 2006-03-02 19:26 UTC (permalink / raw)
  To: Dave Jones, Chuck Ebbert; +Cc: linux-kernel, linux-acpi, Andi Kleen

Dave,
Your DSDT looks fine.
I was wrong assuming there were 3 Processor entries there.

> > Did you really build a 256-CPU SMP kernel or is ACPI 
> > ignoring CONFIG_NR_CPUS or something?
>
>Yes, it's =256.

I expect this is the root problem.

-Len



^ permalink raw reply	[flat|nested] 33+ messages in thread
* RE: 2.6.16rc5 'found' an extra CPU.
@ 2006-03-02 19:37 Brown, Len
  0 siblings, 0 replies; 33+ messages in thread
From: Brown, Len @ 2006-03-02 19:37 UTC (permalink / raw)
  To: Dave Jones; +Cc: Chuck Ebbert, linux-kernel, linux-acpi, Andi Kleen


>On Thu, Mar 02, 2006 at 02:26:24PM -0500, Brown, Len wrote:
> > Dave,
> > Your DSDT looks fine.
> > I was wrong assuming there were 3 Processor entries there.
> > 
> > > > Did you really build a 256-CPU SMP kernel or is ACPI 
> > > > ignoring CONFIG_NR_CPUS or something?
> > >
> > >Yes, it's =256.
> > 
> > I expect this is the root problem.
>
>If this is the _cause_, something needs fixing, but it's hardly
>something we can brush off as 'the root problem'.
>
>It's entirely possible for such a configuration (higher
>CONFIG_NR_CPUS than actual cpus), cf. distro kernels.

I agree.
Did Ashok's sigined-unsigned patch work?

^ permalink raw reply	[flat|nested] 33+ messages in thread
end of thread, other threads:[~2006-03-05  2:26 UTC | newest]

Thread overview: 33+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-03-01 22:46 2.6.16rc5 'found' an extra CPU Dave Jones
2006-03-01 23:03 ` Dave Jones
2006-03-02  0:55   ` Andi Kleen
2006-03-02  1:19     ` Dave Jones
2006-03-02  1:38       ` Andi Kleen
2006-03-02  3:13         ` Dave Jones
2006-03-02  3:24           ` Andi Kleen
2006-03-02  3:45             ` Dave Jones
2006-03-02  3:52         ` Ashok Raj
2006-03-02  4:11           ` Dave Jones
  -- strict thread matches above, loose matches on Subject: below --
2006-03-01 23:01 Moore, Robert
2006-03-02  0:55 Chuck Ebbert
2006-03-02  1:09 ` Dave Jones
2006-03-05  0:42   ` Andrew Morton
2006-03-05  2:26     ` Dave Jones
2006-03-02  5:49 Brown, Len
2006-03-02  9:33 ` Romano Giannetti
2006-03-02 15:53   ` Zwane Mwaikambo
2006-03-02 15:58     ` Romano Giannetti
2006-03-02 12:14 ` Andi Kleen
2006-03-02 16:30 ` Ashok Raj
2006-03-02 18:44   ` Dave Jones
2006-03-02 19:21     ` Ashok Raj
2006-03-03  7:14       ` Andrew Morton
2006-03-03 17:41         ` Ashok Raj
2006-03-02 17:30 Brown, Len
2006-03-02 17:34 Brown, Len
2006-03-02 19:16 Brown, Len
2006-03-02 19:18 Brown, Len
2006-03-02 19:26 Brown, Len
2006-03-02 19:31 ` Dave Jones
2006-03-02 19:33 ` Andi Kleen
2006-03-02 19:37 Brown, Len

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).