[SOLVED] Suspend Broke after update Slackware64-Current

Grifulkin · 06-25-2013, 04:01 PM

So last night I updated my computer. I just did a slackpkg update slackpkg upgrade-all and let it run.

Fixed what I had to fix as I'm running on an LVM.

But after I get it all fixed and restart, suspend no longer works.

I get no errors just

Code:

root@Slackware:/home/ryan# pm-suspend
root@Slackware:/home/ryan#

.

I can show you anything extra you might need just let me know.

And thank you in advance.

Darth Vader · 06-25-2013, 04:31 PM

Well, well, well...

When P.V. built the latest update to pm-utils, believed that everyone use bluetoth...

Then, look to the shiny /etc/rc.d/rc.bluetoth, make it executable, activate it with the parameter start, and... voila! Your suspend is back.

If you ask WTF have to do bluetoth with suspend, I will respond that something is wrong with rfkill now...

Grifulkin · 06-25-2013, 04:35 PM

Quote:

Originally Posted by Darth Vader

Well, well, well...

When P.V. built the latest update to pm-utils, believed that everyone use bluetoth...

Then, look to the shiny /etc/rc.d/rc.bluetoth, make it executable, activate it with the parameter start, and... voila! Your suspend is back.

If you ask WTF have to do bluetoth with suspend, I will respond that something is wrong with rfkill now...

Thank you very much. I never would have figured that out.

yenn · 06-25-2013, 05:00 PM

That's weird. Hibernation/suspend still works for me after last update, I just don't use pm-suspend. With UPower + D-Bus combo it works like a charm.

Chuck56 · 06-26-2013, 05:48 PM

I also ran into suspend/hibernate not working after the Sun 6/23 -current updates. After making /etc/rc.d/rc.bluetooth exacutable and running "/etc/rc.d/rc.bluetooth start" fixed suspend/hibernate.

rworkman · 06-27-2013, 03:50 PM

None of the bluetooth-related stuff was touched in that pm-utils update, so it's unclear to me as to how it's relevant. Since you're going to respond with something about rfkill, I'll point out that it wasn't touched either. Now, if you can provide a pm-suspend.log or something similar that will show me what I need to change to actually fix this (as opposed to papering over it by starting rc.bluetooth), then I'll be more than happy to do that. Snide remarks about what we did or didn't assume aren't helpful.

rworkman · 06-27-2013, 04:09 PM

Remove /usr/lib(64)/pm-utils/sleep.d/49bluetooth-generic and see if that helps. It looks like the kernel handles bluetooth suspend/resume just fine on its own now.

Darth Vader · 06-27-2013, 04:51 PM

Robby, without the activation of rc.bluetooth, we have in /var/log/pm-suspend.log

Code:

<SNIP>
ehci_hcd               34730  1 ehci_pci
xhci_hcd               79520  0
ums_cypress             2480  0
usb_storage            36311  1 ums_cypress
             total       used       free     shared    buffers     cached
Mem:       4144716    1731372    2413344          0      80252     532084
-/+ buffers/cache:    1119036    3025680
Swap:      3911820          0    3911820
/usr/lib/pm-utils/sleep.d/00logging hibernate hibernate: success.

Running hook /usr/lib/pm-utils/sleep.d/00powersave hibernate hibernate:
/usr/lib/pm-utils/sleep.d/00powersave hibernate hibernate: success.

Running hook /usr/lib/pm-utils/sleep.d/01grub hibernate hibernate:
/usr/lib/pm-utils/sleep.d/01grub hibernate hibernate: not applicable.

Running hook /etc/pm/sleep.d/01lilo hibernate hibernate:
/etc/pm/sleep.d/01lilo hibernate hibernate: success.

Running hook /usr/lib/pm-utils/sleep.d/49bluetooth-generic hibernate hibernate:
Can't open RFKILL control device: No such file or directory
/usr/lib/pm-utils/sleep.d/49bluetooth-generic hibernate hibernate: Returned exit code 1.

Thu Jun 27 23:41:56 CEST 2013: Inhibit found, will not perform hibernate
Thu Jun 27 23:41:56 CEST 2013: Running hooks for thaw
Running hook /etc/pm/sleep.d/01lilo thaw hibernate:
/etc/pm/sleep.d/01lilo thaw hibernate: not applicable.

Running hook /usr/lib/pm-utils/sleep.d/01grub thaw hibernate:
/usr/lib/pm-utils/sleep.d/01grub thaw hibernate: not applicable.

Running hook /usr/lib/pm-utils/sleep.d/00powersave thaw hibernate:
/usr/lib/pm-utils/sleep.d/00powersave thaw hibernate: success.

Running hook /usr/lib/pm-utils/sleep.d/00logging thaw hibernate:
/usr/lib/pm-utils/sleep.d/00logging thaw hibernate: success.

I tried to manual execute the command from /usr/lib/pm-utils/sleep.d/49bluetooth-generic

Code:

bash-4.2# rfkill block bluetooth
Can't open RFKILL control device: No such file or directory
bash-4.2# rfkill unblock bluetooth
Can't open RFKILL control device: No such file or directory

Seems like pm-utils do not like the rfkill return code.

WHEN you start the /usr/sbin/bluetoothd via /etc/rc.d/rc.bluetoth, everything is OK.

Sadly, I'm very busy these days then I don't have time to do debugging on that problems...

