diff options
| author | Laurence Oberman <loberman@redhat.com> | 2026-10-06 12:42:50 -0400 |
|---|---|---|
| committer | Martin K. Petersen (Oracle) <mkp@kernel.org> | 2026-10-13 22:36:26 -0400 |
| commit | c9e9f024dd4f61f0f6636c9f2ed0830f87060e11 (patch) | |
| tree | ad4664bba895e70d4b6048d6f7a667cf01a60388 /tools/lib/python/kdoc/python_version.py | |
| parent | 8c8222c255772713eb36cde695777a1fce224917 (diff) | |
| download | linux-next-c9e9f024dd4f61f0f6636c9f2ed0830f87060e11.tar.gz linux-next-c9e9f024dd4f61f0f6636c9f2ed0830f87060e11.zip | |
scsi: st: Save the visited block for the partition the drive is in
set_location() saves the current tape location before switching
partitions, so that switch_partition() can return to it later. It reads
the location with READ POSITION but stores it in the st_partstat of
STp->partition, ignoring the partition the drive reports.
The two differ after a device reset. When the reset is recovered with
MTREW, MTSEEK or MTEOM, st_ioctl() sets STp->partition = 0 and calls
switch_partition() to return to STp->new_partition. A drive that was in
partition 1 is still there, so set_location() files the partition 1
position under partition 0. The next switch to partition 0 locates to
that block: if partition 0 holds less data, MTSETPART fails with EIO
(BLANK CHECK), otherwise the tape is silently positioned at the wrong
block.
IBM ULTRIUM-TD5 (LTO-5), LU reset in partition 1 at block 1025:
st 12:0:0:0: [st0] Visited block 1025 for partition 0 saved.
...
st 12:0:0:0: [st0] Setting block to 1025 and partition to 0.
st 12:0:0:0: [st0] Error: 402, cmd: 2b 2 0 0 0 4
st 12:0:0:0: [st0] Sense Key : Blank Check [current]
st 12:0:0:0: [st0] Add. Sense: End-of-data detected
Store the location in the st_partstat of the partition reported by READ
POSITION. With the fix:
st 12:0:0:0: [st0] Visited block 1025 for partition 1 saved.
This is a pre-existing issue. It was not caught when testing the recent
st reset series because the partition test was only run on scsi_debug:
on the LTO drive it was skipped, since can-partitions is off in the test
harness's stinit.conf, as is normal for LTO. scsi_debug hides the
problem because its emulated tape returns to the beginning of partition
0 on an LU reset. It was found while validating a backport of that
series to RHEL 9.8, when the partition tests were run on real hardware
with can-partitions enabled. The same failure then reproduced on
unmodified RHEL 9.8 and on upstream, and the fix makes the test pass on
v7.3-rc3 and RHEL 9.8 with an LTO-5.
The harness (https://gitlab.com/loberman/tapetest, test X03) now refuses
to silently skip the partition tests on hardware.
Fixes: 7081dc75df79 ("scsi: st: Restore some drive settings after reset")
Assisted-by: Claude
Signed-off-by: Laurence Oberman <loberman@redhat.com>
Link: https://patch.msgid.link/20261006164250.773840-1-loberman@redhat.com
Signed-off-by: Martin K. Petersen (Oracle) <mkp@kernel.org>
Diffstat (limited to 'tools/lib/python/kdoc/python_version.py')
0 files changed, 0 insertions, 0 deletions
