[Barrelfish-users] How to get the wall-clock in Barrelfish?
laizhiquan at gmail.com
Sat Jan 12 11:53:01 CET 2013
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
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.
> 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
> > Then I add some code in the function of rck.c:rck_init() to map the
> > address to a virtual address.
> > BUT after this modification, Barrelfish can not be booted with fault as
> > 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
> > 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.
> Kornilios Kourtis
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Barrelfish-users