Suspend and Hibernation Bugs

/sys/fs/bcache/register; echo /dev/sdb3 > /sys/fs/bcache/register", suspend to RAM failed to change the power state of the machine.

Hello there. I'm not sure if this is the appropriate venue, so please let me know if this information should be somewhere else. I have configured a Debian 7.0 installation on a Dell Inspiron 17R SE laptop to use a bcache root device. The previous known working configuration for the laptop was:

    /dev/sda (1TB HDD)
        ...
        /dev/sda7 (used as LUKS encrypted volume)
            /dev/mapper/sda7_crypt (used as LVM PV)
                /dev/vg0/home
                /dev/vg0/root
                ...
        /dev/sda8 (used as ext3 /boot)

The new configuration is

    /dev/sda (1TB HDD)
        ...
        /dev/sda7 (used as bcache backing device)
            /dev/bcache0 (used as LUKS encrypted volume)
                /dev/mapper/bcache_crypt (used as LVM PV)
                    /dev/vg0/home
                    /dev/vg0/root
                    ...
        /dev/sda8 (used as ext3 /boot)
    /dev/sdb (32GB SSD)
        ...
        /dev/sdb3 (used as bcache caching device)

In order to get things booting, I also:

* Installed a Linux 3.10 kernel from wheezy-backports (3.10-0.bpo.2-686-pae)
* Obtained a copy of the bcache-tools source from the git repo and compiled it
* Constructed a Debian package for bcache-tools using checkinstall
* Because udev recognition wasn't enough at boot time, added a script /etc/initramfs-tools/scripts/init-premount/z-bcache which looks like this:

Quoted 30 lines

Hello there. I'm not sure if this is the appropriate venue, so please let me know if this information should be somewhere else. I have configured a Debian 7.0 installation on a Dell Inspiron 17R SE laptop to use a bcache root device. The previous known working configuration for the laptop was:

     /dev/sda (1TB HDD)
         ...
         /dev/sda7 (used as LUKS encrypted volume)
             /dev/mapper/sda7_crypt (used as LVM PV)
                 /dev/vg0/home
                 /dev/vg0/root
                 ...
         /dev/sda8 (used as ext3 /boot)

The new configuration is

     /dev/sda (1TB HDD)
         ...
         /dev/sda7 (used as bcache backing device)
             /dev/bcache0 (used as LUKS encrypted volume)
                 /dev/mapper/bcache_crypt (used as LVM PV)
                     /dev/vg0/home
                     /dev/vg0/root
                     ...
         /dev/sda8 (used as ext3 /boot)
     /dev/sdb (32GB SSD)
         ...
         /dev/sdb3 (used as bcache caching device)

Quoted 7 lines

In order to get things booting, I also:

* Installed a Linux 3.10 kernel from wheezy-backports (3.10-0.bpo.2-686-pae)
* Obtained a copy of the bcache-tools source from the git repo and compiled it
* Constructed a Debian package for bcache-tools using checkinstall
* Because udev recognition wasn't enough at boot time, added a script /etc/initramfs-tools/scripts/init-premount/z-bcache which looks like this:

Just addressing the udev part; could you check with wipefs (nondestructive with no flags) that /dev/sda7 doesn't have an old non-bcache superblock?

There's been a transitional period when udev rules were stricter than what make-bcache created, which will be fixed with the patch at https://github.com/g2p/bcache-tools/commits.

Interesting; it does indeed have a stale header of some kind:

    zpalmer@thirtyseven:~$ sudo blkid /dev/sda7
    /dev/sda7: UUID="b56e8430-2594-436a-9fba-b91617cdaa5e" TYPE="crypto_LUKS"
    zpalmer@thirtyseven:~$ sudo /sbin/wipefs /dev/sda7
    offset               type
----------------------------------------------------------------
    0x0                  crypto_LUKS   [crypto]
                        UUID: b56e8430-2594-436a-9fba-b91617cdaa5e

But /dev/sda7 is a bcache backing volume.

    zpalmer@thirtyseven:~$ sudo probe-bcache /dev/sda7
    4b6ead1d-3341-407c-9e16-dd9e639268e4: UUID="" TYPE="bcache"

