On Wed, 23 Jan 2013 14:05:25 +0800, bill4carson said:
Hmmm, all the boot messages are routed into a buffer it first printed into
console, here there is no delay, possible tick timer are not setup yet.
But when it does get printed into the console, this process could be
interrupted by other
On Wed, Jan 23, 2013 at 1:36 AM, sandeep kumar
coolsandyfor...@gmail.com wrote:
Dear Anish, Mulyadi,
this is how i read jiffies.
unsigned long start_time, end_time;
start_time = jiffies;
free_area(***);
end_time = jiffies;
printk(%ld, end_time-start_time);
I onserved jiffies getting
Hi..
On Tue, Jan 22, 2013 at 12:51 PM, sandeep kumar
coolsandyfor...@gmail.com wrote:
Hi all
As far as I know jiffie counter is incremented HZ times/second. And it is
used to measure the time lapses in the kernel code.
I m seeing a case where, actualy time spent in some module using giffies
how about to check the disable/enable timer interrupt?
cat /proc/stat before/after 2 seconds?
On 2013-01-22 13:51, sandeep kumar wrote:
Hi all
As far as I know jiffie counter is incremented HZ times/second. And it is
used to measure the time lapses in the kernel code.
I m seeing a case where,
Hi All
I am seeing this problem at the very early in the start_kernel--
mm_init-- free_highpages, at that time nothing is up and kernel is running
in single thread.
Thanks
Sandeep
On Tue, Jan 22, 2013 at 1:07 AM, hejianet hejia...@linux.vnet.ibm.comwrote:
how about to check the disable/enable
On Tue, 22 Jan 2013 10:29:05 -0800, sandeep kumar said:
I am seeing this problem at the very early in the start_kernel--
mm_init-- free_highpages, at that time nothing is up and kernel is running
in single thread.
If you build a kernel with printk timestamps, you'll see that they all
come out
Dear Anish, Mulyadi,
this is how i read jiffies.
unsigned long start_time, end_time;
start_time = jiffies;
free_area(***);
end_time = jiffies;
printk(%ld, end_time-start_time);
I onserved jiffies getting incremented at different place, though
thanks
sandeep
On Tue, Jan 22, 2013 at 10:29 AM,
Hi Mr.Valdis
as you rightly mentioned,cat /proc/kmsg is showing the time stamps,
according to that it is 0ms only.
But when you see the same with UART there is 2sec delay in showing the next
log. i caught this while i m observing the UART logs with
Terminaliranicca.
Since i m early in the
On Tue, 22 Jan 2013 11:32:19 -0800, sandeep kumar said:
as you rightly mentioned,cat /proc/kmsg is showing the time stamps,
according to that it is 0ms only.
But when you see the same with UART there is 2sec delay in showing the next
log. i caught this while i m observing the UART logs with
Hi Valdis,
Device specs: CPU: 1.7Ghz RAM: 2GB.
We are not adding any code in the mm_init, All we do is reserve some memory
during the boot time and rest of the memory around 1.45GB we configure it
as HIGHMEM.
Can you give me any info on how to do the profiling of the function calls
during ealry
On 2013年01月23日 03:32, sandeep kumar wrote:
Hi Mr.Valdis
as you rightly mentioned,cat /proc/kmsg is showing the time stamps, according
to that it is 0ms only.
But when you see the same with UART there is 2sec delay in showing the next
log. i caught this while i m observing the UART logs
Hi all
As far as I know jiffie counter is incremented HZ times/second. And it is
used to measure the time lapses in the kernel code.
I m seeing a case where, actualy time spent in some module using giffies is
zero, but while seeing UART logs i am seein 2 sec time difference. I dont
know how to
On Tue, Jan 22, 2013 at 11:21 AM, sandeep kumar
coolsandyfor...@gmail.com wrote:
Hi all
As far as I know jiffie counter is incremented HZ times/second. And it is
used to measure the time lapses in the kernel code.
I m seeing a case where, actualy time spent in some module using giffies is
13 matches
Mail list logo