ext Tero.Kristo@xxxxxxxxx wrote:
Hi Elvis,
I think I saw something similar last week, and it was caused by not having CONFIG_OMAP_PM_SRF enabled. The actual culprit is the marked line in sr_configure_vp():
vpconfig = PRM_VP1_CONFIG_ERROROFFSET |
PRM_VP1_CONFIG_ERRORGAIN |
PRM_VP1_CONFIG_TIMEOUTEN |
mpu_opps[resource_get_level("vdd1_opp")].vsel <<
OMAP3430_INITVOLTAGE_SHIFT;
SR2 has similar code a bit later.
You will also get a failure if mpu_opps[] and/or l3_opps[] is not defined at all in your board files, this null pointer exception would actually indicate a problem like that more likely.
-Tero
-----Original Message-----
From: linux-omap-owner@xxxxxxxxxxxxxxx
[mailto:linux-omap-owner@xxxxxxxxxxxxxxx] On Behalf Of ext Elvis Dowson
Sent: 19 May, 2009 14:21
To: Kevin Hilman
Cc: Linux OMAP Users
Subject: Smart Reflex pm patches causes a kernel panic
Hi Kevin,
I get a kernel panic on my TI OMAP 3503 when
I incorporate the SR patches. How can I trace and debug this
to find the cause of this null pointer error ?
Power Management for TI OMAP3.
mmc0: mmc_rescan - card ocr from io_op=0x00000000, err = -110
pm_dbg_init()
Unable to handle kernel NULL pointer dereference at virtual
address 0000001e pgd = c0004000 [0000001e] *pgd=00000000
Internal error: Oops: 5 [#1] PREEMPT Modules linked in:
CPU: 0 Not tainted (2.6.29-omap1 #1)
PC is at sr_configure_vp+0x28/0x1bc
LR is at sr_configure_vp+0x1c/0x1bc
pc : [<c01055f4>] lr : [<c01055e8>] psr: 60000113
sp : cf81ff28 ip : cf81ff28 fp : cf81ff3c
r10: 00000000 r9 : 00000000 r8 : 00000001
r7 : c0012b44 r6 : 00000000 r5 : c05c8660 r4 : c05c8624
r3 : 00000000 r2 : 00000001 r1 : 80000113 r0 : 00000000
Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel
Control: 10c5387d Table: 80004019 DAC: 00000017 Process
swapper (pid: 1, stack limit = 0xcf81e2e8)
Stack: (0xcf81ff28 to 0xcf820000)
ff20: c05c8660 c05c8624 cf81ff5c cf81ff40 c0012bc8
c01055d8
ff40: 00000000 08012954 c002d9d0 c002da20 cf81ffd4 cf81ff60
c00f52f8 c0012b50
ff60: cf81ff8c cf81ff70 c01cb9e4 c01cb6a8 cf81ff00 cf9a26e0 c01cbae4
cf81ff96
ff80: cf81ffbc cf81ff90 c014d408 c01cb970 c02fb2b4 35339600
00000031 00000000
ffa0: 00000192 c05d2034 00000000 00000000 cf81ffd4 c002d9d0
c002da20 00000000
ffc0: 00000000 00000000 cf81fff4 cf81ffd8 c00083fc c00f52ac 00000000
00000001
ffe0: 00000000 00000000 00000000 cf81fff8 c011e2b8 c0008384
0836d404 5777f140
Backtrace:
[<c01055cc>] (sr_configure_vp+0x0/0x1bc) from [<c0012bc8>]
(omap3_sr_init+0x84/0x114)
r4:c05c8624
[<c0012b44>] (omap3_sr_init+0x0/0x114) from [<c00f52f8>]
(do_one_initcall+0x58/0x198)
r5:c002da20 r4:c002d9d0
[<c00f52a0>] (do_one_initcall+0x0/0x198) from [<c00083fc>]
(kernel_init
+0x84/0xf4)
r8:00000000 r7:00000000 r6:00000000 r5:c002da20 r4:c002d9d0
[<c0008378>] (kernel_init+0x0/0xf4) from [<c011e2b8>] (do_exit
+0x0/0x7d0)
r5:00000000 r4:00000000
Code: eb0024a7 e59f3180 e3500000 05933000 (01d301be) ---[ end
trace eadc9c7cb4a7e9eb ]--- Kernel panic - not syncing:
Attempted to kill init!
I have extracted the pm patches by doing a
git format-patch master
on the pm branch. This generates 186 patch files, as of today.
Since I don't know which particular patch is causing the
problem, I need to fully exclude the following patch numbers
to prevent the kernel panic.
#
file://omap-pm/0149-OMAP3-SR-Fix-init-voltage-on-OPP-change.patch
;patch=1 \
#
file://omap-pm/0151-OMAP3-SR-Update-VDD1-2-voltages-at-boot.patch
;patch=1 \
#
file://omap-pm/0152-OMAP3-SR-Use-sysclk-for-SR-CLKLENGTH-calc.patch
;patch=1 \
#
file://omap-pm/0153-OMAP3-SR-Disable-SR-autocomp-only-for-CORE-
trans.patch
;patch=1 \
#
file://omap-pm/0154-OMAP3-SR-Reset-voltage-level-on-SR-disable.patch
;patch=1 \
#
file://omap-pm/0155-OMAP3-SR-Replace-printk-s-with-pr_-calls.patch
;patch=1 \
# file://omap-pm/0156-OMAP3-SR-Remove-redundant-
defines.patch;patch=1 \
#
file://omap-pm/0157-OMAP3-SR-Replace-SR_PASS-FAIL-SR_TRUE-FALSE.patch
;patch=1 \
# file://omap-pm/0158-OMAP3-SR-Replace-0x1-n-with-BIT-
n.patch;patch=1 \
#
file://omap-pm/0159-OMAP3-clock-Remove-virt_vdd1-2_prcm_set.patch
;patch=1 \
The following patches (from 167 to 186) are more recent, and
no necessary to reproduce the crash above:
#
file://omap-pm/0168-OMAP3-SR-Fix-SR-driver-to-check-for-omap-pm
-return.patch
;patch=1 \
#
file://omap-pm/0169-OMAP3-PM-Don-t-do-unnecessary-searches-in-o
map_sr_.patch
;patch=1 \
#
file://omap-pm/0181-OMAP-PM-SmartReflex-has-build-dependency-on
-OMAP-P.patch
;patch=1 \
#
file://omap-pm/0186-OMAP3-PM-Fix-Smartreflex-when-used-with-PM_
NOOP-la.patch
;patch=1 \
Excluding the SR patches gives me a workable kernel that
doesn't crash on startup.
Best regards,
Elvis
--
To unsubscribe from this list: send the line "unsubscribe
linux-omap" in the body of a message to
majordomo@xxxxxxxxxxxxxxx More majordomo info at
http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Elvis,
Currently Smartreflex (SR) is dependent on SRF to get OPP levels. Just make sure
you select CONFIG_OMAP_PM_SRF when using SR. OR you can disable Smartreflex till
this issue is fixed.
I am working on a patch that will make Smartreflex independent of SRF. I will
post this soon.
cheers,
Roger.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
