Announcement

Collapse
No announcement yet.

System does not find CPUs [dual core]

Collapse
This topic is closed.
X
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    System does not find CPUs [dual core]

    I think... Kinfocenter tells me I have a Pentium(R) Dual-Core CPU E6700 @ 3.20GHz. But /proc/cpuinfo only shows one core:

    $ cat /proc/cpuinfo | grep core
    core id : 0
    cpu cores : 1

    jon@jon-desktop:~/jon-files/jon-src/jalbum$ cat /proc/cpuinfo
    processor : 0
    vendor_id : GenuineIntel
    cpu family : 6
    model : 23
    model name : Pentium(R) Dual-Core CPU E6700 @ 3.20GHz
    stepping : 10
    microcode : 0xa07
    cpu MHz : 1600.000
    cache size : 2048 KB
    physical id : 0
    siblings : 1
    core id : 0
    cpu cores : 1
    apicid : 0
    initial apicid : 0
    fpu : yes
    fpu_exception : yes
    cpuid level : 13
    wp : yes
    flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good nopl aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm xsave lahf_lm dtherm tpr_shadow vnmi flexpriority
    bogomips : 6399.96
    clflush size : 64
    cache_alignment : 64
    address sizes : 36 bits physical, 48 bits virtual
    power management:

    Same result with lscpu;

    $ lscpu
    Architecture: x86_64
    CPU op-mode(s): 32-bit, 64-bit
    Byte Order: Little Endian
    CPU(s): 1
    On-line CPU(s) list: 0
    Thread(s) per core: 1
    Core(s) per socket: 1
    Socket(s): 1
    NUMA node(s): 1
    Vendor ID: GenuineIntel
    CPU family: 6
    Model: 23
    Stepping: 10
    CPU MHz: 1600.000
    BogoMIPS: 6399.96
    Virtualization: VT-x
    L1d cache: 32K
    L1i cache: 32K
    L2 cache: 2048K
    NUMA node0 CPU(s): 0

    So where is my other core?
    'I must have a prodigious quantity of mind; it takes me as much as a week sometimes to make it up.' Mark Twain

    #2
    What's the ouput of
    Code:
    lscpu
    
    lscpu -a -e
    
    dmesg | grep -i smp

    Comment


      #3
      More info. I have done 5 boots now. On three, I waited for grub to timeout and boot the system. On two, I hurried it along by hitting CR and not waiting for the timeout.

      When I wait out the timeout, all is well and the system finds both cores. E.g.,

      $ dmesg | grep -i smp
      [ 0.000000] Linux version 3.13.0-37-generic (buildd@kapok) (gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1) ) #64-Ubuntu SMP Mon Sep 22 21:28:38 UTC 2014 (Ubuntu 3.13.0-37.64-generic 3.13.11.7)
      [ 0.000000] found SMP MP-table at [mem 0x000f53c0-0x000f53cf] mapped at [ffff8800000f53c0]
      [ 0.000000] Using ACPI (MADT) for SMP configuration information
      [ 0.000000] smpboot: Allowing 4 CPUs, 2 hotplug CPUs
      [ 0.010399] Freeing SMP alternatives memory: 32K (ffffffff81e6e000 - ffffffff81e76000)
      [ 0.061066] smpboot: CPU0: Intel Pentium(R) Dual-Core CPU E6700 @ 3.20GHz (fam: 06, model: 17, stepping: 0a)
      [ 0.064000] x86: Booting SMP configuration:
      [ 0.074764] smpboot: Total of 2 processors activated (12801.18 BogoMIPS)

      Unfortunately, I have lost the dmesg, so I will now reboot again... Stay tuned, please.


      Psensor finds both cores and so does lscpu, etc.

      However, if I hit CR before grub times out, it only finds one core:
      'I must have a prodigious quantity of mind; it takes me as much as a week sometimes to make it up.' Mark Twain

      Comment


        #4
        Ok, one more "Hasty" boot and the result is consistent. Only one core found.

        $ lscpu
        Architecture: x86_64
        CPU op-mode(s): 32-bit, 64-bit
        Byte Order: Little Endian
        CPU(s): 1
        On-line CPU(s) list: 0
        Thread(s) per core: 1
        Core(s) per socket: 1
        Socket(s): 1
        NUMA node(s): 1
        Vendor ID: GenuineIntel
        CPU family: 6
        Model: 23
        Stepping: 10
        CPU MHz: 1600.000
        BogoMIPS: 6399.99
        Virtualization: VT-x
        L1d cache: 32K
        L1i cache: 32K
        L2 cache: 2048K
        NUMA node0 CPU(s): 0
        $ dmesg | grep -i smp
        [ 0.000000] Linux version 3.13.0-37-generic (buildd@kapok) (gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1) ) #64-Ubuntu SMP Mon Sep 22 21:28:38 UTC 2014 (Ubuntu 3.13.0-37.64-generic 3.13.11.7)
        [ 0.000000] found SMP MP-table at [mem 0x000f53c0-0x000f53cf] mapped at [ffff8800000f53c0]
        [ 0.000000] Using ACPI (MADT) for SMP configuration information
        [ 0.000000] smpboot: Allowing 4 CPUs, 2 hotplug CPUs
        [ 0.020375] Freeing SMP alternatives memory: 32K (ffffffff81e6e000 - ffffffff81e76000)
        [ 0.123368] smpboot: CPU0: Intel Pentium(R) Dual-Core CPU E6700 @ 3.20GHz (fam: 06, model: 17, stepping: 0a)
        [ 0.124000] x86: Booting SMP configuration:
        [ 10.160714] smpboot: CPU1: Not responding
        [ 10.160748] smpboot: Total of 1 processors activated (6399.99 BogoMIPS)
        [ 0.124000] Kernel panic - not syncing: smp_callin: CPU1 started up but did not get a callout!

        Is something buffering that CR and returning it at the wrong moment? For info, I have a Logitech K120 USB keyboard with a cable extension. Maybe I should go for a remote KB.
        'I must have a prodigious quantity of mind; it takes me as much as a week sometimes to make it up.' Mark Twain

        Comment


          #5
          Btw, lscpu -a -e says that both a and e are invalid options.
          'I must have a prodigious quantity of mind; it takes me as much as a week sometimes to make it up.' Mark Twain

          Comment


            #6
            Originally posted by joneall View Post
            More info. I have done 5 boots now. On three, I waited for grub to timeout and boot the system. On two, I hurried it along by hitting CR and not waiting for the timeout.

            When I wait out the timeout, all is well and the system finds both cores. However, if I hit CR before grub times out, it only finds one core:
            That is weird. Could GRUB be causing this? Compare your system boot logs with the one-core result and the dual-core result.

            Please Read Me

            Comment


              #7
              Originally posted by oshunluvr View Post
              That is weird. Could GRUB be causing this? Compare your system boot logs with the one-core result and the dual-core result.
              Problem is that /var/log/boot.log is quite short and only for the latest boot. Previous one is gone. I will manually save the current one and then reboot to see what gives.

              The pb is very evident in dmesg. In the good case:

              [ 0.061064] smpboot: CPU0: Intel Pentium(R) Dual-Core CPU E6700 @ 3.20GHz (fam: 06, model: 17, stepping: 0a)
              [ 0.064000] Performance Events: PEBS fmt0+, 4-deep LBR, Core2 events, Intel PMU driver.
              [ 0.064000] ... version: 2
              [ 0.064000] ... bit width: 40
              [ 0.064000] ... generic registers: 2
              [ 0.064000] ... value mask: 000000ffffffffff
              [ 0.064000] ... max period: 000000007fffffff
              [ 0.064000] ... fixed-purpose events: 3
              [ 0.064000] ... event mask: 0000000700000003
              [ 0.064000] x86: Booting SMP configuration:
              [ 0.064000] .... node #0, CPUs: #1
              [ 0.074757] x86: Booted up 1 node, 2 CPUs
              [ 0.074765] smpboot: Total of 2 processors activated (12801.10 BogoMIPS)


              In the bad:

              [ 0.123368] smpboot: CPU0: Intel Pentium(R) Dual-Core CPU E6700 @ 3.20GHz (fam: 06, model: 17, stepping: 0a)
              [ 0.124000] Performance Events: PEBS fmt0+, 4-deep LBR, Core2 events, Intel PMU driver.
              [ 0.124000] ... version: 2
              [ 0.124000] ... bit width: 40
              [ 0.124000] ... generic registers: 2
              [ 0.124000] ... value mask: 000000ffffffffff
              [ 0.124000] ... max period: 000000007fffffff
              [ 0.124000] ... fixed-purpose events: 3
              [ 0.124000] ... event mask: 0000000700000003
              [ 0.124000] x86: Booting SMP configuration:
              [ 0.124000] .... node #0, CPUs: #1
              [ 10.160714] smpboot: CPU1: Not responding
              [ 10.160745] x86: Booted up 1 node, 1 CPUs
              [ 10.160748] smpboot: Total of 1 processors activated (6399.99 BogoMIPS)

              What is the test it uses? Could there be a slight and erratic delay that Linux does not support? I am not _certain_ hitting CR in grub is what does it: My stats are too weak for that. I am keeping my eyes open.
              'I must have a prodigious quantity of mind; it takes me as much as a week sometimes to make it up.' Mark Twain

              Comment


                #8
                My last two boots have been withOUT the CR and the system only gets one CPU. So grub is not in cause.
                'I must have a prodigious quantity of mind; it takes me as much as a week sometimes to make it up.' Mark Twain

                Comment


                  #9
                  Originally posted by joneall View Post
                  In the bad:
                  . . .
                  [ 10.160714] smpboot: CPU1: Not responding
                  . . .
                  For some reason, one of your cores isn't responding. Could be a hardware problem -- either the motherboard or the CPU. Or possibly a firmware problem. Have you tried flashing the latest firmware available for your motherboard?

                  Comment


                    #10
                    Originally posted by SteveRiley View Post
                    For some reason, one of your cores isn't responding. Could be a hardware problem -- either the motherboard or the CPU. Or possibly a firmware problem. Have you tried flashing the latest firmware available for your motherboard?
                    I will have to find out how to do that. Is it safe?

                    In the meantime, following a lead on another site, I disconnected my external USB hub and the hub in my Samsung screen. I left only the keyboard, mouse and printer plugged into the back of the computer. (So no hub, no backup disk, no USB phone/e-book charger, no SD card reader.)

                    After rebooting my computer 7 times, waiting randomly for grub to timeout 3 times, both cores were detected each time. So I can conclude that grub is not a problem.

                    But why does a CPu not respond quickly enough because of a hub? Or is it Linux which is too hasty? Or something else?
                    'I must have a prodigious quantity of mind; it takes me as much as a week sometimes to make it up.' Mark Twain

                    Comment

                    Working...
                    X