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
