* RE: High-Res-Timers: Unexpected "lock" during "Calibrating delay loop "
@ 2003-02-06 20:55 Isabelle, Francois
0 siblings, 0 replies; 4+ messages in thread
From: Isabelle, Francois @ 2003-02-06 20:55 UTC (permalink / raw)
To: 'george anzinger'; +Cc: high-res-timers-discourse, linux-kernel
I might be able to use the "rtc" driver to meet the specific requirements of
this application, but considering the success of other OSes (in the embedded
field) on low cost/low speed x86 compatible devices, you may expect some
interest for your driver from linux enthousiasts for similar CPUs.
Anyway, you are doing some great job here and I'ld be (somehow) available
for validation of the fixes you might come with, if you get some time .
Thank you
Frank
> -----Original Message-----
> From: george anzinger [mailto:george@mvista.com]
> Sent: 5 février, 2003 15:39
> To: Isabelle, Francois
> Cc: high-res-timers-discourse@lists.sourceforge.net;
> linux-kernel@vger.kernel.org
> Subject: Re: High-Res-Timers: Unexpected "lock" during "Calibrating
> delay loop "
>
>
> Isabelle, Francois wrote:
> > Just wanted to add this: this seems to be reproducible on all 486
> >
>
> I hope to get a chance to look at this today. Thus far, I know that
> the PIT version does not keep good time in the face of timers of
> resolution > 1/HZ, i.e. the "_HR" clocks.
>
> This has to do with the fact that we have only one interrupt source
> and must change it to get the sub jiffies interrupts. In the process
> we loose track of where the jiffies interrupt should be. There is an
> attempt to use the second PIT timer to cover for this, but
> assumptions
> are made here that may not be right. (This timer is used for memory
> refresh and is set up by the BIOS. We can not change it and
> we assume
> that it has a given period. I suppose we could attempt to
> measure the
> period, but thus far we have assumed that these sorts of machines
> would not require high res timers and have not tried to run
> down these
> issues.
>
> A side issue is that the timers seem to not follow the spec (at least
> on my test machine) in the regard that a status bit is supposed to
> indicate when the latch has been loaded after a program has been
> output. I can easily find cases where a wait for the bit to
> change is
> followed by a read of the latch which returns a stale value. I
> suppose some of this has to do with a large difference
> between the cpu
> clock and the timer clock.
> >
> >>-----Original Message-----
> >>From: Isabelle, Francois [mailto:Francois.Isabelle@ca.kontron.com]
> >>Sent: 4 février, 2003 09:04
> >>To: high-res-timers-discourse@lists.sourceforge.net;
> >>'george@mvista.com'
> >>Cc: linux-kernel@vger.kernel.org
> >>Subject: High-Res-Timers: Unexpected "lock" during
> "Calibrating delay
> >>loop "
> >>
> >>
> >>Hi,
> >> we are having an unexpected problem with the HR patch(
> >>regardless of
> >>the patch you sent which compiled just fine ). The board uses
> >>a 486DX cpu,
> >>so there is no support for TSC nor ACPI, the only thing we
> >>have is the PIT.
> >>
> >>Without highres, the kernel boots properly, with highres
> >>enabled, the kernel
> >>passes "time_init()" put it hangs in "calibrate_loop() , ( I
> >>though it hung
> >>for real, but it get passed the loop after a while) "
> >>
> >>Seems like the tick is VERY SLOW..
> >>
> >>The PIT has been tested on this board, and without HR, the
> >>kernel boots fine
> >>... if you have any hints, they would be welcome.
> >>
> >>The keyboard detection routine timeouts so the system is
> >>quiet unuseable and
> >>I can't get the calibration results yet.
> >>
> >>
> >>Frank
> >>
> >>
> >>
> >>
> >>
> >>-------------------------------------------------------
> >>This SF.NET email is sponsored by:
> >>SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> >>http://www.vasoftware.com
> >>to unsubscribe:
> >>http://lists.sourceforge.net/lists/listinfo/high-res-timers-
discourse
>>High-res-timers-discourse mailing list
>>High-res-timers-discourse@lists.sourceforge.net
>>https://lists.sourceforge.net/lists/listinfo/high-res-timers-discourse
>>
>
>
>
--
George Anzinger george@mvista.com
High-res-timers: http://sourceforge.net/projects/high-res-timers/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
to unsubscribe:
http://lists.sourceforge.net/lists/listinfo/high-res-timers-discourse
High-res-timers-discourse mailing list
High-res-timers-discourse@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/high-res-timers-discourse
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: High-Res-Timers: Unexpected "lock" during "Calibrating delay loop "
2003-02-04 15:33 Isabelle, Francois
@ 2003-02-05 20:39 ` george anzinger
0 siblings, 0 replies; 4+ messages in thread
From: george anzinger @ 2003-02-05 20:39 UTC (permalink / raw)
To: Isabelle, Francois; +Cc: high-res-timers-discourse, linux-kernel
Isabelle, Francois wrote:
> Just wanted to add this: this seems to be reproducible on all 486
>
I hope to get a chance to look at this today. Thus far, I know that
the PIT version does not keep good time in the face of timers of
resolution > 1/HZ, i.e. the "_HR" clocks.
This has to do with the fact that we have only one interrupt source
and must change it to get the sub jiffies interrupts. In the process
we loose track of where the jiffies interrupt should be. There is an
attempt to use the second PIT timer to cover for this, but assumptions
are made here that may not be right. (This timer is used for memory
refresh and is set up by the BIOS. We can not change it and we assume
that it has a given period. I suppose we could attempt to measure the
period, but thus far we have assumed that these sorts of machines
would not require high res timers and have not tried to run down these
issues.
A side issue is that the timers seem to not follow the spec (at least
on my test machine) in the regard that a status bit is supposed to
indicate when the latch has been loaded after a program has been
output. I can easily find cases where a wait for the bit to change is
followed by a read of the latch which returns a stale value. I
suppose some of this has to do with a large difference between the cpu
clock and the timer clock.
>
>>-----Original Message-----
>>From: Isabelle, Francois [mailto:Francois.Isabelle@ca.kontron.com]
>>Sent: 4 février, 2003 09:04
>>To: high-res-timers-discourse@lists.sourceforge.net;
>>'george@mvista.com'
>>Cc: linux-kernel@vger.kernel.org
>>Subject: High-Res-Timers: Unexpected "lock" during "Calibrating delay
>>loop "
>>
>>
>>Hi,
>> we are having an unexpected problem with the HR patch(
>>regardless of
>>the patch you sent which compiled just fine ). The board uses
>>a 486DX cpu,
>>so there is no support for TSC nor ACPI, the only thing we
>>have is the PIT.
>>
>>Without highres, the kernel boots properly, with highres
>>enabled, the kernel
>>passes "time_init()" put it hangs in "calibrate_loop() , ( I
>>though it hung
>>for real, but it get passed the loop after a while) "
>>
>>Seems like the tick is VERY SLOW..
>>
>>The PIT has been tested on this board, and without HR, the
>>kernel boots fine
>>... if you have any hints, they would be welcome.
>>
>>The keyboard detection routine timeouts so the system is
>>quiet unuseable and
>>I can't get the calibration results yet.
>>
>>
>>Frank
>>
>>
>>
>>
>>
>>-------------------------------------------------------
>>This SF.NET email is sponsored by:
>>SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
>>http://www.vasoftware.com
>>to unsubscribe:
>>http://lists.sourceforge.net/lists/listinfo/high-res-timers-discourse
>>High-res-timers-discourse mailing list
>>High-res-timers-discourse@lists.sourceforge.net
>>https://lists.sourceforge.net/lists/listinfo/high-res-timers-discourse
>>
>
>
>
--
George Anzinger george@mvista.com
High-res-timers: http://sourceforge.net/projects/high-res-timers/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml
^ permalink raw reply [flat|nested] 4+ messages in thread
* RE: High-Res-Timers: Unexpected "lock" during "Calibrating delay loop "
@ 2003-02-04 15:33 Isabelle, Francois
2003-02-05 20:39 ` george anzinger
0 siblings, 1 reply; 4+ messages in thread
From: Isabelle, Francois @ 2003-02-04 15:33 UTC (permalink / raw)
To: Isabelle, Francois, high-res-timers-discourse,
'george@mvista.com'
Cc: linux-kernel
Just wanted to add this: this seems to be reproducable on all 486
> -----Original Message-----
> From: Isabelle, Francois [mailto:Francois.Isabelle@ca.kontron.com]
> Sent: 4 février, 2003 09:04
> To: high-res-timers-discourse@lists.sourceforge.net;
> 'george@mvista.com'
> Cc: linux-kernel@vger.kernel.org
> Subject: High-Res-Timers: Unexpected "lock" during "Calibrating delay
> loop "
>
>
> Hi,
> we are having an unexpected problem with the HR patch(
> regardless of
> the patch you sent which compiled just fine ). The board uses
> a 486DX cpu,
> so there is no support for TSC nor ACPI, the only thing we
> have is the PIT.
>
> Without highres, the kernel boots properly, with highres
> enabled, the kernel
> passes "time_init()" put it hangs in "calibrate_loop() , ( I
> though it hung
> for real, but it get passed the loop after a while) "
>
> Seems like the tick is VERY SLOW..
>
> The PIT has been tested on this board, and without HR, the
> kernel boots fine
> ... if you have any hints, they would be welcome.
>
> The keyboard detection routine timeouts so the system is
> quiet unuseable and
> I can't get the calibration results yet.
>
>
> Frank
>
>
>
>
>
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> http://www.vasoftware.com
> to unsubscribe:
> http://lists.sourceforge.net/lists/listinfo/high-res-timers-discourse
> High-res-timers-discourse mailing list
> High-res-timers-discourse@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/high-res-timers-discourse
>
^ permalink raw reply [flat|nested] 4+ messages in thread
* High-Res-Timers: Unexpected "lock" during "Calibrating delay loop "
@ 2003-02-04 14:04 Isabelle, Francois
0 siblings, 0 replies; 4+ messages in thread
From: Isabelle, Francois @ 2003-02-04 14:04 UTC (permalink / raw)
To: high-res-timers-discourse, 'george@mvista.com'; +Cc: linux-kernel
Hi,
we are having an unexpected problem with the HR patch( regardless of
the patch you sent which compiled just fine ). The board uses a 486DX cpu,
so there is no support for TSC nor ACPI, the only thing we have is the PIT.
Without highres, the kernel boots properly, with highres enabled, the kernel
passes "time_init()" put it hangs in "calibrate_loop() , ( I though it hung
for real, but it get passed the loop after a while) "
Seems like the tick is VERY SLOW..
The PIT has been tested on this board, and without HR, the kernel boots fine
... if you have any hints, they would be welcome.
The keyboard detection routine timeouts so the system is quiet unuseable and
I can't get the calibration results yet.
Frank
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2003-02-06 20:45 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-02-06 20:55 High-Res-Timers: Unexpected "lock" during "Calibrating delay loop " Isabelle, Francois
-- strict thread matches above, loose matches on Subject: below --
2003-02-04 15:33 Isabelle, Francois
2003-02-05 20:39 ` george anzinger
2003-02-04 14:04 Isabelle, Francois
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).