linux-edac.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Ghannam, Yazen" <Yazen.Ghannam@amd.com>
To: "Ghannam, Yazen" <Yazen.Ghannam@amd.com>,
	Adam Borowski <kilobyte@angband.pl>
Cc: "linux-edac@vger.kernel.org" <linux-edac@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"bp@alien8.de" <bp@alien8.de>
Subject: RE: [PATCH v3 0/8] AMD64 EDAC fixes
Date: Fri, 23 Aug 2019 15:28:59 +0000	[thread overview]
Message-ID: <SN6PR12MB263989CCDCC0F74138B6B747F8A40@SN6PR12MB2639.namprd12.prod.outlook.com> (raw)
In-Reply-To: <SN6PR12MB2639CD6D755B6FFCF5C4B756F8A50@SN6PR12MB2639.namprd12.prod.outlook.com>

> -----Original Message-----
> From: linux-edac-owner@vger.kernel.org <linux-edac-owner@vger.kernel.org> On Behalf Of Ghannam, Yazen
> Sent: Thursday, August 22, 2019 1:54 PM
> To: Adam Borowski <kilobyte@angband.pl>
> Cc: linux-edac@vger.kernel.org; linux-kernel@vger.kernel.org; bp@alien8.de
> Subject: RE: [PATCH v3 0/8] AMD64 EDAC fixes
> 
...
> I wonder if the module is being loaded multiple times. I'll try to reproduce this and track it down.
> 

I was able to reproduce a similar failure. I do see that the module is being loaded multiple times on failure.

Here's a call trace from one dump_stack() output:
[  +0.004964] CPU: 132 PID: 2680 Comm: systemd-udevd Not tainted 4.20.0-edac-debug+ #36
[  +0.009802] Call Trace:
[  +0.002727]  dump_stack+0x63/0x85
[  +0.003696]  amd64_edac_init+0x2163/0x3000 [amd64_edac_mod]
[  +0.006216]  ? __wake_up+0x13/0x20
[  +0.003790]  ? 0xffffffffc120d000
[  +0.003694]  do_one_initcall+0x4a/0x1c9
[  +0.004277]  ? _cond_resched+0x19/0x40
[  +0.004178]  ? kmem_cache_alloc_trace+0x15c/0x1d0
[  +0.005244]  do_init_module+0x5f/0x216
[  +0.004180]  load_module+0x21d5/0x2ac0
[  +0.004179]  ? wait_woken+0x80/0x80
[  +0.003889]  __do_sys_finit_module+0xfc/0x120
[  +0.004858]  ? __do_sys_finit_module+0xfc/0x120
[  +0.005052]  __x64_sys_finit_module+0x1a/0x20
[  +0.004857]  do_syscall_64+0x5a/0x120
[  +0.004081]  entry_SYSCALL_64_after_hwframe+0x44/0xa9


So it seems that userspace (systemd-udevd) keeps trying to load the module. I'm not sure how to prevent this from within the module.

Boris,
Do you think it'd be appropriate to change the return values for some cases?

For example, ECC disabled is a hardware configuration. This doesn't mean that the module failed any operations in this case.

In other words, the module checks for a feature. If the feature is not present, then return without failure (and maybe give a message).

Thanks,
Yazen

  reply	other threads:[~2019-08-23 15:29 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-21 23:59 [PATCH v3 0/8] AMD64 EDAC fixes Ghannam, Yazen
2019-08-21 23:59 ` [PATCH v3 1/8] EDAC/amd64: Support more than two controllers for chip selects handling Ghannam, Yazen
2019-08-21 23:59 ` [PATCH v3 2/8] EDAC/amd64: Recognize DRAM device type with EDAC_CTL_CAP Ghannam, Yazen
2019-08-21 23:59 ` [PATCH v3 3/8] EDAC/amd64: Initialize DIMM info for systems with more than two channels Ghannam, Yazen
2019-08-21 23:59 ` [PATCH v3 4/8] EDAC/amd64: Find Chip Select memory size using Address Mask Ghannam, Yazen
2019-08-22  0:00 ` [PATCH v3 5/8] EDAC/amd64: Decode syndrome before translating address Ghannam, Yazen
2019-08-22  0:00 ` [PATCH v3 6/8] EDAC/amd64: Cache secondary Chip Select registers Ghannam, Yazen
2019-08-22  0:00 ` [RFC PATCH v3 08/10] EDAC/amd64: Gather hardware information early Ghannam, Yazen
2019-08-29  9:22   ` Borislav Petkov
2019-09-06 19:14     ` Ghannam, Yazen
2019-09-06 20:35       ` Borislav Petkov
2019-09-06 20:49         ` Ghannam, Yazen
2019-09-09 15:31           ` Borislav Petkov
2019-08-22  0:00 ` [PATCH v3 7/8] EDAC/amd64: Support Asymmetric Dual-Rank DIMMs Ghannam, Yazen
2019-08-23 11:26   ` Borislav Petkov
2019-08-23 13:27     ` Ghannam, Yazen
2019-08-23 15:11       ` Borislav Petkov
2019-08-22  0:00 ` [RFC PATCH v3 10/10] EDAC/amd64: Check for memory before fully initializing an instance Ghannam, Yazen
2019-08-22 18:51   ` [RFC PATCH v2] " Ghannam, Yazen
2019-08-22  0:00 ` [RFC PATCH v3 09/10] EDAC/amd64: Use cached data when checking for ECC Ghannam, Yazen
2019-08-22  0:50 ` [PATCH v3 0/8] AMD64 EDAC fixes Adam Borowski
2019-08-22  8:35   ` Borislav Petkov
2019-08-22  9:46     ` Adam Borowski
2019-08-22  9:55       ` Borislav Petkov
2019-08-22 18:54   ` Ghannam, Yazen
2019-08-23 15:28     ` Ghannam, Yazen [this message]
2019-08-23 15:37       ` Borislav Petkov
2019-08-26 14:19         ` Ghannam, Yazen
2019-08-26 14:59           ` Borislav Petkov
2019-08-26 15:05             ` Ghannam, Yazen
2019-08-22 18:48 ` [RFC PATCH v2] EDAC/amd64: Check for memory before fully initializing an instance Ghannam, Yazen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=SN6PR12MB263989CCDCC0F74138B6B747F8A40@SN6PR12MB2639.namprd12.prod.outlook.com \
    --to=yazen.ghannam@amd.com \
    --cc=bp@alien8.de \
    --cc=kilobyte@angband.pl \
    --cc=linux-edac@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).