Quoting lukas@xxxxxxxxxxxxx:
Hello,
Quoting David Brown <davidb@xxxxxxxxxxxxxx>:
To start with, can you share the .config you built your kernel
with?
Thanks,
David
We are using 'arch/arm/configs/htcleo_defconfig' from the
htc-msm-2.6.32 branch in
git://git.linuxtogo.org/home/groups/mobile-linux/kernel.git repository.
Here is a direct link
http://git.linuxtogo.org/?p=groups/mobile-linux/kernel.git;a=blob;f=arch/arm/configs/htcleo_defconfig;h=4d3141dae827c28a0cb46b04a3a075bf489cd842;hb=refs/heads/htc-msm-2.6.32
Thanks a lot,
Lukas
Hello,
As I think this got under a bit due to the defconfig discussion I'm
just bumping it up. Also LeTama seems to have confirmed the thing with
the failing push instruction in a different case:
http://lists.linuxtogo.org/pipermail/mobile-linux-discuss/2010-May/000095.html
I will just quote again for easier reference.
Le Tama letama at free.fr wrote on
Sun May 30 19:56:23 CEST 2010
Re All,
I did another experiment with the android binaries, this one native android
init with a cleaned init.rc.
This time, it results in segmentation fault, I added few traces to the
kernel:
[ 9.520195] PL:kernel_execve(/init)
[ 9.524717] PL:do_translation_fault
[ 9.529754] PL:do_translation_fault
[ 9.579853] init: cannot open '/initlogo.rle'
[ 9.609789] lcdc_unblank: ()
[ 9.676751] mdp irq already on 4000 4000
[ 9.676762] mdp_dma: busy
[ 9.725516] PL:do_translation_fault
[ 9.734390] msm72k_udc: msm72k_udc: portchange USB_SPEED_HIGH
[ 9.743216] msm72k_udc: msm72k_udc: reset
[ 9.747724] PL:do_translation_fault
[ 9.752509] PL:do_translation_fault
[ 9.757389] PL:do_translation_fault
[ 9.762623] PL:send_signal (sig=17, from_ancestor=0)
[ 9.767116] PL: unlikely(vma->vm_start > addr)1
[ 9.771485] PL:vma->vm_start = 8000
[ 9.775757] PL:vma->vm_end = 20000
[ 9.780001] PL:vma->vm_flags = 8001875
[ 9.784192] PL:addr = 0
[ 9.788386] PL:SIGSEGV/SEC_MAPERR
[ 9.792554] pgd = c655c000
[ 9.796654] [00000000] *pgd=26555031, *pte=00000000, *ppte=00000000
[ 9.804887]
[ 9.808952] Pid: 1, comm: init
[ 9.813014] CPU: 0 Not tainted (2.6.32.9-38056-gee54d02-dirty #146)
[ 9.821087] PC is at 0x15a74
[ 9.825101] LR is at 0xb2f9
[ 9.829050] pc : [<00015a74>] lr : [<0000b2f9>] psr: 00000030
[ 9.829060] sp : bea3bdd0 ip : ff0a0000 fp : 00000000
[ 9.840921] r10: 00000000 r9 : 00000000 r8 : 00000000
[ 9.844872] r7 : 0001c6fc r6 : 0000068d r5 : 00000006 r4 : 0002048c
[ 9.852629] mdp irq already on 4000 4000
[ 9.856538] mdp_dma: busy
[ 9.860403] r3 : 00000000 r2 : 00000000 r1 : 00000000 r0 : 0000068f
[ 9.868101] Flags: nzcv IRQs on FIQs on Mode USER_32 ISA Thumb
Segment user
[ 9.875816] PL: instruction=4c9eb5f0
[ 9.879668] Control: 10c5787d Table: 2655c019 DAC: 00000015
[ 9.887370]
[ 9.887374] IP: 0xff09ff80:
The init disassembly gives me this:
0000b2c4 <read_file>: (the caller as shown by LR, in thumb)
....
b2f0: b9f8 cbnz r0, b332 <read_file+0x6e>
b2f2: 1cb0 adds r0, r6, #2
b2f4: f00a fbbe bl 15a74 <malloc>
b2f8: 4604 mov r4, r0
....
00015a74 <malloc>: (crash location, just at the beginning, in thumb too)
15a74: b5f0 push {r4, r5, r6, r7, lr}
15a76: 4c9e ldr r4, [pc, #632] ; (15cf0
<malloc+0x27c>)
15a78: a200 add r2, pc, #0 ; (adr r2, 15a7c
<malloc+0x8>)
15a7a: 499e ldr r1, [pc, #632] ; (15cf4
<malloc+0x280>)
15a7c: 18a4 adds r4, r4, r2
15a7e: 4605 mov r5, r0
15a80: 1860 adds r0, r4, r1
.....
15cea: 4630 mov r0, r6
15cec: b007 add sp, #28
15cee: bdf0 pop {r4, r5, r6, r7, pc}
15cf0: 0000aa10 .word 0x0000aa10
15cf4: 000012ec .word 0x000012ec
00015cf8 <calloc>:
I don't know if it's a coincidence, but again, a push instruction.
Here:
[ 9.767116] PL: unlikely(vma->vm_start > addr)1
[ 9.771485] PL:vma->vm_start = 8000
[ 9.775757] PL:vma->vm_end = 20000
[ 9.780001] PL:vma->vm_flags = 8001875
[ 9.784192] PL:addr = 0
And here:
[ 9.796654] [00000000] *pgd=26555031, *pte=00000000, *ppte=00000000
, it shows that the instruction at PC tries to access address 0
Why, I have no clue.
In memory, the code at 00015a74 is really the push instruction like
displayed here (this is *(PC)):
[ 9.875816] PL: instruction=4c9eb5f0
Nothing really new here, but it could give hints for the arm guys ?
By the way, Dcordes, you asked them for help, right ? The thread can be seen
somewhere ?
Best,
LeTama
On a side note, we tried to use different snapdragon kernel
repositories like some 2.6.29 at codeaurora and the problem seems to
be the same.
Also might be interesting that we ran into some timer problem with the
kernel configurations of other qsd8250 machines. Nexus one is using GP
timer. If we set that on htcleo machine, system will freeze soon as
there is some 'waiting code'. E.g. setting rootwait=n or rootdelay in
cmdline always caused a panic with GP.
setting
'CONFIG_MSM7X00A_USE_DG_TIMER=y'
instead fixed that. No idea if that is any relevant but it might ring
a bell for somebody who knows this SoC well.
Thank,
Lukas
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
