All of lore.kernel.org
 help / color / mirror / Atom feed
From: Axel Heider <axelheider@gmx.de>
To: dm-crypt@saout.de
Subject: Re: [dm-crypt] dm-crypt LUKS and USB power management
Date: Tue, 31 May 2016 12:59:38 +0200	[thread overview]
Message-ID: <574D6E9A.5070401@gmx.de> (raw)
In-Reply-To: <1464626648.3187.12.camel@researchut.com>




> I doubt if it could be done clean. Most targets in Device Mapper ask for
> careful unstacking.

Couldn't LUKS/cryptsetup/dm-crypt set up a monitor for the disk peripheral
at least? So it releases any connection to the device if it is diconnected.
The device is gone anyway, so there is no gain in keeping any handles open.
Internally, the higher layer file system driver should still get errors
then. But the lower lever driver stack is no longer blocked. So a new
device can become /dev/sda again and not dev/sdb because /dev/sda is still
"somehow" active.



> I would rather investigate the (flaky) USB device. First, does it happen only
> when Runtime PM is enabled ? If so, you should just blacklist it from Power
> Management. Many devices, under Linux, report (false) PM capabilities.

My current solution is using a hub with a dedicated power support to
connect the USB/SATA adapter with the HDD. Then disk spindown can
still be used, but there is no USB disconnect/reconnect. That solves
the problem practically.
I did not find a way yet to disable power/idele management on the
board USB ports. It's a Odroid C1 or C2 with Debian Jesse Kernel
3.14.29 or 3.14.65. The suggestion from
http://unix.stackexchange.com/questions/91027/how-to-disable-usb-autosuspend-on-kernel-3-7-10-or-above
does not work
and so far nobody else had a solution. Will keep searching...

Axel

  reply	other threads:[~2016-05-31 10:59 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-21  1:04 [dm-crypt] dm-crypt LUKS and USB power management Axel Heider
2016-05-30 16:44 ` Ritesh Raj Sarraf
2016-05-31 10:59   ` Axel Heider [this message]
2016-05-31 18:19     ` Arno Wagner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=574D6E9A.5070401@gmx.de \
    --to=axelheider@gmx.de \
    --cc=dm-crypt@saout.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.