All of lore.kernel.org
 help / color / mirror / Atom feed
From: Adrian Vasile <adrian.vasile@imc.nl>
To: Alex <xor@xor.bz>, <linux-kernel@vger.kernel.org>
Subject: Re: TSC Problems (warp between CPUs)
Date: Tue, 7 Oct 2014 12:19:07 +0200	[thread overview]
Message-ID: <5433BE1B.5020703@imc.nl> (raw)
In-Reply-To: <5d63695a1ad08aea5673a833e5055c6b@xor.bz>

Alex,

Have you managed to fix this issue? I'm seeing the same on an Asus X99
Deluxe board with both 5930K and 5960X and the latest BIOS as of today
(0904).
I had some hopes of linux-3.17 working around this but it did not help.
Asus support is disappointing, I don't think they will ever fix this.

I'm wondering if it's worth trying a different motherboard, any
recommendations?

Thank you.

Regards,
Adrian

On 31/12/13 22:24, Alex wrote:
> A Happy new year to all :)
>
> Just wondering whether anyone has any ideas on how I could force the
> TSC to resync?
>
> Starting to get a bit desperate. The motherboard manufacturers support
> is useless.... They keep telling me to install Windows *groan*. I dont
> think there is any easy way to expose what clock source the OS is
> using even in windows.
>
> I even tried firing an email at the AmiBios guys. I think I have
> exhausted every avenue of help as far as the hardware goes.
>
> Any suggestions?
>
> Kind regards,
> Alex
>
> On 2013-12-29 11:21, Alex wrote:
>> On 2013-12-29 01:35, One Thousand Gnomes wrote:
>>>> not guaranteed to be precise. For example a SMI (System Management
>>>> Interrupt) could interrupt the software flow that is attempting to
>>>> write
>>>> the time-stamp counter immediately prior to the WRMSR. This could mean
>>>> the value written to the TSC could vary by thousands to millions of
>>>> clocks.
>>>
>>> Yes SMI is a disaster area for any real time activity (and many other
>>> things ;) ), but many systems actually make little use of it,
>>> especially
>>> once the USB is owned by the OS.
>>>
>>> For synchronization you can retry the sync if it isn't within an
>>> acceptable range. The odds of getting an SMI mid sync setup should be
>>> very very low, so the odds of repeating the failure several times
>>> should
>>> be negligible and after a few tries you could give up and assume the
>>> hardware is buggered then fall back to HPET.
>>
>> Hi Alan,
>>
>> The sync retry sounds like an interesting strategy but is outside my
>> knowledge
>> scope as a regular end user (I do have a reasonable understanding of
>> C and can patch+
>> recompile) but I lack the architecture knowledge to implement a patch
>> to do this.
>>
>> Any suggestions?
>

________________________________

The information in this e-mail is intended only for the person or entity to which it is addressed.

It may contain confidential and /or privileged material. If someone other than the intended recipient should receive this e-mail, he / she shall not be entitled to read, disseminate, disclose or duplicate it.

If you receive this e-mail unintentionally, please inform us immediately by "reply" and then delete it from your system. Although this information has been compiled with great care, neither IMC Financial Markets & Asset Management nor any of its related entities shall accept any responsibility for any errors, omissions or other inaccuracies in this information or for the consequences thereof, nor shall it be bound in any way by the contents of this e-mail or its attachments. In the event of incomplete or incorrect transmission, please return the e-mail to the sender and permanently delete this message and any attachments.

Messages and attachments are scanned for all known viruses. Always scan attachments before opening them.

      reply	other threads:[~2014-10-07 10:29 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-28  2:24 TSC Problems (warp between CPUs) Alex
2013-12-28  4:02 ` Mike Galbraith
2013-12-28  9:51 ` Alex
2013-12-28 13:38   ` el_es
2013-12-28 14:35   ` One Thousand Gnomes
2013-12-29  0:21     ` Alex
2013-12-31 21:24       ` Alex
2014-10-07 10:19         ` Adrian Vasile [this message]

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=5433BE1B.5020703@imc.nl \
    --to=adrian.vasile@imc.nl \
    --cc=linux-kernel@vger.kernel.org \
    --cc=xor@xor.bz \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.