SCIENTIFIC-LINUX-USERS Archives

November 2011

SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Stephan Wiesand <[log in to unmask]>
Reply To:
Stephan Wiesand <[log in to unmask]>
Date:
Sat, 19 Nov 2011 22:37:28 +0100
Content-Type:
text/plain
Parts/Attachments:
text/plain (114 lines)
On Nov 19, 2011, at 22:22 , Yi Ding wrote:

> I do have a i7-920 (Nehalem) processor in my machine, but I haven't
> seen the tsc unstable issue.

That shows up much less frequently than than the hangs. Trying the workaround is probably a good idea in your case, and extremely unlikely to break anything or make things worse. intel_idle.max_cstate=1 works fine for us, at the cost  of some waste of electrical power. If this helps in your case, please consider adding data to the BZ.

Cheers,
	Stephan

> 
> Thanks,
> Yi
> 
> On Fri, Nov 18, 2011 at 11:54 AM, Stephan Wiesand
> <[log in to unmask]> wrote:
>> On Nov 18, 2011, at 18:44 , Fabrizio Giordano wrote:
>> 
>>> I get the same behaviour on my Scientific Linux 6.0 (kernel 2.6.32): my console becomes terribly slow for about 5 minutes. This is what I read when I call 'dmesg':
>>> 
>>> Clocksource tsc unstable (delta = 299996380341 ns)
>>> Switching to clocksource hpet
>> 
>> It's not the first time while following this thread that I wonder whether this is yet another manifestation of the "Nehalem deep C states" problem. See https://bugzilla.redhat.com/show_bug.cgi?id=710265
>> 
>> Cheers,
>>       Stephan
>> 
>>> 
>>> That delta is suspiciously 5 minute long...
>>> 
>>> -----Original Message-----
>>> From: [log in to unmask] [mailto:[log in to unmask]] On Behalf Of Turtaut Geoffroy
>>> Sent: Thursday, November 17, 2011 11:40 PM
>>> To: Gianluca Varenni; [log in to unmask]
>>> Subject: RE: console slowness in sl6.1
>>> 
>>> Yes
>>> 
>>> 
>>> -----Message d'origine-----
>>> De : Gianluca Varenni [mailto:[log in to unmask]]
>>> Envoyé : vendredi 18 novembre 2011 08:38 À : Turtaut Geoffroy; [log in to unmask]
>>> Objet : RE: console slowness in sl6.1
>>> 
>>> Does it happen if you run in purely text mode too (runlevel 3)? I've noticed something similar (several seconds), but totally sporadically. Not much runs on my machine, pretty much the a bare minimal text installation.
>>> 
>>> GV
>>> 
>>> -----Original Message-----
>>> From: Turtaut Geoffroy [mailto:[log in to unmask]]
>>> Sent: Thursday, November 17, 2011 11:35 PM
>>> To: Gianluca Varenni; [log in to unmask]
>>> Subject: RE: console slowness in sl6.1
>>> 
>>> When we hit a key, it takes 1 or 2 seconds (or more).
>>> Applications are slow, Ctrl+Alt+F2 can take 30 seconds, ps -ef 10 seconds, df, ...
>>> 
>>> The problems appears at random intervals, for 5 minutes.
>>> 
>>> Just before and just after, no problem
>>> 
>>> The problem appears on :
>>> Standalone system (no name services, dns, ldap, no network, ..) Network workstation (dns, ldap, ...)
>>> 
>>> Geoffroy
>>> 
>>> 
>>> -----Message d'origine-----
>>> De : Gianluca Varenni [mailto:[log in to unmask]]
>>> Envoyé : vendredi 18 novembre 2011 08:26 À : Turtaut Geoffroy; [log in to unmask]
>>> Objet : RE: console slowness in sl6.1
>>> 
>>> What happens when it's extremely slow? Like you hit a key and it's not echoed on the screen for a long time (seconds)?
>>> 
>>> Have a nice day
>>> GV
>>> 
>>> -----Original Message-----
>>> From: [log in to unmask] [mailto:[log in to unmask]] On Behalf Of Turtaut Geoffroy
>>> Sent: Thursday, November 17, 2011 11:18 PM
>>> To: [log in to unmask]
>>> Subject: Re: console slowness in sl6.1
>>> 
>>> Hi,
>>> 
>>> We have the same issue since we use RHEL 6.X/SL 6.X
>>> 
>>> Topic : HP Z400 system very slow at ramdom times for 5 minutes (october 2011)
>>> 
>>> We use HP workstations (XW4600, Z200, Z400, ...), VM, DELL laptops and the problem is only present on Z400 (xeon) et an HP pavilion (corei7).
>>> 
>>> The problem is not present if we use 2.6.32 kernel from kernel.org.
>>> 
>>> We have a case on RHN ...
>>> 
>>> Last RH comment was :
>>> We have analysed the results and see that there is nothing waiting on I/O but there is a high CPU usage and large run queue.
>>> 
>>> Geoffroy Turtaut
>> 
>> --
>> Stephan Wiesand
>> DESY -DV-
>> Platanenenallee 6
>> 15738 Zeuthen, Germany
>> 

-- 
Stephan Wiesand
DESY -DV-
Platanenenallee 6
15738 Zeuthen, Germany

ATOM RSS1 RSS2