[ktap] Re: KTAP

  • From: "zhangwei(Jovi)" <jovi.zhangwei@xxxxxxxxxx>
  • To: <ktap@xxxxxxxxxxxxx>
  • Date: Sat, 25 May 2013 09:12:37 +0800

On 2013/5/25 0:08, Ilya Voronin wrote:
> 'ftrace_events' is not a public symbol in current kernels because your patch 
> is
> still not accepted:
> 
> https://patchwork.kernel.org/patch/2419141/
> 
> Therefore ktap is not usable now.

Not right, many people already tried ktap in they Linux box, without any patch 
to kernel.
see LWN review on ktap by Corbet?

"ftrace_events" don't need export for ktap use. the problem Oded encountered is 
why global variable
ftrace_events in not listed in /proc/kallsyms? it should be list in there 
whatever global variable is exported or not.
> 
> On Fri, May 24, 2013 at 6:41 AM, zhangwei(Jovi)
> <jovi.zhangwei@xxxxxxxxxx> wrote:
>> On 2013/5/23 19:52, Oded Gabbay wrote:
>>>
>>> On 23/05/13 13:39, zhangwei(Jovi) wrote:
>>>> On 2013/5/23 17:36, Oded Gabbay wrote:
>>>>> On 23/05/13 12:13, zhangwei(Jovi) wrote:
>>>>>> On 2013/5/23 16:48, Oded Gabbay wrote:
>>>>>>> Hi Jovi,
>>>>>>>
>>>>>>> I read today about the ktap release in LWN and tried to give it a go on 
>>>>>>> my custom board, which contains a powerpc processor from Freescale 
>>>>>>> called P2020 (e500v2 core).
>>>>>>>
>>>>>>> I have two comments and a question:
>>>>>>>
>>>>>>> 1. I needed to enable CONFIG_RELAY in the kernel configuration, 
>>>>>>> although this is not mentioned in the requirements. Maybe you should 
>>>>>>> add it.
>>>>>>>
>>>>>> Involve ktap mailing list :)
>>>>>>
>>>>>> Thanks, you are right, I will add it.
>>>>>>
>>>>>>> 2. I needed to add #include <linux/vmalloc.h> to ktap.c for compilation
>>>>>>>
>>>>>> which kernel version of the board? currently ktap can support kernel 3.1 
>>>>>> or later, older kernel need some patch to run ktap.
>>>>>> I haven't compile ktap in powerpc, so might you are right.
>>>>> My kernel version is 3.4.41.
>>>>>>> I now arrived to a situation where I insmod the ktapvm.ko on my board, 
>>>>>>> but when I run:
>>>>>>> ./ktap scripts/syscalls.kp
>>>>>>>
>>>>>>> I get the following error:
>>>>>>> open /sys/kernel/debug/ktap/ktapvm failed: No such file or directory
>>>>>>>
>>>>>>> I checked and indeed there is no /sys/kernel/debug/ktap folder (debug 
>>>>>>> folder is empty).
>>>>>> I guess you are missing mount debugfs?
>>>>>>
>>>>>> mount -t debugfs none /sys/kernel/debug/
>>>>>>
>>>>>> Also I will add this into ktap doc.
>>>>> Yes, I was missing the mount. Thanks :)
>>>>>> Note that currently ktap is not stable enough to running in production 
>>>>>> system, but I'm trying to make it more stable :)
>>>>> I'm aware of that and I'm not putting it in production, but thanks for 
>>>>> the warning.
>>>>> After I fixed the mount issue, I was able to run the syscalls script but 
>>>>> the kernel immediately crashed...
>>>>> I will try to look into it.
>>>>> This was the message from the kernel:
>>>>>
>>>>> [cj:/usr/local/ktap] # ./ktap scripts/syscalls.kp
>>>>> Unable to handle kernel paging request for data at address 0x00000000
>>>>> Faulting instruction address: 0xf1eb5dcc
>>>>> Oops: Kernel access of bad area, sig: 11 [#1]
>>>>> PREEMPT SMP NR_CPUS=2 P2020 FSP150
>>>>> Modules linked in: ktapvm(O) mdio(O) hardware_version(PO) clipresent(PO) 
>>>>> monotonic(O) restartcause(PO) panic_buffer(O) [last unloaded: ktapvm]
>>>>> NIP: f1eb5dcc LR: f1eb5d90 CTR: c0265f04
>>>>> REGS: eedd5c90 TRAP: 0300   Tainted: P           O 
>>>>> (3.4.41-dev_ogabbay-105684*)
>>>>> MSR: 00029000 <CE,EE,ME>  CR: 44000482  XER: 20000000
>>>>> DEAR: 00000000, ESR: 00000000
>>>>> TASK = ef0c6820[2097] 'ktap' THREAD: eedd4000 CPU: 1
>>>>> GPR00: 00000000 eedd5d40 ef0c6820 eedd5d4c f1eb801c 00000016 eedd5d6a 
>>>>> 0000003a
>>>>> GPR08: eedd5d54 00000000 00000000 f1eb801d c0265f04 1002cacc 00000005 
>>>>> 00000003
>>>>> GPR16: 00000001 eede9628 00000001 eede9600 00000000 eee6e640 00000000 
>>>>> 00000000
>>>>> GPR24: 00000000 eedd5d4c f1ec0000 eede9200 ffffffff eede8600 eedd5d4c 
>>>>> eedd5db8
>>>>> NIP [f1eb5dcc] ftrace_on_event_call.clone.6+0xb4/0x1fc [ktapvm]
>>>>> LR [f1eb5d90] ftrace_on_event_call.clone.6+0x78/0x1fc [ktapvm]
>>>>> Call Trace:
>>>>> [eedd5d40] [f1eb0824] kp_tstring_newlstr+0xdc/0x164 [ktapvm] (unreliable)
>>>>> [eedd5db0] [f1eb5ff4] ktap_lib_probe+0xe0/0x198 [ktapvm]
>>>>> [eedd5de0] [f1eb2a90] precall+0x1e4/0x318 [ktapvm]
>>>>> [eedd5e00] [f1eb3244] kp_call+0x680/0x1180 [ktapvm]
>>>>> [eedd5e60] [f1eaf2c0] ktap_ioctl+0x20c/0x30c [ktapvm]
>>>>> [eedd5ea0] [c010d4f4] do_vfs_ioctl+0xa0/0x754
>>>>> [eedd5f10] [c010dc44] sys_ioctl+0x9c/0xa4
>>>>> [eedd5f40] [c000f3a0] ret_from_syscall+0x0/0x3c
>>>>> --- Exception: c01 at 0xff1e254
>>>>>      LR = 0xffb2c0c
>>>>> Instruction dump:
>>>>> 419e0024 88030000 2f800000 409e0148 88180000 2f800000 409e011c 3b200000
>>>>> 3b000000 3f40f1ec 3ac00000 813a93a0 <83c90000> 7f89f000 419e00c0 3b5a93a0
>>>>> ---[ end trace b87e7dec14e55ffe ]---
>>>>>
>>>>> cannot lookup ftrace_events in kallsyms
>>>>> Kernel panic - not syncing: Fatal exception
>>>>> Rebooting in 5 seconds..
>>>> Please pull latest ktap from github, I just figure out I missed function 
>>>> return value check.
>>>> Then there will have no panic, I assume.
>>> Yes, now there is no panic
>>>>
>>>> But I'm still curious on why your kernel didn't exported "ftrace_events", 
>>>> CONFIG_KALLSYMS not enabled?
>>> CONFIG_KALLSYMS is enabled. CONFIG_EVENT_TRACING is also enabled. But, when 
>>> I do:
>>> grep ftrace_events /proc/kallsyms
>>> I don't get any results.
>>> When I look at kernel/trace/trace_events.c, I don't see that 
>>> "ftrace_events" is exported...
>>
>> Sorry, what I said have a little misleading, global variable ftrace_events 
>> is not exported,
>> so ktap use kallsyms_lookup_name to get address of ftrace_events.
>>
>> It's so weird that you cannot found ftrace_events in /proc/kallsyms, it just 
>> is a normal global variable,
>> it seems this is another bug in powerpc or some kernel configuration problem.
>>
>>>>
>>>>>> Thanks.
>>>>>>> I thought maybe you would have any idea how to fix this and save me 
>>>>>>> time.
>>>>>>>
>>>>>>> --
>>
>>
>>
>>
> 
> 
> .
> 



Other related posts: