[Barrelfish-users] How to get the wall-clock in Barrelfish?

[Zhiquan Lai]

Hi Kornilios,

Appreciate your reply.

I have figured out the bug and fixed it*. But the 64 bits read from phy
addr of 0xf9008224 are always be ZERO, rather than the wall-clock ticks as
they said.
Should I need to modify the default LUT to map 0xf9008224 address to the
FPGA clock ? If yes, how to do that ?

Besides, I want to measuring the latency of voltage scaling. And I heard
that the frequency while voltage being scaled is very slow,
therefore rdtsc() should be note suitable for my test. This is why I need a
wall clock to measure the latency.

* The reason of this bug is that when I use paging_map_device() function to
map a page to 0xf9008000 phy addr, the total device space exceeds
X86_32_DEVICE_SPACE_LIMIT. So to fix the bug, I adjust
X86_32_DEVICE_SPACE_LIMIT from 196 pages to 198 pages.

Thanks,
Zhiquan



> Hi Zhiquan,
>
> On Thu, Jan 10, 2013 at 04:50:21PM +0800, Zhiquan Lai wrote:
> > Hi All,
> >
> > I am using Barrelfish built on intel SCC and doing some micro benchmark.
> > However I cann't find any wall-clock function provide by Barrelfish.
> >
> > So I want to make use of the FPGA clock provided by SCC referring to
> > (http://intelopenport.hosted.jivesoftware.com/message/173550).
> > As said, we can acess the 64-bit wall-clock at physical address of
> 0xf9008224.
> > Then I add some code in the function of  rck.c:rck_init() to map the
> physical
> > address to a virtual address.
> > BUT after this modification, Barrelfish can not be booted with fault as
> follow:
> >
> >     kernel 0: exception 14 (error code 0x2): write page fault due to
> page not
> >     present, while in supervisor mode
> >     Address that caused the fault: 0x0
> >     No active process
> >     Faulting instruction pointer (or following instruction): 0x8010566b
> (0x
> >     10566b in binary)
> >     EAX 0x0 EBX 0x8011e198 ECX 0xfffcd100 EDX 0xbffc ESP 0x80927b68
> >     Top o' stack:
> >     0x8010566b 0x10016 0x8 0x10 0xe 0x2 0x8010566b 0x8 0x10016 0x80327000
> >     0x80326000 0x1 0x0 0x0 0x8 0x80 0x0 0xffffffff 0x0 0x8011e198
> >     No GDB backend
> >
> >
> > Any suggestions are appreciated ?
>
> Haven't look at SCC's FPGA clock, but it seems that the change introduced
> a NULL pointer dereference. Have you tried locating where the fault
> occurs by disassembling the cpu driver at location 0x10566b? If not, it
> might give you some hints on where the problem is.
>
> Alternatively, you could use rdtsc() for taking timing measurements. See
> for example usr/bench/bench.c.
>
> cheers,
> Kornilios.
>
> --
> Kornilios Kourtis
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.inf.ethz.ch/pipermail/barrelfish-users/attachments/20130112/f0401327/attachment.html