But, In my honest opinion is something about an little incompatibility of current rfkill and current kernel. Or, maybe an kernel module is not loaded right in demand?

BTW, after making a short diff of modules loaded before and after execution of bluetoothd, we have:

Code:

bash-4.2# diff  lsmod1.txt lsmod2.txt
1a2,5
> rfcomm                 27836  4
> bnep                    8821  2
> bluetooth             188638  10 bnep,rfcomm
> rfkill                 12578  2 bluetooth

Then, bluetoothd loads some modules...

And, last, an brute force, but working, patch for 49bluetooth-generic

Code:

bash-4.2# diff -uN 49bluetooth-generic.orig 49bluetooth-generic
--- 49bluetooth-generic.orig    2013-06-23 21:26:34.000000000 +0200
+++ 49bluetooth-generic 2013-06-28 00:04:26.987886416 +0200
@@ -4,10 +4,10 @@

 case "$1" in
   hibernate|suspend)
-    rfkill block bluetooth
+    rfkill block bluetooth || true
    ;;
   thaw|resume)
-    rfkill unblock bluetooth
+    rfkill unblock bluetooth || true
     ;;
   *) exit $NA
     ;;

volkerdi · 06-27-2013, 05:21 PM

The problem seems to be with the 49bluetooth-generic hook. I'm a bit confused as to why this just became a problem, since the hook didn't change with the latest update to pm-utils.

My machine has a bluetooth USB dongle, but I don't use bluetooth much so my rc.bluetooth isn't executable. Nevertheless, pm-suspend worked fine here. But, when I removed the dongle and rebooted, I found that pm-suspend failed, and that starting rc.bluetooth would allow it to work. The reason is that running rc.bluetooth loads the bluetooth module, which causes the rfkill module to be loaded. This avoids the failure when rfkill is called by the hook.

The solution seems to be making the hook a little more robust about dealing with cases where either the rfkill binary is missing or the kernel lacks support for rfkill:

Code:

#!/bin/sh

. "${PM_FUNCTIONS}"

case "$1" in
  hibernate|suspend)
    if [ -d /sys/devices/virtual/misc/rfkill -a -x /usr/sbin/rfkill ]; then
      rfkill block bluetooth
    fi
   ;;
  thaw|resume)
    if [ -d /sys/devices/virtual/misc/rfkill -a -x /usr/sbin/rfkill ]; then
      rfkill unblock bluetooth
    fi
    ;;
  *)
    ;;
esac

Darth Vader · 06-27-2013, 05:32 PM

I tested your new script and it works like a charm in a not-bluetooth-loaded machine, which previous has this illness.

Also, I agree with the consolidation of dealing with different cases.

volkerdi · 06-27-2013, 05:34 PM

Just to be completely correct, I'm also going to add a test for -a -x /etc/rc.d/rc.bluetooth to avoid needlessly blocking/unblocking on machines where rc.bluetooth is not executable. Update coming soon.

Darth Vader · 06-27-2013, 05:59 PM

Thanks, and I have another suggestion about pm-utils...

How about an new script/hook to ensure that LILO will load the correct kernel on resume from hibernate, something like we have (ironic!) for GRUB?

There is /usr/lib/pm-utils/sleep.d/01lilo.

Code:

#!/bin/sh
# Ensure LILO will load the correct kernel on resume from hibernate.

default_resume_kernel()
{
        [ "$1" = "suspend" ] && return $NA
        case $(uname -m) in
                i?86 | x86_64 | athlon )
                        ;;
                * ) # this is only valid for x86 and x86_64
                        return $NA
                        ;;
        esac

        current=`sed -e 's/^.*BOOT_IMAGE=\([^ ]\+\).*$/\1/' < /proc/cmdline`

        lilo -R ${current} && return 0

        return 1
}

case "$1" in
        hibernate | suspend )
                default_resume_kernel $2
                ;;
        *)
                exit $NA
                ;;
esac

volkerdi · 06-27-2013, 06:05 PM

Quote:

Originally Posted by Darth Vader

Thanks, and I have another suggestion about pm-utils...

How about an new script/hook to ensure that LILO will load the correct kernel on resume from hibernate, something like we have (ironic!) for GRUB?

If anything, that GRUB hook should go.

Darth Vader · 06-27-2013, 06:15 PM

Quote:

Originally Posted by volkerdi

If anything, that GRUB hook should go.

Yeah, thinking that GRUB is not one of Slackware bootloaders, you are probably right, but, talking about that LILO hook, what it make is that at (re)boot, LILO will bypass its boot menu and it will boot directly the resumed kernel.

On an multi-kernel environment, that thing become very handy, avoiding your remembering what kernel was used last time and is also a method to improve the safety of already mounted partitions on a multiboot/multi-OS system.

volkerdi · 06-27-2013, 06:33 PM

Quote:

Originally Posted by Darth Vader

Yeah, thinking that GRUB is not one of Slackware bootloaders, you are probably right, but, talking about that LILO hook, what it make is that at (re)boot, LILO will bypass its boot menu and it will boot directly the resumed kernel.

On an multi-kernel environment, that thing become very handy, avoiding your remembering what kernel was used last time and is also a method to improve the safety of already mounted partitions on a multiboot/multi-OS system.

I can hear it now:

"When P.V. built the latest update to pm-utils, he believed that everyone uses LILO..."