Created attachment 276383 [details] lsmod 4.16 4.16 everything was working great , in 4.17 i get no keyboard or touchpad or battery status . my hardware is Asus Zenbook ux303ub and disrto is archlinux with core repo kernel and linux-git . i get this error in dmesg : [ 52.633484] pcieport 0000:00:1c.5: PCIe Bus Error: severity=Corrected, type=Physical Layer, id=00e5(Receiver ID) [ 52.633488] pcieport 0000:00:1c.5: device [8086:9d15] error status/mask=00000001/00002000 [ 52.633492] pcieport 0000:00:1c.5: [ 0] Receiver Error (First) ls mod for 4.16 and 4.17 is attached . help please .
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>