Koozali.org: home of the SME Server

7.1.3 new installation - incorrect kernel choice?

Offline DavidClarke

  • 14
  • +0/-0
7.1.3 new installation - incorrect kernel choice?
« on: May 27, 2007, 11:57:09 AM »
I have just started the installation of a new SME server, using a Dell GX260 with P4 2.4GHz CPU.

I installed from a 7.1iso CD, and then immediately ran

   yum update

at the console. Firstly I got a message saying that yum was already running - although I could not see any activity on the network. So I shutdown and restarted, after which the update proceeded - downloading 240Mb of upgraded and new RPMs.

After the update is complete, and I have restarted the PC once more ! see that the kernel is:

Linux version 2.6.9-55.ELsmp (mockbuild@builder6.centos.org) (gcc version 3.4.6 20060404 (Red Hat 3.4.6-8)) #1 SMP Wed May 2 1
4:28:44 EDT 2007

Which is odd, because there is no mention of hyperthreading in the Dell BIOS setup (version A09), and other dmesg CPU-related lines include:

CPU: Hyper-Threading is disabled
CPU: After all inits, caps:        bfebf3ff 00000000 00000000 00000080
CPU0: Intel(R) Pentium(R) 4 CPU 2.40GHz stepping 07
Brought up 1 CPUs

cat /proc/cpuinfo gives:
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 15
model           : 2
model name      : Intel(R) Pentium(R) 4 CPU 2.40GHz
stepping        : 7
cpu MHz         : 2392.146
cache size      : 512 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 2
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca
                    cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss
                    ht tm pbe cid xtpr
bogomips        : 4785.79

Which seems to indicate a single CPU, albeit with the ht flag present.

So why should an smp kernel be selected? Is this a bad thing - should I manually reconfigure boot / grub defaults to select the uniprocessor version or can I safely leave the smp kernel running on a single core CPU?

Or Have I, in fact, got a hyperthreading, smp-capable CPU which is simply not enabled as such by the motherboard / BIOS, and is there a way around this (setting ht=on on the kernel parameters in grub.con had no effect).

Offline CharlieBrady

  • *
  • 6,918
  • +3/-0
Re: 7.1.3 new installation - incorrect kernel choice?
« Reply #1 on: May 27, 2007, 02:14:55 PM »
Quote from: "DavidClarke"

... or can I safely leave the smp kernel running on a single core CPU?


Yes you can. Later versions of RedHat won't even give you the choice.

Offline DavidClarke

  • 14
  • +0/-0
7.1.3 new installation - incorrect kernel choice?
« Reply #2 on: May 27, 2007, 05:11:43 PM »
Many thanks, Charlie, for the reassurance.
David Clarke

Offline cactus

  • *
  • 4,880
  • +3/-0
    • http://www.snetram.nl
Re: 7.1.3 new installation - incorrect kernel choice?
« Reply #3 on: May 27, 2007, 05:32:29 PM »
Quote from: "DavidClarke"
I installed from a 7.1iso CD, and then immediately ran

   yum update

at the console. Firstly I got a message saying that yum was already running - although I could not see any activity on the network.
This is due to yum updating its databases after reboot to populate the list of downloadable updates automatically, next time wait a few minutes and everything should be OK.
Be careful whose advice you buy, but be patient with those who supply it. Advice is a form of nostalgia, dispensing it is a way of fishing the past from the disposal, wiping it off, painting over the ugly parts and recycling it for more than its worth ~ Baz Luhrmann - Everybody's Free (To Wear Sunscreen)

Offline DavidClarke

  • 14
  • +0/-0
7.1.3 new installation - incorrect kernel choice?
« Reply #4 on: May 27, 2007, 11:26:23 PM »
Thanks for that explanation.

Perhaps people who create a 'clean installation' like this need to be advised to let the system 'settle down' before running commands such as 'yum update'?

I've installed 7.1 (and earlier) versions and let them update automatically / run the manual update many times and not encountered this conflict before. Perhaps I was in too much of a hurry this time, and as I knew that we'd moved on to 7.1.3 it seemed a good idea to run the update immediately.

Of course, as the system wasn't going to /do/ anything until somewhat later on (after the manual installation of local software, etc.) I should perhaps have carried out my local customisations, and /then/ run the system update.

David Clarke