On Friday 20 December 2013 03:59 PM, Tero Kristo wrote: > On 12/20/2013 12:07 PM, Rajendra Nayak wrote: >> On Friday 20 December 2013 12:32 AM, Tero Kristo wrote: >>> On 12/19/2013 08:26 PM, Tony Lindgren wrote: >>>> * Tero Kristo <t-kristo@xxxxxx> [131219 03:26]: >>>>> Divider clock can now be registered to use low level register access ops. >>>>> Preferred initialization method is via clock description. >>>> >>>> This seems to make omap2 not boot for me. No output whatsoever even with >>>> DEBUG_LL and earlyprintk. >>> >>> Thats weird... I was kind of afraid something like this might happen though as these patches touch the clock low level routines globally, but I can't see what could be broken... >> >> I got hold of a 2430sdp and saw the same behavior, however DEBUG_LL and earlyprintk worked and this is >> what I see >> >> [ 0.000000] Unable to handle kernel NULL pointer dereference at virtual address 00000000 >> [ 0.000000] pgd = c0004000 >> [ 0.000000] [00000000] *pgd=00000000 >> [ 0.000000] Internal error: Oops: 5 [#1] SMP ARM >> [ 0.000000] Modules linked in: >> [ 0.000000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.13.0-rc4-00056-ga9fa93e #2 >> [ 0.000000] task: c07dfcb8 ti: c07d4000 task.ti: c07d4000 >> [ 0.000000] PC is at clk_mux_get_parent+0x14/0xcc >> [ 0.000000] LR is at clk_mux_get_parent+0x10/0xcc >> [ 0.000000] pc : [<c044a234>] lr : [<c044a230>] psr: a00001d3 >> [ 0.000000] sp : c07d5f40 ip : 00000000 fp : 00000000 >> [ 0.000000] r10: c07dc880 r9 : 4107b366 r8 : c07f46a4 >> [ 0.000000] r7 : c0edfa80 r6 : ffffffff r5 : c07f6810 r4 : 00000002 >> [ 0.000000] r3 : 00000000 r2 : 00000000 r1 : c069da67 r0 : 00000002 >> [ 0.000000] Flags: NzCv IRQs off FIQs off Mode SVC_32 ISA ARM Segment kernel >> [ 0.000000] Control: 00c5387d Table: 80004000 DAC: 00000017 >> [ 0.000000] Process swapper/0 (pid: 0, stack limit = 0xc07d4248) >> [ 0.000000] Stack: (0xc07d5f40 to 0xc07d6000) >> [ 0.000000] 5f40: c044a220 00000002 c6001f40 c0448e54 c07dfcb8 c0862f7c c07f3600 c07f4368 >> [ 0.000000] 5f60: ffffffff c0edfa80 c07b6b80 4107b366 c07dc880 c077edf4 c0531008 c07f4380 >> [ 0.000000] 5f80: c07f34d4 c077f20c c0878964 c0edfa80 c07b6b80 c0877ac4 c0877640 ffffffff >> [ 0.000000] 5fa0: c0edfa80 c0777268 00000001 c07792ac c07b5250 c077221c 00000002 c076e974 >> [ 0.000000] 5fc0: ffffffff ffffffff c076e57c 00000000 00000000 c07b6b80 00000000 00c5387d >> [ 0.000000] 5fe0: c07dc928 c07b6b7c c07e1474 80004008 8052c544 80008074 00000000 00000000 >> [ 0.000000] [<c044a234>] (clk_mux_get_parent+0x14/0xcc) from [<c0448e54>] (__clk_init+0xe4/0x3f0) >> [ 0.000000] [<c0448e54>] (__clk_init+0xe4/0x3f0) from [<c077edf4>] (omap_clocks_register+0x24/0x48) >> [ 0.000000] [<c077edf4>] (omap_clocks_register+0x24/0x48) from [<c077f20c>] (omap2430_clk_init+0x4c/0x124) >> [ 0.000000] [<c077f20c>] (omap2430_clk_init+0x4c/0x124) from [<c0777268>] (omap_clk_init+0x28/0x30) >> [ 0.000000] [<c0777268>] (omap_clk_init+0x28/0x30) from [<c07792ac>] (omap2_sync32k_timer_init+0x8/0x58) >> [ 0.000000] [<c07792ac>] (omap2_sync32k_timer_init+0x8/0x58) from [<c077221c>] (time_init+0x1c/0x30) >> [ 0.000000] [<c077221c>] (time_init+0x1c/0x30) from [<c076e974>] (start_kernel+0x1d4/0x360) >> [ 0.000000] [<c076e974>] (start_kernel+0x1d4/0x360) from [<80008074>] (0x80008074) >> [ 0.000000] Code: e1a05000 e5900000 ebfff7f5 e595300c (e5933000) >> [ 0.000000] ---[ end trace 3406ff24bd97382e ]--- >> [ 0.000000] Kernel panic - not syncing: Attempted to kill the idle task! >> >> I'll try and debug further but any quick thoughts on what could be wrong? > > I have a fix for this already and will be posting v12 today. I will just re-post the drivers/clk part of the series though, rest of the patches should be fine. > > This bug was silly actually, I didn't think of the static clock data initialization through the macros from clk-private.h... This caused the resulting clock structures to have NULL for clk_ll_ops as it bypassed the init function where I set it up. So, I will need to check against NULL every time I do anything with ll_ops. yeah, the crash was indeed when ll_ops was dereferenced despite being NULL. > > -Tero > -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
