# AMD64 X2 recognized as single cpu

## percy

I have a desktop with an AMD64 X2 dual core CPU running on Gentoo 2007.1 (for x86_32). Before, the cpuinfo displays 2 processors but not until recently, I just  found out that /proc/cpuinfo recognizes this as single processor. Too bad I was not able to backup the old kernel (I'm using gentoo genkernel in building kernel.)

This problem did not exists in gentoo/ubuntu live cds - there were 2 processors recognized in  /proc/cpuinfo. I also tried using the configuration of the live cds but I was not able to solve the problem. 

By the way, I have the following features enabled in my config ( I'm using 2.6.22-gentoo-r8 custom kernel) :

```

Processor type and features

    [*] Symmetric multi-processing support

    [*] SMT (Hyperthreading) scheduler support

    [*] Multi-core scheduler support
```

Here's the cpuinfo:

```
processor : 0

vendor_id : AuthenticAMD

cpu family : 15

model : 75

model name : AMD Athlon(tm) 64 X2 Dual Core Processor 3800+

stepping : 2

cpu MHz : 1999.935

cache size : 512 KB

physical id : 0

siblings : 1

core id : 0

cpu cores : 1

fdiv_bug : no

hlt_bug : no

f00f_bug : no

coma_bug : no

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 ht syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow pni cx16 lahf_lm cmp_legacy svm extapic cr8legacy ts fid vid ttp tm stc bogomips : 4090.38 

clflush size : 64

```

Here's a snippet of the dmesg:

```

percy at localhost ~ $ dmesg | grep -i cpu

Initializing CPU#0

CPU 0 irqstacks, hard=c0460000 soft=c045e000

CPU: After generic identify, caps: 178bfbff ebd3fbff 00000000 00000000

00002001 00000000 0000001f

CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)

CPU: L2 Cache: 512K (64 bytes/line)

CPU 0(2) -> Core 0

CPU: After all inits, caps: 178bfbff ebd3fbff 00000000 00000410

00002001 00000000 0000001f

CPU0: AMD Athlon(tm) 64 X2 Dual Core Processor 3800+ stepping 02

CPU 1 irqstacks, hard=c0461000 soft=c045f000

CPU #1 not responding - cannot use it. <------------ What causes this?

Brought up 1 CPUs
```

Thinking that it was an ACPI problem, I tried to pass noacpi in the kernel parameters but it didn't nailed it.

Any thoughts?

Thanks.

----------

## DaggyStyle

this: [*] SMT (Hyperthreading) scheduler support  isnt needed

any kernel parameters?

----------

## percy

 *DaggyStyle wrote:*   

> this: [*] SMT (Hyperthreading) scheduler support  isnt needed
> 
> any kernel parameters?

 

I just removed SMT/HyperThreading support but it did not nailed it. I'm not passing any kernel params now. Here's a portion of my config:

```
#

# Processor type and features

#

CONFIG_SMP=y

CONFIG_X86_PC=y

CONFIG_MK8=y

CONFIG_X86_CMPXCHG=y

CONFIG_X86_L1_CACHE_SHIFT=6

CONFIG_X86_XADD=y

CONFIG_RWSEM_XCHGADD_ALGORITHM=y

CONFIG_GENERIC_CALIBRATE_DELAY=y

CONFIG_X86_WP_WORKS_OK=y

CONFIG_X86_INVLPG=y

CONFIG_X86_BSWAP=y

CONFIG_X86_POPAD_OK=y

CONFIG_X86_GOOD_APIC=y

CONFIG_X86_INTEL_USERCOPY=y

CONFIG_X86_USE_PPRO_CHECKSUM=y

CONFIG_X86_TSC=y

CONFIG_X86_MINIMUM_CPU_MODEL=4

CONFIG_NR_CPUS=2

CONFIG_SCHED_MC=y

CONFIG_PREEMPT=y

CONFIG_PREEMPT_BKL=y

CONFIG_X86_LOCAL_APIC=y

CONFIG_X86_IO_APIC=y

CONFIG_VM86=y

CONFIG_TOSHIBA=m

CONFIG_I8K=m

CONFIG_X86_REBOOTFIXUPS=y

CONFIG_MICROCODE=m

CONFIG_MICROCODE_OLD_INTERFACE=y

CONFIG_X86_MSR=m

CONFIG_X86_CPUID=m
```

----------

## 96140

--Last edited by 96140 on Fri Sep 13, 2013 8:57 am; edited 1 time in total

----------

## percy

 *nightmorph wrote:*   

> You're not running 2007.1 . . . because it won't be released until November. You're running 2007.0.

 

Ooops my bad. Yeah, it's 2007.0. Sorry for the confusion.

 *nightmorph wrote:*   

> 
> 
> Anyway, first, get rid of SMT/Hyperthreading. Next, you'll want at least the following in your kernel config, found under Processor Type & Features:
> 
> ```
> ...

 

Is this a 64 bit kernel? I'm using a 32 bit kernel. I've posted a portion of my kernel config in my previous post. You might want to check it out.

 *nightmorph wrote:*   

> 
> 
> Sudden thought: Are you using an amd64 stage or an x86 stage tarball? 
> 
> 

 

I'm using an x86_32 stage.

----------

## Konsti

Your options and the stage chosen seems to be okay (but is x86_32 not called i686?). What is left is tocheck, if it is really the kernel you compiled this way is the booted one. Is this shure also?

----------

## percy

 *Konsti wrote:*   

> Your options and the stage chosen seems to be okay (but is x86_32 not called i686?). What is left is tocheck, if it is really the kernel you compiled this way is the booted one. Is this shure also?

 

Yups, I'm getting the proper configuration via the kernel knob /proc/config.gz

I've also posted this problem to the good guys at AMD64 discuss list - I'm still waiting for their inputs.

----------

## Konsti

Argh! Sorry, I overlooked that you get an error message and the kernel tries actually!

Hm, did you consider trying out a more old kernel? May be this new x86 setup code is behaving not well (or is this introduced in 2.6.23, I am not sure). It is possible all working boot cds are using an older kernel, this is because they work. at least o sort this out...

On what Hardware is this?

----------

## percy

 *Konsti wrote:*   

> Argh! Sorry, I overlooked that you get an error message and the kernel tries actually!
> 
> Hm, did you consider trying out a more old kernel? May be this new x86 setup code is behaving not well (or is this introduced in 2.6.23, I am not sure). It is possible all working boot cds are using an older kernel, this is because they work. at least o sort this out...
> 
> On what Hardware is this?

 

The hardware is AMDX2 64bit 3800+ on an ECS AMD690GM-M2 motherboard.  

http://www.motherboards.org/reviews/motherboards/1700_1.html

----------

## 96140

--Last edited by 96140 on Fri Sep 13, 2013 8:57 am; edited 1 time in total

----------

## Konsti

May be he wants to stay 32bit. I did this recently, merely I switched back from 64bit to an i686 stage. Despite of that SMP with an X2 amd64 should work well both ways (as it is on my machine).

----------

## zeek

 *nightmorph wrote:*   

> 
> 
> [*] Non Uniform Memory Access (NUMA) Support
> 
> [*] ACPI NUMA detection
> ...

 

X2 isn't NUMA, its SMP.  Only multiple physical processors are NUMA (usually Opterons right now).

Make sure you have kernel options power management, acpi, processor, and thermal zone built and if they're modules loaded and running.

----------

## 96140

--Last edited by 96140 on Fri Sep 13, 2013 8:56 am; edited 1 time in total

----------

## percy

Hi guys, I haven't solved this problem yet. Anymore thoughts? I've already tried posting the same problem to the AMD64 ML but didn't get any substantial results.

Here's a more complete dmesg output:[/code]

```
Kernel command line: root=/dev/ram0 init=/linuxrc ramdisk=8192 real_root=/dev/hda9 vga=791 splash=silent,theme:livecd-2007.0 CONSOLE=/dev/tty1 quiet

mapped APIC to ffffd000 (fee00000)

mapped IOAPIC to ffffc000 (fec00000)

Enabling fast FPU save and restore... done.

Enabling unmasked SIMD FPU exception support... done.

Initializing CPU#0

CPU 0 irqstacks, hard=c0460000 soft=c045e000

PID hash table entries: 4096 (order: 12, 16384 bytes)

Detected 1999.873 MHz processor.

Console: colour dummy device 80x25

Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)

Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)

