[ Same player shoot again. Fix address. ]
Ingo Molnar wrote:
> John wrote:
>
>> John Stultz wrote:
>>
>>> Also do check the -rt tree as Ingo suggested. I mis-read your earlier
>>> email and thought you were running it.
>>
>> I've been pulling my hair over a related issue for the past two days.
>>
>> (I think I may be tickling a -hrt bug...)
>>
>> I'm working with 2.6.18.6 + patch-2.6.18-rt7
>
> 2.6.18-rt7 is pretty old, do you see the problem in 2.6.20-rc6-rt5 too?
Ingo, Thomas,
I cannot reproduce in 2.6.20-rc6-rt6, but it is not strictly an
apples-to-apples comparison because I get a tsc clocksource in
2.6.20-rc6-rt6, and an acpi_pm clocksource in 2.6.18.6-rt7.
Here are the relevant parts of my boot messages:
Linux version 2.6.18.6-rt7
ACPI: PM-Timer IO Port: 0x4008
Clock event device pit configured with caps set: 07
Time: acpi_pm clocksource has been installed.
Clock event device pit configured with caps set: 08
Switched to high resolution mode on CPU 0
Linux version 2.6.20-rc6-rt6
ACPI: PM-Timer IO Port: 0x4008
Time: tsc clocksource has been installed.
(pit and acpi_pm have disappeared from 2.6.20-rc6-rt6)
The -rt patch set looks great, but I am somewhat hesitant to use it. It
seems it is only updated for the latest kernel version available. Or am
I mistaken? In other words, once 2.6.20 is released, and work starts on
2.6.21, if a bug is discovered in -rt, the fix will not be back-ported
to the 2.6.20.x (and 2.6.19.x, and 2.6.18.x, etc) patch set?
NB: I do need high-resolution timers, but, at the same time, I'm not
very comfortable living on the bleeding edge, where new bugs and
regressions might not get caught in release candidates. (I work on an
industrial project where continuous operation is a requirement.)
Regards.
* John <[email protected]> wrote:
> > 2.6.18-rt7 is pretty old, do you see the problem in 2.6.20-rc6-rt5
> > too?
>
> Ingo, Thomas,
>
> I cannot reproduce in 2.6.20-rc6-rt6, but it is not strictly an
> apples-to-apples comparison because I get a tsc clocksource in
> 2.6.20-rc6-rt6, and an acpi_pm clocksource in 2.6.18.6-rt7.
that suggests that the TSC was not deemed reliable by the newer kernel -
which almost always means it's not realiable. I think the problems you
were seeing are consistent with TSC being non-monotonic - so the fix is
to not use the TSC - and the newer kernel does this automatically.
Ingo
Ingo Molnar wrote:
> John wrote:
>
>> Ingo Molnar wrote:
>>
>>> 2.6.18-rt7 is pretty old, do you see the problem in 2.6.20-rc6-rt5 too?
>>
>> Ingo, Thomas,
>>
>> I cannot reproduce in 2.6.20-rc6-rt6, but it is not strictly an
>> apples-to-apples comparison because I get a tsc clocksource in
>> 2.6.20-rc6-rt6, and an acpi_pm clocksource in 2.6.18.6-rt7.
>
> That suggests that the TSC was not deemed reliable by the newer kernel,
> which almost always means it's not realiable. I think the problems you
> were seeing are consistent with TSC being non-monotonic - so the fix is
> to not use the TSC - and the newer kernel does this automatically.
Ingo,
Perhaps you've mis-read my message?
*2.6.18.6-rt7* installed an acpi_pm clocksource. When I used a boot
parameter to force the clocksource to tsc, the high-resolution timer
infrastructure broke (timers expired several *ms* too late).
On the other hand, *2.6.20-rc6-rt6* and *2.6.20-rt2* both installed a
tsc clock source, and it works.
Therefore, it is not the newer kernel that ignored the tsc, but the
older kernel. Thus I don't know what to make of your comment :-)
Regards,
John