Recently, as the release of ICS comes with kernel 3.0.x, a few users have been requesting NoDock to support it. By the help of David Schachman, some useful information has been collected.
The most notable error is "Unknown parameter `kl'". Comparing kernel 2.6.32 and 3.0 of include/linux/moduleparam.h reveals that struct kernel_param, which is serialized to the .ko and deserialized when loading the module, is very different. The set/get operators have been refactored to ops that introduced incompatibility.
A quick solution is to use another communication method than module param.
On XT926 of Sean Aloisi, the first problem met is checksum mismatch in printk. This can be tackled by a printk-less version. Then a bug in nmod prevented nodock from loading. It checks if the __versions section is present in the target ko. That is the case of ko compiled without MODVERSION. Once making nmod more tolerant, the phone hang after loading nodock. The kmsg showed:
<6>[ 376.942408,0] nodock:_r9:116 Start resolving
<6>[ 376.942469,0] nodock:resolveOscRange:85 sprint_symbol:c01a4340:0:8 @c01a4340
<6>[ 376.942591,0] nodock:resolveOscRange:85 __sprint_symbol:c01a433f:b7:b8 @c01a4288
<6>[ 376.942652,0] nodock:resolveOscRange:85 __print_symbol:c01a4348:0:4c @c01a4348
<6>[ 376.942774,0] nodock:resolveOscRange:85 kallsyms_lookup:c01a4287:7b:7c @c01a420c
<6>[ 376.942926,0] nodock:resolveOscRange:85 lookup_symbol_name:c01a4394:0:54 @c01a4394
<6>[ 376.942987,0] nodock:resolveOscRange:85 kallsyms_lookup_size_offset:c01a420b:83:84 @c01a4188
<6>[ 376.943109,0] nodock:resolveOscRange:85 lookup_symbol_attrs:c01a43e8:0:74@c01a43e8
<6>[ 376.943232,0] nodock:resolveOscRange:85 kallsyms_open:c01a4187:8b:8c @c01a40fc
<6>[ 376.943293,0] nodock:resolveOscRange:85 sprint_backtrace:c01a445c:0:8 @c01a445c
<6>[ 376.943384,0] nodock:resolveOscRange:85 kallsyms_lookup_name:c01a40fb:97:98 @c01a4064
At least it reveals two facts:
1. nchkvpm was loaded and patched check_version.
2. nodock's hooking hung the phone.
<6>[31726.634301,0] nodock:resolveOscRange:85 kallsyms_lookup_name:c01a40fb:97:98 @c01a4064
<6>[31726.634362,0] nodock:resolveOscRange:103 kl:kallsyms_lookup_name+0x0/0x98
<6>[31726.638360,0] nodock:_x8:39 lookup name wildcard kallsyms_on_each_symbol
<6>[31726.640435,0] nodock:_hook_init:274 substituted lookup name by wrapper
<6>[31726.640496,0] nodock:_k:252 lookup name wrapper kallsyms_lookup kallsyms_on_each_symbol+0x0/0xa4
Finally the panic log was found from /data/kernelpanics, though it isn't in pure text form, the useful fault code can be seen:
shell@android:/data/kernelpanics # grep -A 20 -B 20 nodock ap_kernel_panic_51392CDA
k ap_kernel_panic_51392CDA <
Type: SYSTEM_LAST_KMSG
Linux version 3.0.31-ge95971c (droidth3ory@androidhosting.org) (gcc version 4.7 (GCC) ) #2 SMP PREEMPT Sun May 12 14:10:17 CDT 2013
Linux version 3.0.31-ge95971c (droidth3ory@androidhosting.org) (gcc version 4.7 (GCC) ) #2 SMP PREEMPT Sun May 12 14:10:17 CDT 2013
SERIAL : 0x1000201e829c0
HW_REV : 0x8300
] nodock:resolveOscRange:85 kallsyms_open:c01a4187:8b:8c @c01a40fc
] nodock:resolveOscRange:85 sprint_backtrace:c01a445c:0:8 @c01a445c
] nodock:resolveOscRange:85 kallsyms_lookup_name:c01a40fb:97:98 @c01a4064
] Unable to handle kernel paging request at virtual address c05cc56c
] pgd = c2ad4000
] [c05cc56c] *pgd=8061940e(bad)
] Internal error: Oops: 80d [#1] PREEMPT SMP
] Modules linked in: nodockm(+) nchkvpm wlan(C) tcp_westwood cfg80211 [last unloaded: nchkvpm]
] CPU: 1 Tainted: G C (3.0.31-ge95971c #2)
] PC is at _zkvh32+0x1b8/0x230 [nodockm]
] LR is at _f+0x2c/0x40 [nodockm]
] pc : [<bf01cc14>] lr : [<bf01cd28>] psr: 80000013
] sp : c2b23df8 ip : c2b23df8 fp : c2b23e94
] r10: bf020000 r9 : 00000000 r8 : 00000001
] r7 : 00000008 r6 : 00000000 r5 : 00000006 r4 : bf01d638
] r3 : c2b22000 r2 : eaa9443a r1 : bf000000 r0 : c05cc56c
] Flags: Nzcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel
] Control: 10c5787d Table: 82cd406a DAC: 00000035
]
] Before flush cache...
]
] SP: 0xc2b23d78:
] 3d78 00746e65 6574616c bf01d900 c2b23de4 0000006b 00000000 c0046f08 00005f0b
] 3d98 ffffffff c2b23de4 00000000 00000008 00000001 c07d76ec c05cc56c bf000000
] 3db8 eaa9443a c2b22000
] In oops, interrupt is disabled on IRQ18
] bf01d638 00000006 00000000 00000008 00000001 00000000
] 3dd8 bf020000 c2b23e94 c2b23df8 c2b23df8 bf01cd28 bf01cc14 80000013 ffffffff
] 3df8 66666f5f 00746573 64006c6f 00007400 75727265 74007470 006e6900 6d003774
] 3e18 006c6f62 0073746e 64006c6f 00007400 75727265 74007470 006e6900 c0003774
] 3e38 c0db64c0 c8c26130 00000000 c0dba4e0 000080d0 c0db64c0 c8c26c78 271aed03
shell@android:/data/kernelpanics #
So, it's Oops 80d again. The last time we met was the Defy case. However, this time is caused by the security patch CONFIG_STRICT_MEMORY_RWX. It introduces MT_MEMORY_RX to lock up kernel write access to kernel text. Since this enhancement has addressed the kernel to kernel read/write control too, the set_fs(KERNEL_DS) trick won't save my life.
Ahha, mmu.c has the solution right there. :) See mem_text_address_writeable(). Dunno why it isn't in lxr even version 3.9, maybe Android specific?
Thanks Sean for providing his computer and phone for a remote investigation session that helps to find out the root cause and solution to the loading problem on the latest kernel 3.0.31.
A new release will be made very soon, look out!
Why was nchkvpm being loaded without any problem? This module would patch the check_version method to return 1 using the same set_fs trick used in NoDock. Why wasn't any page fault being generated?