[NTLUG:Discuss] possible processor problems

Wed Feb 15 07:05:53 CST 2006

Stuart,

I wasn't sure if I was interpreting the logs correctly, or if the logs
reported the cpu stat differently between distributions (although unlikely).
Do I have only one physical cpu working with ht, or do I have 2 processors
working with no ht?  Why the difference?  Surely FC4 with with a 2.6.x
kernel can deal with ht, at least one would think.

The questionable server is having issues with gigabit file transfers where
the files are over 1gig in size.  I remember reading "somewhere" that
gigabit nics and/or transfers are more cpu intensive than 100baseT nics.
So, when I looked at /proc/cpuinfo, and didn't see 4 cpus indicated, my
curiosity was raised.  (100baseT transfers work fine, using the same onboard
nics and 3Com 3870 switch.)

Anyway, I want to respect the group and not delve into off-topic
hardware/networking issues on the list.  Just wanted to make sure FC4 was
reporting correctly, and I was interpreting the logs correctly.

Thanks as always for your help.

Monty

-----Original Message-----
From: Stuart Johnston [mailto:saj at thecommune.net]
Sent: Tuesday, February 14, 2006 6:36 PM
To: NTLUG Discussion List
Subject: Re: [NTLUG:Discuss] possible processor problems

What is making you think that one is missing a CPU?  Both log files show 
two physical CPUs.  The first one does not seem to be using 
HyperThreading.  Is that the problem?

