From: "Zheng, Lv" <lv.zheng@intel.com>
To: Chris Bainbridge <chris.bainbridge@gmail.com>
Cc: "Moore, Robert" <robert.moore@intel.com>,
"Wysocki, Rafael J" <rafael.j.wysocki@intel.com>,
"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: RE: [PATCH] ACPICA: Events: Execute some _REG methods in early boot
Date: Tue, 8 Mar 2016 00:54:51 +0000 [thread overview]
Message-ID: <1AE640813FDE7649BE1B193DEA596E883BB60AB0@SHSMSX101.ccr.corp.intel.com> (raw)
In-Reply-To: <20160307101904.GA4417@localhost>
Hi, Chris
> From: linux-acpi-owner@vger.kernel.org [mailto:linux-acpi-
> Subject: Re: [PATCH] ACPICA: Events: Execute some _REG methods in early
> boot
>
> On Mon, Mar 07, 2016 at 06:36:05AM +0000, Zheng, Lv wrote:
> > Hi,
> >
> > First of all, why don't you respond on the kernel bugzilla?
> > Posting a fix here directly without communication doesn't look like a
> constructive help but more like a destructive attack to me.
>
> Sorry if it appears to be an attack. It wasn't meant that way. I was
> under the impression that email is the preferred means of communication
> for kernel development. I'm not sure whether other developers actively
> monitor bugzilla reports (some do, but bug trackers are often graveyards
> for bug reports and it's easy for communications to be missed).
>
[Lv Zheng]
Apologies. It's my fault.
I didn't see your last reply.
> > As I said in the previous reply, this is the known issue and can be fixed by
> applying the whole series.
> > Especially this commit:
> > https://patchwork.kernel.org/patch/8241421/
> > That's why I asked you to test again by applying the whole series.
> > And that's why after having not seen your response for so long time, we
> prepared a test branch and was waiting for your response.
>
> I already replied 9 days ago: https://lkml.org/lkml/2016/2/27/164
> The suggested patch did not fix the issue and the patch series did not
> apply cleanly.
>
> (btw I'm not paid for this work so I tend to handle it in batches when I
> have spare time, which is why you may see replies delayed to weekends etc.)
>
[Lv Zheng]
The problem is the reply didn't arrive the proper mailbox here.
> > You need to post acpidump there to have the issue root caused so that more
> accurate fix can be generated.
>
> I already sent an acpidump for this system to you and Robert (email 3rd Feb).
>
> > The above fix looks hackish to me.
> > IMO, if you want to stop regressions that are triggered by this commit.
> > A simpler and proper way would be to move acpi_gbl_reg_method_enabled =
> TRUE to the end of acpi_load_tables().
> > So that when the order of table loading and ECDT probing is corrected, the
> correct logic can still apply.
> >
> > I don't have ECDT platforms in hand to confirm.
> > Can you help to just give it a try?
>
> Yes the fix may be hackish, but it served the purpose of correctly
> identifying the bug. Your suggestion works fine, for reference the
> tested patch was:
>
>
> diff --git a/drivers/acpi/acpica/tbxfload.c b/drivers/acpi/acpica/tbxfload.c
> index 278666e39563..9136d7250022 100644
> --- a/drivers/acpi/acpica/tbxfload.c
> +++ b/drivers/acpi/acpica/tbxfload.c
> @@ -83,6 +83,7 @@ acpi_status __init acpi_load_tables(void)
> "While loading namespace from ACPI tables"));
> }
>
> + acpi_gbl_reg_methods_enabled = TRUE;
> return_ACPI_STATUS(status);
> }
>
> diff --git a/drivers/acpi/acpica/utxfinit.c b/drivers/acpi/acpica/utxfinit.c
> index 721b87cce908..2c0491038068 100644
> --- a/drivers/acpi/acpica/utxfinit.c
> +++ b/drivers/acpi/acpica/utxfinit.c
> @@ -267,7 +267,6 @@ acpi_status __init acpi_initialize_objects(u32 flags)
> * initialized, even if they contain executable AML (see the call to
> * acpi_ns_initialize_objects below).
> */
> - acpi_gbl_reg_methods_enabled = TRUE;
> if (!(flags & ACPI_NO_ADDRESS_SPACE_INIT)) {
> ACPI_DEBUG_PRINT((ACPI_DB_EXEC,
> "[Init] Executing _REG OpRegion
> methods\n"));
>
>
> With this patch applied the ODEBUG errors do not occur.
[Lv Zheng]
Great!
This line doesn't differ too much in ACPICA upstream, while it matters much in Linux code base.
I should rebase the other patches along with this on top of ACPICA Feb release.
But as I don't have real ECDT platforms, I can just test the fixes by faking ECDT using initrd table override mechanism.
I think it's better to have you confirm the whole series again.
I saw you started to reply on the Bugzilla entry, I'll ping you there after rebasing the patchset.
>
> Thanks.
[Lv Zheng]
Thanks and best regards
-Lv
prev parent reply other threads:[~2016-03-08 0:55 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-03 10:36 [BUG] ODEBUG: assert_init not available (active state 0) Chris Bainbridge
2016-02-05 2:52 ` Zheng, Lv
2016-02-14 10:59 ` Chris Bainbridge
2016-02-23 2:18 ` Zheng, Lv
2016-02-27 19:08 ` Chris Bainbridge
2016-03-05 15:11 ` [PATCH] ACPICA: Events: Execute some _REG methods in early boot Chris Bainbridge
2016-03-07 6:36 ` Zheng, Lv
2016-03-07 10:19 ` Chris Bainbridge
2016-03-08 0:54 ` Zheng, Lv [this message]
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=1AE640813FDE7649BE1B193DEA596E883BB60AB0@SHSMSX101.ccr.corp.intel.com \
--to=lv.zheng@intel.com \
--cc=chris.bainbridge@gmail.com \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rafael.j.wysocki@intel.com \
--cc=robert.moore@intel.com \
/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 read-only IMAP folder(s) and NNTP newsgroup(s).