public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Michael Tokarev <mjt@tls.msk.ru>
To: Ingo Molnar <mingo@elte.hu>
Cc: Avi Kivity <avi@redhat.com>, John Stultz <johnstul@us.ibm.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Andrew Morton <akpm@linux-foundation.org>,
	Linux-kernel <linux-kernel@vger.kernel.org>,
	KVM list <kvm@vger.kernel.org>
Subject: Re: phenom, amd780g, tsc, hpet, kvm, kernel -- who's at fault?
Date: Mon, 23 Mar 2009 11:31:38 +0300	[thread overview]
Message-ID: <49C748EA.6040809@msgid.tls.msk.ru> (raw)
In-Reply-To: <20090323080441.GA27170@elte.hu>

Ingo, I lost any hope already to hear anything about this one..
Surprise.  Thank you for replying!

Ingo Molnar wrote:
[]
>> top/strace, but nothing interesting shows.  I captured Sysrq+T of this situation
>> here: http://www.corpit.ru/mjt/host-high-la -- everything I was able to find
>> in kern.log.
> 
> 403

Fixed both.  Didn't notice it was 0640 (i copied the kern.log).  I just
checked my apache access.log - no one but several bots even looked at
those pages before you.  Oh well.

[]
>> So, to the hell out of it all, and ignoring the magical Friday the 13th --
>> who's fault it is?
>>
>>  o why it declares tsc is unstable while phenom supposed to keep it ok?
> 
> the TSC can drift slowly between cores, and it might not be in sync 
> at bootup time already. You check check the TSC from user-space (on 
> any kernel) via time-warp-test:
> 
>     http://redhat.com/~mingo/time-warp-test/MINI-HOWTO

Aha.  Will do.  But see below.

>>  o why hpet is malfunctioning?
> 
> That's a question for Thomas i guess.
> 
>>  o why the system time on this machine is dog slow without special
>>    adjtimex adjustments, while it worked before (circa 2.6.26) and
>>    windows works ok here?
>>
>> For reference:
>>
>>  https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2351676&group_id=180599
>>   -- kvm bug on sourceforge, without any visible interest in even looking at it
>>
>>  http://www.google.com/search?q=CE%3A+hpet+increasing+min_delta_ns
>>   -- numerous references to that "CE: hpet increasing min_delta_ns" on the 'net,
>>   mostly for C2Ds, mentioning various lockup issues
>>
>>  http://marc.info/?t=123246270000002&r=1&w=2 --
>>   "slow clock on AMD 740G chipset" -- it's about the clock issue, also without
>>   any visible interest.
>>
>> What's the next thing to do here?  I for one don't want to see 
>> todays failures again, it was very, and I mean *very* difficult 
>> day to restore the functionality of this system that (and it isn't 
>> restored at full because of the slowness of its current state).
> 
> it's not clear which kernel you tried - if you tried a recent enough 
> one then i'd chalk this up as a yet-unfixed timekeeping problem - 
> which probably had ripple effects on KVM and the rest of the system.

It is 2.6.28.7 compiled for x86-64 (64 bits).
Config is at http://www.corpit.ru/mjt/2.6.28.7-x86-64.config

> What would be helpful is to debug the problem :-) First verify that 
> basic timekeeping is OK: does 'time sleep 10' really take precisely 
> 10 seconds? Does 'date' advance precisely one second per physical 
> second?
[...]

I'll try - maybe today.  The thing is that this is a production machine
running quite several of various (virtual) servers which are all our
infrastructure.  When it started misbehaving at 13th (just because there
was high load, not because of failures or any other changes), all our
office was stopped... ;)

Now, after quite some googling around, I tried to disable hpet, booting
with hpet=disable parameter.  And that one fixed all the problems at once.
7 days uptime, I stress-tested it several times, it works with TSC as
timesource (still a problem within guests as those shows unstable TSC
anyway) since boot, no issues logged.  Even cpufreq works as expected...

Note that i tried to disable hpet as clocksource several times but without
any noticeable effect - kernel still used hpet and hpet2 for something,
and printed that scary "increasing min_delay" message on a semi-regular
basis usually after the next 'stuck' state....

> A generic hw/sw state output of:
> 
>   http://people.redhat.com/mingo/cfs-scheduler/tools/cfs-debug-info.sh
> 
> would also help people taking a look at this problem.
> 
> If the problem persists, there might be a chance to debug it without 
> rebooting the system. Rebooting and trying out various patches wont 
> really work well for a server i guess.

..so it has to be rebooted back to enable hpet.  Hence I'll do it not
before evening.  But I really want to debug and fix the issue, as it
gave me quite some headaches and I want to kill it once and for all ;)

Thanks for noticing this!

/mjt

  reply	other threads:[~2009-03-23  8:29 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-13 21:06 phenom, amd780g, tsc, hpet, kvm, kernel -- who's at fault? Michael Tokarev
2009-03-23  8:04 ` Ingo Molnar
2009-03-23  8:31   ` Michael Tokarev [this message]
2009-03-23 15:41     ` Ingo Molnar
2009-03-23 16:04       ` Michael Tokarev
2009-03-23 16:13         ` Ingo Molnar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=49C748EA.6040809@msgid.tls.msk.ru \
    --to=mjt@tls.msk.ru \
    --cc=akpm@linux-foundation.org \
    --cc=avi@redhat.com \
    --cc=johnstul@us.ibm.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox