Created attachment 276383 [details]
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]
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.
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.
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
Author: Schmauss, Erik <firstname.lastname@example.org>
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.
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:
Tested-by: Kai-Heng Feng <email@example.com>
Signed-off-by: Bob Moore <firstname.lastname@example.org>
Signed-off-by: Erik Schmauss <email@example.com>
Signed-off-by: Rafael J. Wysocki <firstname.lastname@example.org>
: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,
2. checking the commit at 5a8361f7ecceaed64b4064000d16cb703462be49
yes it is
Could you get the full dmesg and acpidump of this machine?
Created attachment 276533 [details]
Created attachment 276535 [details]
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
> > 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]
(In reply to step-ali from comment #24)
> Created attachment 276957 [details]
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,
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
Author: Rafael J. Wysocki <email@example.com>
AuthorDate: Wed Jan 9 00:34:37 2019 +0100
Commit: Rafael J. Wysocki <firstname.lastname@example.org>
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
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")
Reported-by: step-ali <email@example.com>
Reported-by: Charles Stanhope <firstname.lastname@example.org>
Tested-by: Charles Stanhope <email@example.com>
Reported-by: Paulo Nascimento <firstname.lastname@example.org>
Reported-by: David Purton <email@example.com>
Reported-by: Adam Harvey <firstname.lastname@example.org>
Reported-by: Zhang Rui <email@example.com>
Tested-by: Zhang Rui <firstname.lastname@example.org>
Tested-by: Jean-Marc Lenoir <email@example.com>
Signed-off-by: Rafael J. Wysocki <firstname.lastname@example.org>