Doesn't bcache put its superblock in the first part of the block device? How is it possible that the device looks like a bcache backing volume and a LUKS encrypted volume at the same time? (For the record, I know that the LUKS volume identified above is the stale one; when I used LVM to move everything around, I created a fresh LUKS encrypted volume which has a different UUID than the old one shown above.)

Thanks,

Hello there. I'm not sure if this is the appropriate venue, so please let me know if this information should be somewhere else. I have configured a Debian 7.0 installation on a Dell Inspiron 17R SE laptop to use a bcache root device. The previous known working configuration for the laptop was:

    /dev/sda (1TB HDD)
        ...
        /dev/sda7 (used as LUKS encrypted volume)
            /dev/mapper/sda7_crypt (used as LVM PV)
                /dev/vg0/home
                /dev/vg0/root
                ...
        /dev/sda8 (used as ext3 /boot)

The new configuration is

    /dev/sda (1TB HDD)
        ...
        /dev/sda7 (used as bcache backing device)
            /dev/bcache0 (used as LUKS encrypted volume)
                /dev/mapper/bcache_crypt (used as LVM PV)
                    /dev/vg0/home
                    /dev/vg0/root
                    ...
        /dev/sda8 (used as ext3 /boot)
    /dev/sdb (32GB SSD)
        ...
        /dev/sdb3 (used as bcache caching device)

In order to get things booting, I also:

* Installed a Linux 3.10 kernel from wheezy-backports
(3.10-0.bpo.2-686-pae)
* Obtained a copy of the bcache-tools source from the git repo
and compiled it
* Constructed a Debian package for bcache-tools using checkinstall
* Because udev recognition wasn't enough at boot time, added a
script /etc/initramfs-tools/scripts/init-premount/z-bcache which looks like this:

            #!/bin/sh -e

            # ZEP - Added (2013-08-29) because some bcache devices

were not being detected
# at startup by udev. This sloppy hack should do
the job.

PREREQS=""

prereqs() { echo "$PREREQS"; }

case "$1" in
prereqs)
prereqs
exit 0
;;
esac

. /scripts/functions

if [ -e '/sys/fs/bcache/register_quiet' ]; then
log_begin_msg "Scanning for bcache devices..." for d in ls /dev/sd*; do
echo "$d" > /sys/fs/bcache/register_quiet
2>/dev/null || true
done
log_end_msg "bcache device scan complete"
else
log_warning_msg "/sys/fs/bcache/register_quiet not
found; not registering devices"
fi
* Executed update-initramfs -u -k all to get everything working

My machine boots from /dev/sda8 and the initramfs has enough machinery to get the root drive mounted. I was thrilled until I discovered that neither suspend nor hibernate seems to work; the suspend process seizes up while suspending devices and never comes back. I booted the laptop from a custom Debian live disk using the same kernel (3.10-0.bpo.2-686-pae) and performed a series of tests:

* When the bcache kernel module was not loaded, suspend to RAM
worked correctly.
* When the bcache kernel module was loaded but no devices were
registered, suspend to RAM worked correctly.
* When a single bcache device was registered using "echo
/dev/sda7 > /sys/fs/bcache/register; echo /dev/sdb3 > /sys/fs/bcache/register", suspend to RAM failed to change the power state of the machine.
* With a /dev/bcache0 device in use as an encrypted volume,
running "echo freezer > /sys/power/pm_test; echo platform > /sys/power/disk; echo disk > /sys/power/state" allows the machine to awaken from the test correctly.
* With a /dev/bcache0 device in use as an encrypted volume,
running "echo devices > /sys/power/pm_test; echo platform > /sys/power/disk; echo disk > /sys/power/state" causes the machine to hang.

Has suspend/hibernate been tested with bcache? Is it supported? I'm trying to figure out if it's my specific laptop hardware causing the issue or if bcache is somehow at fault. (Clearly, I can get suspend/hibernate back if I migrate back to using just my HDD, but caching blocks in a fashion designed for SSDs seems like such a lovely idea.)

