Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1352516
| From | "Zheng, Lv" <lv.zheng@intel.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | RE: [PATCH] ACPICA: Events: Execute some _REG methods in early boot |
| Date | 2016-03-08 02:00 +0100 |
| Message-ID | <raeaf-1Ul-29@gated-at.bofh.it> (permalink) |
| References | <r6Spz-7yF-3@gated-at.bofh.it> <r9m9Q-804-3@gated-at.bofh.it> <r9WZH-7HZ-1@gated-at.bofh.it> <ra0qC-1wR-7@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
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
Back to linux.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread
[PATCH] ACPICA: Events: Execute some _REG methods in early boot Chris Bainbridge <chris.bainbridge@gmail.com> - 2016-03-05 16:20 +0100
RE: [PATCH] ACPICA: Events: Execute some _REG methods in early boot "Zheng, Lv" <lv.zheng@intel.com> - 2016-03-07 07:40 +0100
Re: [PATCH] ACPICA: Events: Execute some _REG methods in early boot Chris Bainbridge <chris.bainbridge@gmail.com> - 2016-03-07 11:20 +0100
RE: [PATCH] ACPICA: Events: Execute some _REG methods in early boot "Zheng, Lv" <lv.zheng@intel.com> - 2016-03-08 02:00 +0100
csiph-web