linux-kernel - Re: TSC Problems (warp between CPUs)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <5d63695a1ad08aea5673a833e5055c6b@xor.bz>
Date:	Wed, 01 Jan 2014 08:24:08 +1100
From:	Alex <xor@....bz>
To:	<linux-kernel@...r.kernel.org>
Subject: Re: TSC Problems (warp between CPUs)

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?

-- 
Kind Regards,
Alex.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/