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 -- To unsubscribe from this list: send the line "unsubscribe linux-bcache" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html