Thank you Boris for the information. It is helpful.
>> 2. The default EDAC_OPSTATE_INT in fsl_ddr_mc_init() and the
>> platform_driver_register() is successful. But I don’t see any printk()
>> messages in fsl_mc_err_probe() within fsl_ddr_edac.c. No errors appear
>> in any /var/log/*.
> Yeah, see if it even gets called at all:
I did a grep on /var/log/* and don't see any printk's from
fsl_mc_err_probe(). So, it's not being called.
1) What would cause the probe function not to be called?
2) Were changes made in how .probe functions were called between
different kernel releases of the edac?
3) How should I go about root causing the reason for the .probe to
fail since I may have to backport any changes made?
4) Possibly a patch exists for .probe changes after 4.1.35-rt41?
static struct platform_driver fsl_ddr_mc_err_driver = {
.probe = fsl_mc_err_probe,
.remove = fsl_mc_err_remove,
.driver = {
.name = "fsl_ddr_mc_err",
.of_match_table = fsl_ddr_mc_err_of_match,
},
}l;
int fsl_mc_err_probe(struct platform_device *op)
{
struct mem_ctl_info *mci;
struct edac_mc_layer layers[2];
struct fsl_mc_pdata *pdata;
struct resource r;
u32 sdram_ctl;
int res;
pr_err("%s: entry\n", __func__);
printk("entered fsl_mc_err_probe!\n");
Any assistance greatly appreciated.
On Sat, Nov 17, 2018 at 8:05 AM Borislav Petkov <bp@xxxxxxxxx> wrote:
>
> + York.
>
> On Fri, Nov 16, 2018 at 11:07:50AM -0600, Tracy Smith wrote:
> > I’m attempting to insmod/modprobe the layerscape_edac_mod.ko driver.
> > It seems the driver enters layerscape_edac.c fsl_ddr_mc_init() and
> > completes successfully. But there is no EDAC boot messages and no
> > /proc/interrupts entry for the EDAC. I’m backporting the EDAC from the
> > LSDK to the SDK 2.0.
> >
> > I have set CONFIG_EDAC_DEBUG and set edac_debug_level to 4, but I
> > don’t see any debug messages other than printk()s that I add to
> > fsl_ddr_mc_init() in layerscape_edac.c. No debug messages appear in
> > any logs from fsl_ddr_edac.c.
> >
> > 1. How can I enable debug information? Is debugfs required to print
> > the debug messages for the edac_debug_level and CONFIG_EDAC_DEBUG in
> > the 4.1.35-rt41 kernel for drivers/edac?
>
> No, just slap printks before every return statement, like:
>
> if (!devres_open_group(&op->dev, fsl_mc_err_probe, GFP_KERNEL)) {
> pr_err("%s: Error devres_open_group()\n", __func__);
> return -ENOMEM;
> }
>
> so that you can get closer to the place where it fails.
>
> > 2. The default EDAC_OPSTATE_INT in fsl_ddr_mc_init() and the
> > platform_driver_register() is successful. But I don’t see any printk()
> > messages in fsl_mc_err_probe() within fsl_ddr_edac.c. No errors appear
> > in any /var/log/*.
>
> Yeah, see if it even gets called at all:
>
> int fsl_mc_err_probe(struct platform_device *op)
> {
> struct mem_ctl_info *mci;
> struct edac_mc_layer layers[2];
> struct fsl_mc_pdata *pdata;
> struct resource r;
> u32 sdram_ctl;
> int res;
>
> pr_err("%s: entry\n", __func__);
>
>
> > 3. I don’t see any interrupts, so why would there not be an edac
> > interrupt in /proc/inturrupts?
>
> Probably because it doesn't reach the point where it registers an IRQ
> handler...
>
> > Do I need to inject an error before seeing an edac interrupt in
> > /proc/interrupts?
>
> You should, AFAICT, if it loads and registers stuff properly.
>
> > lsmod
> > module: layerscape_edac_mod 12594 0
> >
> > 4. To inject an error I can use the fsl_mc_inject …. routines in
> > fsl_ddr_edac.c and write to the registers. But is there a utility that
> > already uses these routines that can be used to inject an error
> > (FSL_MC_ECC_ERR_INJECT, FSL_MC_DATA_ERR_INJECT_LO,
>
> You should be able to simply write to *sysfs*. Somewhere under
> /sys/devices/system/edac/...
>
> fsl_mc_inject_data_{lo,hi}_store simply writes the low and high inject
> register.
>
> Btw, looking at it, York, this whole injection functionality needs to
> be behind CONFIG_EDAC_DEBUG because a production driver shouldn't have
> injection capability.
>
> Hmmm.
>
> --
> Regards/Gruss,
> Boris.
>
> Good mailing practices for 400: avoid top-posting and trim the reply.
--
Confidentiality notice: This e-mail message, including any
attachments, may contain legally privileged and/or confidential
information. If you are not the intended recipient(s), please
immediately notify the sender and delete this e-mail message.
