* 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
* 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
* 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
* 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
* 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