diff options
| author | Scott Bauer <scott.bauer@intel.com> | 2017-09-01 16:53:35 +0200 |
|---|---|---|
| committer | Jens Axboe <axboe@kernel.dk> | 2017-09-11 17:45:52 +0200 |
| commit | dbec491b12b52888d120e5be8f15886b3216eb19 (patch) | |
| tree | ae5c7424d03c6b60d229bd216f0666d12c366eed /block/blk-lib.c | |
| parent | block: tolerate tracing of NULL bio (diff) | |
| download | linux-dbec491b12b52888d120e5be8f15886b3216eb19.tar.xz linux-dbec491b12b52888d120e5be8f15886b3216eb19.zip | |
block: sed-opal: Set MBRDone on S3 resume path if TPER is MBREnabled
Users who are booting off their Opal enabled drives are having
issues when they have a shadow MBR set up after s3/resume cycle.
When the Drive has a shadow MBR setup the MBRDone flag is set to
false upon power loss (S3/S4/S5). When the MBRDone flag is false
I/O to LBA 0 -> LBA_END_MBR are remapped to the shadow mbr
of the drive. If the drive contains useful data in the 0 -> end_mbr
range upon s3 resume the user can never get to that data as the
drive will keep remapping it to the MBR. To fix this when we unlock
on S3 resume, we need to tell the drive that we're done with the
shadow mbr (even though we didnt use it) by setting true to MBRDone.
This way the drive will stop the remapping and the user can access
their data.
Acked-by Jon Derrick: <jonathan.derrick@intel.com>
Signed-off-by: Scott Bauer <scott.bauer@intel.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Diffstat (limited to '')
0 files changed, 0 insertions, 0 deletions