Hi, I have a encrypted USB disk at /dev/sda that worked nicely so far. However, recently some new (?) power management seems to break this. Disk spin down and power up still work, but at some point the USB disk disconnects. Searching what happens here, I found that https://www.kernel.org/doc/Documentation/usb/power-management.txt claims it's not uncommon that USB devices don't support power management properly and thus do a disconnect and reconnect there. Seem this is happening as dmesg reports: [ 5.459493] usb 1-1.2: new high-speed USB device number 3 using dwc_otg [ 5.459493] usb-storage 1-1.2:1.0: USB Mass Storage device detected [ 5.561081] scsi0 : usb-storage 1-1.2:1.0 [ 5.561081] scsi 0:0:0:0: Direct-Access Disk Name 2BC1 PQ: 0 ANSI: 2 CCS [ 5.562474] sd 0:0:0:0: [sda] 3907029168 512-byte logical blocks: (2.00 TB/1.81 TiB) .... [ 1659.691793] usb 1-1.2: USB disconnect, device number 3 [ 1659.699144] scsi 0:0:0:0: rejecting I/O to offline device [ 1659.699215] scsi 0:0:0:0: [sda] killing request [ 1659.703914] scsi 0:0:0:0: [sda] Unhandled error code [ 1659.708993] scsi 0:0:0:0: [sda] [ 1659.712500] Result: hostbyte=0x01 driverbyte=0x00 [ 1659.717332] scsi 0:0:0:0: [sda] CDB: [ 1659.721162] cdb[0]=0x28: 28 00 00 04 31 7a 00 00 08 00 [ 1659.726443] end_request: I/O error, dev sda, sector 274810 [ 1663.759509] usb 1-1.2: new high-speed USB device number 4 using dwc_otg [ 1663.865049] usb-storage 1-1.2:1.0: USB Mass Storage device detected [ 1663.866221] scsi1 : usb-storage 1-1.2:1.0 [ 1664.869823] scsi 1:0:0:0: Direct-Access Disk Name 2BC1 PQ: 0 ANSI: 2 CCS [ 1664.874690] sd 1:0:0:0: [sdb] 3907029168 512-byte logical blocks: (2.00 TB/1.81 TiB) [ 1664.881544] sd 1:0:0:0: [sdb] Write Protect is off [ 1664.885663] sd 1:0:0:0: [sdb] Mode Sense: 28 00 00 00 [ 1664.886284] sd 1:0:0:0: [sdb] No Caching mode page found [ 1664.891160] sd 1:0:0:0: [sdb] Assuming drive cache: write through [ 1664.899793] sd 1:0:0:0: [sdb] No Caching mode page found [ 1664.902859] sd 1:0:0:0: [sdb] Assuming drive cache: write through [ 1664.985418] sdb: sdb1 [ 1664.988355] sd 1:0:0:0: [sdb] No Caching mode page found [ 1664.988410] sd 1:0:0:0: [sdb] Assuming drive cache: write through [ 1664.994563] sd 1:0:0:0: [sdb] Attached SCSI disk [ 1665.049694] Aborting journal on device dm-0-8. [ 1665.050009] Buffer I/O error on device dm-0, logical block 243826688 [ 1665.055199] lost page write due to I/O error on dm-0 [ 1665.060425] JBD2: Error -5 detected when updating journal superblock for dm-0-8. [ 1689.789480] Buffer I/O error on device dm-0, logical block 0 [ 1689.793190] lost page write due to I/O error on dm-0 [ 1689.798373] EXT4-fs error (device dm-0): __ext4_journal_start_sb:62: Detected aborted journal [ 1689.806990] EXT4-fs (dm-0): Remounting filesystem read-only [ 1689.812846] EXT4-fs (dm-0): previous I/O error to superblock detected [ 1689.819660] Buffer I/O error on device dm-0, logical block 0 [ 1689.825145] lost page write due to I/O error on dm-0 [ 1689.830320] EXT4-fs (dm-0): ext4_da_writepages: jbd2_start: 5120 pages, ino 13; err -30 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. Thanks, Axel _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
