Laptop unresponsive on lid close

Square · 2013-12-03 11:44:08

This is driving me mad! I'm using a rather old laptop - Dell Lattitude X300 - and the hinge is rather loose... so the lid likes to fall closed sometimes. When the lid closes, I get a completely unresponsive system upon opening it. If I'm in a VT, the screen is lit up but black and unresponsive. If I'm in X, I get a black screen with a pointer on it that is completely unresponsive.

I don't use acpid nor anything like it. In my /etc/systemd/logind.conf I have HandleLidSwitch set to ignore... I'm not sure what else to do at this point... I don't have any logs to show me where to look for the problem. Using xf86-video-intel with an Intel 82852/855GM integrated device (which has some issues).

EDIT: Just tested... cannot ssh access the machine, and an active ssh connection times out after lid close.

Any ideas?

Last edited by Square (2013-12-03 13:04:53)

ewaller · 2013-12-03 16:15:06

Look at /etc/systemd/loginctl.conf
Change the line:

#HandleLidSwitch=suspend

to

HandleLidSwitch=ignore

Don't forget to remove the hash sign.

Reboot.

Square · 2013-12-03 20:09:10

ewaller wrote:

Look at /etc/systemd/loginctl.conf
Change the line:
#HandleLidSwitch=suspend
to
HandleLidSwitch=ignore
Don't forget to remove the hash sign.
Reboot.

Did you... not read my post? This is already done. That's what's maddening.

EDIT: Btw... it's logind.conf, not loginctl.conf

Last edited by Square (2013-12-03 20:11:45)

cfr · 2013-12-03 20:45:15

Do the logs/journal show anything afterwards? (That is, can you find anything when you reboot?)

Can you kill X or switch to a tty?

Have you tried the sys req key?

Ploppz · 2013-12-03 21:02:54

I have slightly the same problem. Sometimes it works when I open the lid. Sometimes I have to wait around 20 seconds. Lately it has always hanged and last time, I got a kernel panic, and got told the error is in synaptics drivers... don't know where to ask now! http://i.imgur.com/ofGUCzs.jpg (really bad picture but it's all I have got)

