Debugging an Oops..

<1>[  161.824645] Unable to handle kernel NULL pointer dereference at virtual address 00000132
<1>[  161.832702] pgd = dba48000
<1>[  161.835418] [00000132] *pgd=00000000
<0>[  161.839019] Internal error: Oops: 1 [#1] PREEMPT SMP ARM
<3>[  161.844329] kona_fb: die notifier invoked
<3>[  161.848327] kona_display_crash_image:355 image_idx=2
<3>[  161.854614] post_async:540 AXIPV has received the same buffer which is used
<3>[  161.861572] post_async:541 It is likely that we see display tearing
<3>[  161.867828] post_async:542 Preventing a potential lock-up by signalling
<4>[  161.874450] Modules linked in:
<4>[  161.877532] CPU: 1    Tainted: G        W     (3.4.5+ #1)
<4>[  161.882934] PC is at ttwu_stat+0x70/0x168
<4>[  161.886932] LR is at ttwu_stat+0x2c/0x168
<4>[  161.890930] pc : []    lr : []    psr: 200000d3
<4>[  161.890960] sp : dbb87e48  ip : 00000001  fp : dbb87e74
<4>[  161.902374] r10: 00000002  r9 : c162c000  r8 : 00000001
<4>[  161.907592] r7 : c093c000  r6 : 00000002  r5 : 00000000  r4 : 00000001
<4>[  161.914123] r3 : 00000002  r2 : dbb87e38  r1 : 00000130  r0 : 00000001
<4>[  161.920623] Flags: nzCv  IRQs off  FIQs off  Mode SVC_32  ISA ARM  Segment user
<4>[  161.927917] Control: 10c53c7d  Table: 9da4804a  DAC: 00000015

From System.map find out the address of ttwu_stat
------------------------
c007fe8c t ttwu_stat
------------------------

Now find the end of function (ttwu_stat+0x70/0x168) is
0xc007fe8c + 0x168 = 0xC007FFF4

Disassemble the code as follows,
arm-eabi-objdump -dS --start-address=0xc007fe8c --stop-address=0xC007FFF4 vmlinux



dumps/vmlinux:     file format elf32-littlearm


Disassembly of section .text:

c007fe8c :
BFD: Dwarf Error: mangled line number section.
c007fe8c:       e92d4ff0        push    {r4, r5, r6, r7, r8, r9, sl, fp, lr}
c007fe90:       e28db020        add     fp, sp, #32     ; 0x20
c007fe94:       e24dd00c        sub     sp, sp, #12     ; 0xc
c007fe98:       e1a06001        mov     r6, r1
c007fe9c:       e1a0a000        mov     sl, r0
c007fea0:       e50b2028        str     r2, [fp, #-40]
c007fea4:       eb06c42b        bl      c0230f58
c007fea8:       e59f213c        ldr     r2, [pc, #316]  ; c007ffec
c007feac:       e59f713c        ldr     r7, [pc, #316]  ; c007fff0
c007feb0:       e7929100        ldr     r9, [r2, r0, lsl #2]
c007feb4:       eb06c427        bl      c0230f58
c007feb8:       e0879009        add     r9, r7, r9
c007febc:       e1560000        cmp     r6, r0
c007fec0:       e1a08000        mov     r8, r0
c007fec4:       1a00000a        bne     c007fef4
c007fec8:       e5993548        ldr     r3, [r9, #1352]
c007fecc:       e3a0cf4a        mov     ip, #296        ; 0x128
c007fed0:       e3a00001        mov     r0, #1  ; 0x1
c007fed4:       e3a01000        mov     r1, #0  ; 0x0
c007fed8:       e2833001        add     r3, r3, #1      ; 0x1
c007fedc:       e5893548        str     r3, [r9, #1352]
c007fee0:       e18a20dc        ldrd    r2, [sl, ip]
c007fee4:       e0922000        adds    r2, r2, r0
c007fee8:       e0a33001        adc     r3, r3, r1
c007feec:       e18a20fc        strd    r2, [sl, ip]
c007fef0:       ea00001f        b       c007ff74
c007fef4:       e3a01e13        mov     r1, #304        ; 0x130
c007fef8:       e3a04001        mov     r4, #1  ; 0x1
c007fefc:       e18a20d1        ldrd    r2, [sl, r1]
c007ff00:       e3a05000        mov     r5, #0  ; 0x0
c007ff04:       e0922004        adds    r2, r2, r4
c007ff08:       e0a33005        adc     r3, r3, r5
c007ff0c:       e18a20f1        strd    r2, [sl, r1]
c007ff10:       eb00cfde        bl      c00b3e90 <__rcu_read_lock>
c007ff14:       e59f20d0        ldr     r2, [pc, #208]  ; c007ffec
c007ff18:       e3560000        cmp     r6, #0  ; 0x0
c007ff1c:       e3a01001        mov     r1, #1  ; 0x1
c007ff20:       e7923108        ldr     r3, [r2, r8, lsl #2]
c007ff24:       e286201f        add     r2, r6, #31     ; 0x1f
c007ff28:       a1a02006        movge   r2, r6
c007ff2c:       e206601f        and     r6, r6, #31     ; 0x1f
c007ff30:       e0877003        add     r7, r7, r3
c007ff34:       e1a022c2        asr     r2, r2, #5
c007ff38:       e1a06611        lsl     r6, r1, r6
c007ff3c:       e59734a8        ldr     r3, [r7, #1192]
c007ff40:       e1a02102        lsl     r2, r2, #2
c007ff44:       ea000007        b       c007ff68
c007ff48:       e0831002        add     r1, r3, r2
c007ff4c:       e59110f8        ldr     r1, [r1, #248]
c007ff50:       e1110006        tst     r1, r6
c007ff54:       159320dc        ldrne   r2, [r3, #220]
c007ff58:       12822001        addne   r2, r2, #1      ; 0x1
c007ff5c:       158320dc        strne   r2, [r3, #220]
c007ff60:       1a000002        bne     c007ff70
c007ff64:       e5933000        ldr     r3, [r3]
c007ff68:       e3530000        cmp     r3, #0  ; 0x0
c007ff6c:       1afffff5        bne     c007ff48
c007ff70:       eb00d511        bl      c00b53bc <__rcu_read_unlock>
c007ff74:       e51b3028        ldr     r3, [fp, #-40]
c007ff78:       e3130004        tst     r3, #4  ; 0x4
c007ff7c:       0a000006        beq     c007ff9c
c007ff80:       e3a0ce12        mov     ip, #288        ; 0x120
c007ff84:       e3a00001        mov     r0, #1  ; 0x1
c007ff88:       e18a20dc        ldrd    r2, [sl, ip]
c007ff8c:       e3a01000        mov     r1, #0  ; 0x0
c007ff90:       e0922000        adds    r2, r2, r0
c007ff94:       e0a33001        adc     r3, r3, r1
c007ff98:       e18a20fc        strd    r2, [sl, ip]
c007ff9c:       e5993544        ldr     r3, [r9, #1348]
c007ffa0:       e3a0ce11        mov     ip, #272        ; 0x110
c007ffa4:       e3a00001        mov     r0, #1  ; 0x1
c007ffa8:       e3a01000        mov     r1, #0  ; 0x0
c007ffac:       e2833001        add     r3, r3, #1      ; 0x1
c007ffb0:       e5893544        str     r3, [r9, #1348]
c007ffb4:       e18a20dc        ldrd    r2, [sl, ip]
c007ffb8:       e0922000        adds    r2, r2, r0
c007ffbc:       e0a33001        adc     r3, r3, r1
c007ffc0:       e18a20fc        strd    r2, [sl, ip]
c007ffc4:       e51b2028        ldr     r2, [fp, #-40]
c007ffc8:       e3120001        tst     r2, #1  ; 0x1
c007ffcc:       0a000004        beq     c007ffe4
c007ffd0:       e3a0cf46        mov     ip, #280        ; 0x118
c007ffd4:       e18a20dc        ldrd    r2, [sl, ip]
c007ffd8:       e0922000        adds    r2, r2, r0
c007ffdc:       e0a33001        adc     r3, r3, r1
c007ffe0:       e18a20fc        strd    r2, [sl, ip]
c007ffe4:       e24bd020        sub     sp, fp, #32     ; 0x20
c007ffe8:       e8bd8ff0        pop     {r4, r5, r6, r7, r8, r9, sl, fp, pc}
c007ffec:       c095e988        .word   0xc095e988
c007fff0:       c093c000        .word   0xc093c000

The PC is show in read above. So the instruction resulted in crash is,
c007fefc:       e18a20d1        ldrd    r2, [sl, r1]

i.e, reading a double word (ldrd) from address (s1(ie r10) and r1)
From the opps message r10 = 2 and r1 = 130. Both are highlighted in red.

so trying to load from address 132 which is an invalid address.

Possible mistakes,
Match the time stamp of ramdump and vmlinux first.
strings dumps/AP__0x82000000.hex | grep "Linux version"

strings dumps/vmlinux | grep "Linux version"

Both timestamps should match.

Add networking to project

1) Open .pro file and add,

Its not "networking", you have to add "network". The pic is incorrect.

Volatile in simple terms

Consider this eg:

1  int main(void){

2  int a, x, y;

3  x=a;

4  y=a;

5  }

Line 3 with be converted to a LDR instruction.

Line 4 is where the compiler optimization comes in. It may be loaded from the previous loaded register.

Line 3: ldr r0[r1];   r1 is having the address of a

Line 4: mov r2 r0;   because we have value of a already in r0.

But if a is a volatile vairable, then compiler places ldr for both instructions( for x=a and y=a)
So Line 4 will change as follows,

Line 3: ldr r0[r1];   r1 is having the address of a
Line 4: ldr r2[r1];   r1 is having the address of a 

But if cache is enabled for these memory region, with the first ldr, data is cached. Now second ldr can fetch the data from cache. So using just volatile is not sufficient. Proper MMU mappings(non cached mapping in this case) is a must.

The fight for PTM Traces

PTM(Programme trace Marcocell)

This is an interesting feature provided by ARM CoreSight. This piece of hardware monitors a ARM core. When every there is a deviation from the normal execution of the core, PTM generates traces. These deviations can be interrupts or a simple branching.

There is already a linux driver for this at arch/arm/kernel/etm.c. But few patches are missing compared to linaro tree as of this writing. Apart from what driver provides, you have to do few more things.

 1. Register a AMBA device. This has to be done to get the probe of etm driver to be called. You can see how omap guys have done this here,
AMBA_APB_DEVICE(omap3_etm, "etm", 0x102bb921, ETM_BASE, { }, NULL);


2. Configure the funnels. This will require a bigger explanation.
    Can be found from CoreSight documention in arm infocenter.
    In short there will a lot of trace sources(PTM is one amoung them), you need to configure those funnels so the PTM traces will reach ETB or TPIU.
   

Now I got it working. Working here can be divided into two parts.
1. Configure the traces sources(PTM here) and funnels and get the data to ETB.
2. Collect the data from the ETB and decode it to meaningful information.

Some how after two week , PTM stopped working. Actually it is partially working. It is working for single core traces but not for dual core. Either configuring the PTM or decoding the PTM can go wrong.

After lot of debugging, I figure out that this is because of arm going to dormant. When ever arm goes to dormant  it cuts off the power to the processor which results in loosing values in PTM registers.

The reason it worked two weeks before was because dormant was disabled in our kernel. I m just wondering how difficutl it should have been if I have used this driver (PTM) after the dormant is enabled. It would have been a long journey to figure out for me that dormant was the culprit.

compiling fastboot.exe

File location in android,
system/core/fastboot/*

Command to compile,
make -j2 win_sdk

binary will be build here,
out/host/windows-x86/bin/fastboot.exe

Git advanced topics

I m going to write features of git which I feel are advanced.

1. Editing a commit which is not HEAD

git rebase -i e39f5d5f122029f6e1271^

where e39f5d5f122029f6e1271 is the commit which I want to amend.

Now some thing like this will come, which is self explanatory,

now change those commits  to "edit" from "pick". Save and close.

Now edit those files you want to and do git add for the files.

After that git commit --amend
then,
git rebase --continue

2. Interactive adding of files(git add -i)

http://linux.die.net/man/1/git-add

3. Git bisecting to find out where bug was introduced.

commands,

git bisect start

git bisect bad                     /* inform git that current commit you are on is broken */

git bisect good [good_commit_id]                   /* inform git about the working commit */

Now git will checkout to the middle of these commit. You have to build and test if bug exits now.

If bug is present, then type

git bisect bad

else 

git bisect good

To finish,

git bisect reset.

3. Git send email.

http://burzalodowa.wordpress.com/2013/10/05/how-to-send-patches-with-git-send-email/

4.  git add only few changes in same file

    git add -p filename.c

5. Git grep on different branches

git grep -n "string here"

VIVT, VIPT and PIPT caches

https://patchwork.kernel.org/patch/1046072/

Uncompressing Linux... done, booting the kernel.

[    0.000000] Booting Linux on physical CPU 0

[    0.000000] Initializing cgroup subsys cpuset

[    0.000000] Initializing cgroup subsys cpu

[    0.000000] Linux version 3.4.5+ (arunks@xl-blr-02) (gcc version 4.4.3 (GCC) ) #19 PREEMPT Mon Oct 1 10:42:05 IST 2012

[    0.000000] CPU: ARMv7 Processor [412fc099] revision 9 (ARMv7), cr=10c53c7d

[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache

[    0.000000] Machine: rheastone

[    0.000000] Kona dt @0xc00001ac, size of 0x284 words, rooted @ 0xc00001ec

Related links,
http://blogs.arm.com/software-enablement/716-page-colouring-on-armv6-and-a-bit-on-armv7/#MMAP

Discussion in linux-arm, good explantion from Catalin Marinas,
sub: ARM caches variants,
http://lists.infradead.org/pipermail/linux-arm-kernel/2010-March/011900.html

http://www.linuxjournal.com/article/7105?page=0,0