Suspension of the system and blocking of peripherals.

Forum Forums New users New Users and General Questions Suspension of the system and blocking of peripherals.

  • This topic has 13 replies, 3 voices, and was last updated Jul 7-5:36 pm by slickowl.
Viewing 14 posts - 1 through 14 (of 14 total)
  • Author
    Posts
  • #37254
    Member
    slickowlslickowl

    Hello antiX community

    I would like to learn more about this version of Linux and I have encountered some problems that I have been fixing. However, I don’t hit the key with this.

    I’m using 19.2 32-bit version on an EXO Mate X352 netbook with 2GB of RAM. Without hard drive, therefore, I run the system from a 4GB USB drive, with persistent mode.

    The point is that when hibernating the system (lowering the drive cover) and then restoring it, the return is “no mouse”.

    I have tried some solutions, but none has given a satisfactory result, among them, a recommendation to execute the following command [ sh -c ‘echo -n “exps” > protocol ] before the restoration and indeed works, but the return is “without keyboard”.
    To fix the keyboard crash problem I have seen those who have successfully used this command [ GRUB_CMDLINE_LINUX_DEFAULT”quiet splash atkbd.reset” ] on Ubuntu distributions, so I do not know if it will work in antiX, a derivative of Debian. This also requires modifying the Grub. And here I find another pitfall. By modifying the Grub files, I find that I cannot update it, I fail the [ update-grub ] or [ update-grub2 ] command.

    The sequence with which I try to fix the mouse problem is as follows:

    sudo gedit /etc/default/grub

    Change the line:
    GRUB_CMDLINE_LINUX_DEFAULT”quiet splash”
    By:
    GRUB_CMDLINE_LINUX_DEFAULT”quiet splash psmouse.proto-exps”
    Save

    sudo update-grub

    Reboot

    I do not get to reboot, because when I run the [ update-grub ] I receive the following error message:
    /usr/sbin/grub-probe: error: failed to get canonical path of ‘overlay’

    I have also read that it is not possible to make modifications to Grub while working in Persistence mode on a flash memory.

    Any ideas so they can help me?

    Thank you.

    #37256
    Member
    XecureXecure

    If it was me, I would use Suspend instead of hibernate, as suspends keeps things in RAM when “going to sleep”, while hibernate saves them in disk. With only 4 GB of space in your USB, (I don’t know if you also have swap in this same USB), you are a bit limited. Anyway, as using this option may be indespensable for you, I will just trust it is something needed. I missread. sorry. You are using suspend.

    For editing boot parameters in live systems, you need to edit: /live/boot-dev/boot/grub/grub.cfg
    Under your Custom entry, change the boot parameters there. Save persistent changes and reboot (no update grub needed).

    EDIT: I searched, for the specific problem, and it seems that after waking up, the system changes the controller for the mouse/touchpad.
    Your sugestion of editing the boot parameter should work.
    quiet splash psmouse.proto=exps
    should set the mouse to keep this controller “exps” running.

    • This reply was modified 1 month, 3 weeks ago by Xecure.
    #37936
    Member
    slickowlslickowl

    Hi.
    Xecure, thanks for your reply.
    I have added to grub.cfg the line [GRUB_CMDLINE_LINUX_DEFAULT = “quiet splash psmouse.proto = exps”], as you indicate in your suggestion.
    It works indeed, when you lift the netbook cover back up, the touchpad / mouse works, but there is no video signal, and you just get a beautiful white arrow wandering around a horrible black screen.
    If there is any other suggestion to try it will be welcome.
    Thank you.

    #37938
    Member
    XecureXecure

    Please post here the result of executing in a terminal
    inxi -Fxz
    and we may be able to better assess the video problem.

    #38194
    Member
    slickowlslickowl

    Hi, this is the output of the [inxi -Fxz] command:

    System:
    Host: antix1 Kernel: 4.9.212-antix.1-486-smp i686 bits: 32 compiler: gcc
    v: 8.3.0 Desktop: IceWM 1.6.5
    Distro: antiX-19.2_386-full Hannie Schaft 27 March 2020
    base: Debian GNU/Linux 10 (buster)
    Machine:
    Type: Other-vm? System: EXO product: Exomate X352 v: MP PV
    serial: <filter>
    Mobo: Intel model: Intel powered classmate PC v: MP PV serial: <filter>
    BIOS: Phoenix v: MPPNV10A.86A.001F.2010.0308.1453 date: 03/08/2010
    Battery:
    ID-1: BAT1 charge: 29.9 Wh condition: 42.1/47.5 Wh (89%) model: ECS CMPC
    status: Discharging
    CPU:
    Topology: Single Core model: Intel Atom N450 bits: 64 type: MT
    arch: Bonnell rev: A L2 cache: 512 KiB
    flags: lm nx pae sse sse2 sse3 ssse3 bogomips: 6650
    Speed: 1000 MHz min/max: 1000/1667 MHz Core speeds (MHz): 1: 1000 2: 1000
    Graphics:
    Device-1: Intel Atom Processor D4xx/D5xx/N4xx/N5xx Integrated Graphics
    vendor: Elite Systems driver: i915 v: kernel bus ID: 00:02.0
    Display: x11 server: X.Org 1.20.4 driver: intel
    unloaded: fbdev,modesetting,vesa resolution: 1024×600~60Hz
    OpenGL: renderer: Mesa DRI Intel Pineview M x86/MMX/SSE2
    v: 1.4 Mesa 18.3.6 direct render: Yes
    Audio:
    Device-1: Intel NM10/ICH7 Family High Definition Audio
    vendor: Elite Systems driver: snd_hda_intel v: kernel bus ID: 00:1b.0
    Sound Server: ALSA v: k4.9.212-antix.1-486-smp
    Network:
    Device-1: Realtek RTL8101/2/6E PCI Express Fast/Gigabit Ethernet
    vendor: Elite Systems RTL810xE driver: r8169 v: 2.3LK-NAPI port: 2000
    bus ID: 07:00.0
    IF: eth0 state: down mac: <filter>
    Device-2: Realtek RTL8191SEvB Wireless LAN driver: rtl8192se v: kernel
    port: 3000 bus ID: 09:00.0
    IF: wlan0 state: up mac: <filter>
    Drives:
    Local Storage: total: 3.61 GiB used: 22.5 MiB (0.6%)
    ID-1: /dev/sda type: USB vendor: Verbatim model: MICRO PLUS size: 3.61 GiB
    Partition:
    ID-1: / size: 1.54 GiB used: 22.5 MiB (1.4%) fs: overlay source: ERR-102
    Sensors:
    System Temperatures: cpu: 30.0 C mobo: N/A
    Fan Speeds (RPM): N/A
    Info:
    Processes: 125 Uptime: 2m Memory: 1.96 GiB used: 118.8 MiB (5.9%)
    Init: SysVinit runlevel: 5 Compilers: gcc: 8.3.0 Shell: bash v: 5.0.3
    inxi: 3.0.36

    #38197
    Member
    XecureXecure

    Graphics:
    Device-1: Intel Atom Processor D4xx/D5xx/N4xx/N5xx Integrated Graphics
    vendor: Elite Systems driver: i915 v: kernel bus ID: 00:02.0
    Display: x11 server: X.Org 1.20.4 driver: intel

    I can only think of two possibilities.
    1. One of the video drivers changes to a different one when waking up, as experienced with the mouse issue.
    Testing this is easy. Start your netbook. Wait for it to settle, then close the lid, wait for it to suspend, and lift up the lid and wake the machine.
    On the keyboard, do Control+Alt+F1, log in there with your user account and see if the drivers have changed with
    inxi -G
    If the drivers do change, the device driver (i915) or xorg driver (intel) will have changed.

    2. On waking up, the system is trying to resume with a different resolution, and that leads to the black screen.
    This could be tested by adding a boot parameter to force a screen resolution, but I am not sure how this is done exactly. It could be something like
    video=1024×600
    but I am not sure if this works exactly as I suggest.

    Hopefully we can get some extra help.

    #38326
    Member
    slickowlslickowl

    Xecure, thanks for your reply.

    I have used the command that you indicate and this is its result:

    before suspending

    inxi -G
    Graphics:
    Device-1: Intel Atom Processor D4xx / D5xx / N4xx / N5xx Integrated Graphics
    driver: i915 v: kernel
    Display: x11 server: X.Org 1.20.4 driver: intel
    unloaded: fbdev, modesetting, vesa resolution: 1024×600 ~ 60Hz
    OpenGL: renderer: DRI table Intel Pineview M x86 / MMX / SSE2
    v: 1.4 Table 18.3.6

    after suspending

    inxi -G
    Graphics:
    Device-1: Intel Atom Processor D4xx / D5xx / N4xx / N5xx Integrated Graphics
    driver: i915 v: kernel
    Display: server: X.Org 1.20.4 driver: intel
    unloaded: fbdev, modesetting, vesa tty: 123×31
    Message: Advanced graphics data unavailable in console. Try -G –display

    Well, after this when executing inxi -G –display the system that gives an infinite lethargy of which it is necessary to return with ctrl-alt-del (I did not try ctrl + c, now that I think about it). However, going back to testing with ctrl-alt-F1 and with the cursor ready, I run “statx” and the desktop reacts, although with a somewhat strange behavior, for example:
    1.- the task bar is perfect
    2.- the desktop does not display the background that I have placed (it is completely black)
    3.- the icons are not found in it
    4.- conky does not load
    5.- the mouse arrow disappears, but appears when you move it

    Strange, right?

    I have seen this in the grub.cfg:

    # search –no-floppy –set = root –fs-uuid% UUID%
    set timeout = 60
    set gfxmode = 1024×768
    #set gfxpayload = “3200×1800; 2560×1440; 2160×1440; 1920×1080; 1600×1200; 1600×1050; 1600×900; 1440×900; 1366×768; 1280×1024; 1280×800; 1280×720; 1024×768; auto”
    set gfxpayload = “2048×2048; 2048×1280; 2048×1080; 1920×1080; 1600×900; 1600×1200; 1600×1050; 1500×1000; 1440×960; 1440×900; 1368×912; 1366×768; 1280×800; 1280×720; 1280×1024; 1200×800; 1024×768; auto”
    set default = 1
    .
    .
    .
    menuentry “antiX-19.2 386-full (1024×768)” {
    linux / antiX / vmlinuz blab = UUI quiet splasht disable = lxF
    initrd /antiX/initrd.gz
    }

    Here the configuration indicates 1024×768, different from the 1024×600 in which the system is supposedly running. I don’t know if this is some relevant information though.

    Thanks for your collaboration, I will continue to investigate.

    #38332
    Member
    XecureXecure

    This problem may take some time to solve (if possible), so we will have to test many things.

    If instead of closing the lid, you hit Suspend (in the Menu > Logout, select Suspend), and then press a key to wake up, does the issue also ocurre? If it does, maybe the

    You could test changing the set gfxmode = 1024×768 to your resolution of 1024×600, as you sugest, and see if this helps, but I suspect this is only for the bootscreen and will not be carried to the main system.
    Then, you can test adding the boot parameter video=1024×600 at the end of the Custom line (as you did with the psmouse.proto=exps).

    The users with same grahic card and that experienced the same issues some never reported if they found a fix (like this one), but some said that a kernel update fixed their problems.

    When you have time, attach the file /var/log/pm-suspend.log (if the forum software doesn’t let you upload it, compress it to a .zip file first). Maybe we can find something there.

    Edit: found someone with the same hardware and issue filed a bug report for Ubuntu (https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1094509). It was never resolved (at least there is no followup).

    #38362
    Moderator
    masinickmasinick

    I hope that you find a successful solution to this issue. Even though it’s not very satisfying right now, it appears that you have learned several useful diagnosis techniques.

    Keep up the good work. I’m positive that it will be helpful. Hopefully it’ll result in a solution to this issue. Even if not, you have shared useful information with others and are honing your system administration skills!

    Brian Masinick

    #38380
    Member
    slickowlslickowl

    Well, Xecure, these are the news: we have made progress.

    I have followed some guidelines that you have raised.

    Instead of suspending the system with the cover of the notebook, I did it with the sequence that you indicate and I also run out of mouse, but here is the burena news, there is no longer a black screen dominating the system, but everything is there and i can work antiX with keyboard. This led me to try modifying grub.cfg with the lines: gfxmode = 1024 × 600 and video = 1024 x 600. But here I was struck by the fact that from the graphical environment (nor with geany, leafpad, nano) it could not do it despite being as root. So I opened a console and edited grub.cfg with VIM and launched a reboot (thanks to Pat’s Slackware, for this knowledge). However, the issue of suspending from the menu again after the grub file changes and restarting remained unchanged.

    At this point, I took a look at the link you sent me about a similar bug in the Ubuntu distro. Although it has no answers and is currently unsolvable (and that practically 8 years have passed !!), there was one detail that aroused my attention: the word “modules” in two lines. Although it does not allude to our problem in question, it gave me an idea: “What would happen if I downloaded and reloaded the mouse module?”

    Okay. I rebooted the system to make it clean. I suspended antiX from the Logout menu. I woke up the system, of course, as I said without a mouse, but with video and keyboard. I accessed a terminal and ran the following: [modprobe -r psmouse] to disable the mousepad and then [modprobe -i psmouse] to reactivate it and “voila”, I had video, keyboard and mouse, as if nothing had happened.

    I think this is far from an optimal solution, but it works. We would have to find a way to solve it in a more elegant way, don’t you think?
    Regarding the possibility of updating the kernel, I do not know if it is viable if I am working from a USB memory. On the other hand, in the link that you indicate the user says to work with a 3.5.0 kernel and currently I am working with a 4.9.212 kernel. Or maybe you mean, not the version but the type of kernel?
    Anyway, I’ve been thinking that maybe the lack of hard disk and a swap partition could be a problem for antiX to work optimally and this is the origin of the problem when suspending the system. However, I am happy with this solution that I have found and that you have selflessly helped. Although perhaps a better solution appears, it has been a great advance, don’t you think?

    I attach the log file that you indicate, in case it is useful.

    Thanks for your great help.

    A cordial greeting.

    Slickowl.

    VIM (Vi IMproved)

    Attachments:
    #38414
    Member
    XecureXecure

    Unfortunately, it seems the logs are only for this session, and not for the one where you close the lid.

    The ideal thing would be to make the “close lid behavior” work exactly the same as suspend/wake.

    I won’t have much time to look into this this weak, so I will give you all my suggestions.

    Add hook to suspend/resume
    If you are going to use (Suspend) and then close the lid, you can always (with root privileges) create a file in /usr/lib/pm-utils/sleep.d/ with a name like 0000trackpad
    and add this code:

    #!/bin/sh
    case "$1" in
    	suspend|hibernate)
    		modprobe -r psmouse
    		;;
    	resume|thaw)
    		modprobe psmouse
    		;;
    esac

    then make it executable
    sudo chmod +x /usr/lib/pm-utils/sleep.d/0000trackpad

    Updating the kernel
    About updating the kernel, it can be done on a live system. I would first back up the entire system though.
    The steps are the ones I follow whenever I update the kernel on my live-USB (there is a shorter way, but this is the one that always works for me.:
    1. download and install the latest 4.19 kernel using antiX package installer, synaptic or cli-aptiX
    2. Save persistent changes (I always like to do this) and reboot
    3. Remaster your antiX live system. Reboot
    4. Use the Live-USB Kernel Updater (can be found from the menu or from the control centre > Live).
    4.1 Select the kernel you want to update (4.19). Follow the steps. The reboot.
    5. If all goes well, your system will now boot with the new kernel. If it breaks, you can recover your system by accessing your live/boot-dev/antiX/ folder (from a different system I think) and renaming rootfs to rootfs.bac, rename linuxfs to linuxfs.bac, then restoring your linuxfs.old to linuxfs and rootfs.old to rootfs.
    It may sound a bit complicated, but it is not that bad. Anyway, if it seems too complicated and you don’t want to risk your live system then ignore this and try it out some other time in the future.

    Checking acpi-support
    About suspending by closing the lid, you need to check the file /etc/default/acpi-support. There is a line there that should be uncommented. It needs to look like this:
    LID_SLEEP=true
    I would comment out the hibernate option just in case that is the problem when closing the lid. It should look like:
    #ACPI_HYBERNATE=true

    If you find you need help, I am sure someone else can comment here while I am away. You could also wait or test things out to see how everything works (make sure to backup before experiments).

    Good luck!

    • This reply was modified 1 month ago by Xecure. Reason: correction
    • This reply was modified 4 weeks, 1 day ago by Xecure. Reason: error in code
    #38614
    Member
    slickowlslickowl

    Hello, Xecure.

    Well, here is the news:

    1) I have created the script file 0000trackpad, but unfortunately it has not worked. I have thought about this matter, I was interested in solving it this way, but unfortunately, I have not had positive results yet.

    2) With the kernel update there has been no luck either. Some errors arise during the time of installation, after downloading, of which I have not taken due note considering that it is perhaps the reason for another post and not the one in question. It is for these errors that when trying to update the live-usb the kernel is not listed to select it.

    3) Checking the acpi-support file that you indicate I have also made the necessary changes, once again without solution to the problem.

    I am currently using the stone-stone method [modprobe -i psmouse] from the console. Meanwhile, in time I will be looking for other alternatives.

    Well that’s it.

    Thank you for your support.

    #38630
    Member
    XecureXecure

    Sorry for writing the code wrong (I forgot a #!/bin/sh at the top of the line). Now it is fixed.

    If you created the 0000trackpad file (and realized the error in my code) and it didn’t work, you can check the /var/log/pm-suspend.log file (after testing a suspension) and see if the file 0000trackpad ever launches. If it does but still nothing happens, then I am out of ideas.

    I hope you can find the solution somewhere. Meanwhile, you can create a script (make executable) on your home folder, similar to:

    #!/bin/sh
    #reload module
    gksu modprobe -r psmouse
    sudo modprobe -i psmouse

    to automate the process of unloading/loading of the module (you can bind it to a key shortcut in ~/.icewm/keys to something like Control+Alt+M or any other free key combination).
    This way, after waking the laptop, you just need to hit the key combination, enter your password and the touchpad should recover.

    Let us know if you ever find a solution, so that others, if they ever encounter this problem, can make use of your research.

    #38640
    Member
    slickowlslickowl

    I have indeed created the file 0000trackpad with #! at the beginning of it.

    I’ve parsed the /var/log/pm-suspend.log file and found no trace of 0000trackpad running at any time.

    I am thinking that perhaps there is some other problem that is moving us away from the possible solution. Anyway, I have decided to leave this like this momentarily. If I find news, I will post it.

    Thanks for everything.

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