* Re: [Fwd: Re: Regarding systemtap support for AArch64]
[not found] <1383340682.3850.864.camel@bordewijk.wildebeest.org>
@ 2013-11-04 15:28 ` Petr Machata
2013-11-04 15:42 ` Petr Machata
2013-11-04 19:56 ` William Cohen
0 siblings, 2 replies; 22+ messages in thread
From: Petr Machata @ 2013-11-04 15:28 UTC (permalink / raw)
To: William Cohen
Cc: Mark Wielaard, Masami Hiramatsu, systemtap, Deepak Saxena,
Krishna Dani, Jakub Pavelek
Mark Wielaard <mjw@redhat.com> writes:
> According to the call abi the simple integer value should be in
> register "x0". It looks in the generated c code for the module that
> it is trying to access the return value with:
>
> { int64_t value = fetch_register (0); STAP_RETVALUE = value; }
Is this using ebl_return_value_location? That should be on the branch,
and unless I'm interpreting things wrong, it's doing the right thing:
$ ./tests/funcretval -e ~/tmp/aarch64-ble
() fun_char: return value location: {0x50, 0}
() fun_short: return value location: {0x50, 0}
() fun_int: return value location: {0x50, 0}
() fun_ptr: return value location: {0x50, 0}
() fun_iptr: return value location: {0x50, 0}
() fun_long: return value location: {0x50, 0}
() fun_int128: return value location: {0x50, 0} {0x93, 0x8} {0x51, 0} {0x93, 0x8}
[...]
I don't think there are any real tests for this in elfutils--such that
would really check that yes, the values that we expect are in the
registers that ebl_return_value_location claims.
An idea that I had was to start a binary that calls a function and
crashes (br 0?), and then inspect the coredump to see if the values are
in the registers that elfutils expect. But that seems cumbersome. I'm
reluctant to use ptrace, but that would obviously work as well.
> As a sanity check I ran a "make -s check" on the locally built aarch64
> elfutils to see if there were any issues with it.
Yes, I know of the failures. The port isn't finished yet. I had to
switch gears for some other work. I'm probably missing a bunch of hooks
that need implementing, I'm working through them one at a time.
Thanks,
PM
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Fwd: Re: Regarding systemtap support for AArch64]
2013-11-04 15:28 ` [Fwd: Re: Regarding systemtap support for AArch64] Petr Machata
@ 2013-11-04 15:42 ` Petr Machata
2013-11-04 16:06 ` Mark Wielaard
2013-11-04 19:56 ` William Cohen
1 sibling, 1 reply; 22+ messages in thread
From: Petr Machata @ 2013-11-04 15:42 UTC (permalink / raw)
To: William Cohen
Cc: Mark Wielaard, Masami Hiramatsu, systemtap, Deepak Saxena,
Krishna Dani, Jakub Pavelek
>Mark Wielaard <mjw@redhat.com> writes:
>
>> According to the call abi the simple integer value should be in
>> register "x0". It looks in the generated c code for the module that
>> it is trying to access the return value with:
>>
>> { int64_t value = fetch_register (0); STAP_RETVALUE = value; }
>
> Is this using ebl_return_value_location? That should be on the branch,
> and unless I'm interpreting things wrong, it's doing the right thing:
By which I mean dwfl_module_return_value_location ;)
Thanks,
PM
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Fwd: Re: Regarding systemtap support for AArch64]
2013-11-04 15:42 ` Petr Machata
@ 2013-11-04 16:06 ` Mark Wielaard
0 siblings, 0 replies; 22+ messages in thread
From: Mark Wielaard @ 2013-11-04 16:06 UTC (permalink / raw)
To: Petr Machata
Cc: William Cohen, Masami Hiramatsu, systemtap, Deepak Saxena,
Krishna Dani, Jakub Pavelek
On Mon, 2013-11-04 at 16:41 +0100, Petr Machata wrote:
> >Mark Wielaard <mjw@redhat.com> writes:
> >
> >> According to the call abi the simple integer value should be in
> >> register "x0". It looks in the generated c code for the module that
> >> it is trying to access the return value with:
> >>
> >> { int64_t value = fetch_register (0); STAP_RETVALUE = value; }
> >
> > Is this using ebl_return_value_location? That should be on the branch,
> > and unless I'm interpreting things wrong, it's doing the right thing:
>
> By which I mean dwfl_module_return_value_location ;)
Yes it should.
The systemtap sources contain a loc2c-test program that is build by
default. You can use it to print out something like the above output if
you want to know how stap translates some variable, argument or return
values at a given address.
For example on my x86_64 setup it will produce something like:
$ ./loc2c-test -K vfs_read "return"
#define PROBEADDR 0xffffffff81181a10ULL
static void print_value(struct pt_regs *regs)
{
intptr_t value;
{
{ int64_t value = fetch_register (0); value = value; }
}
/* max expression stack depth 0 */
printk (" ---> %ld\n", (unsigned long) value);
return;
}
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Fwd: Re: Regarding systemtap support for AArch64]
2013-11-04 15:28 ` [Fwd: Re: Regarding systemtap support for AArch64] Petr Machata
2013-11-04 15:42 ` Petr Machata
@ 2013-11-04 19:56 ` William Cohen
2013-11-05 2:48 ` Petr Machata
1 sibling, 1 reply; 22+ messages in thread
From: William Cohen @ 2013-11-04 19:56 UTC (permalink / raw)
To: Petr Machata
Cc: Mark Wielaard, Masami Hiramatsu, systemtap, Deepak Saxena,
Krishna Dani, Jakub Pavelek, Mark Salter
On 11/04/2013 10:27 AM, Petr Machata wrote:
> Mark Wielaard <mjw@redhat.com> writes:
>
>> According to the call abi the simple integer value should be in
>> register "x0". It looks in the generated c code for the module that
>> it is trying to access the return value with:
>>
>> { int64_t value = fetch_register (0); STAP_RETVALUE = value; }
>
> Is this using ebl_return_value_location? That should be on the branch,
> and unless I'm interpreting things wrong, it's doing the right thing:
>
> $ ./tests/funcretval -e ~/tmp/aarch64-ble
> () fun_char: return value location: {0x50, 0}
> () fun_short: return value location: {0x50, 0}
> () fun_int: return value location: {0x50, 0}
> () fun_ptr: return value location: {0x50, 0}
> () fun_iptr: return value location: {0x50, 0}
> () fun_long: return value location: {0x50, 0}
> () fun_int128: return value location: {0x50, 0} {0x93, 0x8} {0x51, 0} {0x93, 0x8}
> [...]
>
> I don't think there are any real tests for this in elfutils--such that
> would really check that yes, the values that we expect are in the
> registers that ebl_return_value_location claims.
>
> An idea that I had was to start a binary that calls a function and
> crashes (br 0?), and then inspect the coredump to see if the values are
> in the registers that elfutils expect. But that seems cumbersome. I'm
> reluctant to use ptrace, but that would obviously work as well.
>
>> As a sanity check I ran a "make -s check" on the locally built aarch64
>> elfutils to see if there were any issues with it.
>
> Yes, I know of the failures. The port isn't finished yet. I had to
> switch gears for some other work. I'm probably missing a bunch of hooks
> that need implementing, I'm working through them one at a time.
>
> Thanks,
> PM
>
Hi Petr,
Thanks for working on the elfutils aarch64 support.
I implemented the print_regs() function for systemtap to print out the various fields in pt_regs. I have the print_regs() ansl printing out the orig_x0 and syscallno fields also. The x0 field's value looks questionable as seen below in the short one- line systemtap scripts on the aarch64.
$ sudo ~/systemtap_write/install/bin/stap -k -e 'probe vfs.read.return {printf("$return = 0x%x\n", $return);print_regs(); exit()}'
[sudo] password for wcohen:
$return = 0xffffffc04abe5e00
CPU: 0
x0 : FFFFFFC04ABE5E00 0000007FCC574070 0000000000002004 FFFFFFC077CFBEB0
x4 : 0000000000000000 0000000000000002 0000000000000000 0000000000000005
x8 : 000000000000003F 0000000000000028 0000000000401277 0000007FCC571E70
x12: 0000000000000000 0000000000000001 0000007FCC5763B0 0000000000000004
x16: FFFFFFC0001868E0 0000007FA3F26A50 0000007FCC571B90 FFFFFFC04ABE5E00
x20: 0000007FCC574070 0000000000000001 0000007FA3F26AA8 0000000080000000
x24: 0000000000000015 0000000000000112 000000000000003F FFFFFFC000835000
x28: FFFFFFC077CF8000 FFFFFFC077CFBE80 FFFFFFC000186924
sp [ffffffc077cfbe30] pc [ffffffc000186134]
pstate [0000000060000145]
orig_x0 [0000000000000015]
syscallno [0000000000000112]
Keeping temporary directory "/tmp/stap1OWdNi"
$ sudo ~/systemtap_write/install/bin/stap -k -e 'probe vfs.read {printf("$$parms = %sn", $$parms);print_regs(); exit()}'
[sudo] password for wcohen:
$$parms = file=0xffffffc04ab83e00 buf=0x7fdaad4290 count=0x2004 pos=0xffffffc043847eb0n CPU: 0
x0 : FFFFFFC04AB83E00 0000007FDAAD4290 0000000000002004 FFFFFFC043847EB0
x4 : 0000000000000000 0000000000000002 0000000000000000 0000000000000005
x8 : 000000000000003F 0000000000000028 0000000000401277 0000007FDAAD2090
x12: 0000000000000000 0000000000000001 0000007FDAAD65D0 0000000000000004
x16: FFFFFFC0001868E0 0000007F7F6E0A50 0000007FDAAD1DB0 FFFFFFC04AB83E00
x20: 0000007FDAAD4290 0000000000000001 0000007F7F6E0AA8 0000000080000000
x24: 0000000000000015 0000000000000112 000000000000003F FFFFFFC000835000
x28: FFFFFFC043844000 FFFFFFC043847E80 FFFFFFC000186924
sp [ffffffc043847e80] pc [ffffffc000186130]
pstate [0000000060000145]
orig_x0 [0000007fdaad4120]
syscallno [ffffffc000082fec]
Keeping temporary directory "/tmp/stapQI9d6o"
-Will
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Fwd: Re: Regarding systemtap support for AArch64]
2013-11-04 19:56 ` William Cohen
@ 2013-11-05 2:48 ` Petr Machata
2013-11-05 16:09 ` William Cohen
0 siblings, 1 reply; 22+ messages in thread
From: Petr Machata @ 2013-11-05 2:48 UTC (permalink / raw)
To: William Cohen
Cc: Mark Wielaard, Masami Hiramatsu, systemtap, Deepak Saxena,
Krishna Dani, Jakub Pavelek, Mark Salter
William Cohen <wcohen@redhat.com> writes:
> x0 : FFFFFFC04ABE5E00 0000007FCC574070 0000000000002004 FFFFFFC077CFBEB0
> x4 : 0000000000000000 0000000000000002 0000000000000000 0000000000000005
> x8 : 000000000000003F 0000000000000028 0000000000401277 0000007FCC571E70
> x12: 0000000000000000 0000000000000001 0000007FCC5763B0 0000000000000004
> x16: FFFFFFC0001868E0 0000007FA3F26A50 0000007FCC571B90 FFFFFFC04ABE5E00
> x20: 0000007FCC574070 0000000000000001 0000007FA3F26AA8 0000000080000000
> x24: 0000000000000015 0000000000000112 000000000000003F FFFFFFC000835000
> x28: FFFFFFC077CF8000 FFFFFFC077CFBE80 FFFFFFC000186924
> sp [ffffffc077cfbe30] pc [ffffffc000186134]
> pstate [0000000060000145]
> orig_x0 [0000000000000015]
> syscallno [0000000000000112]
> Keeping temporary directory "/tmp/stap1OWdNi"
>
> $ sudo ~/systemtap_write/install/bin/stap -k -e 'probe vfs.read {printf("$$parms = %sn", $$parms);print_regs(); exit()}'
> [sudo] password for wcohen:
> $$parms = file=0xffffffc04ab83e00 buf=0x7fdaad4290 count=0x2004 pos=0xffffffc043847eb0n CPU: 0
> x0 : FFFFFFC04AB83E00 0000007FDAAD4290 0000000000002004 FFFFFFC043847EB0
> x4 : 0000000000000000 0000000000000002 0000000000000000 0000000000000005
> x8 : 000000000000003F 0000000000000028 0000000000401277 0000007FDAAD2090
> x12: 0000000000000000 0000000000000001 0000007FDAAD65D0 0000000000000004
> x16: FFFFFFC0001868E0 0000007F7F6E0A50 0000007FDAAD1DB0 FFFFFFC04AB83E00
> x20: 0000007FDAAD4290 0000000000000001 0000007F7F6E0AA8 0000000080000000
> x24: 0000000000000015 0000000000000112 000000000000003F FFFFFFC000835000
> x28: FFFFFFC043844000 FFFFFFC043847E80 FFFFFFC000186924
> sp [ffffffc043847e80] pc [ffffffc000186130]
> pstate [0000000060000145]
> orig_x0 [0000007fdaad4120]
> syscallno [ffffffc000082fec]
> Keeping temporary directory "/tmp/stapQI9d6o"
That 0x3F in x8 might be __NR_read, that might be from the syscall that
got us here. So possibly makes sense. 0x112 is __NR_syscalls, I don't
see how that ended up there. Maybe from a conditional? 0x2004 might
certainly be a length, though it's an odd one. The two kernel-space
parameters have similar values, and the one user-space is quite
different--again, makes sense.
So why doesn't the return value appear in x0 I don't understand. Is the
0x15 in orig_X0 the right return value?
Thanks,
PM
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Fwd: Re: Regarding systemtap support for AArch64]
2013-11-05 2:48 ` Petr Machata
@ 2013-11-05 16:09 ` William Cohen
2013-11-06 2:44 ` Sandeepa Prabhu
2013-11-06 9:55 ` Petr Machata
0 siblings, 2 replies; 22+ messages in thread
From: William Cohen @ 2013-11-05 16:09 UTC (permalink / raw)
To: Petr Machata
Cc: Mark Wielaard, Masami Hiramatsu, systemtap, Deepak Saxena,
Krishna Dani, Jakub Pavelek, Mark Salter
On 11/04/2013 09:48 PM, Petr Machata wrote:
> William Cohen <wcohen@redhat.com> writes:
>
>> x0 : FFFFFFC04ABE5E00 0000007FCC574070 0000000000002004 FFFFFFC077CFBEB0
>> x4 : 0000000000000000 0000000000000002 0000000000000000 0000000000000005
>> x8 : 000000000000003F 0000000000000028 0000000000401277 0000007FCC571E70
>> x12: 0000000000000000 0000000000000001 0000007FCC5763B0 0000000000000004
>> x16: FFFFFFC0001868E0 0000007FA3F26A50 0000007FCC571B90 FFFFFFC04ABE5E00
>> x20: 0000007FCC574070 0000000000000001 0000007FA3F26AA8 0000000080000000
>> x24: 0000000000000015 0000000000000112 000000000000003F FFFFFFC000835000
>> x28: FFFFFFC077CF8000 FFFFFFC077CFBE80 FFFFFFC000186924
>> sp [ffffffc077cfbe30] pc [ffffffc000186134]
>> pstate [0000000060000145]
>> orig_x0 [0000000000000015]
>> syscallno [0000000000000112]
>> Keeping temporary directory "/tmp/stap1OWdNi"
>
>>
>> $ sudo ~/systemtap_write/install/bin/stap -k -e 'probe vfs.read {printf("$$parms = %sn", $$parms);print_regs(); exit()}'
>> [sudo] password for wcohen:
>> $$parms = file=0xffffffc04ab83e00 buf=0x7fdaad4290 count=0x2004 pos=0xffffffc043847eb0n CPU: 0
>> x0 : FFFFFFC04AB83E00 0000007FDAAD4290 0000000000002004 FFFFFFC043847EB0
>> x4 : 0000000000000000 0000000000000002 0000000000000000 0000000000000005
>> x8 : 000000000000003F 0000000000000028 0000000000401277 0000007FDAAD2090
>> x12: 0000000000000000 0000000000000001 0000007FDAAD65D0 0000000000000004
>> x16: FFFFFFC0001868E0 0000007F7F6E0A50 0000007FDAAD1DB0 FFFFFFC04AB83E00
>> x20: 0000007FDAAD4290 0000000000000001 0000007F7F6E0AA8 0000000080000000
>> x24: 0000000000000015 0000000000000112 000000000000003F FFFFFFC000835000
>> x28: FFFFFFC043844000 FFFFFFC043847E80 FFFFFFC000186924
>> sp [ffffffc043847e80] pc [ffffffc000186130]
>> pstate [0000000060000145]
>> orig_x0 [0000007fdaad4120]
>> syscallno [ffffffc000082fec]
>> Keeping temporary directory "/tmp/stapQI9d6o"
>
> That 0x3F in x8 might be __NR_read, that might be from the syscall that
> got us here. So possibly makes sense. 0x112 is __NR_syscalls, I don't
> see how that ended up there. Maybe from a conditional? 0x2004 might
> certainly be a length, though it's an odd one. The two kernel-space
> parameters have similar values, and the one user-space is quite
> different--again, makes sense.
>
> So why doesn't the return value appear in x0 I don't understand. Is the
> 0x15 in orig_X0 the right return value?
>
> Thanks,
> PM
>
Hi Petr,
These examples systemtap might not be the best. It is just printing information for the first vfs.read or vfs.read.return encountered, so the precise values are not known for the run of these examples. These are more sanity checks. Do the values here make sense? The $return value doesn't; it should be either a positive number or some small negative number. The number printed for $return matches with what is in x0 of pt_reg, so getting a value from what appears to be the right place. However, that value in x0 looks questionable.
I wonder if there might be some issue with the patches implementing the arm64 kprobes support and that the registers are not be saved properly.
-Will
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Fwd: Re: Regarding systemtap support for AArch64]
2013-11-05 16:09 ` William Cohen
@ 2013-11-06 2:44 ` Sandeepa Prabhu
2013-11-06 9:55 ` Petr Machata
1 sibling, 0 replies; 22+ messages in thread
From: Sandeepa Prabhu @ 2013-11-06 2:44 UTC (permalink / raw)
To: William Cohen
Cc: Petr Machata, Mark Wielaard, Masami Hiramatsu, systemtap,
Deepak Saxena, Krishna Dani, Jakub Pavelek, Mark Salter
[-- Attachment #1: Type: text/plain, Size: 1377 bytes --]
> These examples systemtap might not be the best. It is just printing information for the first vfs.read or vfs.read.return encountered, so the precise values are not known for the run of these examples. These are more sanity checks. Do the values here make sense? The $return value doesn't; it should be either a positive number or some small negative number. The number printed for $return matches with what is in x0 of pt_reg, so getting a value from what appears to be the right place. However, that value in x0 looks questionable.
>
> I wonder if there might be some issue with the patches implementing the arm64 kprobes support and that the registers are not be saved properly.
Hi Will,
Just I am back from Linaro connect week, and did not get enough chance
to run systemtap with my patchset yet. but, quickly tried sample
ret-probe on some functions like vfs_read, vfs_write and do_fork,
sys_sync etc to see the return values, find the attached the log
files. sys_sync return value is zero and looks proper, but not sure
of vfs_read/write or do_fork that return ssize_t or a positive number,
I suppose register context is restored properly since all the api work
normally after restoring, need to check the copy of regs being passed
to the pre/post handlers is correct or not. I will check my code and
get back.
Thanks,
Sandeepa
>
> -Will
>
[-- Attachment #2: kernel_logs_kretprobe_sample.log --]
[-- Type: text/x-log, Size: 32409 bytes --]
Initializing cgroup subsys cpu
Linux version 3.12.0-rc4+ (sandeepa@linaro-workstation) (gcc version 4.7.3 20130328 (prerelease) (crosstool-NG linaro-1.13.1-4.7-2013.04-20130415 - Linaro GCC 2013.04) ) #2 SMP Thu Oct 17 15:39:11 IST 2013
CPU: AArch64 Processor [410fd0f0] revision 0
Machine: RTSM_VE_AEMv8A
bootconsole [earlycon0] enabled
PERCPU: Embedded 10 pages/cpu @ffffffc87ffa8000 s11904 r8192 d20864 u40960
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 1034240
Kernel command line: console=ttyAMA0 root=/dev/mmcblk0p2 earlyprintk=pl011,0x1c090000 consolelog=9 rw
PID hash table entries: 4096 (order: 3, 32768 bytes)
Dentry cache hash table entries: 524288 (order: 10, 4194304 bytes)
Inode-cache hash table entries: 262144 (order: 9, 2097152 bytes)
software IO TLB [mem 0x8f8000000-0x8fc000000] (64MB) mapped at [ffffffc878000000-ffffffc87bffffff]
Memory: 4058248K/4194304K available (3331K kernel code, 203K rwdata, 1168K rodata, 175K init, 159K bss, 136056K reserved)
Virtual kernel memory layout:
vmalloc : 0xffffff8000000000 - 0xffffffbbffff0000 (245759 MB)
vmemmap : 0xffffffbc01c00000 - 0xffffffbc1f800000 ( 476 MB)
modules : 0xffffffbffc000000 - 0xffffffc000000000 ( 64 MB)
memory : 0xffffffc000000000 - 0xffffffc880000000 ( 34816 MB)
.init : 0xffffffc0004e6000 - 0xffffffc000511e80 ( 176 kB)
.text : 0xffffffc000080000 - 0xffffffc0004e5cf4 ( 4504 kB)
.data : 0xffffffc000514000 - 0xffffffc000546d80 ( 204 kB)
SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
Hierarchical RCU implementation.
RCU restricting CPUs from NR_CPUS=8 to nr_cpu_ids=4.
NR_IRQS:64 nr_irqs:64 0
Architected cp15 timer(s) running at 100.00MHz (phys).
Console: colour dummy device 80x25
Calibrating delay loop (skipped), value calculated using timer frequency.. 200.00 BogoMIPS (lpj=1000000)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 256
hw perfevents: enabled with arm/armv8-pmuv3 PMU driver, 9 counters available
CPU1: Booted secondary processor
CPU2: Booted secondary processor
CPU3: Booted secondary processor
Brought up 4 CPUs
SMP: Total of 4 processors activated.
devtmpfs: initialized
atomic64 test passed
NET: Registered protocol family 16
of_amba_device_create(): amba_device_add() failed (-19) for /smb/motherboard/iofpga@3,00000000/sysctl@020000
vdso: 2 pages (1 code, 1 data) at base ffffffc000548000
hw-breakpoint: found 16 breakpoint and 16 watchpoint registers.
Serial: AMBA PL011 UART driver
1c090000.uart: ttyAMA0 at MMIO 0x1c090000 (irq = 37, base_baud = 0) is a PL011 rev2
console [ttyAMA0] enabled, bootconsole disabled
console [ttyAMA0] enabled, bootconsole disabled
1c0a0000.uart: ttyAMA1 at MMIO 0x1c0a0000 (irq = 38, base_baud = 0) is a PL011 rev2
1c0b0000.uart: ttyAMA2 at MMIO 0x1c0b0000 (irq = 39, base_baud = 0) is a PL011 rev2
1c0c0000.uart: ttyAMA3 at MMIO 0x1c0c0000 (irq = 40, base_baud = 0) is a PL011 rev2
bio: create slab <bio-0> at 0
SCSI subsystem initialized
Switched to clocksource arch_sys_counter
NET: Registered protocol family 2
TCP established hash table entries: 32768 (order: 7, 524288 bytes)
TCP bind hash table entries: 32768 (order: 7, 524288 bytes)
TCP: Hash tables configured (established 32768 bind 32768)
TCP: reno registered
UDP hash table entries: 2048 (order: 4, 65536 bytes)
UDP-Lite hash table entries: 2048 (order: 4, 65536 bytes)
NET: Registered protocol family 1
RPC: Registered named UNIX socket transport module.
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
RPC: Registered tcp NFSv4.1 backchannel transport module.
Unpacking initramfs...
Freeing initrd memory: 1068K (ffffffc010000000 - ffffffc01010b000)
fuse init (API version 7.22)
msgmni has been set to 7928
io scheduler noop registered
io scheduler cfq registered (default)
Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
smc91x: not found (-19).
mousedev: PS/2 mouse device common for all mice
TCP: cubic registered
NET: Registered protocol family 17
<NUL>Freeing unused kernel memory: 172K (ffffffc0004e6000 - ffffffc000511000)
Wed Nov 18 01:00:00 UTC 2009
sh: can't access tty; job control turned off
/ #
/ #
/ #
/ # insm\r/ # insmod ^[[Jkr\r/ # insmod kretprobe_example.ko ^[[Jfunc=sys_sync
Planted return probe at sys_sync: ffffffc00015b518
/ # sync
sys_sync returned 0 and took 8390 ns to execute
/ #
/ #
/ #
/ #
/ #
/ # ls
^[[1;34mbin^[[0m ^[[0;0mjprobe_example.ko^[[0m ^[[1;34mroot^[[0m
^[[1;34mdata^[[0m ^[[0;0mkprobe_dbg_addr.ko^[[0m ^[[1;34msdcard^[[0m
^[[1;36mdebug^[[0m ^[[0;0mkprobe_dbg_sym.ko^[[0m ^[[1;34msys^[[0m
^[[1;34mdev^[[0m ^[[0;0mkprobe_example.ko^[[0m ^[[1;34msystem^[[0m
^[[1;34mhome^[[0m ^[[0;0mkretprobe_example.ko^[[0m ^[[1;34mtmp^[[0m
^[[1;32minit^[[0m ^[[1;34mproc^[[0m
/ #
/ #
/ #
/ #
/ #
/ # rmm\r/ # rmmod ^[[J\b^[[J\b^[[J\b^[[J\b^[[J\b^[[J\b^[[Jrmm\r/ # rmmod ^[[Jkr\r/ # rmmod kretprobe_example.ko ^[[J
kretprobe at ffffffc00015b518 unregistered
Missed probing 0 instances of sys_sync
/ # uins\b^[[J\b^[[J\b^[[J\b^[[Jnsm\a\b^[[J\b^[[J\b^[[Jinsm\r/ # insmod ^[[Jkr\r/ # insmod kretprobe_example.ko ^[[Jfunc=do_fork
Planted return probe at do_fork: ffffffc000092dec
/ #
/ # ls
do_fork returned 18874385 and took 7370 ns to execute
^[[1;34mbin^[[0m ^[[0;0mjprobe_example.ko^[[0m ^[[1;34mroot^[[0m
^[[1;34mdata^[[0m ^[[0;0mkprobe_dbg_addr.ko^[[0m ^[[1;34msdcard^[[0m
^[[1;36mdebug^[[0m ^[[0;0mkprobe_dbg_sym.ko^[[0m ^[[1;34msys^[[0m
^[[1;34mdev^[[0m ^[[0;0mkprobe_example.ko^[[0m ^[[1;34msystem^[[0m
^[[1;34mhome^[[0m ^[[0;0mkretprobe_example.ko^[[0m ^[[1;34mtmp^[[0m
^[[1;32minit^[[0m ^[[1;34mproc^[[0m
/ # ps
do_fork returned 18874385 and took 7370 ns to execute
PID USER COMMAND
1 0 /bin/busybox sh
2 0 [kthreadd]
3 0 [ksoftirqd/0]
4 0 [kworker/0:0]
5 0 [kworker/0:0H]
6 0 [kworker/u8:0]
7 0 [migration/0]
8 0 [rcu_bh]
9 0 [rcu_sched]
10 0 [migration/1]
11 0 [ksoftirqd/1]
12 0 [kworker/1:0]
13 0 [kworker/1:0H]
14 0 [migration/2]
15 0 [ksoftirqd/2]
16 0 [kworker/2:0]
17 0 [kworker/2:0H]
18 0 [migration/3]
19 0 [ksoftirqd/3]
20 0 [kworker/3:0]
21 0 [kworker/3:0H]
22 0 [khelper]
23 0 [kdevtmpfs]
24 0 [kworker/u8:1]
168 0 [writeback]
170 0 [bioset]
172 0 [kblockd]
266 0 [kworker/3:1]
267 0 [rpciod]
282 0 [kswapd0]
327 0 [fsnotify_mark]
348 0 [nfsiod]
413 0 [kworker/0:1]
414 0 [kpsmoused]
433 0 [deferwq]
434 0 [kworker/1:1]
452 0 [kworker/2:1]
461 0 ps
/ #
/ #
/ # rmm\r/ # rmmod ^[[Jkr\r/ # rmmod kretprobe_example.ko ^[[J
do_fork returned 18874385 and took 8650 ns to execute
kretprobe at ffffffc000092dec unregistered
Missed probing 0 instances of do_fork
/ #
/ #
/ # \r/ # rmmod kretprobe_example.ko ^[[J\r/ # ps^[[J\r/ # ls^[[J\r/ # insmod kretprobe_example.ko func=do_fork^[[J\r/ # rmmod kretprobe_example.ko ^[[J\r/ # insmod kretprobe_example.ko func=do_fork^[[J\b^[[J\b^[[J\b^[[J\b^[[J\b^[[J\b^[[J\b^[[Jvfs_read
Planted return probe at vfs_read: ffffffc000132364
/ # vfs_read returned 2012380160 and took 8390 ns to execute
/ # vfs_read returned 2012380160 and took 8390 ns to execute
/ # vfs_read returned 2012380160 and took 7370 ns to execute
lvfs_read returned 2012380160 and took 7370 ns to execute
svfs_read returned 2012380160 and took 7370 ns to execute
vfs_read returned 2010203904 and took 7360 ns to execute
vfs_read returned 2010203904 and took 8500 ns to execute
^[[1;34mbin^[[0m ^[[0;0mjprobe_example.ko^[[0m ^[[1;34mroot^[[0m
^[[1;34mdata^[[0m ^[[0;0mkprobe_dbg_addr.ko^[[0m ^[[1;34msdcard^[[0m
^[[1;36mdebug^[[0m ^[[0;0mkprobe_dbg_sym.ko^[[0m ^[[1;34msys^[[0m
^[[1;34mdev^[[0m ^[[0;0mkprobe_example.ko^[[0m ^[[1;34msystem^[[0m
^[[1;34mhome^[[0m ^[[0;0mkretprobe_example.ko^[[0m ^[[1;34mtmp^[[0m
^[[1;32minit^[[0m ^[[1;34mproc^[[0m
/ # vfs_read returned 2012380160 and took 7360 ns to execute
/ # vfs_read returned 2012380160 and took 7370 ns to execute
pvfs_read returned 2012380160 and took 7370 ns to execute
svfs_read returned 2012380160 and took 7370 ns to execute
vfs_read returned 2010204416 and took 7360 ns to execute
vfs_read returned 2010204416 and took 8490 ns to execute
PID USER COMMAND
vfs_read returned 2144132864 and took 8390 ns to execute
vfs_read returned 2144130304 and took 8490 ns to execute
vfs_read returned 2144130304 and took 8390 ns to execute
1 0 /bin/busybox sh
vfs_read returned 2144130816 and took 8400 ns to execute
vfs_read returned 2144130560 and took 8390 ns to execute
2 0 [kthreadd]
vfs_read returned 2144129536 and took 8390 ns to execute
vfs_read returned 2144130048 and took 8390 ns to execute
3 0 [ksoftirqd/0]
vfs_read returned 2144129792 and took 8390 ns to execute
vfs_read returned 2144129280 and took 8400 ns to execute
4 0 [kworker/0:0]
vfs_read returned 2144129024 and took 8390 ns to execute
vfs_read returned 2144092160 and took 8390 ns to execute
5 0 [kworker/0:0H]
vfs_read returned 2144092672 and took 8390 ns to execute
vfs_read returned 2144092928 and took 8390 ns to execute
6 0 [kworker/u8:0]
vfs_read returned 2144092416 and took 8400 ns to execute
vfs_read returned 2144093440 and took 8390 ns to execute
7 0 [migration/0]
vfs_read returned 2144093696 and took 8390 ns to execute
vfs_read returned 2144093184 and took 8390 ns to execute
8 0 [rcu_bh]
vfs_read returned 2144094208 and took 8390 ns to execute
vfs_read returned 2144094464 and took 8390 ns to execute
9 0 [rcu_sched]
vfs_read returned 2144093952 and took 8390 ns to execute
vfs_read returned 2144094976 and took 8390 ns to execute
10 0 [migration/1]
vfs_read returned 2144095232 and took 8390 ns to execute
vfs_read returned 2144094720 and took 8380 ns to execute
11 0 [ksoftirqd/1]
vfs_read returned 2144095744 and took 8380 ns to execute
vfs_read returned 2144096000 and took 8390 ns to execute
12 0 [kworker/1:0]
vfs_read returned 2144095488 and took 8390 ns to execute
vfs_read returned 2004431104 and took 8380 ns to execute
13 0 [kworker/1:0H]
vfs_read returned 2004431360 and took 8390 ns to execute
vfs_read returned 2004430848 and took 8390 ns to execute
14 0 [migration/2]
vfs_read returned 2004431872 and took 8390 ns to execute
vfs_read returned 2004432128 and took 8390 ns to execute
15 0 [ksoftirqd/2]
vfs_read returned 2004431616 and took 8390 ns to execute
vfs_read returned 2004432640 and took 8390 ns to execute
16 0 [kworker/2:0]
vfs_read returned 2004432896 and took 8390 ns to execute
vfs_read returned 2004432384 and took 8390 ns to execute
17 0 [kworker/2:0H]
vfs_read returned 2004433408 and took 8390 ns to execute
vfs_read returned 2004433664 and took 8390 ns to execute
18 0 [migration/3]
vfs_read returned 2004433152 and took 8390 ns to execute
vfs_read returned 2004434176 and took 8390 ns to execute
19 0 [ksoftirqd/3]
vfs_read returned 2004434432 and took 8390 ns to execute
vfs_read returned 2004433920 and took 8390 ns to execute
20 0 [kworker/3:0]
vfs_read returned 2004434688 and took 8390 ns to execute
vfs_read returned 2004434944 and took 8390 ns to execute
21 0 [kworker/3:0H]
vfs_read returned 2004435200 and took 8390 ns to execute
vfs_read returned 2004435712 and took 8390 ns to execute
22 0 [khelper]
vfs_read returned 2004435968 and took 8390 ns to execute
vfs_read returned 2004435456 and took 8390 ns to execute
23 0 [kdevtmpfs]
vfs_read returned 2004436480 and took 8390 ns to execute
vfs_read returned 2004436736 and took 8390 ns to execute
24 0 [kworker/u8:1]
vfs_read returned 2004436224 and took 8390 ns to execute
vfs_read returned 2004437248 and took 8390 ns to execute
168 0 [writeback]
vfs_read returned 2004437504 and took 8390 ns to execute
vfs_read returned 2004436992 and took 8390 ns to execute
170 0 [bioset]
vfs_read returned 2004438016 and took 8390 ns to execute
vfs_read returned 2004438272 and took 8390 ns to execute
172 0 [kblockd]
vfs_read returned 2004437760 and took 8390 ns to execute
vfs_read returned 2004438784 and took 8380 ns to execute
266 0 [kworker/3:1]
vfs_read returned 2004438528 and took 8390 ns to execute
vfs_read returned 2004439040 and took 8390 ns to execute
267 0 [rpciod]
vfs_read returned 2004439552 and took 8390 ns to execute
vfs_read returned 2004439808 and took 8390 ns to execute
282 0 [kswapd0]
vfs_read returned 2004439296 and took 8390 ns to execute
vfs_read returned 2004440320 and took 8390 ns to execute
327 0 [fsnotify_mark]
vfs_read returned 2004440576 and took 8390 ns to execute
vfs_read returned 2004440064 and took 8390 ns to execute
348 0 [nfsiod]
vfs_read returned 2004441088 and took 8390 ns to execute
vfs_read returned 2004441344 and took 8400 ns to execute
413 0 [kworker/0:1]
vfs_read returned 2004440832 and took 8390 ns to execute
vfs_read returned 2004441856 and took 8390 ns to execute
414 0 [kpsmoused]
vfs_read returned 2004442112 and took 8390 ns to execute
vfs_read returned 2004441600 and took 8390 ns to execute
433 0 [deferwq]
vfs_read returned 2004442624 and took 8390 ns to execute
vfs_read returned 2004442880 and took 8390 ns to execute
434 0 [kworker/1:1]
vfs_read returned 2004442368 and took 8390 ns to execute
vfs_read returned 2010887680 and took 8390 ns to execute
452 0 [kworker/2:1]
vfs_read returned 2010886912 and took 7370 ns to execute
vfs_read returned 2010888704 and took 8490 ns to execute
vfs_read returned 2010888704 and took 8390 ns to execute
467 0 ps
/ # vfs_read returned 2012380160 and took 7370 ns to execute
/ # vfs_read returned 2012380160 and took 7370 ns to execute
lvfs_read returned 2012380160 and took 7380 ns to execute
svfs_read returned 2012380160 and took 8390 ns to execute
vfs_read returned 2010204928 and took 7370 ns to execute
vfs_read returned 2010204928 and took 8490 ns to execute
^[[1;34mbin^[[0m ^[[0;0mjprobe_example.ko^[[0m ^[[1;34mroot^[[0m
^[[1;34mdata^[[0m ^[[0;0mkprobe_dbg_addr.ko^[[0m ^[[1;34msdcard^[[0m
^[[1;36mdebug^[[0m ^[[0;0mkprobe_dbg_sym.ko^[[0m ^[[1;34msys^[[0m
^[[1;34mdev^[[0m ^[[0;0mkprobe_example.ko^[[0m ^[[1;34msystem^[[0m
^[[1;34mhome^[[0m ^[[0;0mkretprobe_example.ko^[[0m ^[[1;34mtmp^[[0m
^[[1;32minit^[[0m ^[[1;34mproc^[[0m
/ # vfs_read returned 2012380160 and took 7360 ns to execute
/ # vfs_read returned 2012380160 and took 7370 ns to execute
pvfs_read returned 2012380160 and took 8650 ns to execute
svfs_read returned 2012380160 and took 7360 ns to execute
vfs_read returned 2010202368 and took 7360 ns to execute
vfs_read returned 2010202368 and took 8480 ns to execute
PID USER COMMAND
vfs_read returned 2010886912 and took 8400 ns to execute
vfs_read returned 2010886656 and took 8500 ns to execute
vfs_read returned 2010886656 and took 8390 ns to execute
1 0 /bin/busybox sh
vfs_read returned 2010887424 and took 8390 ns to execute
vfs_read returned 2010887936 and took 8390 ns to execute
2 0 [kthreadd]
vfs_read returned 2010888448 and took 8380 ns to execute
vfs_read returned 2010888960 and took 8390 ns to execute
3 0 [ksoftirqd/0]
vfs_read returned 2010889472 and took 8390 ns to execute
vfs_read returned 2010886144 and took 8390 ns to execute
4 0 [kworker/0:0]
vfs_read returned 2010887168 and took 8390 ns to execute
vfs_read returned 2004442368 and took 8400 ns to execute
5 0 [kworker/0:0H]
vfs_read returned 2004442880 and took 8390 ns to execute
vfs_read returned 2004442624 and took 8390 ns to execute
6 0 [kworker/u8:0]
vfs_read returned 2004441600 and took 8400 ns to execute
vfs_read returned 2004442112 and took 8390 ns to execute
7 0 [migration/0]
vfs_read returned 2004441856 and took 8390 ns to execute
vfs_read returned 2004440832 and took 8400 ns to execute
8 0 [rcu_bh]
vfs_read returned 2004441344 and took 8380 ns to execute
vfs_read returned 2004441088 and took 8390 ns to execute
9 0 [rcu_sched]
vfs_read returned 2004440064 and took 8390 ns to execute
vfs_read returned 2004440576 and took 8390 ns to execute
10 0 [migration/1]
vfs_read returned 2004440320 and took 8390 ns to execute
vfs_read returned 2004439296 and took 8380 ns to execute
11 0 [ksoftirqd/1]
vfs_read returned 2004439808 and took 8390 ns to execute
vfs_read returned 2004439552 and took 8400 ns to execute
12 0 [kworker/1:0]
vfs_read returned 2004439040 and took 8390 ns to execute
vfs_read returned 2004438528 and took 8390 ns to execute
13 0 [kworker/1:0H]
vfs_read returned 2004438784 and took 8390 ns to execute
vfs_read returned 2004437760 and took 8390 ns to execute
14 0 [migration/2]
vfs_read returned 2004438272 and took 8390 ns to execute
vfs_read returned 2004438016 and took 8390 ns to execute
15 0 [ksoftirqd/2]
vfs_read returned 2004436992 and took 8390 ns to execute
vfs_read returned 2004437504 and took 8380 ns to execute
16 0 [kworker/2:0]
vfs_read returned 2004437248 and took 8390 ns to execute
vfs_read returned 2004436224 and took 8390 ns to execute
17 0 [kworker/2:0H]
vfs_read returned 2004436736 and took 8390 ns to execute
vfs_read returned 2004436480 and took 8390 ns to execute
18 0 [migration/3]
vfs_read returned 2004435456 and took 8390 ns to execute
vfs_read returned 2004435968 and took 8390 ns to execute
19 0 [ksoftirqd/3]
vfs_read returned 2004435712 and took 8390 ns to execute
vfs_read returned 2004435200 and took 8390 ns to execute
20 0 [kworker/3:0]
vfs_read returned 2004434944 and took 8380 ns to execute
vfs_read returned 2004434688 and took 8390 ns to execute
21 0 [kworker/3:0H]
vfs_read returned 2004433920 and took 8390 ns to execute
vfs_read returned 2004434432 and took 8390 ns to execute
22 0 [khelper]
vfs_read returned 2004434176 and took 8390 ns to execute
vfs_read returned 2004433152 and took 8400 ns to execute
23 0 [kdevtmpfs]
vfs_read returned 2004433664 and took 8390 ns to execute
vfs_read returned 2004433408 and took 8390 ns to execute
24 0 [kworker/u8:1]
vfs_read returned 2004432384 and took 8390 ns to execute
vfs_read returned 2004432896 and took 8400 ns to execute
168 0 [writeback]
vfs_read returned 2004432640 and took 8390 ns to execute
vfs_read returned 2004431616 and took 8390 ns to execute
170 0 [bioset]
vfs_read returned 2004432128 and took 8400 ns to execute
vfs_read returned 2004431872 and took 8390 ns to execute
172 0 [kblockd]
vfs_read returned 2004430848 and took 8390 ns to execute
vfs_read returned 2004431360 and took 8390 ns to execute
266 0 [kworker/3:1]
vfs_read returned 2004431104 and took 8390 ns to execute
vfs_read returned 2144095488 and took 8390 ns to execute
267 0 [rpciod]
vfs_read returned 2144096000 and took 8390 ns to execute
vfs_read returned 2144095744 and took 8390 ns to execute
282 0 [kswapd0]
vfs_read returned 2144094720 and took 8390 ns to execute
vfs_read returned 2144095232 and took 8390 ns to execute
327 0 [fsnotify_mark]
vfs_read returned 2144094976 and took 8390 ns to execute
vfs_read returned 2144093952 and took 8390 ns to execute
348 0 [nfsiod]
vfs_read returned 2144094464 and took 8390 ns to execute
vfs_read returned 2144094208 and took 8390 ns to execute
413 0 [kworker/0:1]
vfs_read returned 2144093184 and took 8390 ns to execute
vfs_read returned 2144093696 and took 8390 ns to execute
414 0 [kpsmoused]
vfs_read returned 2144093440 and took 8390 ns to execute
vfs_read returned 2144092416 and took 8390 ns to execute
433 0 [deferwq]
vfs_read returned 2144092928 and took 8390 ns to execute
vfs_read returned 2144092672 and took 8390 ns to execute
434 0 [kworker/1:1]
vfs_read returned 2144092160 and took 8390 ns to execute
vfs_read returned 2144131840 and took 8390 ns to execute
452 0 [kworker/2:1]
vfs_read returned 2144129024 and took 7370 ns to execute
vfs_read returned 2144129280 and took 8480 ns to execute
vfs_read returned 2144129280 and took 8400 ns to execute
469 0 ps
/ # vfs_read returned 2012380160 and took 7370 ns to execute
/ # vfs_read returned 2012380160 and took 7380 ns to execute
rvfs_read returned 2012380160 and took 7370 ns to execute
mvfs_read returned 2012380160 and took 7370 ns to execute
mvfs_read returned 2012380160 and took 7370 ns to execute
\r/ # rmmod ^[[Jvfs_read returned 2012380160 and took 7360 ns to execute
kvfs_read returned 2012380160 and took 8380 ns to execute
rvfs_read returned 2012380160 and took 7370 ns to execute
\r/ # rmmod kretprobe_example.ko ^[[Jvfs_read returned 2012380160 and took 8650 ns to execute
vfs_read returned 2010204672 and took 8480 ns to execute
vfs_read returned 2010204672 and took 8480 ns to execute
kretprobe at ffffffc000132364 unregistered
Missed probing 0 instances of vfs_read
/ #
/ #
/ #
/ #
/ #
/ #
/ # insm\r/ # insmod ^[[Jvfs\a_w\a\b^[[J\b^[[J\b^[[J\b^[[J\b^[[Jkr\r/ # insmod kretprobe_example.ko ^[[Jfunc=vfs_wru\b^[[Jite
Planted return probe at vfs_write: ffffffc0001321c0
vfs_write returned 2012380160 and took 8400 ns to execute
/ # vfs_write returned 2012380160 and took 8390 ns to execute
vfs_write returned 2012380160 and took 8390 ns to execute
/ # vfs_write returned 2012380160 and took 8390 ns to execute
lvfs_write returned 2012380160 and took 8390 ns to execute
svfs_write returned 2012380160 and took 8390 ns to execute
vfs_write returned 2004413952 and took 7370 ns to execute
vfs_write returned 2012380160 and took 7370 ns to execute
^[[1;34mbin^[[0m ^[[0;0mjprobe_example.ko^[[0m ^[[1;34mroot^[[0m
vfs_write returned 2012380160 and took 7360 ns to execute
^[[1;34mdata^[[0m ^[[0;0mkprobe_dbg_addr.ko^[[0m ^[[1;34msdcard^[[0m
vfs_write returned 2012380160 and took 8390 ns to execute
^[[1;36mdebug^[[0m ^[[0;0mkprobe_dbg_sym.ko^[[0m ^[[1;34msys^[[0m
vfs_write returned 2012380160 and took 7380 ns to execute
^[[1;34mdev^[[0m ^[[0;0mkprobe_example.ko^[[0m ^[[1;34msystem^[[0m
vfs_write returned 2012380160 and took 8390 ns to execute
^[[1;34mhome^[[0m ^[[0;0mkretprobe_example.ko^[[0m ^[[1;34mtmp^[[0m
vfs_write returned 2012380160 and took 7370 ns to execute
^[[1;32minit^[[0m ^[[1;34mproc^[[0m
vfs_write returned 2012380160 and took 8390 ns to execute
/ # vfs_write returned 2012380160 and took 8380 ns to execute
pvfs_write returned 2012380160 and took 8390 ns to execute
svfs_write returned 2012380160 and took 8390 ns to execute
vfs_write returned 2004413952 and took 7370 ns to execute
vfs_write returned 2012380160 and took 8650 ns to execute
PID USER COMMAND
vfs_write returned 2012380160 and took 8650 ns to execute
1 0 /bin/busybox sh
vfs_write returned 2012380160 and took 7360 ns to execute
2 0 [kthreadd]
vfs_write returned 2012380160 and took 7370 ns to execute
3 0 [ksoftirqd/0]
vfs_write returned 2012380160 and took 7370 ns to execute
4 0 [kworker/0:0]
vfs_write returned 2012380160 and took 8390 ns to execute
5 0 [kworker/0:0H]
vfs_write returned 2012380160 and took 8390 ns to execute
6 0 [kworker/u8:0]
vfs_write returned 2012380160 and took 7360 ns to execute
7 0 [migration/0]
vfs_write returned 2012380160 and took 8390 ns to execute
8 0 [rcu_bh]
vfs_write returned 2012380160 and took 8380 ns to execute
9 0 [rcu_sched]
vfs_write returned 2012380160 and took 7360 ns to execute
10 0 [migration/1]
vfs_write returned 2012380160 and took 7370 ns to execute
11 0 [ksoftirqd/1]
vfs_write returned 2012380160 and took 7370 ns to execute
12 0 [kworker/1:0]
vfs_write returned 2012380160 and took 8390 ns to execute
13 0 [kworker/1:0H]
vfs_write returned 2012380160 and took 7370 ns to execute
14 0 [migration/2]
vfs_write returned 2012380160 and took 7370 ns to execute
15 0 [ksoftirqd/2]
vfs_write returned 2012380160 and took 7380 ns to execute
16 0 [kworker/2:0]
vfs_write returned 2012380160 and took 8390 ns to execute
17 0 [kworker/2:0H]
vfs_write returned 2012380160 and took 7370 ns to execute
18 0 [migration/3]
vfs_write returned 2012380160 and took 7380 ns to execute
19 0 [ksoftirqd/3]
vfs_write returned 2012380160 and took 7380 ns to execute
20 0 [kworker/3:0]
vfs_write returned 2012380160 and took 8390 ns to execute
21 0 [kworker/3:0H]
vfs_write returned 2012380160 and took 8390 ns to execute
22 0 [khelper]
vfs_write returned 2012380160 and took 8390 ns to execute
23 0 [kdevtmpfs]
vfs_write returned 2012380160 and took 8390 ns to execute
24 0 [kworker/u8:1]
vfs_write returned 2012380160 and took 8390 ns to execute
168 0 [writeback]
vfs_write returned 2012380160 and took 8390 ns to execute
170 0 [bioset]
vfs_write returned 2012380160 and took 8390 ns to execute
172 0 [kblockd]
vfs_write returned 2012380160 and took 7360 ns to execute
266 0 [kworker/3:1]
vfs_write returned 2012380160 and took 8390 ns to execute
267 0 [rpciod]
vfs_write returned 2012380160 and took 8390 ns to execute
282 0 [kswapd0]
vfs_write returned 2012380160 and took 8390 ns to execute
327 0 [fsnotify_mark]
vfs_write returned 2012380160 and took 8390 ns to execute
348 0 [nfsiod]
vfs_write returned 2012380160 and took 7370 ns to execute
413 0 [kworker/0:1]
vfs_write returned 2012380160 and took 8390 ns to execute
414 0 [kpsmoused]
vfs_write returned 2012380160 and took 8390 ns to execute
433 0 [deferwq]
vfs_write returned 2012380160 and took 7370 ns to execute
434 0 [kworker/1:1]
vfs_write returned 2012380160 and took 7370 ns to execute
452 0 [kworker/2:1]
vfs_write returned 2012380160 and took 7370 ns to execute
475 0 ps
vfs_write returned 2012380160 and took 8390 ns to execute
/ # vfs_write returned 2012380160 and took 8390 ns to execute
vfs_write returned 2012380160 and took 8390 ns to execute
/ # vfs_write returned 2012380160 and took 8390 ns to execute
lvfs_write returned 2012380160 and took 8380 ns to execute
svfs_write returned 2012380160 and took 8390 ns to execute
vfs_write returned 2004413952 and took 7370 ns to execute
vfs_write returned 2012380160 and took 7360 ns to execute
^[[1;34mbin^[[0m ^[[0;0mjprobe_example.ko^[[0m ^[[1;34mroot^[[0m
vfs_write returned 2012380160 and took 7370 ns to execute
^[[1;34mdata^[[0m ^[[0;0mkprobe_dbg_addr.ko^[[0m ^[[1;34msdcard^[[0m
vfs_write returned 2012380160 and took 8380 ns to execute
^[[1;36mdebug^[[0m ^[[0;0mkprobe_dbg_sym.ko^[[0m ^[[1;34msys^[[0m
vfs_write returned 2012380160 and took 7380 ns to execute
^[[1;34mdev^[[0m ^[[0;0mkprobe_example.ko^[[0m ^[[1;34msystem^[[0m
vfs_write returned 2012380160 and took 8390 ns to execute
^[[1;34mhome^[[0m ^[[0;0mkretprobe_example.ko^[[0m ^[[1;34mtmp^[[0m
vfs_write returned 2012380160 and took 7380 ns to execute
^[[1;32minit^[[0m ^[[1;34mproc^[[0m
vfs_write returned 2012380160 and took 8380 ns to execute
/ # vfs_write returned 2012380160 and took 8390 ns to execute
vfs_write returned 2012380160 and took 8390 ns to execute
/ # vfs_write returned 2012380160 and took 8380 ns to execute
vfs_write returned 2012380160 and took 8390 ns to execute
/ # vfs_write returned 2012380160 and took 8390 ns to execute
cvfs_write returned 2012380160 and took 8390 ns to execute
vfs_write returned 2004413952 and took 7370 ns to execute
vfs_write returned 2012380160 and took 8390 ns to execute
sh: vfs_write returned 2012380160 and took 7380 ns to execute
c: not foundvfs_write returned 2012380160 and took 7370 ns to execute
vfs_write returned 2012380160 and took 8390 ns to execute
/ # vfs_write returned 2012380160 and took 8390 ns to execute
vfs_write returned 2012380160 and took 8390 ns to execute
/ # vfs_write returned 2012380160 and took 8390 ns to execute
vfs_write returned 2012380160 and took 8390 ns to execute
/ # vfs_write returned 2012380160 and took 8390 ns to execute
cvfs_write returned 2012380160 and took 8390 ns to execute
lvfs_write returned 2012380160 and took 8390 ns to execute
evfs_write returned 2012380160 and took 8390 ns to execute
avfs_write returned 2012380160 and took 8390 ns to execute
rvfs_write returned 2012380160 and took 8390 ns to execute
vfs_write returned 2004413952 and took 7370 ns to execute
vfs_write returned 2012380160 and took 8390 ns to execute
^[[H^[[Jvfs_write returned 2012380160 and took 8390 ns to execute
/ # vfs_write returned 2012380160 and took 8390 ns to execute
vfs_write returned 2012380160 and took 8390 ns to execute
/ # vfs_write returned 2012380160 and took 8390 ns to execute
vfs_write returned 2012380160 and took 8400 ns to execute
/ # vfs_write returned 2012380160 and took 8390 ns to execute
vfs_write returned 2012380160 and took 8390 ns to execute
/ # vfs_write returned 2012380160 and took 8390 ns to execute
vfs_write returned 2012380160 and took 8390 ns to execute
/ # vfs_write returned 2012380160 and took 8390 ns to execute
lvfs_write returned 2012380160 and took 8390 ns to execute
svfs_write returned 2012380160 and took 8390 ns to execute
vfs_write returned 2004413952 and took 7370 ns to execute
vfs_write returned 2012380160 and took 7370 ns to execute
^[[1;34mbin^[[0m ^[[0;0mjprobe_example.ko^[[0m ^[[1;34mroot^[[0m
vfs_write returned 2012380160 and took 7370 ns to execute
^[[1;34mdata^[[0m ^[[0;0mkprobe_dbg_addr.ko^[[0m ^[[1;34msdcard^[[0m
vfs_write returned 2012380160 and took 8390 ns to execute
^[[1;36mdebug^[[0m ^[[0;0mkprobe_dbg_sym.ko^[[0m ^[[1;34msys^[[0m
vfs_write returned 2012380160 and took 7370 ns to execute
^[[1;34mdev^[[0m ^[[0;0mkprobe_example.ko^[[0m ^[[1;34msystem^[[0m
vfs_write returned 2012380160 and took 8390 ns to execute
^[[1;34mhome^[[0m ^[[0;0mkretprobe_example.ko^[[0m ^[[1;34mtmp^[[0m
vfs_write returned 2012380160 and took 7370 ns to execute
^[[1;32minit^[[0m ^[[1;34mproc^[[0m
vfs_write returned 2012380160 and took 8390 ns to execute
/ # vfs_write returned 2012380160 and took 8390 ns to execute
rvfs_write returned 2012380160 and took 8390 ns to execute
mvfs_write returned 2012380160 and took 8400 ns to execute
mvfs_write returned 2012380160 and took 8390 ns to execute
\r/ # vfs_write returned 2012380160 and took 7370 ns to execute
rmmod ^[[Jvfs_write returned 2012380160 and took 8400 ns to execute
kvfs_write returned 2012380160 and took 8390 ns to execute
rvfs_write returned 2012380160 and took 7360 ns to execute
\r/ # vfs_write returned 2012380160 and took 7370 ns to execute
rmmod kretprobe_example.ko ^[[Jvfs_write returned 2012380160 and took 8390 ns to execute
vfs_write returned 2004413184 and took 8390 ns to execute
kretprobe at ffffffc0001321c0 unregistered
Missed probing 0 instances of vfs_write
/ #
/ #
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Fwd: Re: Regarding systemtap support for AArch64]
2013-11-05 16:09 ` William Cohen
2013-11-06 2:44 ` Sandeepa Prabhu
@ 2013-11-06 9:55 ` Petr Machata
2013-11-07 11:54 ` Sandeepa Prabhu
1 sibling, 1 reply; 22+ messages in thread
From: Petr Machata @ 2013-11-06 9:55 UTC (permalink / raw)
To: William Cohen
Cc: Mark Wielaard, Masami Hiramatsu, systemtap, Deepak Saxena,
Krishna Dani, Jakub Pavelek, Mark Salter
William Cohen <wcohen@redhat.com> writes:
> On 11/04/2013 09:48 PM, Petr Machata wrote:
>> That 0x3F in x8 might be __NR_read, that might be from the syscall that
>> got us here. So possibly makes sense. 0x112 is __NR_syscalls, I don't
>> see how that ended up there. Maybe from a conditional? 0x2004 might
>> certainly be a length, though it's an odd one. The two kernel-space
>> parameters have similar values, and the one user-space is quite
>> different--again, makes sense.
>
> These examples systemtap might not be the best. It is just printing
> information for the first vfs.read or vfs.read.return encountered, so
I understand. I was trying to figue out what's in the registers. I can
agree that x0 to x4 hold vfs_read arguments on entry, so why doesn't, on
function return, x0 hold the return value?
> I wonder if there might be some issue with the patches implementing
> the arm64 kprobes support and that the registers are not be saved
> properly.
I was wondering about the same thing.
Thanks,
PM
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Fwd: Re: Regarding systemtap support for AArch64]
2013-11-06 9:55 ` Petr Machata
@ 2013-11-07 11:54 ` Sandeepa Prabhu
2013-11-07 13:44 ` Sandeepa Prabhu
2013-11-07 14:56 ` [Fwd: Re: Regarding systemtap support for AArch64] William Cohen
0 siblings, 2 replies; 22+ messages in thread
From: Sandeepa Prabhu @ 2013-11-07 11:54 UTC (permalink / raw)
To: Petr Machata
Cc: William Cohen, Mark Wielaard, Masami Hiramatsu, systemtap,
Deepak Saxena, Krishna Dani, Jakub Pavelek, Mark Salter
On 6 November 2013 15:24, Petr Machata <pmachata@redhat.com> wrote:
> William Cohen <wcohen@redhat.com> writes:
>
>> On 11/04/2013 09:48 PM, Petr Machata wrote:
>>> That 0x3F in x8 might be __NR_read, that might be from the syscall that
>>> got us here. So possibly makes sense. 0x112 is __NR_syscalls, I don't
>>> see how that ended up there. Maybe from a conditional? 0x2004 might
>>> certainly be a length, though it's an odd one. The two kernel-space
>>> parameters have similar values, and the one user-space is quite
>>> different--again, makes sense.
>>
>> These examples systemtap might not be the best. It is just printing
>> information for the first vfs.read or vfs.read.return encountered, so
>
> I understand. I was trying to figue out what's in the registers. I can
> agree that x0 to x4 hold vfs_read arguments on entry, so why doesn't, on
> function return, x0 hold the return value?
>
>> I wonder if there might be some issue with the patches implementing
>> the arm64 kprobes support and that the registers are not be saved
>> properly.
>
> I was wondering about the same thing.
Hi Will, Petr,
Yes, I found some design issue with respect to trampoline placement,
(my code is the culprit!!). I am going to fix this soon and update you
all.
Thanks,
Sandeepa
>
> Thanks,
> PM
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Fwd: Re: Regarding systemtap support for AArch64]
2013-11-07 11:54 ` Sandeepa Prabhu
@ 2013-11-07 13:44 ` Sandeepa Prabhu
2013-11-07 13:50 ` Sandeepa Prabhu
2013-11-07 14:56 ` [Fwd: Re: Regarding systemtap support for AArch64] William Cohen
1 sibling, 1 reply; 22+ messages in thread
From: Sandeepa Prabhu @ 2013-11-07 13:44 UTC (permalink / raw)
To: Petr Machata
Cc: William Cohen, Mark Wielaard, Masami Hiramatsu, systemtap,
Deepak Saxena, Mark Salter
On 7 November 2013 17:24, Sandeepa Prabhu <sandeepa.prabhu@linaro.org> wrote:
> On 6 November 2013 15:24, Petr Machata <pmachata@redhat.com> wrote:
>> William Cohen <wcohen@redhat.com> writes:
>>
>>> On 11/04/2013 09:48 PM, Petr Machata wrote:
>>>> That 0x3F in x8 might be __NR_read, that might be from the syscall that
>>>> got us here. So possibly makes sense. 0x112 is __NR_syscalls, I don't
>>>> see how that ended up there. Maybe from a conditional? 0x2004 might
>>>> certainly be a length, though it's an odd one. The two kernel-space
>>>> parameters have similar values, and the one user-space is quite
>>>> different--again, makes sense.
>>>
>>> These examples systemtap might not be the best. It is just printing
>>> information for the first vfs.read or vfs.read.return encountered, so
>>
>> I understand. I was trying to figue out what's in the registers. I can
>> agree that x0 to x4 hold vfs_read arguments on entry, so why doesn't, on
>> function return, x0 hold the return value?
>>
>>> I wonder if there might be some issue with the patches implementing
>>> the arm64 kprobes support and that the registers are not be saved
>>> properly.
>>
>> I was wondering about the same thing.
> Hi Will, Petr,
>
> Yes, I found some design issue with respect to trampoline placement,
> (my code is the culprit!!). I am going to fix this soon and update you
> all.
>
Hi Will, Petr,
I have fixed the issue and now able to get proper function return
values. (Earlier, trampoline was not installed at correct location, so
used to carry wrong register context to handler)
Updated patches are at:
https://git.linaro.org/gitweb?p=people/sandeepa.prabhu/linux-aarch64.git;a=shortlog;h=refs/heads/arm64-kprobes-devel
Please switch to my devel branch:
"git://git.linaro.org/people/sandeepa.prabhu/linux-aarch64.git
Branch: arm64-kprobes-devel" and let me know how this work.
~Sandeepa
> Thanks,
> Sandeepa
>>
>> Thanks,
>> PM
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Fwd: Re: Regarding systemtap support for AArch64]
2013-11-07 13:44 ` Sandeepa Prabhu
@ 2013-11-07 13:50 ` Sandeepa Prabhu
2013-11-07 15:22 ` William Cohen
0 siblings, 1 reply; 22+ messages in thread
From: Sandeepa Prabhu @ 2013-11-07 13:50 UTC (permalink / raw)
To: Petr Machata
Cc: William Cohen, Mark Wielaard, Masami Hiramatsu, systemtap,
Deepak Saxena, Mark Salter
On 7 November 2013 19:13, Sandeepa Prabhu <sandeepa.prabhu@linaro.org> wrote:
> On 7 November 2013 17:24, Sandeepa Prabhu <sandeepa.prabhu@linaro.org> wrote:
>> On 6 November 2013 15:24, Petr Machata <pmachata@redhat.com> wrote:
>>> William Cohen <wcohen@redhat.com> writes:
>>>
>>>> On 11/04/2013 09:48 PM, Petr Machata wrote:
>>>>> That 0x3F in x8 might be __NR_read, that might be from the syscall that
>>>>> got us here. So possibly makes sense. 0x112 is __NR_syscalls, I don't
>>>>> see how that ended up there. Maybe from a conditional? 0x2004 might
>>>>> certainly be a length, though it's an odd one. The two kernel-space
>>>>> parameters have similar values, and the one user-space is quite
>>>>> different--again, makes sense.
>>>>
>>>> These examples systemtap might not be the best. It is just printing
>>>> information for the first vfs.read or vfs.read.return encountered, so
>>>
>>> I understand. I was trying to figue out what's in the registers. I can
>>> agree that x0 to x4 hold vfs_read arguments on entry, so why doesn't, on
>>> function return, x0 hold the return value?
>>>
>>>> I wonder if there might be some issue with the patches implementing
>>>> the arm64 kprobes support and that the registers are not be saved
>>>> properly.
>>>
>>> I was wondering about the same thing.
>> Hi Will, Petr,
>>
>> Yes, I found some design issue with respect to trampoline placement,
>> (my code is the culprit!!). I am going to fix this soon and update you
>> all.
>>
> Hi Will, Petr,
>
> I have fixed the issue and now able to get proper function return
> values. (Earlier, trampoline was not installed at correct location, so
> used to carry wrong register context to handler)
> Updated patches are at:
> https://git.linaro.org/gitweb?p=people/sandeepa.prabhu/linux-aarch64.git;a=shortlog;h=refs/heads/arm64-kprobes-devel
>
> Please switch to my devel branch:
> "git://git.linaro.org/people/sandeepa.prabhu/linux-aarch64.git
> Branch: arm64-kprobes-devel" and let me know how this work.
[ Also, please ignore the code comment and commit descriptions, I will
change them when publishing v3 patchset, but before that, want to
conduct more test and find as many bugs as possible ]
>
> ~Sandeepa
>
>> Thanks,
>> Sandeepa
>>>
>>> Thanks,
>>> PM
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Fwd: Re: Regarding systemtap support for AArch64]
2013-11-07 11:54 ` Sandeepa Prabhu
2013-11-07 13:44 ` Sandeepa Prabhu
@ 2013-11-07 14:56 ` William Cohen
2013-11-08 2:22 ` Sandeepa Prabhu
1 sibling, 1 reply; 22+ messages in thread
From: William Cohen @ 2013-11-07 14:56 UTC (permalink / raw)
To: Sandeepa Prabhu, Petr Machata
Cc: Mark Wielaard, Masami Hiramatsu, systemtap, Deepak Saxena,
Krishna Dani, Jakub Pavelek, Mark Salter
On 11/07/2013 06:54 AM, Sandeepa Prabhu wrote:
> On 6 November 2013 15:24, Petr Machata <pmachata@redhat.com> wrote:
>> William Cohen <wcohen@redhat.com> writes:
>>
>>> On 11/04/2013 09:48 PM, Petr Machata wrote:
>>>> That 0x3F in x8 might be __NR_read, that might be from the syscall that
>>>> got us here. So possibly makes sense. 0x112 is __NR_syscalls, I don't
>>>> see how that ended up there. Maybe from a conditional? 0x2004 might
>>>> certainly be a length, though it's an odd one. The two kernel-space
>>>> parameters have similar values, and the one user-space is quite
>>>> different--again, makes sense.
>>>
>>> These examples systemtap might not be the best. It is just printing
>>> information for the first vfs.read or vfs.read.return encountered, so
>>
>> I understand. I was trying to figue out what's in the registers. I can
>> agree that x0 to x4 hold vfs_read arguments on entry, so why doesn't, on
>> function return, x0 hold the return value?
>>
>>> I wonder if there might be some issue with the patches implementing
>>> the arm64 kprobes support and that the registers are not be saved
>>> properly.
>>
>> I was wondering about the same thing.
> Hi Will, Petr,
>
> Yes, I found some design issue with respect to trampoline placement,
> (my code is the culprit!!). I am going to fix this soon and update you
> all.
>
> Thanks,
> Sandeepa
>>
>> Thanks,
>> PM
Hi Sandeepa,
I was just going to ask you about the trampoline code. I ran a little experiment and it looked like the place the probe was firing wasn't correct.
$ sudo ~/systemtap_write/install/bin/stap -k -v -e 'probe vfs.read.return {printf("$return = 0x%x\n", $return);print_regs(); exit()}'
[sudo] password for wcohen:
Pass 1: parsed user script and 93 library script(s) using 140720virt/25044res/2776shr/22936data kb, in 4740usr/190sys/5353real ms.
Pass 2: analyzed script: 2 probe(s), 8 function(s), 6 embed(s), 0 global(s) using 323612virt/103604res/3656shr/100456data kb, in 39780usr/13630sys/58215real ms.
Pass 3: translated to C into "/tmp/stap0GjZue/stap_1107_src.c" using 323612virt/105948res/6000shr/100456data kb, in 150usr/10sys/176real ms.
Pass 4: compiled C into "stap_1107.ko" in 119270usr/10570sys/143518real ms.
Pass 5: starting run.
$return = 0xffffffc04609f700
pc : [<ffffffc000186134>] lr : [<ffffffc000186924>] pstate: 60000145
sp : ffffffc04ce8be30
x29: ffffffc04ce8be80 x28: ffffffc04ce88000
x27: ffffffc000835000 x26: 000000000000003f
x25: 0000000000000112 x24: 0000000000000015
x23: 0000000080000000 x22: 0000007f7a332aa8
x21: 0000000000000001 x20: 0000007fd0e51730
x19: ffffffc04609f700 x18: 0000007fd0e4f250
x17: 0000007f7a332a50 x16: ffffffc0001868e0
x15: 0000000000000004 x14: 0000007fd0e53a70
x13: 0000000000000001 x12: 0000000000000000
x11: 0000007fd0e4f530 x10: 0000000000401277
x9 : 0000000000000028 x8 : 000000000000003f
x7 : 0000000000000005 x6 : 0000000000000000
x5 : 0000000000000002 x4 : 0000000000000000
x3 : ffffffc04ce8beb0 x2 : 0000000000002004
x1 : 0000007fd0e51730 x0 : ffffffc04609f700
Pass 5: run completed in 120usr/80sys/579real ms.
Keeping temporary directory "/tmp/stap0GjZue"
[wcohen@localhost systemtap]$
Look at pc : [<ffffffc000186134>]
ffffffc000186130 <vfs_read>:
ffffffc000186130: a9bb7bfd stp x29, x30, [sp,#-80]!
ffffffc000186134: 910003fd mov x29, sp
ffffffc000186138: a9025bf5 stp x21, x22, [sp,#32]
ffffffc00018613c: a90153f3 stp x19, x20, [sp,#16]
Look at lr : [<ffffffc000186924>]
ffffffc00018691c: f9001ba4 str x4, [x29,#48]
ffffffc000186920: 97fffe04 bl ffffffc000186130 <vfs_read>
ffffffc000186924: aa0003f4 mov x20, x0
The lr value look plausible, but the pc value looks like the function entry not the function exit.
-Will
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Fwd: Re: Regarding systemtap support for AArch64]
2013-11-07 13:50 ` Sandeepa Prabhu
@ 2013-11-07 15:22 ` William Cohen
2013-11-27 5:35 ` Sandeepa Prabhu
0 siblings, 1 reply; 22+ messages in thread
From: William Cohen @ 2013-11-07 15:22 UTC (permalink / raw)
To: Sandeepa Prabhu, Petr Machata
Cc: Mark Wielaard, Masami Hiramatsu, systemtap, Deepak Saxena, Mark Salter
On 11/07/2013 08:49 AM, Sandeepa Prabhu wrote:
> On 7 November 2013 19:13, Sandeepa Prabhu <sandeepa.prabhu@linaro.org> wrote:
>> On 7 November 2013 17:24, Sandeepa Prabhu <sandeepa.prabhu@linaro.org> wrote:
>>> On 6 November 2013 15:24, Petr Machata <pmachata@redhat.com> wrote:
>>>> William Cohen <wcohen@redhat.com> writes:
>>>>
>>>>> On 11/04/2013 09:48 PM, Petr Machata wrote:
>>>>>> That 0x3F in x8 might be __NR_read, that might be from the syscall that
>>>>>> got us here. So possibly makes sense. 0x112 is __NR_syscalls, I don't
>>>>>> see how that ended up there. Maybe from a conditional? 0x2004 might
>>>>>> certainly be a length, though it's an odd one. The two kernel-space
>>>>>> parameters have similar values, and the one user-space is quite
>>>>>> different--again, makes sense.
>>>>>
>>>>> These examples systemtap might not be the best. It is just printing
>>>>> information for the first vfs.read or vfs.read.return encountered, so
>>>>
>>>> I understand. I was trying to figue out what's in the registers. I can
>>>> agree that x0 to x4 hold vfs_read arguments on entry, so why doesn't, on
>>>> function return, x0 hold the return value?
>>>>
>>>>> I wonder if there might be some issue with the patches implementing
>>>>> the arm64 kprobes support and that the registers are not be saved
>>>>> properly.
>>>>
>>>> I was wondering about the same thing.
>>> Hi Will, Petr,
>>>
>>> Yes, I found some design issue with respect to trampoline placement,
>>> (my code is the culprit!!). I am going to fix this soon and update you
>>> all.
>>>
>> Hi Will, Petr,
>>
>> I have fixed the issue and now able to get proper function return
>> values. (Earlier, trampoline was not installed at correct location, so
>> used to carry wrong register context to handler)
>> Updated patches are at:
>> https://git.linaro.org/gitweb?p=people/sandeepa.prabhu/linux-aarch64.git;a=shortlog;h=refs/heads/arm64-kprobes-devel
>>
>> Please switch to my devel branch:
>> "git://git.linaro.org/people/sandeepa.prabhu/linux-aarch64.git
>> Branch: arm64-kprobes-devel" and let me know how this work.
> [ Also, please ignore the code comment and commit descriptions, I will
> change them when publishing v3 patchset, but before that, want to
> conduct more test and find as many bugs as possible ]
Hi Sandeepa,
I have switched to the arm64-kprobes-devel branch, pulled in the msalters uefi patches (armv8-uefi-lates branch of https://github.com/mosalter/linux), and started building a new kernel. The simulator is slow, so it will take a while for a new kernel to be available.
I have pushed the aarch64 print_reg() support into the systemtap git repository to make it easier to test out aarch64 support include the kprobes and kretprobes. So on the aarch64 simulator something like the following to get a systemtap that has support for aarch64:
# get the elfutils sources
cd ~
git clone git://git.fedorahosted.org/git/elfutils.git
cd elfutils
git checkout aarch64
# get systemtap
cd ~
mkdir systemtap_write
cd systemtap_write
git clone git://sourceware.org/git/systemtap.git
cd systemtap
./configure --disable-docs --prefix=~/systemtap_write/install --with-elfutils=~/elfutils
make
make install
I noticed for the 32-bit arm uprobes that there are some test to make sure that the uprobes simulate the instructions properly. How are the various instructions emulation/fixups for the arm64 being tested? The code for the 32-bit arm uprobes testing is at:
https://github.com/rabinv/uprobes-test
-Will
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Fwd: Re: Regarding systemtap support for AArch64]
2013-11-07 14:56 ` [Fwd: Re: Regarding systemtap support for AArch64] William Cohen
@ 2013-11-08 2:22 ` Sandeepa Prabhu
2013-11-09 3:27 ` William Cohen
0 siblings, 1 reply; 22+ messages in thread
From: Sandeepa Prabhu @ 2013-11-08 2:22 UTC (permalink / raw)
To: William Cohen
Cc: Petr Machata, Mark Wielaard, Masami Hiramatsu, systemtap,
Deepak Saxena, Krishna Dani, Jakub Pavelek, Mark Salter
On 7 November 2013 20:26, William Cohen <wcohen@redhat.com> wrote:
> On 11/07/2013 06:54 AM, Sandeepa Prabhu wrote:
>> On 6 November 2013 15:24, Petr Machata <pmachata@redhat.com> wrote:
>>> William Cohen <wcohen@redhat.com> writes:
>>>
>>>> On 11/04/2013 09:48 PM, Petr Machata wrote:
>>>>> That 0x3F in x8 might be __NR_read, that might be from the syscall that
>>>>> got us here. So possibly makes sense. 0x112 is __NR_syscalls, I don't
>>>>> see how that ended up there. Maybe from a conditional? 0x2004 might
>>>>> certainly be a length, though it's an odd one. The two kernel-space
>>>>> parameters have similar values, and the one user-space is quite
>>>>> different--again, makes sense.
>>>>
>>>> These examples systemtap might not be the best. It is just printing
>>>> information for the first vfs.read or vfs.read.return encountered, so
>>>
>>> I understand. I was trying to figue out what's in the registers. I can
>>> agree that x0 to x4 hold vfs_read arguments on entry, so why doesn't, on
>>> function return, x0 hold the return value?
>>>
>>>> I wonder if there might be some issue with the patches implementing
>>>> the arm64 kprobes support and that the registers are not be saved
>>>> properly.
>>>
>>> I was wondering about the same thing.
>> Hi Will, Petr,
>>
>> Yes, I found some design issue with respect to trampoline placement,
>> (my code is the culprit!!). I am going to fix this soon and update you
>> all.
>>
>> Thanks,
>> Sandeepa
>>>
>>> Thanks,
>>> PM
>
> Hi Sandeepa,
>
> I was just going to ask you about the trampoline code. I ran a little experiment and it looked like the place the probe was firing wasn't correct.
>
> $ sudo ~/systemtap_write/install/bin/stap -k -v -e 'probe vfs.read.return {printf("$return = 0x%x\n", $return);print_regs(); exit()}'
> [sudo] password for wcohen:
> Pass 1: parsed user script and 93 library script(s) using 140720virt/25044res/2776shr/22936data kb, in 4740usr/190sys/5353real ms.
> Pass 2: analyzed script: 2 probe(s), 8 function(s), 6 embed(s), 0 global(s) using 323612virt/103604res/3656shr/100456data kb, in 39780usr/13630sys/58215real ms.
> Pass 3: translated to C into "/tmp/stap0GjZue/stap_1107_src.c" using 323612virt/105948res/6000shr/100456data kb, in 150usr/10sys/176real ms.
> Pass 4: compiled C into "stap_1107.ko" in 119270usr/10570sys/143518real ms.
> Pass 5: starting run.
> $return = 0xffffffc04609f700
> pc : [<ffffffc000186134>] lr : [<ffffffc000186924>] pstate: 60000145
> sp : ffffffc04ce8be30
> x29: ffffffc04ce8be80 x28: ffffffc04ce88000
> x27: ffffffc000835000 x26: 000000000000003f
> x25: 0000000000000112 x24: 0000000000000015
> x23: 0000000080000000 x22: 0000007f7a332aa8
> x21: 0000000000000001 x20: 0000007fd0e51730
> x19: ffffffc04609f700 x18: 0000007fd0e4f250
> x17: 0000007f7a332a50 x16: ffffffc0001868e0
> x15: 0000000000000004 x14: 0000007fd0e53a70
> x13: 0000000000000001 x12: 0000000000000000
> x11: 0000007fd0e4f530 x10: 0000000000401277
> x9 : 0000000000000028 x8 : 000000000000003f
> x7 : 0000000000000005 x6 : 0000000000000000
> x5 : 0000000000000002 x4 : 0000000000000000
> x3 : ffffffc04ce8beb0 x2 : 0000000000002004
> x1 : 0000007fd0e51730 x0 : ffffffc04609f700
>
> Pass 5: run completed in 120usr/80sys/579real ms.
> Keeping temporary directory "/tmp/stap0GjZue"
> [wcohen@localhost systemtap]$
>
>
> Look at pc : [<ffffffc000186134>]
>
> ffffffc000186130 <vfs_read>:
> ffffffc000186130: a9bb7bfd stp x29, x30, [sp,#-80]!
> ffffffc000186134: 910003fd mov x29, sp
> ffffffc000186138: a9025bf5 stp x21, x22, [sp,#32]
> ffffffc00018613c: a90153f3 stp x19, x20, [sp,#16]
>
>
> Look at lr : [<ffffffc000186924>]
>
> ffffffc00018691c: f9001ba4 str x4, [x29,#48]
> ffffffc000186920: 97fffe04 bl ffffffc000186130 <vfs_read>
> ffffffc000186924: aa0003f4 mov x20, x0
>
> The lr value look plausible, but the pc value looks like the function entry not the function exit.
Yes exactly, the trampoline was replacing exception return (ERET)
address not the function return (RET) address! (wrong manipulation of
saved pt_regs), so was firing ret-probe at the function entry not
return and x0 showed the function argument not the return value.
Thanks for pointing out this, have fixed this on my devel branch.
~Sandeepa
>
> -Will
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Fwd: Re: Regarding systemtap support for AArch64]
2013-11-08 2:22 ` Sandeepa Prabhu
@ 2013-11-09 3:27 ` William Cohen
0 siblings, 0 replies; 22+ messages in thread
From: William Cohen @ 2013-11-09 3:27 UTC (permalink / raw)
To: Sandeepa Prabhu
Cc: Petr Machata, Mark Wielaard, Masami Hiramatsu, systemtap,
Deepak Saxena, Krishna Dani, Jakub Pavelek, Mark Salter
On 11/07/2013 09:22 PM, Sandeepa Prabhu wrote:
> Yes exactly, the trampoline was replacing exception return (ERET)
> address not the function return (RET) address! (wrong manipulation of
> saved pt_regs), so was firing ret-probe at the function entry not
> return and x0 showed the function argument not the return value.
> Thanks for pointing out this, have fixed this on my devel branch.
> ~Sandeepa
>>
>> -Will
Hi Sandeepa,
The build of the devel branch kernel finally finished and I was able to boot it. The results look much better for the probe of vfs.return. Thanks for fixing this. Thanks so much for fixing the kretprobes.
$ uname -a
Linux localhost 3.12.0-rc5+ #6 SMP Thu Nov 7 21:27:15 EST 2013 aarch64 aarch64 aarch64 GNU/Linux
$ sudo ~/systemtap_write/install/bin/stap -k -e 'probe vfs.read.return {printf("$return = 0x%x\n", $return);print_regs(); exit()}'
[sudo] password for wcohen:
$return = 0xc
pc : [<ffffffc000186924>] lr : [<ffffffc00008b07c>] pstate: 40000145
sp : ffffffc05f6f7e80
x29: ffffffc05f6f7e80 x28: ffffffc05f6f4000
x27: ffffffc000835000 x26: 000000000000003f
x25: 0000000000000112 x24: 0000000000000015
x23: 0000000080000000 x22: 0000007fa256eaa8
x21: 0000000000000001 x20: 0000007fdf0520e0
x19: ffffffc05f502100 x18: 0000007fdf050c70
x17: 0000007fa256ea50 x16: ffffffc0001868e0
x15: 0000000000000004 x14: 0000007fdf054420
x13: 0000000000000001 x12: 0000000000000008
x11: 00000000106180f0 x10: 0000000000401277
x9 : 0000000000000028 x8 : 000000000000003f
x7 : 0000000000000005 x6 : 0000000000000000
x5 : 0000000000000000 x4 : 0000000000000000
x3 : 0000000000000001 x2 : 00000000000000a6
x1 : ffffffc072d62800 x0 : 000000000000000c
Keeping temporary directory "/tmp/stapJO91tf"
Looking at where the pc is in the disassembled vmlinux that seems to make sense. The instruction right after the call to vfs_read:
ffffffc00018691c: f9001ba4 str x4, [x29,#48]
ffffffc000186920: 97fffe04 bl ffffffc000186130 <vfs_read>
ffffffc000186924: aa0003f4 mov x20, x0
ffffffc000186928: b7f80074 tbnz x20, #63, ffffffc000186934 <SyS\
_read+0x54>
-Will
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Fwd: Re: Regarding systemtap support for AArch64]
2013-11-07 15:22 ` William Cohen
@ 2013-11-27 5:35 ` Sandeepa Prabhu
2013-11-27 8:30 ` Petr Machata
2013-11-27 15:51 ` New location for aarch64 Fedora 19 packages William Cohen
0 siblings, 2 replies; 22+ messages in thread
From: Sandeepa Prabhu @ 2013-11-27 5:35 UTC (permalink / raw)
To: William Cohen
Cc: Petr Machata, Mark Wielaard, Masami Hiramatsu, systemtap,
Deepak Saxena, Mark Salter
> Hi Sandeepa,
>
> I have switched to the arm64-kprobes-devel branch, pulled in the msalters uefi patches (armv8-uefi-lates branch of https://github.com/mosalter/linux), and started building a new kernel. The simulator is slow, so it will take a while for a new kernel to be available.
>
> I have pushed the aarch64 print_reg() support into the systemtap git repository to make it easier to test out aarch64 support include the kprobes and kretprobes. So on the aarch64 simulator something like the following to get a systemtap that has support for aarch64:
>
> # get the elfutils sources
> cd ~
> git clone git://git.fedorahosted.org/git/elfutils.git
> cd elfutils
> git checkout aarch64
> # get systemtap
> cd ~
> mkdir systemtap_write
> cd systemtap_write
> git clone git://sourceware.org/git/systemtap.git
> cd systemtap
> ./configure --disable-docs --prefix=~/systemtap_write/install --with-elfutils=~/elfutils
> make
> make install
Hi Will,
I have booted fc19 as per
http://fedoraproject.org/wiki/Architectures/ARM/AArch64/QuickStart
successfully and able to setup networking.
However, when I tried to install basic packages like git, it throws
timeout errors:
----------------------------
[root@localhost ~]# yum install git-core
Loaded plugins: langpacks, refresh-packagekit
arm64 | 2.9 kB 00:00
http://arm-temp.ausil.us/pub/fedora-arm/stage4/repodata/repomd.xml:
[Errno 12] Timeout on
http://arm-temp.ausil.us/pub/fedora-arm/stage4/repodata/repomd.xml:
(28, 'Connection timed out after 30050 milliseconds')
Trying other mirror.
----------------------------
What could be the issue? Is it could be because of slow internet or I
am missing something?
Thanks,
Sandeepa
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Fwd: Re: Regarding systemtap support for AArch64]
2013-11-27 5:35 ` Sandeepa Prabhu
@ 2013-11-27 8:30 ` Petr Machata
2013-11-27 8:49 ` Sandeepa Prabhu
2013-11-27 15:51 ` New location for aarch64 Fedora 19 packages William Cohen
1 sibling, 1 reply; 22+ messages in thread
From: Petr Machata @ 2013-11-27 8:30 UTC (permalink / raw)
To: Sandeepa Prabhu
Cc: William Cohen, Mark Wielaard, Masami Hiramatsu, systemtap,
Deepak Saxena, Mark Salter
Sandeepa Prabhu <sandeepa.prabhu@linaro.org> writes:
> [root@localhost ~]# yum install git-core
> Loaded plugins: langpacks, refresh-packagekit
> arm64 | 2.9 kB 00:00
> http://arm-temp.ausil.us/pub/fedora-arm/stage4/repodata/repomd.xml:
> [Errno 12] Timeout on
> http://arm-temp.ausil.us/pub/fedora-arm/stage4/repodata/repomd.xml:
> (28, 'Connection timed out after 30050 milliseconds')
> Trying other mirror.
> ----------------------------
>
> What could be the issue? Is it could be because of slow internet or I
> am missing something?
http://isup.me/http://arm-temp.ausil.us says:
It's not just you! http://arm-temp.ausil.us looks down from here.
I think that domain belongs to Dennis Gilmore (a.k.a. ausil), but I
don't see him on IRC at the moment. Normally he hangs out on
#fedora-arm, #fedora-devel etc. on freenode.
Thanks,
PM
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Fwd: Re: Regarding systemtap support for AArch64]
2013-11-27 8:30 ` Petr Machata
@ 2013-11-27 8:49 ` Sandeepa Prabhu
2013-11-27 8:57 ` Sandeepa Prabhu
0 siblings, 1 reply; 22+ messages in thread
From: Sandeepa Prabhu @ 2013-11-27 8:49 UTC (permalink / raw)
To: Petr Machata
Cc: William Cohen, Mark Wielaard, Masami Hiramatsu, systemtap,
Deepak Saxena, Mark Salter
On 27 November 2013 13:59, Petr Machata <pmachata@redhat.com> wrote:
> Sandeepa Prabhu <sandeepa.prabhu@linaro.org> writes:
>
>> [root@localhost ~]# yum install git-core
>> Loaded plugins: langpacks, refresh-packagekit
>> arm64 | 2.9 kB 00:00
>> http://arm-temp.ausil.us/pub/fedora-arm/stage4/repodata/repomd.xml:
>> [Errno 12] Timeout on
>> http://arm-temp.ausil.us/pub/fedora-arm/stage4/repodata/repomd.xml:
>> (28, 'Connection timed out after 30050 milliseconds')
>> Trying other mirror.
>> ----------------------------
>>
>> What could be the issue? Is it could be because of slow internet or I
>> am missing something?
>
> http://isup.me/http://arm-temp.ausil.us says:
> It's not just you! http://arm-temp.ausil.us looks down from here.
>
> I think that domain belongs to Dennis Gilmore (a.k.a. ausil), but I
> don't see him on IRC at the moment. Normally he hangs out on
> #fedora-arm, #fedora-devel etc. on freenode.
Hi Petr,
Hmm think the server may be down, I tried from host machine: 'wget
http://arm-temp.ausil.us/pub/fedora-arm/stage4/kernel-3.12.0-0.rc4.git0.1.x2.fc19/kernel-3.12.0-0.rc4.git0.1.x2.fc19.src.rpm'
and it timed-out too, so atleast it's not fast-model issue.
Isn't it possible to download the rpms/packages from different
location? I would need 'git' and gcc (compiling) to be working before
pulling kernel and systemtap. Any pointers?
Thanks,
Sandeepa
>
> Thanks,
> PM
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Fwd: Re: Regarding systemtap support for AArch64]
2013-11-27 8:49 ` Sandeepa Prabhu
@ 2013-11-27 8:57 ` Sandeepa Prabhu
0 siblings, 0 replies; 22+ messages in thread
From: Sandeepa Prabhu @ 2013-11-27 8:57 UTC (permalink / raw)
To: Petr Machata
Cc: William Cohen, Mark Wielaard, Masami Hiramatsu, systemtap,
Deepak Saxena, Mark Salter
On 27 November 2013 14:19, Sandeepa Prabhu <sandeepa.prabhu@linaro.org> wrote:
> On 27 November 2013 13:59, Petr Machata <pmachata@redhat.com> wrote:
>> Sandeepa Prabhu <sandeepa.prabhu@linaro.org> writes:
>>
>>> [root@localhost ~]# yum install git-core
>>> Loaded plugins: langpacks, refresh-packagekit
>>> arm64 | 2.9 kB 00:00
>>> http://arm-temp.ausil.us/pub/fedora-arm/stage4/repodata/repomd.xml:
>>> [Errno 12] Timeout on
>>> http://arm-temp.ausil.us/pub/fedora-arm/stage4/repodata/repomd.xml:
>>> (28, 'Connection timed out after 30050 milliseconds')
>>> Trying other mirror.
>>> ----------------------------
>>>
>>> What could be the issue? Is it could be because of slow internet or I
>>> am missing something?
>>
>> http://isup.me/http://arm-temp.ausil.us says:
>> It's not just you! http://arm-temp.ausil.us looks down from here.
>>
>> I think that domain belongs to Dennis Gilmore (a.k.a. ausil), but I
>> don't see him on IRC at the moment. Normally he hangs out on
>> #fedora-arm, #fedora-devel etc. on freenode.
> Hi Petr,
> Hmm think the server may be down, I tried from host machine: 'wget
> http://arm-temp.ausil.us/pub/fedora-arm/stage4/kernel-3.12.0-0.rc4.git0.1.x2.fc19/kernel-3.12.0-0.rc4.git0.1.x2.fc19.src.rpm'
> and it timed-out too, so atleast it's not fast-model issue.
> Isn't it possible to download the rpms/packages from different
> location? I would need 'git' and gcc (compiling) to be working before
> pulling kernel and systemtap. Any pointers?
Hmm just found on fedora-arm ML that server is replaced very recently
to: : http://arm.koji.fedoraproject.org/aarch64/stage4/, so yum needs
to be updated.
>
> Thanks,
> Sandeepa
>
>>
>> Thanks,
>> PM
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: New location for aarch64 Fedora 19 packages
2013-11-27 5:35 ` Sandeepa Prabhu
2013-11-27 8:30 ` Petr Machata
@ 2013-11-27 15:51 ` William Cohen
2013-11-28 7:52 ` Sandeepa Prabhu
1 sibling, 1 reply; 22+ messages in thread
From: William Cohen @ 2013-11-27 15:51 UTC (permalink / raw)
To: Sandeepa Prabhu
Cc: Petr Machata, Mark Wielaard, Masami Hiramatsu, systemtap,
Deepak Saxena, Mark Salter
[-- Attachment #1: Type: text/plain, Size: 2246 bytes --]
On 11/27/2013 12:35 AM, Sandeepa Prabhu wrote:
>> Hi Sandeepa,
>>
>> I have switched to the arm64-kprobes-devel branch, pulled in the msalters uefi patches (armv8-uefi-lates branch of https://github.com/mosalter/linux), and started building a new kernel. The simulator is slow, so it will take a while for a new kernel to be available.
>>
>> I have pushed the aarch64 print_reg() support into the systemtap git repository to make it easier to test out aarch64 support include the kprobes and kretprobes. So on the aarch64 simulator something like the following to get a systemtap that has support for aarch64:
>>
>> # get the elfutils sources
>> cd ~
>> git clone git://git.fedorahosted.org/git/elfutils.git
>> cd elfutils
>> git checkout aarch64
>> # get systemtap
>> cd ~
>> mkdir systemtap_write
>> cd systemtap_write
>> git clone git://sourceware.org/git/systemtap.git
>> cd systemtap
>> ./configure --disable-docs --prefix=~/systemtap_write/install --with-elfutils=~/elfutils
>> make
>> make install
> Hi Will,
>
> I have booted fc19 as per
> http://fedoraproject.org/wiki/Architectures/ARM/AArch64/QuickStart
> successfully and able to setup networking.
> However, when I tried to install basic packages like git, it throws
> timeout errors:
> ----------------------------
> [root@localhost ~]# yum install git-core
> Loaded plugins: langpacks, refresh-packagekit
> arm64 | 2.9 kB 00:00
> http://arm-temp.ausil.us/pub/fedora-arm/stage4/repodata/repomd.xml:
> [Errno 12] Timeout on
> http://arm-temp.ausil.us/pub/fedora-arm/stage4/repodata/repomd.xml:
> (28, 'Connection timed out after 30050 milliseconds')
> Trying other mirror.
> ----------------------------
>
> What could be the issue? Is it could be because of slow internet or I
> am missing something?
>
> Thanks,
> Sandeepa
>
Hi Sandeepa,
Your internet probably works. The location of the repo has changed and you will need to copy the attached file into /etc/yum.repos.d/. This is mentioned in the following URL:
https://lists.fedoraproject.org/pipermail/arm/2013-November/007089.html
You might also need to set the date correctly for the aarch64 simulator. If the date is way off, yum might not like that.
-Will
[-- Attachment #2: stage4.repo --]
[-- Type: text/plain, Size: 221 bytes --]
[stage4]
name=Fedora fc19-stage4 - aarch64
failovermethod=priority
#baseurl=http://arm-temp.ausil.us/pub/fedora-arm/stage4
baseurl=http://arm.koji.fedoraproject.org/aarch64/stage4
enabled=1
#metadata_expire=7d
gpgcheck=0
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: New location for aarch64 Fedora 19 packages
2013-11-27 15:51 ` New location for aarch64 Fedora 19 packages William Cohen
@ 2013-11-28 7:52 ` Sandeepa Prabhu
2013-11-29 20:23 ` William Cohen
0 siblings, 1 reply; 22+ messages in thread
From: Sandeepa Prabhu @ 2013-11-28 7:52 UTC (permalink / raw)
To: William Cohen
Cc: Petr Machata, Mark Wielaard, Masami Hiramatsu, systemtap,
Deepak Saxena, Mark Salter
On 27 November 2013 21:21, William Cohen <wcohen@redhat.com> wrote:
> On 11/27/2013 12:35 AM, Sandeepa Prabhu wrote:
>>> Hi Sandeepa,
>>>
>>> I have switched to the arm64-kprobes-devel branch, pulled in the msalters uefi patches (armv8-uefi-lates branch of https://github.com/mosalter/linux), and started building a new kernel. The simulator is slow, so it will take a while for a new kernel to be available.
>>>
>>> I have pushed the aarch64 print_reg() support into the systemtap git repository to make it easier to test out aarch64 support include the kprobes and kretprobes. So on the aarch64 simulator something like the following to get a systemtap that has support for aarch64:
>>>
>>> # get the elfutils sources
>>> cd ~
>>> git clone git://git.fedorahosted.org/git/elfutils.git
>>> cd elfutils
>>> git checkout aarch64
>>> # get systemtap
>>> cd ~
>>> mkdir systemtap_write
>>> cd systemtap_write
>>> git clone git://sourceware.org/git/systemtap.git
>>> cd systemtap
>>> ./configure --disable-docs --prefix=~/systemtap_write/install --with-elfutils=~/elfutils
>>> make
>>> make install
>> Hi Will,
>>
>> I have booted fc19 as per
>> http://fedoraproject.org/wiki/Architectures/ARM/AArch64/QuickStart
>> successfully and able to setup networking.
>> However, when I tried to install basic packages like git, it throws
>> timeout errors:
>> ----------------------------
>> [root@localhost ~]# yum install git-core
>> Loaded plugins: langpacks, refresh-packagekit
>> arm64 | 2.9 kB 00:00
>> http://arm-temp.ausil.us/pub/fedora-arm/stage4/repodata/repomd.xml:
>> [Errno 12] Timeout on
>> http://arm-temp.ausil.us/pub/fedora-arm/stage4/repodata/repomd.xml:
>> (28, 'Connection timed out after 30050 milliseconds')
>> Trying other mirror.
>> ----------------------------
>>
>> What could be the issue? Is it could be because of slow internet or I
>> am missing something?
>>
>> Thanks,
>> Sandeepa
>>
>
> Hi Sandeepa,
>
> Your internet probably works. The location of the repo has changed and you will need to copy the attached file into /etc/yum.repos.d/. This is mentioned in the following URL:
>
> https://lists.fedoraproject.org/pipermail/arm/2013-November/007089.html
>
> You might also need to set the date correctly for the aarch64 simulator. If the date is way off, yum might not like that.
Thanks, after updating baseurl, yum & git clone are working fine.
Also time is set correctly to Eastern zone(Thu Nov 28 02:48:31 EST
2013) , able to install gcc: "gcc version 4.8.1 20130920 (Red Hat
4.8.1-10) (GCC)"
~Sandeepa
>
> -Will
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: New location for aarch64 Fedora 19 packages
2013-11-28 7:52 ` Sandeepa Prabhu
@ 2013-11-29 20:23 ` William Cohen
0 siblings, 0 replies; 22+ messages in thread
From: William Cohen @ 2013-11-29 20:23 UTC (permalink / raw)
To: Sandeepa Prabhu
Cc: Petr Machata, Mark Wielaard, Masami Hiramatsu, systemtap,
Deepak Saxena, Mark Salter
On 11/28/2013 02:51 AM, Sandeepa Prabhu wrote:
> On 27 November 2013 21:21, William Cohen <wcohen@redhat.com> wrote:
>> Hi Sandeepa,
>>
>> Your internet probably works. The location of the repo has changed and you will need to copy the attached file into /etc/yum.repos.d/. This is mentioned in the following URL:
>>
>> https://lists.fedoraproject.org/pipermail/arm/2013-November/007089.html
>>
>> You might also need to set the date correctly for the aarch64 simulator. If the date is way off, yum might not like that.
> Thanks, after updating baseurl, yum & git clone are working fine.
> Also time is set correctly to Eastern zone(Thu Nov 28 02:48:31 EST
> 2013) , able to install gcc: "gcc version 4.8.1 20130920 (Red Hat
> 4.8.1-10) (GCC)"
Hi Sandeepa,
You can set the time zone to what ever you want. I have seen in the past that yum wasn't able to update things if the time wasn't set to something reasonable.
If you are building a kernel on the simulator, you probably want to prune the list of modules in the feodra config to just the minimal and use the following as the starting point for the kernel:
make localmodconfig
Similarly when building systemtap on the simulator you probably want to disable the building of the documentation, which is very slow, with a --disable-docs in the configure.
-Will
^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2013-11-29 20:23 UTC | newest]
Thread overview: 22+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <1383340682.3850.864.camel@bordewijk.wildebeest.org>
2013-11-04 15:28 ` [Fwd: Re: Regarding systemtap support for AArch64] Petr Machata
2013-11-04 15:42 ` Petr Machata
2013-11-04 16:06 ` Mark Wielaard
2013-11-04 19:56 ` William Cohen
2013-11-05 2:48 ` Petr Machata
2013-11-05 16:09 ` William Cohen
2013-11-06 2:44 ` Sandeepa Prabhu
2013-11-06 9:55 ` Petr Machata
2013-11-07 11:54 ` Sandeepa Prabhu
2013-11-07 13:44 ` Sandeepa Prabhu
2013-11-07 13:50 ` Sandeepa Prabhu
2013-11-07 15:22 ` William Cohen
2013-11-27 5:35 ` Sandeepa Prabhu
2013-11-27 8:30 ` Petr Machata
2013-11-27 8:49 ` Sandeepa Prabhu
2013-11-27 8:57 ` Sandeepa Prabhu
2013-11-27 15:51 ` New location for aarch64 Fedora 19 packages William Cohen
2013-11-28 7:52 ` Sandeepa Prabhu
2013-11-29 20:23 ` William Cohen
2013-11-07 14:56 ` [Fwd: Re: Regarding systemtap support for AArch64] William Cohen
2013-11-08 2:22 ` Sandeepa Prabhu
2013-11-09 3:27 ` William Cohen
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).