(edit: this is fairly similar to _some_ instances of my problem but probably not yours: https://bugzilla.kernel.org/show_bug.cgi?id=60535)

Last edited by Ploppz (2013-12-03 21:17:40)

ewaller · 2013-12-03 21:39:49

Square wrote:

[Did you... not read my post? This is already done. That's what's maddening.

Guilty. But in my defense, I read that you did not have acpid or anything like it -- so I stopped reading. Sorry.

EDIT: Btw... it's logind.conf, not loginctl.conf

Guilty. No defense; just not enough coffee

Any chance you are running a desktop environment that tries to manage power (Kde, Gnome, xfce4?)

Square · 2013-12-04 11:43:20

ewaller wrote:

Square wrote:
[Did you... not read my post? This is already done. That's what's maddening.
Guilty. But in my defense, I read that you did not have acpid or anything like it -- so I stopped reading. Sorry.
EDIT: Btw... it's logind.conf, not loginctl.conf
Guilty. No defense; just not enough coffee

Any chance you are running a desktop environment that tries to manage power (Kde, Gnome, xfce4?)

Fair enough

I'm not using a DE or anything additional on my system. I keep it simple... startx into xmonad. I cannot switch to a tty or get any responses out of my system at all... Like I said, an active ssh connection will completely time out when I close the system. I cannot type blindly into the system and get any response... There is nothing in my logs to point me in any direction. It seems as though it is instantly freezing with no time for anything as soon as the lid shuts. No kernel panic... no errors... nothing...

I don't understand first and foremost why, if the lid switch is being ignored... it would be doing anything in the first place.

EDIT: Found something in my logs after system has been running a while... perhaps related?

[ 1800.289873] INFO: task kworker/0:1:19 blocked for more than 120 seconds.
[ 1800.289884]       Not tainted 3.12.2-1-ARCH #1
[ 1800.289887] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 1800.289890] kworker/0:1     D 00000030     0    19      2 0x00000000
[ 1800.289907] Workqueue: kacpid acpi_os_execute_deferred
[ 1800.289911]  e6593cdc 00000046 c129e8b0 00000030 00000000 00000000 00000000 c1693ac0
[ 1800.289929]  ebfb073a 00000083 c1693ac0 e7181ac0 e64ae6f0 00000000 00000000 00000000
[ 1800.289937]  e6593cd4 e6593cc8 c12b0d85 00000001 00000000 000000ff 00000008 e681f57c
[ 1800.289946] Call Trace:
[ 1800.289957]  [<c129e8b0>] ? acpi_ex_access_region+0x1f0/0x279
[ 1800.289965]  [<c12b0d85>] ? acpi_ut_repair_name+0x24/0x77
[ 1800.289970]  [<c128aea9>] ? acpi_os_release_lock+0xd/0xf
[ 1800.289979]  [<c142f753>] schedule+0x23/0x60
[ 1800.289984]  [<c142c705>] schedule_timeout+0x1b5/0x210
[ 1800.289990]  [<c12ae8b6>] ? acpi_ut_update_object_reference+0xec/0x159
[ 1800.289995]  [<c142ebcf>] __down_timeout+0x4c/0x77
[ 1800.290003]  [<c1067eae>] down_timeout+0x3e/0x50
[ 1800.290025]  [<c128ae21>] acpi_os_wait_semaphore+0x39/0x4d
[ 1800.290031]  [<c12a2b60>] acpi_ex_system_wait_semaphore+0x38/0x48
[ 1800.290036]  [<c12a2c6e>] acpi_ex_system_wait_event+0x1a/0x20
[ 1800.290040]  [<c12a0957>] acpi_ex_opcode_2A_0T_1R+0xc7/0x150
[ 1800.290046]  [<c1298b34>] acpi_ds_exec_end_op+0xc4/0x3a8
[ 1800.290053]  [<c12a979b>] ? acpi_ps_complete_op+0x1c9/0x1db
[ 1800.290058]  [<c12a928b>] acpi_ps_parse_loop+0x497/0x4d4
[ 1800.290063]  [<c12b086c>] ? acpi_ut_create_generic_state+0x32/0x4c
[ 1800.290069]  [<c12a9be6>] acpi_ps_parse_aml+0x8a/0x23c
[ 1800.290075]  [<c12aa34a>] acpi_ps_execute_method+0x19e/0x23c
[ 1800.290080]  [<c12a5434>] acpi_ns_evaluate+0x1b8/0x243
[ 1800.290086]  [<c129a20b>] ? acpi_ev_asynch_execute_gpe_method+0x113/0x18b
[ 1800.290091]  [<c129a220>] acpi_ev_asynch_execute_gpe_method+0x128/0x18b
[ 1800.290097]  [<c128a48b>] acpi_os_execute_deferred+0x20/0x2b
[ 1800.290103]  [<c105cf07>] process_one_work+0x107/0x380
[ 1800.290108]  [<c105d761>] worker_thread+0x101/0x340
[ 1800.290113]  [<c105d660>] ? manage_workers.isra.26+0x250/0x250
[ 1800.290118]  [<c1062d34>] kthread+0x94/0xa0
[ 1800.290124]  [<c1060000>] ? task_work_cancel+0x30/0x70
[ 1800.290131]  [<c1437637>] ret_from_kernel_thread+0x1b/0x28
[ 1800.290136]  [<c1062ca0>] ? kthread_create_on_node+0xc0/0xc0

Last edited by Square (2013-12-04 11:54:21)

Neitsab · 2013-12-05 15:38:27

As I was investigating a similar issue (systematic kernel panic/oops when resuming from suspend to RAM on my laptop, a Clevo W540EU), I stumbled upon this tread from the kernel mailing list. It seems that an update to the rtxs driver (realtek PCIe card) between kernel 3.11 and 3.12 messes up with acpi, even without using it.

You'll see that in the last post the problem has been isolated and a patch is proposed, but I was wondering: how long will it take to arrive in Arch repos? Will it be with a new kernel version, or is it within a specific driver package? It is really problematic not to be able to suspend, so I'm wondering whether I should learn to apply a patch and compile kernel myself...

Cheers

Square · 2013-12-06 06:05:23

Neitsab wrote:

As I was investigating a similar issue (systematic kernel panic/oops when resuming from suspend to RAM on my laptop, a Clevo W540EU), I stumbled upon this tread from the kernel mailing list. It seems that an update to the rtxs driver (realtek PCIe card) between kernel 3.11 and 3.12 messes up with acpi, even without using it.
You'll see that in the last post the problem has been isolated and a patch is proposed, but I was wondering: how long will it take to arrive in Arch repos? Will it be with a new kernel version, or is it within a specific driver package? It is really problematic not to be able to suspend, so I'm wondering whether I should learn to apply a patch and compile kernel myself...
Cheers

I'm not sure how this applies then... as my issue occurs without using suspend...

Unless systemd is failing to ignore the lid and trying to suspend... in which case I'd really like to know why or how.

Last edited by Square (2013-12-06 06:06:57)

CESAR · 2023-04-09 00:10:05

Square wrote:

ewaller wrote:
Look at /etc/systemd/loginctl.conf
Change the line:
#HandleLidSwitch=suspend
to
HandleLidSwitch=ignore
Don't forget to remove the hash sign.
Reboot.
Did you... not read my post? This is already done. That's what's maddening.
EDIT: Btw... it's logind.conf, not loginctl.conf

Thanks, It works for me.
This is my system.

OS: Arch Linux x86_64
Host: HP Pavilion Gaming Laptop 15-cx0xxx
Kernel: 6.2.9-arch1-1
Uptime: 41 mins
Packages: 2109 (pacman)
Shell: fish 3.6.1
Resolution: 1920x1080
DE: Hyprland
WM: sway
Theme: Adwaita [GTK3]
Icons: Adwaita [GTK3]
Terminal: tmux
CPU: Intel i5-8300H (8) @ 2.300GHz
GPU: Intel CoffeeLake-H GT2 [UHD Graphics 630]
GPU: NVIDIA GeForce GTX 1050 Mobile
Memory: 2165MiB / 7834MiB

Arch Linux

#1 2013-12-03 11:44:08

Laptop unresponsive on lid close

#2 2013-12-03 16:15:06

Re: Laptop unresponsive on lid close

#3 2013-12-03 20:09:10

Re: Laptop unresponsive on lid close

#4 2013-12-03 20:45:15

Re: Laptop unresponsive on lid close

#5 2013-12-03 21:02:54

Re: Laptop unresponsive on lid close

#6 2013-12-03 21:39:49

Re: Laptop unresponsive on lid close

#7 2013-12-04 11:43:20

Re: Laptop unresponsive on lid close

#8 2013-12-05 15:38:27

Re: Laptop unresponsive on lid close

#9 2013-12-06 06:05:23

Re: Laptop unresponsive on lid close

#10 2023-04-09 00:10:05

Re: Laptop unresponsive on lid close

Board footer