Close lid – laptop hangs

Forum Forums General Hardware Close lid – laptop hangs

  • This topic has 24 replies, 7 voices, and was last updated Jan 18-9:35 am by dortega.
Viewing 15 posts - 1 through 15 (of 25 total)
  • Author
    Posts
  • #45831
    Member
    dortega

    Hi.

    I have revived my old laptop (Dell D505) with antiX and it runs beautifully!
    I have a few problems with antiX so I will post several threads.
    I’m not new to linux but I’m not so good in getting around it when solving hardware issues and customizing.

    To the topic: Closing the laptop lid results in laptop hanging
    When I close the lid the system hangs with blank screen and a mouse pointer (not moving). I can’t do ctrl+alt+F1. CapsLock shows no light. System becomes unresponsive. I believe this is not Suspend mode because if I choose suspend from the menus the laptop suspends with power light blinking and comes back without a problem.
    I have read a couple of topics from other forums and also the antiX archives. There is one topic about it in the archive but it’s not applicable to the newer antiX versions. None of the solutions seem to work or I’m not able to find the config files needed in this system.

    How can I disable the action that happens when the close lid switch is on?

    #45834
    Member
    Xecure
    Helpful
    Up
    0
    :D

    Hi.

    Suspending seems to work for you, so maybe we could change the close-lid behavior.
    For now, try disabling the close lid suspend behavior just to see if it doesn’t lock after closing and opening the lid.
    If you have antiX 19.3 or antix 19.2 full, edit the file /etc/default/acpi-support and disable
    LID_SLEEP=false
    If running antiX 19.2.1 base, you first need to install acpi-support
    sudo apt install acpi-support

    There are a few threads related to lid sleep or suspend problems:
    https://www.antixforum.com/forums/topic/suspension-of-the-system-and-blocking-of-peripherals/
    https://www.antixforum.com/forums/topic/antix19-32bit-does-not-resume-from-suspend/
    https://www.antixforum.com/forums/topic/sleep-mode-on-laptop-after-closing-the-lid/#post-38546

    Also, when you can, provide us with hardware info
    inxi -Fxz

    #45883
    Member
    dortega
    Helpful
    Up
    0
    :D

    Thank you for helping.

    Yes, I remember trying to change this in acpi-support file
    LID_SLEEP=false
    It didn’t work. And it doesn’t work now. I did it right – I uncommented the line and changed to “false” then did a reboot. Even worse – somehow now my acpi-support file is blank! It wasn’t blank after the first reboot because I checked if the line remained the same. After the second reboot (reboot needed because I was checking if lid switch worked) I tried to press the lid switch WHILE the system was booting (and it hanged) – maybe it damaged the acpi-support file along the way (?)

    On GRUB the lid switch works. Screen blanks while the switch is pressed and then comes back.
    As soon as the kernel boots pressing the lid switch hangs the system to the same black screen with mouse pointer.

    Here is my system info:

    System:
    Host: dell Kernel: 4.9.212-antix.1-486-smp i686 bits: 32 compiler: gcc
    v: 8.3.0 Desktop: Fluxbox 1.3.7
    Distro: antiX-19.2_386-full Hannie Schaft 27 March 2020
    base: Debian GNU/Linux 10 (buster)
    Machine:
    Type: Portable System: Dell product: Latitude D505 v: N/A serial: <filter>
    Mobo: Dell model: 0H2049 serial: <filter> BIOS: Dell v: A11
    date: 11/03/2006
    CPU:
    Topology: Single Core model: Intel Pentium M bits: 32 type: MCP
    arch: M Banias rev: 5 L2 cache: 1024 KiB
    flags: sse sse2 bogomips: 2797
    Speed: 1400 MHz min/max: 600/1400 MHz Core speed (MHz): 1: 1400
    Graphics:
    Device-1: Intel 82852/855GM Integrated Graphics vendor: Dell Latitude D505
    driver: i915 v: kernel bus ID: 00:02.0
    Display: x11 server: X.Org 1.20.4 driver: intel
    unloaded: fbdev,modesetting,vesa resolution: 1024x768~60Hz
    OpenGL: renderer: Mesa DRI Intel 852GM/855GM x86/MMX/SSE2
    v: 1.3 Mesa 18.3.6 direct render: Yes
    Audio:
    Device-1: Intel 82801DB/DBL/DBM AC97 Audio vendor: Dell Latitude D505
    driver: snd_intel8x0 v: kernel bus ID: 00:1f.5
    Sound Server: ALSA v: k4.9.212-antix.1-486-smp
    Network:
    Device-1: Intel PRO/Wireless 2200BG [Calexico2] Network driver: ipw2200
    v: 1.2.2kmprq port: d080 bus ID: 01:03.0
    IF: eth1 state: up mac: <filter>
    Device-2: Intel 82801DB PRO/100 VE Ethernet vendor: Dell Latitude D500
    driver: e100 v: 3.5.24-k2-NAPI port: ecc0 bus ID: 01:08.0
    IF: eth0 state: down mac: <filter>
    Drives:
    Local Storage: total: 55.90 GiB used: 7.48 GiB (13.4%)
    ID-1: /dev/sda vendor: Samsung model: HM060HC size: 55.90 GiB
    Partition:
    ID-1: / size: 14.36 GiB used: 3.94 GiB (27.4%) fs: ext4 dev: /dev/sda1
    ID-2: /home size: 36.51 GiB used: 3.54 GiB (9.7%) fs: ext4 dev: /dev/sda2
    ID-3: swap-1 size: 3.91 GiB used: 0 KiB (0.0%) fs: swap dev: /dev/sda3
    Sensors:
    System Temperatures: cpu: 51.0 C mobo: N/A
    Fan Speeds (RPM): cpu: 2215
    Info:
    Processes: 148 Uptime: 1m Memory: 1.96 GiB used: 205.8 MiB (10.3%)
    Init: SysVinit runlevel: 5 Compilers: gcc: 8.3.0 Shell: bash v: 5.0.3
    inxi: 3.0.36

    #45889
    Member
    Xecure
    Helpful
    Up
    0
    :D

    This is really a strange experience.
    Try purging and reinstall acpi-support
    sudo apt purge acpi-support && sudo apt install acpi-support
    and see if you can edit it again.
    Try to re-enable lid_sleep and acpi_sleep and disable acpi_hibernate (comment it out). See if this helps after rebooting.

    #45890
    Member
    Xecure
    Helpful
    Up
    0
    :D

    I tried to press the lid switch WHILE the system was booting (and it hanged)

    On GRUB the lid switch works.

    I may be getting this wrong, but is this a switch that is pressed by the laptop when the lid goes down or is this the laptop’s power button?
    Sorry if this is a stupid question, but I have no experience with lid switches.

    #45892
    Member
    dortega
    Helpful
    Up
    0
    :D

    It’s a small switch located at the base of the screen/lid. When the lid closes it mechanically presses down on the switch. You can see the switch and press it with a finger.

    Look in this photo – the little thing sticking out under the lid
    http://assets.suredone.com/2306/media-photos/d4-0747-dell-latitude-d505-141-notebook-intel-pentium-m-160ghz-1gb-ram-dvd-no-hdd-5.jpg

    Maybe “lid switch” in acpi is not meant to be for this type of switch?

    #45893
    Member
    Xecure
    Helpful
    Up
    0
    :D

    Aaaah! Ok. Now I see it. I suppose this switch isn’t normally seen. But it should still have the same behavior as lid close.
    Maybe Brian Masinick or some other expert who has seen and used more computers than myself can clarify if this switch is also controlled by the lid_sleep acpi option.

    Thanks for sharing the picture and explanation.

    #45894
    Member
    dortega
    Helpful
    Up
    0
    :D

    Try to re-enable lid_sleep and acpi_sleep and disable acpi_hibernate (comment it out). See if this helps after rebooting.

    Tried this, nothing changes, it still hangs. I did successfully purge and reinstall acpi-support – thanks for including the commands.

    I will try some more things another day and report back..

    #45897
    Member
    Xecure
    Helpful
    Up
    0
    :D

    To try and guess what acpi event is called by the lid switch, open a terminal and run:
    acpi_listen >> acpi_listen.log
    This should save all acpi events as they occur in a file named acpi_listen.log in your home folder. When you hit the lid switch, it will register the event before freezing the computer. On the next reboot, you should be able to see what event is saved in the file and know what event is being called by the lid switch.
    From there we can be sure that the lid switch is really calling close lid event and maybe we can figure out how to change the instruction in /etc/acpi/events/

    Not much experience here. I tried stopping a power-button event in a cheap Chinese tablet I have and it worked. What didn’t work was me trying to make it launch an app instead of powering off the tablet (I wasn’t able to figure this out, so I disabled the acpi event).
    We could maybe be able to replace whatever event corresponds to the lid switch for a pm-suspend instruction.

    #45901
    Forum Admin
    rokytnji
    Helpful
    Up
    0
    :D

    If wanting to dig deeper.

    I usually google search with a line like

    lid freeze debian grep

    Maybe later insert laptop model number with search term.

    Older gear requires rolling your sleeves lately. Plug and play has left the building . Seems Covid moved in , in it’s place.

    http://forums.debian.net/viewtopic.php?f=7&t=73767

    Citatation: Link

    Sometimes I drive a crooked road to get my mind straight.
    Not all who Wander are Lost.
    I'm not outa place. I'm from outer space.

    Linux Registered User # 475019
    How to Search for AntiX solutions to your problems

    #45971
    Member
    dortega
    Helpful
    Up
    0
    :D

    Older gear requires rolling your sleeves lately. Plug and play has left the building . Seems Covid moved in , in it’s place.

    http://forums.debian.net/viewtopic.php?f=7&t=73767

    Hi and Thanks. Of course older gear always required workarounds. Hey – It’s an up-to-date system on a 2005 laptop – of course there’s going to be trouble with some things.
    I did stumble on this thread you linked when I first started to tackle the problem a month ago. I remember changing lid.sh values to disable action and also the other solution from that thread. It doesn’t work.

    The problem seems to be the lid button on this laptop is not registered as an acpi event but still manages to hang the system somehow. If you read on..

    To try and guess what acpi event is called by the lid switch, open a terminal and run:
    acpi_listen >> acpi_listen.log
    This should save all acpi events as they occur in a file named acpi_listen.log in your home folder. When you hit the lid switch, it will register the event before freezing the computer. On the next reboot, you should be able to see what event is saved in the file and know what event is being called by the lid switch.
    From there we can be sure that the lid switch is really calling close lid event and maybe we can figure out how to change the instruction in /etc/acpi/events/

    Great! I did the log pressed the button and after the reboot ..the log file was blank. The log file also didn’t register the power button that I pressed after the system hanged.
    On the next boot I tried just pressing the power button to see if the log works. And it works – this is the power button readout.

    button/power PBTN 00000080 00000000
    button/power PNP0C0C:00 00000080 00000001

    This says to me that my lid button is not even an acpi event. Any changes I made to acpi-support or lid.sh don’t affect this button. Am I thinking in the right way? But what makes the system hang then?

    #45986
    Member
    Xecure
    Helpful
    Up
    0
    :D

    Hi.

    This says to me that my lid button is not even an acpi event. Any changes I made to acpi-support or lid.sh don’t affect this button. Am I thinking in the right way?

    I think you are right. I found a very similar bug searching for “lid switch no acpi event” using google, happening a few years ago on different HP and Dell machines.
    Here is an example for a similar model to yours:
    https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1254131

    But what makes the system hang then?

    acpi doesn’t register the event, but the BIOS still does, and it tries to suspend without giving the correct instructions to linux to prepare everything needed to be able to restore after suspend.
    I haven’t found any solution except for someone who rebuilt a 3.XX kernel on fedora, but I am not sure this would also work on any of the antiX kernels.
    As a last test, you could install the latest 4.4 antiX kernel and see if this fix is present in that kernel version. If it isn’t, we would have to track what module must be included/disabled before compiling the kernel, but I am not sure if it is even present nowadays.

    Or maybe I wasn’t able to find a more recent post that 2015 because a newer kernel version has the fix? I am not confident on any of my assumptions.

    The best you can do is to continue with the workaround of suspending before closing the lid. Maybe one of the experts in the forum has a better suggestion and hint to a possible path for its resolution.

    • This reply was modified 6 months, 3 weeks ago by Xecure.
    #46066
    Member
    dortega
    Helpful
    Up
    0
    :D

    I understand the problem now, thank you. I will create a shortcut to suspend and hopefully remember to use it before I close the lid. Or physically remove the lid button.

    The thread you linked is right on the money (Dell D505) and I never found it myself.

    I doubt that the newest kernel will fix this. The kernel I’m currently running is new (or am I mistaken?). Certainly if the problem was fixed it would be fixed by now.

    I will report if I find a fix.
    Cheers!

    #46078
    Member
    Xecure
    Helpful
    Up
    0
    :D

    The thing with kernels is a bit complicated.
    antiX brings by default a 4.9 kernel, that has all security patches included, but has more support for older computers. New machines cannot boot with it because it doesn’t bring the new drivers and patches for new processors or very new motherboards, graphic cards, etc.
    For extremely old computers, the 4.4 kernel (also available in repos) seems to perform much better (also includes security patches), but is even less compatible with newer machines.
    Kernel 4.19 seems to be compatible with the wider number of machines. It usually can boot any computer more than 5 years old and even some new devices.
    Kernel 5.X is the newest available and supports the newest on the cutting edge hardware. Gives almost zero support for very old machines (depends on modules included), and is needed for very very recent machines.

    As you see, some patches may have been included in some versions or may be removed in others.
    The great variety of kernel options is to try to support as many devices as possible, each catering for different time frames.
    If there was only one big kernel, it would be as big as the whole antiX iso, and you would have to manually block some newer modules (or older ones) that bring updates for some devices that break others (regressions). It is too complicated to explain, and I am not an expert, so many things could be wrong.

    For now, continue with the work around. If you find something that works, let us know.

    If you see something else you would like to know or fix, come back and we will help as best we can.

    Regards.

    #46149
    Member
    seaken64
    Helpful
    Up
    0
    :D

    My experiences with some old hardware is that you may get different results with different kernels, different Window Managers or Desktops (try IceWM, JWM instead of Fluxbox), or different Distros (Slackware, Xubuntu, Puppy, etc.)

    It sounds like a kernel issue. I would first try all the kernels mentioned and even the MX AHS distro.

    Then change the desktops. Then start trying other distros. At some point maybe it will be too much trouble and you can instead use a work-around.

    Welcome to the antiX forum.

    Seaken64

Viewing 15 posts - 1 through 15 (of 25 total)
  • You must be logged in to reply to this topic.