We have a server which has four Intel Xeon E7 4860 CPU. Strangely, the model name in /proc/cpuinfo contains a 000 string instead of E4860.
Incorrect model name:
model name : Genuine Intel(R) CPU 000 @ 2.27GHz
Correct model name:
model name : Intel(R) Xeon(R) CPU E5620 @ 2.40GHz
The servers runs Arch Linux with kernel 3.2.12
BTW, I digged into kernel source code and found the relevant information are retrieved using Intel CPUID instruction.
Using wireshark, I discovered that Firefox v3.0 gets stuck every time before "client key exchange, change cipher spec" stage when establishing a SSL session.
Specifically, it takes 0.8~1.8 second before Firefox send "Client Key Exchange" request. This is unacceptable since our application is HTTPS only.
I tested this on IE6 and IE8, both works well. Any clues?
[Update]
Finally, I found the reason of 1 ~ 2 seconds stuck by displaying all captured packets in Wireshark. After the "server hello" stage, Firefox makes a request to ocsp.verisign.com combined with an additional DNS lookup for that domain. Firefox must wait the revocation status from OCSP before entering the next stage of SSL. Depends on whether DNS cache is in effect, this process takes 1 ~ 2 seconds.
A interesting observation is that the IP packet contains "client key exchange" has a high possibility to get lost and thus a TCP retransmission is necessary. When this happens, the process can take 3 seconds at worst. I'm not sure if this is a coincidence or a bug. Anyway, here is the result from Wireshark:
(delta-time)
0.369296 src-ip dst-ip TCP [ACK] Seq=161 Ack=2741 Win=65340 Len=0
2.538835 src-ip dst-ip TLSv1 Client Key Exchange, Change Cipher Spec, Finished
2.987034 src-ip dst-ip TLSv1 [TCP Retransmission] Client Key Exchange, Change Cipher Spec, Finished
The difference between Firefox and IE is this: Firefox 3 enables OCSP checking by default where as IE only supports it. So, there is no problem with both IE6 and IE8. This is indeed a "certificate revoke" problem. Thanks