* Suspend and Hibernation Bugs
@ 2013-09-01 18:10 Zachary Palmer
[not found] ` <52238303.6040509-J5qI5MFTcs8@public.gmane.org>
0 siblings, 1 reply; 6+ messages in thread
From: Zachary Palmer @ 2013-09-01 18:10 UTC (permalink / raw)
To: linux-bcache-u79uwXL29TY76Z2rM5mHXA
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.)
Thanks,
Zach
^ permalink raw reply [flat|nested] 6+ messages in thread[parent not found: <52238303.6040509-J5qI5MFTcs8@public.gmane.org>]
* Re: Suspend and Hibernation Bugs [not found] ` <52238303.6040509-J5qI5MFTcs8@public.gmane.org> @ 2013-09-01 19:46 ` Gabriel de Perthuis [not found] ` <5223999F.2050508-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 2013-09-02 16:37 ` Darrick J. Wong 1 sibling, 1 reply; 6+ messages in thread From: Gabriel de Perthuis @ 2013-09-01 19:46 UTC (permalink / raw) To: Zachary Palmer; +Cc: linux-bcache-u79uwXL29TY76Z2rM5mHXA > 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: 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. ^ permalink raw reply [flat|nested] 6+ messages in thread
[parent not found: <5223999F.2050508-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]
* Re: Suspend and Hibernation Bugs [not found] ` <5223999F.2050508-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> @ 2013-09-01 23:13 ` Zachary Palmer [not found] ` <5223CA04.4010607-J5qI5MFTcs8@public.gmane.org> 0 siblings, 1 reply; 6+ messages in thread From: Zachary Palmer @ 2013-09-01 23:13 UTC (permalink / raw) To: Gabriel de Perthuis; +Cc: linux-bcache-u79uwXL29TY76Z2rM5mHXA 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, Zach p.s.: Regarding the hibernation issue, I believe that a related bug has already been reported to the Debian crew, who have sent at least some of the information upstream to kernel development (see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=715019). I've added my own information to that bug report, of course. If I can provide any information that would be of assistance, please let me know. >> 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: > 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. > ^ permalink raw reply [flat|nested] 6+ messages in thread
[parent not found: <5223CA04.4010607-J5qI5MFTcs8@public.gmane.org>]
* Re: Suspend and Hibernation Bugs [not found] ` <5223CA04.4010607-J5qI5MFTcs8@public.gmane.org> @ 2013-09-02 9:58 ` Gabriel de Perthuis 0 siblings, 0 replies; 6+ messages in thread From: Gabriel de Perthuis @ 2013-09-02 9:58 UTC (permalink / raw) To: Zachary Palmer; +Cc: linux-bcache-u79uwXL29TY76Z2rM5mHXA > 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, The first 4k of the device weren't erased; the bcache superblock comes after that. Fixed now. You can erase with wipefs -a, and do the same look/erase thing on /dev/sdb3. I'm on bcache-for-3.11 which doesn't have shutdown issues. I see your kernel is based on stable kernel 3.10.4, which backports a fix for #715019. I'd consider the suspend issue a separate one. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Suspend and Hibernation Bugs [not found] ` <52238303.6040509-J5qI5MFTcs8@public.gmane.org> 2013-09-01 19:46 ` Gabriel de Perthuis @ 2013-09-02 16:37 ` Darrick J. Wong [not found] ` <20130902163743.GA14878-yuuUpGxbzT9UbpRmUfBrXUB+6BGkLq7r@public.gmane.org> 1 sibling, 1 reply; 6+ messages in thread From: Darrick J. Wong @ 2013-09-02 16:37 UTC (permalink / raw) To: Zachary Palmer; +Cc: linux-bcache-u79uwXL29TY76Z2rM5mHXA On Sun, Sep 01, 2013 at 02:10:11PM -0400, Zachary Palmer wrote: > 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.) 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
[parent not found: <20130902163743.GA14878-yuuUpGxbzT9UbpRmUfBrXUB+6BGkLq7r@public.gmane.org>]
* Re: Suspend and Hibernation Bugs [not found] ` <20130902163743.GA14878-yuuUpGxbzT9UbpRmUfBrXUB+6BGkLq7r@public.gmane.org> @ 2013-09-02 20:07 ` Zachary Palmer 0 siblings, 0 replies; 6+ messages in thread From: Zachary Palmer @ 2013-09-02 20:07 UTC (permalink / raw) To: Darrick J. Wong; +Cc: linux-bcache-u79uwXL29TY76Z2rM5mHXA It seems that installing linux-image-3.11-rc4-686-pae=3.11~rc4-1~exp1 from Debian's experimental repository solved my problem. :) Thanks! - Zach > On Sun, Sep 01, 2013 at 02:10:11PM -0400, Zachary Palmer wrote: >> 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.) > 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 > ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2013-09-02 20:07 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-09-01 18:10 Suspend and Hibernation Bugs Zachary Palmer
[not found] ` <52238303.6040509-J5qI5MFTcs8@public.gmane.org>
2013-09-01 19:46 ` Gabriel de Perthuis
[not found] ` <5223999F.2050508-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2013-09-01 23:13 ` Zachary Palmer
[not found] ` <5223CA04.4010607-J5qI5MFTcs8@public.gmane.org>
2013-09-02 9:58 ` Gabriel de Perthuis
2013-09-02 16:37 ` Darrick J. Wong
[not found] ` <20130902163743.GA14878-yuuUpGxbzT9UbpRmUfBrXUB+6BGkLq7r@public.gmane.org>
2013-09-02 20:07 ` Zachary Palmer
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox