On Thu, 9 Sep 2004, Alex Williamson wrote: > On Thu, 2004-09-09 at 08:28 -0700, Christoph Lameter wrote: > > On Thu, 9 Sep 2004, Alex Williamson wrote: > > > > > On Wed, 2004-09-08 at 16:23 -0700, Christoph Lameter wrote: > > > > Sorry. I was too superficial when looking at this issue. The following > > > > patch makes the hpet driver build again but I do not have a machine here > > > > that would allow me to test this. Could you verify that this works and get > > > > back to me? > > > > > > > > > > It builds and boots, so a definite improvement. I'm not sure how to > > > check if the hpet is being used though. Thanks, > > > > Could you run the following program and sent me the output? The precision > > of the REALTIME clock should be the same as the HPET device. > > > > The program reports: > > Gettimeofday() = 1094745228.671790000 > CLOCK_REALTIME= -17032.000003664 resolution= 3648.000238936 > CLOCK_MONOTONIC= -17032.000003664 resolution= 3648.000238936 > CLOCK_PROCESS_CPUTIME_ID= 0.000714263 resolution= 0.000000001 > CLOCK_THREAD_CPUTIME_ID= 0.000723913 resolution= 0.000000001 > > > The HPET driver reported a 4ns tick on the timer. Thanks, Sorry but the data is useless. You might be running a glibc build with 2.4.X headers. The values for CLOCK_REALTIME and CLOCK_MONOTONIC are wrong and the same. CLOCK_REALTIME should be >1000000000 (same as gettimeofday) at this point whereas CLOCK_MONOTONIC should reflect uptime. If glibc is build with 2.4.X headers then it will improvise these clocks. That maybe happening. If you have a 4ns tick then the resolution should be 0.000000004. - To unsubscribe from this list: send the line "unsubscribe linux-ia64" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.htmlReceived on Thu Sep 9 12:37:21 2004
This archive was generated by hypermail 2.1.8 : 2005-08-02 09:20:30 EST