You are not logged in.
Pages: 1
I run Arch + KDE Plasma + systemd-boot on a Samsung laptop (model NP900X3L-KW1BR) which is my daily driver. Recently, I started experiencing a problem: The battery status does not change to discharging when I unplug the laptop or to charging when I plug it. The problem happens with all three kernels that I have installed: stock (version 4.17.14), LTS (version 4.14.63) and pf (version 4.18.0-pf1). The laptop is less than two years old and the battery is good condition (94%). Bios is in the latest version.
[cribari@darwin5]: ~>$ cat /sys/class/power_supply/BAT1/uevent
POWER_SUPPLY_NAME=BAT1
POWER_SUPPLY_STATUS=Unknown
POWER_SUPPLY_PRESENT=1
POWER_SUPPLY_TECHNOLOGY=Li-ion
POWER_SUPPLY_CYCLE_COUNT=349
POWER_SUPPLY_VOLTAGE_MIN_DESIGN=7600000
POWER_SUPPLY_VOLTAGE_NOW=8480000
POWER_SUPPLY_CURRENT_NOW=0
POWER_SUPPLY_CHARGE_FULL_DESIGN=3950000
POWER_SUPPLY_CHARGE_FULL=3700000
POWER_SUPPLY_CHARGE_NOW=3589000
POWER_SUPPLY_CAPACITY=97
POWER_SUPPLY_CAPACITY_LEVEL=Normal
POWER_SUPPLY_MODEL_NAME=SR Real Battery
POWER_SUPPLY_MANUFACTURER=SAMSUNG Electronics
POWER_SUPPLY_SERIAL_NUMBER=123456789
[cribari@darwin5]: ~>$ cat /sys/class/power_supply/BAT1/uevent
POWER_SUPPLY_NAME=BAT1
POWER_SUPPLY_STATUS=Unknown
POWER_SUPPLY_PRESENT=1
POWER_SUPPLY_TECHNOLOGY=Li-ion
POWER_SUPPLY_CYCLE_COUNT=349
POWER_SUPPLY_VOLTAGE_MIN_DESIGN=7600000
POWER_SUPPLY_VOLTAGE_NOW=8480000
POWER_SUPPLY_CURRENT_NOW=0
POWER_SUPPLY_CHARGE_FULL_DESIGN=3950000
POWER_SUPPLY_CHARGE_FULL=3700000
POWER_SUPPLY_CHARGE_NOW=3589000
POWER_SUPPLY_CAPACITY=97
POWER_SUPPLY_CAPACITY_LEVEL=Normal
POWER_SUPPLY_MODEL_NAME=SR Real Battery
POWER_SUPPLY_MANUFACTURER=SAMSUNG Electronics
POWER_SUPPLY_SERIAL_NUMBER=123456789
[cribari@darwin5]: ~>$ upower -i /org/freedesktop/UPower/devices/battery_BAT1
native-path: BAT1
vendor: SAMSUNG Electronics
model: SR Real Battery
serial: 123456789
power supply: yes
updated: Fri 17 Aug 2018 02:24:26 PM -03 (89 seconds ago)
has history: yes
has statistics: yes
battery
present: yes
rechargeable: yes
state: fully-charged
warning-level: none
energy: 27.2764 Wh
energy-empty: 0 Wh
energy-full: 28.88 Wh
energy-full-design: 30.02 Wh
energy-rate: 0.0456 W
voltage: 8.482 V
percentage: 97%
capacity: 96.2025%
technology: lithium-ion
icon-name: 'battery-full-charged-symbolic'When the laptop is plugged in I get:
[cribari@darwin5]: ~>$ acpi -i
Battery 0: Unknown, 97%
Battery 0: design capacity 3950 mAh, last full capacity 3700 mAh = 93%When I unplug it (i.e., it starts running on the battery) I get:
[cribari@darwin5]: ~>$ acpi -i
Battery 0: Charging, 97%, 00:07:00 until charged
Battery 0: design capacity 3950 mAh, last full capacity 3700 mAh = 93%Notice that it says "charging". The only way I can successfully update the battery status is by suspending to RAM and resuming. After suspending and resuming (with the laptop unplugged) I get:
[cribari@darwin5]: ~>$ acpi -i
Battery 0: Discharging, 96%, 03:37:14 remaining
Battery 0: design capacity 3950 mAh, last full capacity 3700 mAh = 93%After I plug the laptop, I get:
[cribari@darwin5]: ~>$ cat /sys/class/power_supply/BAT1/status
DischargingIn this past I experienced the same problem, but it went away after a while. I noticed the following bug report:
https://bugzilla.kernel.org/show_bug.cgi?id=44161
From what I understand, the patch mentioned in comment 254 has already made it upstream and was included in the Linux kernel. See
https://www.systutorials.com/linux-kern … ux-4-14-3/
If so, the problem I am experiencing may be Arch-related. Can someone help me to sort this out? Thank you in advance.
Last edited by cribari (2018-08-17 17:45:31)
Linux, street photography and Baroque music enthusiast.
Offline
Have you tried the patch from https://bugzilla.kernel.org/show_bug.cgi?id=44161#c254 ?
Offline
Have you tried the patch from https://bugzilla.kernel.org/show_bug.cgi?id=44161#c254 ?
I didn't try to compile the kernel applying this patch because I understood such a patch has already been included in the Linux kernel:
Linux, street photography and Baroque music enthusiast.
Offline
After looking at the patch I referenced you believed it was the same as that which had already been applied?
diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c
index 236b143..82b3ce5 100644
--- a/drivers/acpi/ec.c
+++ b/drivers/acpi/ec.c
@@ -486,8 +486,11 @@ static inline void __acpi_ec_enable_event(struct acpi_ec *ec)
{
if (!test_and_set_bit(EC_FLAGS_QUERY_ENABLED, &ec->flags))
ec_log_drv("event unblocked");
- if (!test_bit(EC_FLAGS_QUERY_PENDING, &ec->flags))
- advance_transaction(ec);
+ /*
+ * Unconditionally invoke this once after enabling the event
+ * handling mechanism to detect the pending events.
+ */
+ advance_transaction(ec);
}
static inline void __acpi_ec_disable_event(struct acpi_ec *ec)
@@ -1456,11 +1459,10 @@ static int ec_install_handlers(struct acpi_ec *ec, bool handle_events)
if (test_bit(EC_FLAGS_STARTED, &ec->flags) &&
ec->reference_count >= 1)
acpi_ec_enable_gpe(ec, true);
-
- /* EC is fully operational, allow queries */
- acpi_ec_enable_event(ec);
}
}
+ /* EC is fully operational, allow queries */
+ acpi_ec_enable_event(ec);
return 0;
}@@ -, +, @@
---
drivers/acpi/ec.c | 53 +++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 53 insertions(+)
--- a/drivers/acpi/ec.c
+++ a/drivers/acpi/ec.c
@@ -194,6 +194,7 @@ static struct workqueue_struct *ec_query_wq;
static int EC_FLAGS_QUERY_HANDSHAKE; /* Needs QR_EC issued when SCI_EVT set */
static int EC_FLAGS_CORRECT_ECDT; /* Needs ECDT port address correction */
static int EC_FLAGS_IGNORE_DSDT_GPE; /* Needs ECDT GPE as correction setting */
+static int EC_FLAGS_CLEAR_ON_RESUME; /* Needs acpi_ec_clear() on boot/resume */
/* --------------------------------------------------------------------------
* Logging/Debugging
@@ -499,6 +500,26 @@ static inline void __acpi_ec_disable_event(struct acpi_ec *ec)
ec_log_drv("event blocked");
}
+/*
+ * Process _Q events that might have accumulated in the EC.
+ * Run with locked ec mutex.
+ */
+static void acpi_ec_clear(struct acpi_ec *ec)
+{
+ int i, status;
+ u8 value = 0;
+
+ for (i = 0; i < ACPI_EC_CLEAR_MAX; i++) {
+ status = acpi_ec_query(ec, &value);
+ if (status || !value)
+ break;
+ }
+ if (unlikely(i == ACPI_EC_CLEAR_MAX))
+ pr_warn("Warning: Maximum of %d stale EC events cleared\n", i);
+ else
+ pr_info("%d stale EC events cleared\n", i);
+}
+
static void acpi_ec_enable_event(struct acpi_ec *ec)
{
unsigned long flags;
@@ -507,6 +528,10 @@ static void acpi_ec_enable_event(struct acpi_ec *ec)
if (acpi_ec_started(ec))
__acpi_ec_enable_event(ec);
spin_unlock_irqrestore(&ec->lock, flags);
+
+ /* Drain additional events if hardware requires that */
+ if (EC_FLAGS_CLEAR_ON_RESUME)
+ acpi_ec_clear(ec);
}
#ifdef CONFIG_PM_SLEEP
@@ -1803,6 +1828,31 @@ static int ec_flag_query_handshake(const struct dmi_system_id *id)
#endif
/*
+ * On some hardware it is necessary to clear events accumulated by the EC during
+ * sleep. These ECs stop reporting GPEs until they are manually polled, if too
+ * many events are accumulated. (e.g. Samsung Series 5/9 notebooks)
+ *
+ * https://bugzilla.kernel.org/show_bug.cgi?id=44161
+ *
+ * Ideally, the EC should also be instructed NOT to accumulate events during
+ * sleep (which Windows seems to do somehow), but the interface to control this
+ * behaviour is not known at this time.
+ *
+ * Models known to be affected are Samsung 530Uxx/535Uxx/540Uxx/550Pxx/900Xxx,
+ * however it is very likely that other Samsung models are affected.
+ *
+ * On systems which don't accumulate _Q events during sleep, this extra check
+ * should be harmless.
+ */
+static int ec_clear_on_resume(const struct dmi_system_id *id)
+{
+ pr_debug("Detected system needing EC poll on resume.\n");
+ EC_FLAGS_CLEAR_ON_RESUME = 1;
+ ec_event_clearing = ACPI_EC_EVT_TIMING_STATUS;
+ return 0;
+}
+
+/*
* Some ECDTs contain wrong register addresses.
* MSI MS-171F
* https://bugzilla.kernel.org/show_bug.cgi?id=12461
@@ -1851,6 +1901,9 @@ static const struct dmi_system_id ec_dmi_table[] __initconst = {
ec_honor_ecdt_gpe, "ASUS X580VD", {
DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
DMI_MATCH(DMI_PRODUCT_NAME, "X580VD"),}, NULL},
+ {
+ ec_clear_on_resume, "Samsung hardware", {
+ DMI_MATCH(DMI_SYS_VENDOR, "SAMSUNG ELECTRONICS CO., LTD.")}, NULL},
{},
};
-- Offline
My mistake. Sorry. I'll try to compile the kernel using the referenced patch. Is there any way to know whether this patch will eventually make it into the Linux kernel?
Linux, street photography and Baroque music enthusiast.
Offline
I compiled kernel 4.18.1 with the referenced patch. After doing that the problem was gone. That is, the patch works. Thank you, @loqs. I hope this patch will make into the Linux kernel.
Linux, street photography and Baroque music enthusiast.
Offline
Pages: 1