You are not logged in.

#1 2017-11-18 05:41:32

cfr
Member
From: Cymru
Registered: 2011-11-27
Posts: 7,130

Screen remains black on renewed activity

I thought that my laptop was simply non-responsive the first couple of times this happened. However, I now think that the problem is that the screen brightness remains zero. This does not happen when I'm using the laptop, but only when I've left it without using it for a time and return to find it unresponsive. It does not happen on waking from sleep. Moreover, the laptop cannot be put to sleep while in this state. I only have 3 LEDs: one on the power button, one on the microphone key and one in the lid. They all glow steadily. The laptop only apparently responds to holding down the power key, forcing a hard shutdown.

However, the journal suggests that the problem is rather concerned with backlight brightness. I looked for this because there have been a number of threads about this recently. However, I haven't been able to find a thread fitting my combination of hardware and symptoms. I have intel integrated graphics (only), the brightness keys work out of the box, sleep works without problem etc.

Tach 18 02:53:28 MyComputer org_kde_powerdevil[1224]: powerdevil: Screen brightness value:  426
Tach 18 02:53:28 MyComputer org_kde_powerdevil[1224]: powerdevil: Screen brightness value:  426
Tach 18 02:53:28 MyComputer dbus-daemon[604]: [system] Activating service name='org.kde.powerdevil.backlighthelper' requested by ':1.28' (uid=1000 pid=1224 comm="/usr/lib/org_kde_
powerdevil -session 101561a614111") (using servicehelper)
Tach 18 02:53:28 MyComputer org_kde_powerdevil[1224]: powerdevil: Kbd backlight brightness value:  0
Tach 18 02:53:28 MyComputer org_kde_powerdevil[1224]: powerdevil: Can't contact ck
Tach 18 02:53:28 MyComputer org_kde_powerdevil[1224]: powerdevil: set screen brightness value:  213
Tach 18 02:53:28 MyComputer dbus-daemon[604]: [system] Successfully activated service 'org.kde.powerdevil.backlighthelper'
Tach 18 02:53:28 MyComputer org_kde_powerdevil[1224]: powerdevil: Udev device changed "/sys/devices/pci0000:00/0000:00:02.0/drm/card0/card0-eDP-1/intel_backlight" "/sys/devices/pc
i0000:00/0000:00:02.0/drm/card0/card0-eDP-1/intel_backlight"
Tach 18 02:53:58 MyComputer org_kde_powerdevil[1224]: powerdevil: Screen brightness value:  213
Tach 18 02:53:58 MyComputer org_kde_powerdevil[1224]: powerdevil: Can't contact ck
Tach 18 02:53:58 MyComputer org_kde_powerdevil[1224]: powerdevil: set screen brightness value:  53
Tach 18 02:53:58 MyComputer dbus-daemon[604]: [system] Activating service name='org.kde.powerdevil.backlighthelper' requested by ':1.28' (uid=1000 pid=1224 comm="/usr/lib/org_kde_
powerdevil -session 101561a614111") (using servicehelper)
Tach 18 02:53:58 MyComputer dbus-daemon[604]: [system] Successfully activated service 'org.kde.powerdevil.backlighthelper'
Tach 18 02:53:58 MyComputer org_kde_powerdevil[1224]: powerdevil: Udev device changed "/sys/devices/pci0000:00/0000:00:02.0/drm/card0/card0-eDP-1/intel_backlight" "/sys/devices/pc
i0000:00/0000:00:02.0/drm/card0/card0-eDP-1/intel_backlight"
Tach 18 02:54:28 MyComputer org_kde_powerdevil[1224]: powerdevil: Screen brightness value:  53
Tach 18 02:54:28 MyComputer org_kde_powerdevil[1224]: powerdevil: Can't contact ck
Tach 18 02:54:28 MyComputer org_kde_powerdevil[1224]: powerdevil: set screen brightness value:  0
Tach 18 02:54:28 MyComputer dbus-daemon[604]: [system] Activating service name='org.kde.powerdevil.backlighthelper' requested by ':1.28' (uid=1000 pid=1224 comm="/usr/lib/org_kde_
powerdevil -session 101561a614111") (using servicehelper)
Tach 18 02:54:28 MyComputer dbus-daemon[604]: [system] Successfully activated service 'org.kde.powerdevil.backlighthelper'
Tach 18 02:54:28 MyComputer org_kde_powerdevil[1224]: powerdevil: Udev device changed "/sys/devices/pci0000:00/0000:00:02.0/drm/card0/card0-eDP-1/intel_backlight" "/sys/devices/pc
i0000:00/0000:00:02.0/drm/card0/card0-eDP-1/intel_backlight"
Tach 18 02:57:28 MyComputer org_kde_powerdevil[1224]: powerdevil: Kbd backlight brightness value:  0
Tach 18 03:02:23 MyComputer org_kde_powerdevil[1224]: powerdevil: Can't contact ck
Tach 18 03:02:23 MyComputer org_kde_powerdevil[1224]: powerdevil: Suspend session triggered with QMap(("GraceFade", QVariant(bool, true))("Type", QVariant(uint, 0)))
Tach 18 03:02:28 MyComputer org_kde_powerdevil[1224]: powerdevil: Can't contact ck
Tach 18 03:02:28 MyComputer org_kde_powerdevil[1224]: powerdevil: Suspend session triggered with QMap(("SkipFade", QVariant(bool, true))("Type", QVariant(uint, 0)))
Tach 18 03:09:22 MyComputer dhclient[20052]: DHCPREQUEST on wlan0 to XXX
Tach 18 03:09:22 MyComputer dhclient[20052]: DHCPACK from XXX
Tach 18 03:09:22 MyComputer dhclient[20052]: bound to XXX -- renewal in 5669 seconds.
Tach 18 03:12:23 MyComputer smartd[601]: Device: /dev/nvme0n1, Temperature changed -3 Celsius to 18 Celsius (Min/Max 17/26)
Tach 18 03:35:20 MyComputer kernel: IN=wlan0 OUT= MAC= SRC=XXX DST=XXX ...
Tach 18 03:43:40 MyComputer kernel: IN=wlan0 OUT= MAC= SRC=XXX DST=XXX ...
Tach 18 04:16:04 MyComputer systemd-logind[573]: Suspend key pressed.
Tach 18 04:16:04 MyComputer root[26372]: SleepButton pressed
Tach 18 04:16:04 MyComputer root[26374]: arg1 is button/sleep, arg2 is SBTN, arg3 is 00000080 and arg4 is 00000000
Tach 18 04:16:19 MyComputer kernel: thinkpad_acpi: unknown possible thermal alarm or keyboard event received
Tach 18 04:16:19 MyComputer kernel: thinkpad_acpi: unhandled HKEY event 0x6032
Tach 18 04:16:19 MyComputer kernel: thinkpad_acpi: please report the conditions when this event happened to ibm-acpi-devel@lists.sourceforge.net
Tach 18 04:16:19 MyComputer systemd-logind[573]: Lid closed.
Tach 18 04:16:19 MyComputer root[26377]: ACPI group/action undefined: ibm/hotkey / LEN0268:00
Tach 18 04:16:19 MyComputer root[26379]: arg1 is ibm/hotkey, arg2 is LEN0268:00, arg3 is 00000080 and arg4 is 00006032
Tach 18 04:16:19 MyComputer root[26381]: LID closed
Tach 18 04:16:19 MyComputer root[26383]: arg1 is button/lid, arg2 is LID, arg3 is close and arg4 is
Tach 18 04:16:47 MyComputer kernel: thinkpad_acpi: unknown possible thermal alarm or keyboard event received
Tach 18 04:16:47 MyComputer kernel: thinkpad_acpi: unhandled HKEY event 0x6032
Tach 18 04:16:47 MyComputer kernel: thinkpad_acpi: please report the conditions when this event happened to ibm-acpi-devel@lists.sourceforge.net
Tach 18 04:16:47 MyComputer systemd-logind[573]: Lid opened.
Tach 18 04:16:47 MyComputer root[26387]: ACPI group/action undefined: ibm/hotkey / LEN0268:00
Tach 18 04:16:47 MyComputer root[26389]: arg1 is ibm/hotkey, arg2 is LEN0268:00, arg3 is 00000080 and arg4 is 00006032
Tach 18 04:16:47 MyComputer root[26391]: LID opened
Tach 18 04:16:47 MyComputer root[26393]: arg1 is button/lid, arg2 is LID, arg3 is open and arg4 is
-- Reboot --

The messages here aren't unusual. The closing the lid and pressing the suspend button is me trying to make the laptop sleep while unresponsive. All that is really different here is the lack of any messages concerning the brightness: apparently, powerdevil is just off duty.

The unrecognised keys and so on are in the logs all the time so, while these might be relevant, they can't be the whole story. i did think that the inclusion of 'Kbd backlight brightness value:  0' was implicated. However, it isn't. I get that in other cases, too. It is a bit odd, however, as my keyboard is not backlit. Hence, I don't know what is supposed to have a brightness value of 0. (I suppose the keyboard does have this brightness value, in the sense that no light at all presumably has zero brightness, but I assume that wouldn't normally need monitoring.)

If this should have been appended to an existing thread, I apologise. However, I didn't want to confuse what seemed to be a different set of symptoms by mixing in another.

I'm using the kernel's builtin modesetting driver rather than the intel package. I'm wondering whether that might be part of the problem.

Note that the journal above does not show that I tried to switch to a non-X tty or that I tried to kill X. Nor does it respond to lid close or the suspend key as it normally would (i.e. by sleeping). It is almost as if it is passively registering stuff but not actually responding actively to anything, if that makes any sense. So I'm rather puzzled. I expected to find either no trace in the journal or errors of some kind, but nothing seems to be announcing that, so if there's an error here, it is not very well advertised.


CLI Paste | How To Ask Questions

Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L

Offline

#2 2017-11-18 14:53:54

seth
Member
Registered: 2012-09-03
Posts: 49,981

Re: Screen remains black on renewed activity

Check whether you can control the backlight with xbacklight or similar tools: https://wiki.archlinux.org/index.php/Ba … _utilities
Then cause the condition, ssh into the notebook and try to modify the backlight via software. Also check dmesg, might be some acpi issue (on either the buttons or the backlight control), but could also just be input impeded by the kde screen locker (do you run the screen locker?)

Offline

#3 2017-11-19 01:30:09

cfr
Member
From: Cymru
Registered: 2011-11-27
Posts: 7,130

Re: Screen remains black on renewed activity

Thanks.

seth wrote:

Check whether you can control the backlight with xbacklight or similar tools: https://wiki.archlinux.org/index.php/Ba … _utilities
Then cause the condition, ssh into the notebook and try to modify the backlight via software.

Unfortunately, I can't cause the issue. I can do something which makes it possible, but that's it. Mostly, leaving the laptop alone for a bit is fine. Just not always. It would be tricky to ssh in for this reason. I'd have to run a ssh server, which I'm a bit reluctant to do. I'd then need to set up one of those IP tracking things so i could get the laptop's IP at the time. Finally, I'd need a machine to ssh from. The last condition is the real issue. If I could create the problem reliably, it would be inconvenient but straightforward. But there's really no way for me to do this without a reliable reproduction mechanism. (If I could reproduce, I could go sit by the box I normally ssh *to*, recreate the issue with sshd on the laptop and then ssh *from* that box into the laptop. But I could sit by my remote box for a few days and it might not happen, which doesn't make this option very realistic.)

Unless, I guess, somebody can suggest something to increase the probability of the problem.

I don't actually know that the brightness keys won't work as I did not think about the brightness possibility until I looked at the journal.

Otherwise, I wonder if I could configure some shortcut to apply xbacklight, if that can control the backlight. But I'm not sure this would work if the brightness keys don't. I can't actually use xbacklight as I'm using the modesetting driver, but I could try one of the alternatives listed on the wiki  this way.

Also check dmesg, might be some acpi issue (on either the buttons or the backlight control), but could also just be input impeded by the kde screen locker (do you run the screen locker?)

Do you mean dmesg from the incident?

I just realised that at least the last time this happened, the laptop should have been sleeping when I returned, because powerdevil should have suspended the machine after 10 mins on battery. However, nothing in the log suggested that it had even tried to suspend - let alone succeeded. The lights did not indicate sleep either (steady light on power and lid LEDs rather than slow blinking).

I do have a screen locker. It is not configured to lock the screen automatically except when sleeping.

There are definitely some ACPI oddities on this laptop. I'm running tlp (which doesn't touch brightness or display) and can't get it to respond to a switch to battery, even though it responds to plugging into AC. Moreover, I have not yet managed to even get ACPI to log power supply changes, even though it logs plenty of 'unknown hotkey' events. However, I've been assuming this was a user-configuration issue and that I've just set up the triggers wrongly.

Last edited by cfr (2017-11-19 01:35:02)


CLI Paste | How To Ask Questions

Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L

Offline

#4 2017-11-19 08:44:53

seth
Member
Registered: 2012-09-03
Posts: 49,981

Re: Screen remains black on renewed activity

Finally, I'd need a machine to ssh from.

Valid problem.

I'd have to run a ssh server, which I'm a bit reluctant to do.

No need to. As long as you don't allow to trigger the port in your router, this is a LAN only thing. Esp. not if you're on IPv4 (where explicit port forwarding is a mandatory aprt of the NAT)

I'd then need to set up one of those IP tracking things so i could get the laptop's IP at the time.

The leases are listed in your router.

If you're not on a configured LAN and connect to the internet directly (ewww...) the ISP provided IP rarely changes (usually about once every 24h on IPv4 and never on IPv6), you can just look at it every morning ;-)
The secure way to use ssh in this case is however to force pub key auth: https://wiki.archlinux.org/index.php/Se … Protection

Otherwise: get KDE and TLP out of the equation.
You can install acpid (more flexible than logind ACPI handling and allows to monitor events, so you might check on the battery state detection) and use powertop/udev to configure the power savings.

From your elaboration, I'd say powerdevil tries to suspend & lock the system and that fails miserably - "somehow".

Offline

#5 2017-11-19 22:08:37

cfr
Member
From: Cymru
Registered: 2011-11-27
Posts: 7,130

Re: Screen remains black on renewed activity

seth wrote:

Finally, I'd need a machine to ssh from.

Valid problem.

I'd have to run a ssh server, which I'm a bit reluctant to do.

No need to. As long as you don't allow to trigger the port in your router, this is a LAN only thing. Esp. not if you're on IPv4 (where explicit port forwarding is a mandatory aprt of the NAT)

I don't understand this. How can I ssh to something not running sshd?

I'd then need to set up one of those IP tracking things so i could get the laptop's IP at the time.

The leases are listed in your router.

If you're not on a configured LAN and connect to the internet directly (ewww...) the ISP provided IP rarely changes (usually about once every 24h on IPv4 and never on IPv6), you can just look at it every morning ;-)

The problem is that the machine I could SSH from is on a LAN I do not manage. So I don't have access to the router - at least, not as far as I know. I mostly access that machine remotely over SSH, but for this, I'd obviously have to do the opposite. So I wouldn't be directly on the internet. Also, the laptop would be on eduroam, whereas the machine I'd need to SSH from would not (as it doesn't have wireless, but a wired connection). They would still be on the same LAN, I think. At least, I assume they must be as wired and wireless devices have access to networked resources such as photocopiers for printing.

If I'm at home, I have access to the router. However, then I don't have the wired box to SSH to the laptop.

However, I'm sure I could figure this out. The real problem is that I can't really sit by the wired box for a few days waiting for the laptop to not respond. So unless I figure out a reproducible trigger, sshing in isn't really an option.

The secure way to use ssh in this case is however to force pub key auth: https://wiki.archlinux.org/index.php/Se … Protection

I know. This is how the laptop connects to the desktop. It is harder doing it from the desktop to the thing that roams, unless you can reproduce the problem at will on the thing while not currently roaming.

Otherwise: get KDE and TLP out of the equation.
You can install acpid (more flexible than logind ACPI handling and allows to monitor events, so you might check on the battery state detection) and use powertop/udev to configure the power savings.

From your elaboration, I'd say powerdevil tries to suspend & lock the system and that fails miserably - "somehow".

Yes. This is my suspicion. I think I might try taking powerdevil out of it as a first step, as that seems the most likely culprit. I can't decide whether I want to hold off to try the brightness keys next time it happens or go ahead without further investigation.

Last edited by cfr (2017-11-19 22:11:25)


CLI Paste | How To Ask Questions

Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L

Offline

Board footer

Powered by FluxBB