'Trace patches test' [Was: ccio_clear_io_tlb() and __raw_write() more question?]

'Trace patches test' [Was: ccio_clear_io_tlb() and __raw_write() more question?]

[rubisher]

[snip]
> >> Willy is correct - writes to this IO space (0xf0000000) address is 
> >> uncached.
> > mmm, is it the reason why you (I mean hp engineers) call it "f-space": IO 
> > space addresses starting by 0xf?
> 
> Yes.
> 
> grant
> 
Cool ;<)

Btw, a while back, I dream to use relayfs to grab debug info.
(<http://lists.parisc-linux.org/pipermail/parisc-linux/2006-April/053237.html>)

Somebody else write it:
<http://lkml.org/lkml/2007/11/13/208>

Obviously, I have to instrument things manually but I test it succesfully.
Here is already some primarily data test:
[snip]
:1201001199222127606:ccio_map_single_1:ccio_map_single() 0x1eb91896 ->
0x63b4896 size: 0x1000
:1201001199222203288:ccio_map_single_2: pdir 1fcb1da0 038100000eb91017
:1201001199222391065:ccio_map_single_1:ccio_map_single() 0x1febc096 ->
0x63b5096 size: 0x1000
:1201001199222460820:ccio_map_single_2: pdir 1fcb1da8 02a800000febc017
:1201001199222687339:ccio_map_single_1:ccio_map_single() 0x1eae7896 ->
0x63b6896 size: 0x1000
:1201001199222759615:ccio_map_single_2: pdir 1fcb1db0 02fb00000eae7017
:1201001199223529366:ccio_unmap_single_1:ccio_unmap_single() iovp 0x63b4896/5ea
:1201001199226080604:ccio_unmap_single_1:ccio_unmap_single() iovp 0x63b5096/5ea
:1201001199226146742:ccio_unmap_single_1:ccio_unmap_single() iovp 0x63b6896/5ea
:1201001199226443370:ccio_map_single_1:ccio_map_single() 0x1dc5f096 ->
0x63b7096 size: 0x1000
:1201001199226517113:ccio_map_single_2: pdir 1fcb1db8 005700000dc5f017
:1201001199226737227:ccio_map_single_1:ccio_map_single() 0x1dc7b096 ->
0x63b8096 size: 0x1000
:1201001199226807153:ccio_map_single_2: pdir 1fcb1dc0 007700000dc7b017
:1201001199226990619:ccio_map_single_1:ccio_map_single() 0x1dedf896 ->
0x63b9896 size: 0x1000
:1201001199227060207:ccio_map_single_2: pdir 1fcb1dc8 02c700000dedf017
:1201001199227877694:ccio_unmap_single_1:ccio_unmap_single() iovp 0x63b7096/5ea
:1201001199230211964:ccio_unmap_single_1:ccio_unmap_single() iovp 0x63b8096/5ea
:1201001199230277457:ccio_unmap_single_1:ccio_unmap_single() iovp 0x63b9896/3aa
:1201001199932184243:ccio_map_single_1:ccio_map_single() 0x1dedf896 ->
0x63ba896 size: 0x1000
:1201001199932262292:ccio_map_single_2: pdir 1fcb1dd0 02c700000dedf017
:1201001199932471488:ccio_map_single_1:ccio_map_single() 0x1dc7b096 ->
0x63bb096 size: 0x1000
:1201001199932540658:ccio_map_single_2: pdir 1fcb1dd8 007700000dc7b017
:1201001199932742704:ccio_map_single_1:ccio_map_single() 0x1dc5f096 ->
0x63bc096 size: 0x1000
[snip]

Exciting results? (just what would give me DEBUG_RUN() printk() but without
degrading system performance)

I still have to had some more DEBUG_RUN_SG() stuff and hope to be able to
collect more.

Cheers,
    r.

---
Scarlet One, ADSL 6 Mbps + Telephone, from EUR 29,95...
http://www.scarlet.be/

Re: 'Trace patches test' [Was: ccio_clear_io_tlb() and __raw_write() more question?]

[Grant Grundler]

On Tue, Jan 22, 2008 at 02:35:21PM +0100, rubisher wrote:
> Btw, a while back, I dream to use relayfs to grab debug info.
> (<http://lists.parisc-linux.org/pipermail/parisc-linux/2006-April/053237.html>)
> 
> Somebody else write it:
> <http://lkml.org/lkml/2007/11/13/208>
> 
> Obviously, I have to instrument things manually but I test it succesfully.
> Here is already some primarily data test:
> [snip]
> :1201001199222127606:ccio_map_single_1:ccio_map_single() 0x1eb91896 ->
> 0x63b4896 size: 0x1000
> :1201001199222203288:ccio_map_single_2: pdir 1fcb1da0 038100000eb91017
> :1201001199222391065:ccio_map_single_1:ccio_map_single() 0x1febc096 ->
> 0x63b5096 size: 0x1000
...
> Exciting results?

Yes! Nice!

> (just what would give me DEBUG_RUN() printk() but without
>  degrading system performance)

I don't believe that. :)
Measure the CPU utilization and/or compare pktgen performance with
and without the tracing compiled into the kernel.

However, that doesn't mean this is useless. This is alot better than
rolling our own "light weight" tracing mechanism and it's certainly
alot better than using printk's to debug DMA issues (as long as
the system doesn't crash - e.g. HPMC).

hth,
grant

> I still have to had some more DEBUG_RUN_SG() stuff and hope to be able to
> collect more.
> 
> Cheers,
>     r.
> 
> ---
> Scarlet One, ADSL 6 Mbps + Telephone, from EUR 29,95...
> http://www.scarlet.be/
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-parisc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

How to grab begining/end functions' address? [Wa: 'Trace patches test' ]

[rubisher]

Grant Grundler wrote:
> On Tue, Jan 22, 2008 at 02:35:21PM +0100, rubisher wrote:
>> Btw, a while back, I dream to use relayfs to grab debug info.
>> (<http://lists.parisc-linux.org/pipermail/parisc-linux/2006-April/053237.html>)
>>
>> Somebody else write it:
>> <http://lkml.org/lkml/2007/11/13/208>
>>
>> Obviously, I have to instrument things manually but I test it succesfully.
>> Here is already some primarily data test:
>> [snip]
>> :1201001199222127606:ccio_map_single_1:ccio_map_single() 0x1eb91896 ->
>> 0x63b4896 size: 0x1000
>> :1201001199222203288:ccio_map_single_2: pdir 1fcb1da0 038100000eb91017
>> :1201001199222391065:ccio_map_single_1:ccio_map_single() 0x1febc096 ->
>> 0x63b5096 size: 0x1000
> ...
>> Exciting results?
> 
> Yes! Nice!
> 
>> (just what would give me DEBUG_RUN() printk() but without
>>  degrading system performance)
> 
> I don't believe that. :)
> Measure the CPU utilization and/or compare pktgen performance with
> and without the tracing compiled into the kernel.
> 
> However, that doesn't mean this is useless. This is alot better than
> rolling our own "light weight" tracing mechanism and it's certainly
> alot better than using printk's to debug DMA issues (as long as
> the system doesn't crash - e.g. HPMC).
> 
> hth,
> grant
> 
>> I still have to had some more DEBUG_RUN_SG() stuff and hope to be able to
>> collect more.
>>
Hello Grant,

Has far as the gcc builtin instrument-functions doesn't work as I expected, I would like to grab manually the address of the 
functions' begin and end like something:
void foo(){
foo_start:
	printk ("%s() start at %p.\n, __FUNCTION__, ???ADDRESS_OF???(foo_start);
[snip]
foo_end:
	printk ("%s() start at %p.\n, __FUNCTION__, ???ADDRESS_OF???(foo_end);
};

It seems to me that I read it something like this in the past but no means to remember how to do it.
Can you help me to refresh my mind?

Tia,
	r.

Re: How to grab begining/end functions' address? [Wa: 'Trace patches test' ]

[Matthew Wilcox]

On Sun, Feb 17, 2008 at 10:52:28AM +0000, rubisher wrote:
> Has far as the gcc builtin instrument-functions doesn't work as I expected, 
> I would like to grab manually the address of the functions' begin and end 
> like something:
> void foo(){
> foo_start:
> 	printk ("%s() start at %p.\n, __FUNCTION__, 
> 	???ADDRESS_OF???(foo_start);
> [snip]
> foo_end:
> 	printk ("%s() start at %p.\n, __FUNCTION__, 
> 	???ADDRESS_OF???(foo_end);
> };
> 
> It seems to me that I read it something like this in the past but no means 
> to remember how to do it.

The kernel already has code to do this -- look at the stack backtraces.
They show addresses, function names and length of the function.  Start
by looking at BUG() and trace through to find out how the kernel does
this.

-- 
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."