[Galaxy S II Original Android Development] zeitferne:
Regarding the freeze:

Even though I *am* busy, curiosity got the best of me: I got a last_kmsg from a kernel with extra logging.

Kernel patchset

last_kmsg logfile

The interesting part is probably immediately before the crash (that happens at 25361.818397):

<6>[25359.486837] c0 exynos4210_set_frequency: old_index=3 (800000, r=800000), new_index=4 (500000) (exynos_target)
<6>[25359.636956] c0 cpu1 turnning off!
<4>[25359.639442] c1 IRQ112 no longer affine to CPU1
[b]<4>[25359.639811] c0 local tick on wrong CPU; handler: hrtimer_interrupt[/b]
<5>[25359.641237] c0 CPU1: shutdown
<6>[25359.666876] c0 cpu1 off!
<6>[25359.787295] c0 exynos4210_set_frequency: old_index=4 (500000, r=500000), new_index=3 (800000) (exynos_target)
<6>[25359.887445] c0 exynos4210_set_frequency: old_index=3 (800000, r=800000), new_index=1 (1200000) (exynos_target)
<6>[25360.166854] c0 cpu1 turning on!
<4>[25360.199258] c1 CPU1: Booted secondary processor
<4>[25360.199290] c1 CPU1: Booted secondary processor
<6>[25360.200200] c1 notifier_call_chain : NOTIFY BAD tick_notify
<6>[25360.202558] c1 Switched to NOHz mode on CPU #1

The crash itself happens at the same place as before. It seems I made a mistake with my clock dumping code, so the output is less useful than I wished (also I accidentally printed some information twice), but nevertheless, here is the information, we got from it (I should have added 0x in front of hex numbers; makes it a bit too easy to misread sometimes):

<0>[25361.979635] c0 exynos_target: CPU 0: policy->cur is 1200000, but actual speed is 150000; freqs.old=1200000, freqs.new=1200000
<0>[25361.980956] c0 freqs: cpu=0, old=1200000, new=1200000
<0>[25361.981700] c0 disable=0, lock_disable=0, init_done=1
<0>[25361.983134] c0 limit_id=0, limit_level=1
<0>[25361.983765] c0 limit_val[0]=1
[…] (all =1 up to and including index 17)
<0>[25362.030262] c0 limit_val[17]=1
<0>[25362.070764] c0 lock_id=0, lock_level=5
<0>[25362.071397] c0 lock_val[0]=5
[…] (all =5 up to and including index 17)
<0>[25362.211249] c0 CLKDIV_CPU: 77143737; CLKDIV_CPU1: 50
<0>[25362.212549] c0 APLL_LOCK: 1c20; APLL_CON0: a0960301
<0>[25362.213491] c0 CLK armclk: r=150000000
<0>[25362.214112] c0 CLK moutcore: r=1200000000
<0>[25362.214805] c0 CLK mout_mpll: r=800000000
<0>[25362.215482] c0 CLK mout_apll: r=1200000000
<0>[25362.376792] c0 vdd_arm: 1300000 uv; vdd_int: 1025000 uv
<0>[25362.378207] c0 Kernel panic - not syncing: Frequency mismatch.

Also extremely interesting is that amidst the duplicate information I accidentally printed immediately before that is a call to exynos_cpufreq_policy_notifier_call (from another kernel thread):

<0>[25361.818397] c0 CLKDIV_CPU: 77143737; CLKDIV_CPU1: 50
[…] (same values as above in this post)
<0>[25361.886434] c0 CLK mout_apll: r=1200000000
[b]<6>[25361.956389] c0 exynos_cpufreq_policy_notifier_call: code=3; policy: [U]cpu=1, cur=150000[/U], min=200000, max=1200000
<6>[25361.959113] c0 cpu1 on[/b]
<0>[25361.978707] c0 vdd_arm: 1300000 uv; vdd_int: 1025000 uv

I wonder what role exynos_cpufreq_cpu_init plays in all this.

All in all, I feel we are finally getting closer to the source of the 150 Mhz (a workaround could probably be easily derived from the patch [MENTION=5397920]xhoster[/MENTION] found, but I am interested in finding the source of the bug).

PS:

Probably not :D but the if-branch was never taken anyway; maybe my initial assumption on the behavior of this freeze is right after all: could it be that last_kmsg is cut off early if one forces a reboot by long-pressing power?