Memory: 1942272k/1965952k available (2512k kernel code, 22424k reserved, 623k data, 268k init, 1048448k highmem)

virtual kernel memory layout:

    fixmap  : 0xfff9d000 - 0xfffff000   ( 392 kB)

    pkmap   : 0xff800000 - 0xffc00000   (4096 kB)

    vmalloc : 0xf8800000 - 0xff7fe000   ( 111 MB)

    lowmem  : 0xc0000000 - 0xf8000000   ( 896 MB)

      .init : 0xc0416000 - 0xc0459000   ( 268 kB)

      .data : 0xc0374334 - 0xc0410164   ( 623 kB)

      .text : 0xc0100000 - 0xc0374334   (2512 kB)

Checking if this processor honours the WP bit even in supervisor mode... Ok.

Calibrating delay using timer specific routine.. 4090.34 BogoMIPS (lpj=20451708)

Mount-cache hash table entries: 512

CPU: After generic identify, caps: 178bfbff ebd3fbff 00000000 00000000 00002001 00000000 0000001f

CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)

CPU: L2 Cache: 512K (64 bytes/line)

CPU 0(2) -> Core 0

CPU: After all inits, caps: 178bfbff ebd3fbff 00000000 00000410 00002001 00000000 0000001f

Compat vDSO mapped to ffffe000.

