From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.server123.net (Postfix) with ESMTPS for ; Tue, 31 May 2016 08:53:17 +0200 (CEST) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1b7dJb-0001kM-18 for dm-crypt@saout.de; Tue, 31 May 2016 08:38:11 +0200 Received: from 115.99.100.29 ([115.99.100.29]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 31 May 2016 08:38:11 +0200 Received: from rrs by 115.99.100.29 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 31 May 2016 08:38:11 +0200 From: Ritesh Raj Sarraf Date: Mon, 30 May 2016 22:14:08 +0530 Message-ID: <1464626648.3187.12.camel@researchut.com> References: <573FB404.4000405@gmx.de> Reply-To: rrs@researchut.com Mime-Version: 1.0 Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="=-AvF1mhgMeFxFKY+epNtP" In-Reply-To: <573FB404.4000405@gmx.de> Subject: Re: [dm-crypt] dm-crypt LUKS and USB power management List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dm-crypt@saout.de --=-AvF1mhgMeFxFKY+epNtP Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, 2016-05-21 at 03:04 +0200, Axel Heider wrote: >=20 > I wonder if there are any ideas how dm-crypto or LUKS can handle this > case. Or is the recommendation that the USB suspend should not happen > at all for devices that are broken (ie. that disconnect and reconnect > on resume)? > Even if all handles on /dev/sda are released internally, there is not > really a guarantee that the devices comes back as /dev/sda are the > disconnect/reconnect. However, the UUID should be the same, so that > could be used to detect it's the same device and partition then and > accesses get re-routed to it then transparently. I doubt if it could be done clean. Most targets in Device Mapper ask for ca= reful unstacking. Red Hat (leading Linux vendor) still seems to be recommending that. https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/ht= ml-si ngle/Storage_Administration_Guide/#removing_devices I would rather investigate the (flaky) USB device. First, does it happen on= ly when Runtime PM is enabled ? If so, you should just blacklist it from Power Management. Many devices, under Linux, report (false) PM capabilities. --=20 Given the large number of mailing lists I follow, I request you to CC me in replies for quicker response --=-AvF1mhgMeFxFKY+epNtP Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- iQIcBAABCgAGBQJXTG3YAAoJEKY6WKPy4XVprwkQALSMaIBgkKcSzGN6LqxfVtGi ovK/42Qgtrmu+p8PkbrBwEJ103sfWB+4oWW3vSlKKjzSzMFnyY5x1SOCJygzI1Zq LNi4/6KLZ3mbn4fnP4ksEBafz9gtijtgcxA/tW/q3mYmXuK1+TG6U6dO4xHY0d87 5xw2EJc/ASC6pdZNtL1kMgyGALEomZsHcKB0HGr3VKvdaJFMxXZO9rjOO5WSBS1b eUdTIUMk3uU/aZk9qQLZOqKcSh7OlGfi3rTKqYTAIBVbhAdnD5mEpvkJw1wUZCqk wDlYye7duMLDODaeiYSmM/QfBZaf39KgYqTz1LDeKj7zEGVSrUfmMiWcrobTnEB7 5DcY53sPxn1dncZi2a0aaQ9zuMs4iKJjnZ+XsUSAoajlUn+tW+qtOrnQRDkwonCp Hsysgy5Ld9p6WtDmX1n37RE9Qs8tayJyR+KVxqOgkge1TB13nDWVac+3t3NRJf1C pt7ck/rxA+pCeRwx57jztXbsYSpGfpDk89pUoiQ0lzijDI9+V0DYo9cRmEHqf6iU GB4ZKFrftQ1fFEIEURnIDuKKQn19Vzk4x3Meg2RM27INRgBinSJOrMc5IY0gq/CP akCmhucgmi9GCyKy/3dUoth0Qqxgr0+doRgT96sbQ3i1euT3LdJXwd9IWXDm97rK 4bcl+8LoTff7+30E99ZH =iU9w -----END PGP SIGNATURE----- --=-AvF1mhgMeFxFKY+epNtP--