On Tue, Apr 03, 2012 at 03:27:52PM +0100, Kevin Hilman wrote: > Hi Will, Hi Kevin, > Will Deacon <will.deacon@xxxxxxx> writes: > > The problem is, trying to boot this on my pandaboard results in a hang (see > > dmesg below). Even worse, the problem isn't easily bisectable since rebuilding > > a working image can give you something that no longer boots and I haven't found > > a reliable way to cause the lockup. > > > > I'll take JTAG for a whirl to see where we are. If anything looks wrong in > > my dmesg, please shout (there are plenty of things in there that look like > > they've gone awry). > > Not sure why it hangs for you, but it worked for me both with your > branch on v3.3 and merging with v3.4-rc1[1] Thanks for testing that. It turns out that updating my x-loader (it was pretty ancient) fixed the boot hang, though I'm not sure I want to know why! > # perf stat sleep 1 > > Performance counter stats for 'sleep 1': > > 9.582520 task-clock # 0.009 CPUs utilized > 1 context-switches # 0.104 K/sec > 0 CPU-migrations # 0.000 K/sec > 147 page-faults # 0.015 M/sec > 5096283 cycles # 0.532 GHz > 607876 stalled-cycles-frontend # 11.93% frontend cycles idle > 3285045 stalled-cycles-backend # 64.46% backend cycles idle > 2722485 instructions # 0.53 insns per cycle > # 1.21 stalled cycles per insn > 259247 branches # 27.054 M/sec > 84274 branch-misses # 32.51% of all branches Right. Can you confirm whether the PMU/CTI interrupts fire for you please? Just run perf top and look at /proc/interrupts while it's running. You should see a couple of arm-pmu entries in there and hopefully numbers > 0. For me, my earlier mis-diagnosis has turned out to be true and I can only see PMU interrupts if I apply the SWSUSP patch, which Santosh says will break pm. Cheers, Will -- 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
