Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 14 Jan 2013 01:18:32 +0200
From:      Alexander Motin <mav@FreeBSD.org>
To:        Ian Lepore <freebsd@damnhippie.dyndns.org>
Cc:        Davide Italiano <davide@freebsd.org>, freebsd-arch@freebsd.org, FreeBSD Current <freebsd-current@freebsd.org>, Marius Strobl <marius@alchemy.franken.de>
Subject:   Re: [RFC/RFT] calloutng
Message-ID:  <50F340C8.2040905@FreeBSD.org>
In-Reply-To: <1358118601.32417.41.camel@revolution.hippie.lan>
References:  <50CCAB99.4040308@FreeBSD.org> <50CE5B54.3050905@FreeBSD.org> <50D03173.9080904@FreeBSD.org> <20121225232126.GA47692@alchemy.franken.de> <50DB4EFE.2020600@FreeBSD.org> <20130106152313.GD26039@alchemy.franken.de> <50EBF921.2000304@FreeBSD.org> <20130113180940.GM26039@alchemy.franken.de> <50F30CAB.3000001@FreeBSD.org> <1358118601.32417.41.camel@revolution.hippie.lan>

next in thread | previous in thread | raw e-mail | index | archive | help
On 14.01.2013 01:10, Ian Lepore wrote:
> On Sun, 2013-01-13 at 21:36 +0200, Alexander Motin wrote:
>> On 13.01.2013 20:09, Marius Strobl wrote:
> [...]
>>>
>>> Uhm, there are no NMIs on sparc64. Does it make sense to bypass this
>>> adjustment on sparc64?
>>
>> If it is not possible or not good to to stop timer during programming,
>> there will always be some race window between code execution and timer
>> ticking. So some minimal safety range should be reserved. Though it
>> probably can be significantly reduced. In case of x86/HPET there is
>> additional factor of NMI, that extends race to unpredictable level and
>> so makes additional post-read almost mandatory.
>>
>>>> May be with rereading counter
>>>> after programming comparator (same as done for HPET, reading which is
>>>> probably much more expensive) this value could be reduced.
>>>
>>> I see. There are some bigger fish to fry at the moment though :)
>>
> 
> Speaking of the HPET code, it seems to me that its restart logic can
> fire the same event twice.  Is that harmless?

It is much less harmful then not fire and loose interrupt completely,
and as result stuck for indefinite time. I have no better ideas, while
this seems works well.

-- 
Alexander Motin



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?50F340C8.2040905>