MontyS at videopost.com wrote:
> Greetings.
> 
> I have 2 dual processor servers with Xeon processors on Supermicro
> motherboards.  It appears that one of the servers has lost a processor.  I
> am not positive, however, since I am running different versions of linux
on
> each server.
> 
> The server that appears to be less one processor is running Fedora Core 4.
> The server that appears correct is running RHES3.  I guess I want to make
> sure Fedora Core 4 reports the correct number of processors.
> 
> Below is the >>uname -r<< and grepped message log files after a reboot.
The
> dmesg log file doesn't illuminate the problem any, except the server with
> the problem indicates that the Xeon processors are Lindhurst.  Again, I
> don't know if that makes any difference.
> 
> Please forgive the length of this email.
> 
> Thanks as always for your help.
> 
> Monty
> 
>>> Questionable server<<
> 
> Linux  2.6.13-1.1526_FC4smp #1 SMP Wed Sep 28 19:30:04 EDT 2005 i686 i686
> i386 GNU/Linux
> 
> Feb 14 09:03:33  kernel: Initializing CPU#0
> Feb 14 09:03:33  kernel: CPU 0 irqstacks, hard=c043b000 soft=c041b000
> Feb 14 09:03:34  kernel: CPU: Trace cache: 12K uops, L1 D cache: 16K
> Feb 14 09:03:34  kernel: CPU: L2 cache: 1024K
> Feb 14 09:03:34  kernel: CPU: Physical Processor ID: 0
> Feb 14 09:03:34  kernel: Intel machine check reporting enabled on CPU#0.
> Feb 14 09:03:34  kernel: CPU0: Intel P4/Xeon Extended MCE MSRs (24)
> available
> Feb 14 09:03:34  kernel: CPU0: Thermal monitoring enabled
> Feb 14 09:03:34  kernel: CPU0: Intel(R) Xeon(TM) CPU 3.00GHz stepping 01
> Feb 14 09:03:34  kernel: CPU 1 irqstacks, hard=c043c000 soft=c041c000
> Feb 14 09:03:34  kernel: Initializing CPU#1
> Feb 14 09:03:34  kernel: CPU: Trace cache: 12K uops, L1 D cache: 16K
> Feb 14 09:03:34  kernel: CPU: L2 cache: 1024K
> Feb 14 09:03:34  kernel: CPU: Physical Processor ID: 3
> Feb 14 09:03:34  kernel: Intel machine check reporting enabled on CPU#1.
> Feb 14 09:03:34  kernel: CPU1: Intel P4/Xeon Extended MCE MSRs (24)
> available
> Feb 14 09:03:34  kernel: CPU1: Thermal monitoring enabled
> Feb 14 09:03:34  kernel: CPU1: Intel(R) Xeon(TM) CPU 3.00GHz stepping 01
> Feb 14 09:03:34  kernel: checking TSC synchronization across 2 CPUs:
passed.
> Feb 14 09:03:34  kernel: Brought up 2 CPUs
> Feb 14 10:27:58  kernel: Initializing CPU#0
> Feb 14 10:27:58  kernel: CPU 0 irqstacks, hard=c043b000 soft=c041b000
> Feb 14 10:27:58  kernel: CPU: Trace cache: 12K uops, L1 D cache: 16K
> Feb 14 10:27:58  kernel: CPU: L2 cache: 1024K
> Feb 14 10:27:58  kernel: CPU: Physical Processor ID: 0
> Feb 14 10:27:58  kernel: Intel machine check reporting enabled on CPU#0.
> Feb 14 10:27:58  kernel: CPU0: Intel P4/Xeon Extended MCE MSRs (24)
> available
> Feb 14 10:27:58  kernel: CPU0: Thermal monitoring enabled
> Feb 14 10:27:58  kernel: CPU0: Intel(R) Xeon(TM) CPU 3.00GHz stepping 01
> Feb 14 10:27:59  kernel: CPU 1 irqstacks, hard=c043c000 soft=c041c000
> Feb 14 10:27:59  kernel: Initializing CPU#1
> Feb 14 10:27:59  kernel: CPU: Trace cache: 12K uops, L1 D cache: 16K
> Feb 14 10:27:59  kernel: CPU: L2 cache: 1024K
> Feb 14 10:27:59  kernel: CPU: Physical Processor ID: 3
> Feb 14 10:27:59  kernel: Intel machine check reporting enabled on CPU#1.
> Feb 14 10:27:59  kernel: CPU1: Intel P4/Xeon Extended MCE MSRs (24)
> available
> Feb 14 10:27:59  kernel: CPU1: Thermal monitoring enabled
> Feb 14 10:27:59  kernel: CPU1: Intel(R) Xeon(TM) CPU 3.00GHz stepping 01
> Feb 14 10:27:59  kernel: checking TSC synchronization across 2 CPUs:
passed.
> Feb 14 10:27:59  kernel: Brought up 2 CPUs
> 
>>> known good server<<
> 
> Linux  2.4.21-20.ELsmp #1 SMP Wed Aug 18 20:46:40 EDT 2004 i686 i686 i386
> GNU/Linux
> 
> Feb 14 17:52:49  kernel: CPU 0 (0x0000) enabledProcessor #0 Pentium 4(tm)
> XEON(tm) APIC version 20
> Feb 14 17:52:49  kernel: CPU 1 (0x0600) enabledProcessor #6 Pentium 4(tm)
> XEON(tm) APIC version 20
> Feb 14 17:52:49  kernel: CPU 2 (0x0100) enabledProcessor #1 Pentium 4(tm)
> XEON(tm) APIC version 20
> Feb 14 17:52:49  kernel: CPU 3 (0x0700) enabledProcessor #7 Pentium 4(tm)
> XEON(tm) APIC version 20
> Feb 14 17:52:49  kernel: 4 CPUs total
> Feb 14 17:52:49  kernel: Enabling the CPU's according to the ACPI table
> Feb 14 17:52:49  kernel: Initializing CPU#0
> Feb 14 17:52:49  kernel: CPU: Trace cache: 12K uops, L1 D cache: 8K
> Feb 14 17:52:49  kernel: CPU: L2 cache: 512K
> Feb 14 17:52:49  kernel: CPU: Physical Processor ID: 0
> Feb 14 17:52:49  kernel: Intel machine check reporting enabled on CPU#0.
> Feb 14 17:52:49  kernel: CPU: Trace cache: 12K uops, L1 D cache: 8K
> Feb 14 17:52:49  kernel: CPU: L2 cache: 512K
> Feb 14 17:52:49  kernel: CPU: Physical Processor ID: 0
> Feb 14 17:52:49  kernel: Intel machine check reporting enabled on CPU#0.
> Feb 14 17:52:49  kernel: CPU0: Intel(R) Xeon(TM) CPU 2.66GHz stepping 05
> Feb 14 17:52:49  kernel: per-CPU timeslice cutoff: 1463.11 usecs.
> Feb 14 17:52:49  kernel: enabled ExtINT on CPU#0
> Feb 14 17:52:49  kernel: Initializing CPU#1
> Feb 14 17:52:49  kernel: masked ExtINT on CPU#1
> Feb 14 17:52:49  kernel: CPU: Trace cache: 12K uops, L1 D cache: 8K
> Feb 14 17:52:49  kernel: CPU: L2 cache: 512K
> Feb 14 17:52:49  kernel: ACPI tables and CPU MSR values mismatch about cpu
> number
> Feb 14 17:52:49  kernel: CPU: Physical Processor ID: 3
> Feb 14 17:52:49  kernel: Intel machine check reporting enabled on CPU#1.
> Feb 14 17:52:49  kernel: CPU1: Intel(R) Xeon(TM) CPU 2.66GHz stepping 05
> Feb 14 17:52:49  kernel: Initializing CPU#2
> Feb 14 17:52:49  kernel: masked ExtINT on CPU#2
> Feb 14 17:52:49  kernel: CPU: Trace cache: 12K uops, L1 D cache: 8K
> Feb 14 17:52:49  kernel: CPU: L2 cache: 512K
> Feb 14 17:52:49  kernel: CPU: Physical Processor ID: 0
> Feb 14 17:52:49  kernel: Intel machine check reporting enabled on CPU#2.
> Feb 14 17:52:49  kernel: CPU2: Intel(R) Xeon(TM) CPU 2.66GHz stepping 05
> Feb 14 17:52:49  kernel: Initializing CPU#3
> Feb 14 17:52:49  kernel: masked ExtINT on CPU#3
> Feb 14 17:52:49  kernel: CPU: Trace cache: 12K uops, L1 D cache: 8K
> Feb 14 17:52:49  kernel: CPU: L2 cache: 512K
> Feb 14 17:52:49  kernel: CPU: Physical Processor ID: 3
> Feb 14 17:52:49  kernel: Intel machine check reporting enabled on CPU#3.
> Feb 14 17:52:49  kernel: CPU3: Intel(R) Xeon(TM) CPU 2.66GHz stepping 05
> Feb 14 17:52:49  kernel: ..... CPU clock speed is 2666.0648 MHz.
> Feb 14 17:52:49  kernel:
CPU0<T0:1333024,T1:1066416,D:2,S:266606,C:1333030>
> Feb 14 17:52:49  kernel: CPU1<T0:1333024,T1:799808,D:4,S:266606,C:1333030>
> Feb 14 17:52:49  kernel:
CPU2<T0:1333024,T1:533184,D:22,S:266606,C:1333030>
> Feb 14 17:52:49  kernel: CPU3<T0:1333024,T1:266592,D:8,S:266606,C:1333030>
> Feb 14 17:52:50  kernel: mapping CPU#0's runqueue to CPU#2's runqueue.
> Feb 14 17:52:50  kernel: mapping CPU#1's runqueue to CPU#3's runqueue.
> _______________________________________________
> https://ntlug.org/mailman/listinfo/discuss

_______________________________________________
https://ntlug.org/mailman/listinfo/discuss