Checking 'hlt' instruction... OK.

Freeing SMP alternatives: 12k freed

ACPI: Core revision 20070126

CPU0: AMD Athlon(tm) 64 X2 Dual Core Processor 3800+ stepping 02

Booting processor 1/1 eip 2000

CPU 1 irqstacks, hard=c0461000 soft=c045f000

Not responding.

Inquiring remote APIC #1...

... APIC #1 ID: 1000000

... APIC #1 VERSION: 80050010

... APIC #1 SPIV: ff

CPU #1 not responding - cannot use it.

Total of 1 processors activated (4090.34 BogoMIPS).

```

----------

## percy

 *Quote:*   

>  *nightmorph wrote:*   
> 
> X2 isn't NUMA, its SMP.  Only multiple physical processors are NUMA (usually Opterons right now). 
> 
> Wrong, according to AMD. From one of their whitepapers:
> ...

 

Thanks for all the help and information. I was able to figure out what causes the problem. Apparently, it was the experimental 64 bit Memory and IO resources option in the Processor types and features section.

```
# CONFIG_RESOURCES_64BIT is not set
```

After unsetting this, the kernel finally recognized the 2 cores.

```
percy@localhost ~ $ dmesg | grep -i cpu

Initializing CPU#0

CPU 0 irqstacks, hard=c0471000 soft=c046f000

CPU: After generic identify, caps: 178bfbff ebd3fbff 00000000 00000000 00002001 00000000 0000001f

CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)

CPU: L2 Cache: 512K (64 bytes/line)

CPU 0(2) -> Core 0

CPU: After all inits, caps: 178bfbff ebd3fbff 00000000 00000410 00002001 00000000 0000001f

CPU0: AMD Athlon(tm) 64 X2 Dual Core Processor 3800+ stepping 02

CPU 1 irqstacks, hard=c0472000 soft=c0470000

Initializing CPU#1

CPU: After generic identify, caps: 178bfbff ebd3fbff 00000000 00000000 00002001 00000000 0000001f

CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)

CPU: L2 Cache: 512K (64 bytes/line)

CPU 1(2) -> Core 1

CPU: After all inits, caps: 178bfbff ebd3fbff 00000000 00000410 00002001 00000000 0000001f

CPU1: AMD Athlon(tm) 64 X2 Dual Core Processor 3800+ stepping 02

Brought up 2 CPUs

percy@localhost ~ $ grep -i processor /proc/cpuinfo

processor       : 0

model name      : AMD Athlon(tm) 64 X2 Dual Core Processor 3800+

processor       : 1

model name      : AMD Athlon(tm) 64 X2 Dual Core Processor 3800+

percy@localhost ~ $

```

Thanks for all the very helpful inputs.

Cheers.

----------

## Cyker

No, thank YOU for posting the fix!  :Wink: 

I don't think I'd have ever figure that out  :Razz: 

Where is this NUMA option anyway? I don't see it in 2.6.23-gentoo.

Can you pick that instead of SMP if you're using a K8? Does it work better?

----------

## neiljw

 *Cyker wrote:*   

> Where is this NUMA option anyway?

 

It's a way of using memory more efficiently on multi-processor systems. That is, physically separate processors. It is irrelevant and unsupported by single chip multi-core processors.

 *Quote:*   

> I don't see it in 2.6.23-gentoo.

 

It's there on mine.

 *Quote:*   

> Can you pick that instead of SMP if you're using a K8?

 

No. It works with SMP on multi-processor systems.

----------

## darklegion

I had the same problem but CONFIG_RESOURCES_64BIT wasn't available through menuconfig and when I changed it to "# CONFIG_RESOURCES_64bit is not set" or CONFIG_RESOURCES_64bit=no it would just reset itself back to CONFIG_RESOURCES_64bit=y after running make.So I put "noapic" on my kernel commandline and that seems to of fixed it (probably should run a few more restarts to be sure).

My question is, does turning of the ioapic result in any performance loss or other issues?

----------

## Cyker

IIRC, that limits your system to using the 'normal' AT IRQs up to 15, rather than the 26+ you can get with the APIC on.

You're probably okay if it isn't causing problems with anything else.

The APIC is supposedly needed for multi-cpu setups, but I don't know about multi-core.

----------