Quoted 97 lines

Hello there. I'm not sure if this is the appropriate venue, so please let me know if this information should be somewhere else. I have configured a Debian 7.0 installation on a Dell Inspiron 17R SE laptop to use a bcache root device. The previous known working configuration for the laptop was:

     /dev/sda (1TB HDD)
         ...
         /dev/sda7 (used as LUKS encrypted volume)
             /dev/mapper/sda7_crypt (used as LVM PV)
                 /dev/vg0/home
                 /dev/vg0/root
                 ...
         /dev/sda8 (used as ext3 /boot)

The new configuration is

     /dev/sda (1TB HDD)
         ...
         /dev/sda7 (used as bcache backing device)
             /dev/bcache0 (used as LUKS encrypted volume)
                 /dev/mapper/bcache_crypt (used as LVM PV)
                     /dev/vg0/home
                     /dev/vg0/root
                     ...
         /dev/sda8 (used as ext3 /boot)
     /dev/sdb (32GB SSD)
         ...
         /dev/sdb3 (used as bcache caching device)

In order to get things booting, I also:

* Installed a Linux 3.10 kernel from wheezy-backports
(3.10-0.bpo.2-686-pae)
* Obtained a copy of the bcache-tools source from the git repo
and compiled it
* Constructed a Debian package for bcache-tools using checkinstall
* Because udev recognition wasn't enough at boot time, added a
script /etc/initramfs-tools/scripts/init-premount/z-bcache which looks like this:

             #!/bin/sh -e

             # ZEP - Added (2013-08-29) because some bcache devices

were not being detected
# at startup by udev. This sloppy hack should do
the job.

PREREQS=""

prereqs() { echo "$PREREQS"; }

case "$1" in
prereqs)
prereqs
exit 0
;;
esac

. /scripts/functions

if [ -e '/sys/fs/bcache/register_quiet' ]; then
log_begin_msg "Scanning for bcache devices..." for d in ls /dev/sd*; do
echo "$d" > /sys/fs/bcache/register_quiet
2>/dev/null || true
done
log_end_msg "bcache device scan complete"
else
log_warning_msg "/sys/fs/bcache/register_quiet not
found; not registering devices"
fi
* Executed update-initramfs -u -k all to get everything working

My machine boots from /dev/sda8 and the initramfs has enough machinery to get the root drive mounted. I was thrilled until I discovered that neither suspend nor hibernate seems to work; the suspend process seizes up while suspending devices and never comes back. I booted the laptop from a custom Debian live disk using the same kernel (3.10-0.bpo.2-686-pae) and performed a series of tests:

* When the bcache kernel module was not loaded, suspend to RAM
worked correctly.
* When the bcache kernel module was loaded but no devices were
registered, suspend to RAM worked correctly.
* When a single bcache device was registered using "echo
/dev/sda7 > /sys/fs/bcache/register; echo /dev/sdb3 > /sys/fs/bcache/register", suspend to RAM failed to change the power state of the machine.
* With a /dev/bcache0 device in use as an encrypted volume,
running "echo freezer > /sys/power/pm_test; echo platform > /sys/power/disk; echo disk > /sys/power/state" allows the machine to awaken from the test correctly.
* With a /dev/bcache0 device in use as an encrypted volume,
running "echo devices > /sys/power/pm_test; echo platform > /sys/power/disk; echo disk > /sys/power/state" causes the machine to hang.

Quoted 6 lines

Has suspend/hibernate been tested with bcache? Is it supported? I'm trying to figure out if it's my specific laptop hardware causing the issue or if bcache is somehow at fault. (Clearly, I can get suspend/hibernate back if I migrate back to using just my HDD, but caching blocks in a fashion designed for SSDs seems like such a lovely idea.)

Suspend/resume works fine for me (sort of). On 3.10.5 I saw some sort of bug with the freezer that went away if I disabled the Intel MEI driver (or just applied Kent's for-3.11 branch). I don't recall if Kent ever submitted it for 3.10.

--D