On 18.03.2016 14:30, Guenter Roeck wrote:
Hi Dirk,
On 03/18/2016 02:18 AM, Dirk Behme wrote:
Hi Guenter,
On 18.03.2016 07:44, Guenter Roeck wrote:
Hi,
I am seeing the attached crash when running a realview-pb-a8 image with
realview_defconfig in qemu.
bisect wasn't successful, but a commit analysis identified commit
'drivers/perf: arm_pmu: make info
messages more verbose' as the culprit. Reverting this commit fixes the
problem.
The code roughly looks as follows.
int arm_pmu_device_probe()
{
...
if (node && ..) {
} else {
}
if (ret) {
pr_info("%s: failed to probe PMU! Error %i\n",
node->full_name, ret);
goto out_free;
}
....
out_free:
pr_info("%s: failed to register PMU devices! Error %i\n",
node->full_name, ret);
....
}
Note that 'node' is dereferenced even though it was previously checked
if it is NULL.
The configuration I am testing does not use devicetree.
Can you use dev_info() instead ?
Does anything like below [1] does work for you?
If so, could you please share the output? I.e. what it prints in your
non-devicetree non-pmu case?
This is what I get:
hw perfevents: probing PMU on CPU 0
armv7-pmu armv7-pmu: failed to probe PMU! Error -6
armv7-pmu armv7-pmu: failed to register PMU devices! Error -6
Another option might be to use of_node_full_name() (or even better
both dev_info() and of_node_full_name()).
Not sure though what you are looking for. '/soc/pmu_a53' doesn't
tell (me) much either, and I am not sure I understand the context
of the bug description. Why would the kernel try to initialize PMU
for a CPU which isn't online ?
I have a device tree based ARMv8 Cortex A57 / Cortex A53 based system.
The Cortex A57 are always starting fine, but based on some firmware
issues the Cortex A53 are sometimes online, sometimes not. But enabling
the PMUs is always in the device tree, which fails some times then, too.
With the initial non-verbose PMU error messages I needed some time to
find out that the error messages were due to the Cortex A53 not being
online. And I thought it would help to debug similar cases to make this
more verbose.
Best regards
Dirk
--
To unsubscribe from this list: send the line "unsubscribe linux-next" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
