Bug 199981

Created attachment 276385 [details]
lsmod 4.17

any help ??

A straightforward way is to do a git bisect to address the bad commit thus we can help figuring out what the problem is.
https://git-scm.com/docs/git-bisect

when i do :

git bisect good 4.16.14 , i get :

fatal: Needed a single revision
Bad rev input: 4.16.14

what to do ?

First, I think you need to bisect upstream kernel.
something like
git bisect start
git bisect good v4.16
git bisect bad v4.17

yes i got it working ,

but i found more than one bad commit , is that okay ??

(In reply to step-ali from comment #6)
> yes i got it working ,
> 
> but i found more than one bad commit , is that okay ??

There should only be one 'first bad commit' AFAIK, please confirm  each bad bisect results are consistent, say, the symptom are the same -  no keyboard , touchpad nor battery.

first two commits were bad ,

third one is good ,

any ideas ??

also i had to build using gcc7 ,

gcc8 were throwing errors .

5a8361f7ecceaed64b4064000d16cb703462be49 is the first bad commit
commit 5a8361f7ecceaed64b4064000d16cb703462be49
Author: Schmauss, Erik <erik.schmauss@intel.com>
Date:   Thu Feb 15 13:09:30 2018 -0800

    ACPICA: Integrate package handling with module-level code
    
    ACPICA commit 8faf6fca445eb7219963d80543fb802302a7a8c7
    
    This change completes the integration of the recent changes to
    package object handling with the module-level code support.
    
    For acpi_exec, the -ep flag is removed.
    
    This change allows table load to behave as if it were a method
    invocation. Before this, the definition block definition below would
    have loaded all named objects at the root scope. After loading, it
    would execute the if statements at the root scope.
    
    DefinitionBlock (...)
    {
      Name(OBJ1, 0)
    
      if (1)
      {
        Device (DEV1)
        {
          Name (_HID,0x0)
        }
      }
      Scope (DEV1)
      {
        Name (OBJ2)
      }
    }
    
    The above code would load OBJ1 to the namespace, defer the execution
    of the if statement and attempt to add OBJ2 within the scope of DEV1.
    Since DEV1 is not in scope, this would incur an AE_NOT_FOUND error.
    After this error is emitted, the if block is invoked and DEV1 and its
    _HID is added to the namespace.
    
    This commit changes the behavior to execute the if block in place
    rather than deferring it until all tables are loaded. The new
    behavior is as follows: insert OBJ1 in the namespace, invoke the if
    statement and add DEV1 and its _HID to the namespace, add OBJ2 to the
    scope of DEV1.
    
    Bug report links:
    Link: https://bugs.acpica.org/show_bug.cgi?id=963
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=153541
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=196165
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=192621
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=197207
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=198051
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=198515
    
    ACPICA repo:
    Link: https://github.com/acpica/acpica/commit/8faf6fca
    
    Tested-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
    Signed-off-by: Bob Moore <robert.moore@intel.com>
    Signed-off-by: Erik Schmauss <erik.schmauss@intel.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

:040000 040000 f219e9da26cbd8b2ef039583aad89d6e19a49d12 d1c678b85e4617b4cb2f10dbe27b73754e33831c M	drivers
:040000 040000 e19959d679e7bef5a4d6990ab3311735e0a2e6c1 660ed431fc1e61b9b764e676582e47a089429806 M	include

Thanks for the test, may I know if it is possible for you to confirm this is the bad commit by:
1. checking the commit preceding 5a8361f7ecceaed64b4064000d16cb703462be49 by 1,
    AKA, 7decc66df940fc0b128a642df9ac3d917f1b0c1f
2. checking the commit at 5a8361f7ecceaed64b4064000d16cb703462be49

yes it is

Could you get the full dmesg and acpidump of this machine?

Created attachment 276533 [details]
dmesg

Created attachment 276535 [details]
acpidump

when can i see the fix please ??

ok , git kernel fixed , keyboard and touchpad are working , but battery icon have a quistion mark on it ??

(In reply to step-ali from comment #17)
> ok , git kernel fixed , keyboard and touchpad are working , but battery icon
> have a quistion mark on it ??


Which kernel version are you talking about?

(In reply to Erik Schmauss from comment #18)
> (In reply to step-ali from comment #17)
> > ok , git kernel fixed , keyboard and touchpad are working , but battery
> icon
> > have a quistion mark on it ??
> 
> 
> Which kernel version are you talking about?

Linux aj 4.17.0-ga27fc14219f2

(In reply to step-ali from comment #19)
> (In reply to Erik Schmauss from comment #18)
> > (In reply to step-ali from comment #17)
> > > ok , git kernel fixed , keyboard and touchpad are working , but battery
> > icon
> > > have a quistion mark on it ??

I don't know what the question mark indicates. Can you provide more information about what this means?

In gnome DE while charging the battery icon used to have lightening bolt on it , but now it has a question mark .

Please try to get more information about the question mark and what it means. Maybe you could try asking gnome developers.

please attach the output of "grep . /sys/class/power_supply/*/*"

Created attachment 276957 [details]
grep

(In reply to step-ali from comment #24)
> Created attachment 276957 [details]
> grep

I assume this is got in 4.18-rc kernel, right?

what is the model name of your laptop?

can the questions mark problem be reproduced in 4.15 kernel?

I have seen quite a lot of battery driver changes in 4.17-rc1 and 4.18-rc1. To make clear which piece of changes makes the difference, I'd to be clear about the behavior in 4.15, 4.16, 4.17 final, and latest 4.18-rc

(In reply to Zhang Rui from comment #25)
> (In reply to step-ali from comment #24)
> > Created attachment 276957 [details]
> > grep
> 
> I assume this is got in 4.18-rc kernel, right?
> 
> what is the model name of your laptop?
> 
> can the questions mark problem be reproduced in 4.15 kernel?
> 
> I have seen quite a lot of battery driver changes in 4.17-rc1 and 4.18-rc1.
> To make clear which piece of changes makes the difference, I'd to be clear
> about the behavior in 4.15, 4.16, 4.17 final, and latest 4.18-rc

yes this is with 4.18 , 4.17 doesn't even boot on the machine ,

my laptop is an Asus Zenbook UX303UB ,

4.14 ts work properly on the machine but nvidia driver is broken on that kernel ,

4.16 used to work properly .

Hi, Can you try the latest 4.19 rc?

@step-ali, can you please check the latest upstream kernel, say 4.20-rc?

So, first of all, please make sure your kernel is built with CONFIG_ACPI_DEBUG=Y, and then boot with kernel parameter "acpi.debug_level=0x420 acpi.debug_layer=0x05", and attach the full dmesg output after boot, for both good and bad kernels.

hi, I have the same issue (question mark appears in the battery icon when laptop is fully charged) and if I click on the battery it is stuck at "estimating". This only happens when laptop is fully charged and plugged in. When charging all indications are correct. When unplugged all indications are correct. It seems like a miscommunication issue.. my kernel is 4.18.0-11-generic

this only happens on my asus n550-jk laptop. I have a dell laptop that this does not happen to.

please confirm if the problem is gone with the patch from https://bugzilla.kernel.org/show_bug.cgi?id=200011#c71

Thank you Zhang, can you please provide me with instructions on how to implement this patch as I am new to linux.. it seems like I need to update some lines in some file but I am not sure.. thanks (then I can report back on if it worked)

Created attachment 280095 [details]
run EC _REG explicitly

please apply this patch on top of upstream kernel, say 4.20-rc
and see if the problem still exists.

*** Bug 201351 has been marked as a duplicate of this bug. ***

*** Bug 200011 has been marked as a duplicate of this bug. ***

*** Bug 201679 has been marked as a duplicate of this bug. ***

here is the latest patch,
https://patchwork.kernel.org/patch/10753143/
please apply it on top of 5.0-rc1 and check if it works or not.

I have tested this patch on Linux 5.0-rc1 and 4.20.1, it works well.

Fix by the following commit
commit b1c0330823fe842dbb34641f1410f0afa51c29d3
Author:     Rafael J. Wysocki <rafael.j.wysocki@intel.com>
AuthorDate: Wed Jan 9 00:34:37 2019 +0100
Commit:     Rafael J. Wysocki <rafael.j.wysocki@intel.com>
CommitDate: Tue Jan 15 23:18:23 2019 +0100

    ACPI: EC: Look for ECDT EC after calling acpi_load_tables()
    
    Some systems have had functional issues since commit 5a8361f7ecce
    (ACPICA: Integrate package handling with module-level code) that,
    among other things, changed the initial values of the
    acpi_gbl_group_module_level_code and acpi_gbl_parse_table_as_term_list
    global flags in ACPICA which implicitly caused acpi_ec_ecdt_probe() to
    be called before acpi_load_tables() on the vast majority of platforms.
    
    Namely, before commit 5a8361f7ecce, acpi_load_tables() was called from
    acpi_early_init() if acpi_gbl_parse_table_as_term_list was FALSE and
    acpi_gbl_group_module_level_code was TRUE, which almost always was
    the case as FALSE and TRUE were their initial values, respectively.
    The acpi_gbl_parse_table_as_term_list value would be changed to TRUE
    for a couple of platforms in acpi_quirks_dmi_table[], but it remained
    FALSE in the vast majority of cases.
    
    After commit 5a8361f7ecce, the initial values of the two flags have
    been reversed, so in effect acpi_load_tables() has not been called
    from acpi_early_init() any more.  That, in turn, affects
    acpi_ec_ecdt_probe() which is invoked before acpi_load_tables() now
    and it is not possible to evaluate the _REG method for the EC address
    space handler installed by it.  That effectively causes the EC address
    space to be inaccessible to AML on platforms with an ECDT matching the
    EC device definition in the DSDT and functional problems ensue in
    there.
    
    Because the default behavior before commit 5a8361f7ecce was to call
    acpi_ec_ecdt_probe() after acpi_load_tables(), it should be safe to
    do that again.  Moreover, the EC address space handler installed by
    acpi_ec_ecdt_probe() is only needed for AML to be able to access the
    EC address space and the only AML that can run during acpi_load_tables()
    is module-level code which only is allowed to access address spaces
    with default handlers (memory, I/O and PCI config space).
    
    For this reason, move the acpi_ec_ecdt_probe() invocation back to
    acpi_bus_init(), from where it was taken away by commit d737f333b211
    (ACPI: probe ECDT before loading AML tables regardless of module-level
    code flag), and put it after the invocation of acpi_load_tables() to
    restore the original code ordering from before commit 5a8361f7ecce.
    
    Fixes: 5a8361f7ecce ("ACPICA: Integrate package handling with module-level code")
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=199981
    Reported-by: step-ali <sunmooon15@gmail.com>
    Reported-by: Charles Stanhope <charles.stanhope@gmail.com>
    Tested-by: Charles Stanhope <charles.stanhope@gmail.com>
    Reported-by: Paulo Nascimento <paulo.ulusu@googlemail.com>
    Reported-by: David Purton <dcpurton@marshwiggle.net>
    Reported-by: Adam Harvey <adam@adamharvey.name>
    Reported-by: Zhang Rui <rui.zhang@intel.com>
    Tested-by: Zhang Rui <rui.zhang@intel.com>
    Tested-by: Jean-Marc Lenoir <archlinux@jihemel.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>