Re: edac driver initialization, interrupt, & debug

[Steve Inkpen <steve@theinkpens.com>]

Are you using a device tree? If yes, make sure there is an entry for this device.

From your snippet of code, there appears to be a match entry in of_match_table?

Steve

> On Nov 17, 2018, at 6:22 PM, Tracy Smith <tlsmith3777@gmail.com> wrote:
> 
> 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@alien8.de> 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.
--
To unsubscribe from this list: send the line "unsubscribe backports" in