[PATCH v2 0/2] scsi: st: Fix drive settings and position after reset recovery with MTLOAD/MTRETEN

[PATCH v2 0/2] scsi: st: Fix drive settings and position after reset recovery with MTLOAD/MTRETEN

[Laurence Oberman]

After a device reset st blocks tape access until one of MTREW, MTOFFL,
MTLOAD, MTRETEN, MTERASE, MTSEEK or MTEOM clears the reset condition.
Testing the reset handling on scsi_debug and on IBM LTO drives found two
problems when the condition is cleared with MTLOAD or MTRETEN.

1. Changed block size and density are silently lost

   A reset returns the drive's block size and density to their defaults.
   Commit 7081dc75df79 ("scsi: st: Restore some drive settings after
   reset") re-applies the values set by the user, but only for MTREW,
   MTSEEK and MTEOM.  Because check_tape() reads the drive's block size
   with MODE SENSE on every open, the driver follows the drive back to
   its default after the reset.  An application that set fixed-block
   mode with MTSETBLK and recovers with MTLOAD or MTRETEN keeps writing
   without any error, but in variable-length blocks.

   Patch 1 restores the changed settings for MTLOAD and MTRETEN as well.
   Both may make the drive report a new medium, and the new session
   started by check_tape() clears the "changed" flags and applies the
   mode defaults.  The values are therefore saved before the operation
   and re-applied after check_tape() has run.  scsi_debug reports a new
   medium after MTRETEN and MTLOAD; the IBM drives do not.  The series
   was tested against both behaviours.

2. Tape state is not reset after MTLOAD of an already loaded medium

   Commit 0b120edb37dc ("scsi: st: Add MTIOCGET and MTLOAD to ioctls
   allowed after device reset") allows MTLOAD because the tape location
   is known after it, but the position is not recorded:
   reset_state() sets -1/-1, and do_load_unload() leaves it there unless
   check_tape() starts a new session.  With drives that do not report a
   new medium for an already loaded cartridge (IBM LTO), MTIOCGET keeps
   reporting -1/-1 and no BOT.  Without a reset, the EOF state is also
   left as it was: after reading to EOD, a read following MTLOAD fails
   with EIO although the tape is at BOT.

   Patch 2 sets the position to BOT and resets the EOF state after a
   successful load when the current partition is 0, as MTREW does.

MTOFFL is deliberately not changed: the medium is unloaded, and a
different one may be loaded next, for which the mode defaults should
apply.

Immediate mode: with MT_ST_NOWAIT, MTRETEN returns before the
retension completes, so patch 1 does not restore the settings there
rather than waiting for the drive.

The SCSI tape driver is currently marked Orphan in MAINTAINERS.  Kai is
Cc'ed as the author of the reset handling these patches build on.

Testing (v7.3-rc2, scsi_debug and IBM LTO drives on FC):

                            R03.load       R04.load      R04.retension  R04.offline
                            (pos. after    (MTSETBLK     (MTSETBLK      (MTSETBLK
                             reset+LOAD)    after LOAD)   after RETEN)   after OFFL)
unpatched:
  scsi_debug                ok (0:0)       discarded     discarded      discarded
  IBM ULTRIUM-TD5 (LTO-5)   -1:-1          discarded     discarded      discarded
  IBM ULT3580-TDA           -1:-1          discarded     discarded      discarded
patched:
  scsi_debug (2 hosts)      ok             restored      restored       discarded (*)
  IBM ULTRIUM-TD5 (LTO-5)   ok             restored      restored       discarded (*)
  IBM ULT3580-TDA           ok             restored      restored       discarded (*)

(*) unchanged by design, see above.

MTLOAD of an already loaded tape at EOD, no reset (B09: read after load):

  IBM ULT3580-TDA   v1: read() fails with EIO   v2: ok
  scsi_debug        v1: ok (new session)        v2: ok

For the position tests, "ok" means that MTIOCPOS returns 0 and the
first block read without repositioning is block 0 of file 0; it is not
based on MTIOCGET alone.  The restore after MTREW/MTSEEK/MTEOM from
7081dc75df79 is unaffected on all devices.  Every test ends with a
byte-exact read-back of the whole tape.

The tests are part of a tape validation harness (reset detection, the
blocked-operation matrix, recovery operations, interrupted I/O, SCSI EH
via scsi_debug error injection):
https://gitlab.com/loberman/tapetest (developed with AI assistance)

Changes since v1:
- Patch 2: also reset the EOF state (and at_sm, last_block_valid) after
  the load, as MTREW does (found by Sashiko).  v2 retested on scsi_debug
  and IBM ULT3580-TDA.
- Patch 1: unchanged.

v1: https://marc.info/?l=linux-scsi&m=179051462299046&w=2

Laurence Oberman (2):
  scsi: st: Restore changed drive settings after reset also for MTLOAD
    and MTRETEN
  scsi: st: Record the tape position after a successful MTLOAD

 drivers/scsi/st.c | 59 +++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 59 insertions(+)

-- 
2.55.0

[PATCH v2 1/2] scsi: st: Restore changed drive settings after reset also for MTLOAD and MTRETEN

[Laurence Oberman]

A device reset returns the drive's density and block size to their
defaults.  Commit 7081dc75df79 ("scsi: st: Restore some drive settings
after reset") re-applies values changed by the user when the position is
recovered with MTREW, MTSEEK or MTEOM.  MTLOAD and MTRETEN are also
allowed to clear the reset condition and also leave the same medium at
BOT, but they restore nothing.

Because check_tape() reads the drive's block size with MODE SENSE on
every open, the driver silently switches to the drive default after the
reset.  An application that set fixed-block mode with MTSETBLK and
recovers with MTLOAD or MTRETEN keeps writing, but variable-length
blocks, without any error.

Restore the changed density and block size for MTLOAD and MTRETEN as
well.  Both operations may make the drive report a new medium, and the
new session started by check_tape() clears the "changed" flags and
applies the mode defaults.  So save the values before the operation, let
check_tape() run first (do_load_unload() already calls it for MTLOAD;
call it after MTRETEN), and then re-apply them.  Retry the restore once
in case a unit attention is still pending.
In immediate mode (MT_ST_NOWAIT) MTRETEN may return before the
retension has finished; do not wait for it there.

MTOFFL is not changed: the medium is unloaded and a different one may be
loaded next, for which the mode defaults apply.

Reproduced with scsi_debug (which reports a new medium after MTRETEN and
MTLOAD) and with IBM LTO drives on FC (which do not).

Fixes: 7081dc75df79 ("scsi: st: Restore some drive settings after reset")
Assisted-by: Claude sashiko
Signed-off-by: Laurence Oberman <loberman@redhat.com>
---
 drivers/scsi/st.c | 45 +++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 45 insertions(+)

diff --git a/drivers/scsi/st.c b/drivers/scsi/st.c
index f1c3c4946637..0a4263bef9cb 100644
--- a/drivers/scsi/st.c
+++ b/drivers/scsi/st.c
@@ -3586,6 +3586,23 @@ static long st_common_ioctl(struct scsi_tape *STp, struct st_modedef *STm,
 	return retval;
 }
 
+/*
+ * Re-apply a density and block size that were changed by the user before a
+ * device reset (a negative value means "not changed").  A unit attention
+ * still pending after the operation (e.g. new medium after a load) fails the
+ * first MODE SELECT, so retry each once.  As in the other post-reset restore
+ * path, errors are ignored and one setting failing does not prevent
+ * restoring the other.
+ */
+static void st_restore_changed_settings(struct scsi_tape *STp, int density,
+					int blksize)
+{
+	if (density >= 0 && st_int_ioctl(STp, MTSETDENSITY, density))
+		st_int_ioctl(STp, MTSETDENSITY, density);
+	if (blksize >= 0 && st_int_ioctl(STp, MTSETBLK, blksize))
+		st_int_ioctl(STp, MTSETBLK, blksize);
+}
+
 /* The ioctl command */
 static long st_ioctl(struct file *file, unsigned int cmd_in, unsigned long arg)
 {
@@ -3594,6 +3611,7 @@ static long st_ioctl(struct file *file, unsigned int cmd_in, unsigned long arg)
 	int retval = 0;
 	unsigned int blk;
 	bool cmd_mtiocget;
+	int restore_density = -1, restore_blksize = -1;
 	struct scsi_tape *STp = file->private_data;
 	struct st_modedef *STm;
 	struct st_partstat *STps;
@@ -3740,6 +3758,17 @@ static long st_ioctl(struct file *file, unsigned int cmd_in, unsigned long arg)
 					st_int_ioctl(STp, MTSETDENSITY, STp->changed_density);
 				if (STp->blksize_changed)
 					st_int_ioctl(STp, MTSETBLK, STp->changed_blksize);
+			} else if (mtc.mt_op == MTLOAD || mtc.mt_op == MTRETEN) {
+				/*
+				 * The same medium ends up at BOT, so the settings
+				 * apply as with MTREW.  The operation may start a
+				 * new session, which clears the "changed" flags:
+				 * save the values and restore them afterwards.
+				 */
+				if (STp->density_changed)
+					restore_density = STp->changed_density;
+				if (STp->blksize_changed)
+					restore_blksize = STp->changed_blksize;
 			}
 		}
 
@@ -3819,6 +3848,9 @@ static long st_ioctl(struct file *file, unsigned int cmd_in, unsigned long arg)
 
 		if (mtc.mt_op == MTLOAD) {
 			retval = do_load_unload(STp, file, max(1, mtc.mt_count));
+			if (!retval)
+				st_restore_changed_settings(STp, restore_density,
+							    restore_blksize);
 			goto out;
 		}
 
@@ -3837,6 +3869,19 @@ static long st_ioctl(struct file *file, unsigned int cmd_in, unsigned long arg)
 			retval = st_compression(STp, (mtc.mt_count & 1));
 		else
 			retval = st_int_ioctl(STp, mtc.mt_op, mtc.mt_count);
+		if (!retval && mtc.mt_op == MTRETEN && !STp->immediate &&
+		    (restore_density >= 0 || restore_blksize >= 0)) {
+			/*
+			 * Retension reloads the medium and the drive may
+			 * report a new medium.  Let check_tape() start the new
+			 * session (applying the mode defaults) now, as for
+			 * MTLOAD; otherwise it happens at the next open and
+			 * overrides the restored settings.
+			 */
+			if (check_tape(STp, file) >= 0)
+				st_restore_changed_settings(STp, restore_density,
+							    restore_blksize);
+		}
 		goto out;
 	}
 	if (!STm->defined) {
-- 
2.55.0

Re: [PATCH v2 1/2] scsi: st: Restore changed drive settings after reset also for MTLOAD and MTRETEN

["Kai Mäkisara (Kolumbus)"]

> On 28. Sep 2026, at 16.25, Laurence Oberman <loberman@redhat.com> wrote:
> 
> A device reset returns the drive's density and block size to their
> defaults.  Commit 7081dc75df79 ("scsi: st: Restore some drive settings
> after reset") re-applies values changed by the user when the position is
> recovered with MTREW, MTSEEK or MTEOM.  MTLOAD and MTRETEN are also
> allowed to clear the reset condition and also leave the same medium at
> BOT, but they restore nothing.
> 
> Because check_tape() reads the drive's block size with MODE SENSE on
> every open, the driver silently switches to the drive default after the
> reset.  An application that set fixed-block mode with MTSETBLK and
> recovers with MTLOAD or MTRETEN keeps writing, but variable-length
> blocks, without any error.

Reset also returns the drive buffering mode (STp->drv_buffer) to the default.
This should also be restored. It might be possible to use the same logic than
with density and block size. check_tape() reads the possibly damaged drv_buffer
value. So the old value should be saved before check_tape() and restored if
the value after check_tape() differs from the saved value (and the saved
value != 1). (I may have overlooked somthing.)

Another thing is the auto_lock mode. It should be enough to set
STp->door_locked = ST_UNLOCKED when reset is recognized. The door wiil
then be locked at first read or write.

Otherwise I did not find any issues.

Thanks, Kai

Re: [PATCH v2 1/2] scsi: st: Restore changed drive settings after reset also for MTLOAD and MTRETEN

[Laurence Oberman]

On Tue, 2026-09-29 at 17:15 +0300, Kai Mäkisara (Kolumbus) wrote:
> 
> 
> > On 28. Sep 2026, at 16.25, Laurence Oberman <loberman@redhat.com>
> > wrote:
> > 
> > A device reset returns the drive's density and block size to their
> > defaults.  Commit 7081dc75df79 ("scsi: st: Restore some drive
> > settings
> > after reset") re-applies values changed by the user when the
> > position is
> > recovered with MTREW, MTSEEK or MTEOM.  MTLOAD and MTRETEN are also
> > allowed to clear the reset condition and also leave the same medium
> > at
> > BOT, but they restore nothing.
> > 
> > Because check_tape() reads the drive's block size with MODE SENSE
> > on
> > every open, the driver silently switches to the drive default after
> > the
> > reset.  An application that set fixed-block mode with MTSETBLK and
> > recovers with MTLOAD or MTRETEN keeps writing, but variable-length
> > blocks, without any error.
> 
> Reset also returns the drive buffering mode (STp->drv_buffer) to the
> default.
> This should also be restored. It might be possible to use the same
> logic than
> with density and block size. check_tape() reads the possibly damaged
> drv_buffer
> value. So the old value should be saved before check_tape() and
> restored if
> the value after check_tape() differs from the saved value (and the
> saved
> value != 1). (I may have overlooked somthing.)
> 
> Another thing is the auto_lock mode. It should be enough to set
> STp->door_locked = ST_UNLOCKED when reset is recognized. The door
> wiil
> then be locked at first read or write.
> 
> Otherwise I did not find any issues.
> 
> Thanks, Kai
> 
> 
Thanks Kai. Both are new patches in v3: 3/4 records the buffering mode
set with MTSETDRVBUFFER and restores it in both restore paths (it is
already lost when the device is reopened after the reset, so it is
saved when set rather than before check_tape()), and 4/4 sets
door_locked = ST_UNLOCKED when the reset is recognized. Both reproduced
and verified on an IBM LTO-5.

[PATCH v2 2/2] scsi: st: Record the tape position after a successful MTLOAD

[Laurence Oberman]

Commit 0b120edb37dc ("scsi: st: Add MTIOCGET and MTLOAD to ioctls allowed
after device reset") allows MTLOAD to clear the reset condition because
the tape location is known after MTLOAD.  But the driver does not record
it: reset_state() sets the file and block numbers to -1, and
do_load_unload() leaves them there.  check_tape() sets them to 0 only for
a new session, which requires a new-medium unit attention.  Drives that
do not report one when the medium was already loaded (seen with IBM LTO
drives) keep reporting file/block -1 in MTIOCGET and no BOT, although the
tape is at the beginning.

Set the file and block numbers to 0 after a successful load when the
current partition is 0, where LOAD positions the medium, and reset the
EOF state as MTREW does; otherwise a read after loading at EOD fails
with EIO.

Fixes: 0b120edb37dc ("scsi: st: Add MTIOCGET and MTLOAD to ioctls allowed after device reset")
Assisted-by: Claude sashiko
Signed-off-by: Laurence Oberman <loberman@redhat.com>
---
 drivers/scsi/st.c | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/drivers/scsi/st.c b/drivers/scsi/st.c
index 0a4263bef9cb..f4393a8e8fb1 100644
--- a/drivers/scsi/st.c
+++ b/drivers/scsi/st.c
@@ -2686,6 +2686,20 @@ static int do_load_unload(struct scsi_tape *STp, struct file *filp, int load_cod
 		else {
 			STp->rew_at_close = STp->autorew_dev;
 			retval = check_tape(STp, filp);
+			/*
+			 * LOAD leaves the medium at the beginning of partition
+			 * 0.  check_tape() records that only for a new session;
+			 * without a new-medium unit attention (the medium was
+			 * already loaded) the position and the EOF state would
+			 * be left as before the load.  Set them as MTREW does.
+			 */
+			if (retval == CHKRES_READY && STp->partition == 0) {
+				STps = &(STp->ps[0]);
+				STps->drv_file = STps->drv_block = 0;
+				STps->eof = ST_NOEOF;
+				STps->at_sm = 0;
+				STps->last_block_valid = 0;
+			}
 			if (retval > 0)
 				retval = 0;
 		}
-- 
2.55.0

Re: [PATCH v2 2/2] scsi: st: Record the tape position after a successful MTLOAD

["Kai Mäkisara (Kolumbus)"]

> On 28. Sep 2026, at 16.25, Laurence Oberman <loberman@redhat.com> wrote:
> 
> Commit 0b120edb37dc ("scsi: st: Add MTIOCGET and MTLOAD to ioctls allowed
> after device reset") allows MTLOAD to clear the reset condition because
> the tape location is known after MTLOAD.  But the driver does not record
> it: reset_state() sets the file and block numbers to -1, and
> do_load_unload() leaves them there.  check_tape() sets them to 0 only for
> a new session, which requires a new-medium unit attention.  Drives that
> do not report one when the medium was already loaded (seen with IBM LTO
> drives) keep reporting file/block -1 in MTIOCGET and no BOT, although the
> tape is at the beginning.
> 
> Set the file and block numbers to 0 after a successful load when the
> current partition is 0, where LOAD positions the medium, and reset the
> EOF state as MTREW does; otherwise a read after loading at EOD fails
> with EIO.
> 
> Fixes: 0b120edb37dc ("scsi: st: Add MTIOCGET and MTLOAD to ioctls allowed after device reset")
> Assisted-by: Claude sashiko
> Signed-off-by: Laurence Oberman <loberman@redhat.com>
> ---
> drivers/scsi/st.c | 14 ++++++++++++++
> 1 file changed, 14 insertions(+)
> 
> diff --git a/drivers/scsi/st.c b/drivers/scsi/st.c
> index 0a4263bef9cb..f4393a8e8fb1 100644
> --- a/drivers/scsi/st.c
> +++ b/drivers/scsi/st.c
> @@ -2686,6 +2686,20 @@ static int do_load_unload(struct scsi_tape *STp, struct file *filp, int load_cod
> else {
> STp->rew_at_close = STp->autorew_dev;
> retval = check_tape(STp, filp);
> + /*
> + * LOAD leaves the medium at the beginning of partition
> + * 0.  check_tape() records that only for a new session;
> + * without a new-medium unit attention (the medium was
> + * already loaded) the position and the EOF state would
> + * be left as before the load.  Set them as MTREW does.
> + */

Should the following be done for all values of STp->partition?
And the code should set STp->partition = STp->new_partition = 0
to match the LOAD behaviour. (Usually
STp->partition == STp-> new_partition
and the partition would not be changed even if STp->partition
is not correct. But if later the partition is changed to the wrong value,
the change does not occur.)

> + if (retval == CHKRES_READY && STp->partition == 0) {
> + STps = &(STp->ps[0]);
> + STps->drv_file = STps->drv_block = 0;
> + STps->eof = ST_NOEOF;
> + STps->at_sm = 0;
> + STps->last_block_valid = 0;
> + }
> if (retval > 0)
> retval = 0;
> }
> -- 
> 2.55.0
> 

Thanks, Kai

Re: [PATCH v2 2/2] scsi: st: Record the tape position after a successful MTLOAD

[Laurence Oberman]

On Tue, 2026-09-29 at 15:39 +0300, Kai Mäkisara (Kolumbus) wrote:
> 
> > On 28. Sep 2026, at 16.25, Laurence Oberman <loberman@redhat.com>
> > wrote:
> > 
> > Commit 0b120edb37dc ("scsi: st: Add MTIOCGET and MTLOAD to ioctls
> > allowed
> > after device reset") allows MTLOAD to clear the reset condition
> > because
> > the tape location is known after MTLOAD.  But the driver does not
> > record
> > it: reset_state() sets the file and block numbers to -1, and
> > do_load_unload() leaves them there.  check_tape() sets them to 0
> > only for
> > a new session, which requires a new-medium unit attention.  Drives
> > that
> > do not report one when the medium was already loaded (seen with IBM
> > LTO
> > drives) keep reporting file/block -1 in MTIOCGET and no BOT,
> > although the
> > tape is at the beginning.
> > 
> > Set the file and block numbers to 0 after a successful load when
> > the
> > current partition is 0, where LOAD positions the medium, and reset
> > the
> > EOF state as MTREW does; otherwise a read after loading at EOD
> > fails
> > with EIO.
> > 
> > Fixes: 0b120edb37dc ("scsi: st: Add MTIOCGET and MTLOAD to ioctls
> > allowed after device reset")
> > Assisted-by: Claude sashiko
> > Signed-off-by: Laurence Oberman <loberman@redhat.com>
> > ---
> > drivers/scsi/st.c | 14 ++++++++++++++
> > 1 file changed, 14 insertions(+)
> > 
> > diff --git a/drivers/scsi/st.c b/drivers/scsi/st.c
> > index 0a4263bef9cb..f4393a8e8fb1 100644
> > --- a/drivers/scsi/st.c
> > +++ b/drivers/scsi/st.c
> > @@ -2686,6 +2686,20 @@ static int do_load_unload(struct scsi_tape
> > *STp, struct file *filp, int load_cod
> > else {
> > STp->rew_at_close = STp->autorew_dev;
> > retval = check_tape(STp, filp);
> > + /*
> > + * LOAD leaves the medium at the beginning of partition
> > + * 0.  check_tape() records that only for a new session;
> > + * without a new-medium unit attention (the medium was
> > + * already loaded) the position and the EOF state would
> > + * be left as before the load.  Set them as MTREW does.
> > + */
> 
> Should the following be done for all values of STp->partition?
> And the code should set STp->partition = STp->new_partition = 0
> to match the LOAD behaviour. (Usually
> STp->partition == STp-> new_partition
> and the partition would not be changed even if STp->partition
> is not correct. But if later the partition is changed to the wrong
> value,
> the change does not occur.)
> 
> > + if (retval == CHKRES_READY && STp->partition == 0) {
> > + STps = &(STp->ps[0]);
> > + STps->drv_file = STps->drv_block = 0;
> > + STps->eof = ST_NOEOF;
> > + STps->at_sm = 0;
> > + STps->last_block_valid = 0;
> > + }
> > if (retval > 0)
> > retval = 0;
> > }
> > -- 
> > 2.55.0
> > 
> 
> Thanks, Kai
> 
Hello Kai, thank you very much for the review. Let me look into
these points and make necessary changes and send a V3.

Regards
Laurence

Re: [PATCH v2 2/2] scsi: st: Record the tape position after a successful MTLOAD

[Laurence Oberman]

On Tue, 2026-09-29 at 15:39 +0300, Kai Mäkisara (Kolumbus) wrote:
> 
> > On 28. Sep 2026, at 16.25, Laurence Oberman <loberman@redhat.com>
> > wrote:
> > 
> > Commit 0b120edb37dc ("scsi: st: Add MTIOCGET and MTLOAD to ioctls
> > allowed
> > after device reset") allows MTLOAD to clear the reset condition
> > because
> > the tape location is known after MTLOAD.  But the driver does not
> > record
> > it: reset_state() sets the file and block numbers to -1, and
> > do_load_unload() leaves them there.  check_tape() sets them to 0
> > only for
> > a new session, which requires a new-medium unit attention.  Drives
> > that
> > do not report one when the medium was already loaded (seen with IBM
> > LTO
> > drives) keep reporting file/block -1 in MTIOCGET and no BOT,
> > although the
> > tape is at the beginning.
> > 
> > Set the file and block numbers to 0 after a successful load when
> > the
> > current partition is 0, where LOAD positions the medium, and reset
> > the
> > EOF state as MTREW does; otherwise a read after loading at EOD
> > fails
> > with EIO.
> > 
> > Fixes: 0b120edb37dc ("scsi: st: Add MTIOCGET and MTLOAD to ioctls
> > allowed after device reset")
> > Assisted-by: Claude sashiko
> > Signed-off-by: Laurence Oberman <loberman@redhat.com>
> > ---
> > drivers/scsi/st.c | 14 ++++++++++++++
> > 1 file changed, 14 insertions(+)
> > 
> > diff --git a/drivers/scsi/st.c b/drivers/scsi/st.c
> > index 0a4263bef9cb..f4393a8e8fb1 100644
> > --- a/drivers/scsi/st.c
> > +++ b/drivers/scsi/st.c
> > @@ -2686,6 +2686,20 @@ static int do_load_unload(struct scsi_tape
> > *STp, struct file *filp, int load_cod
> > else {
> > STp->rew_at_close = STp->autorew_dev;
> > retval = check_tape(STp, filp);
> > + /*
> > + * LOAD leaves the medium at the beginning of partition
> > + * 0.  check_tape() records that only for a new session;
> > + * without a new-medium unit attention (the medium was
> > + * already loaded) the position and the EOF state would
> > + * be left as before the load.  Set them as MTREW does.
> > + */
> 
> Should the following be done for all values of STp->partition?
> And the code should set STp->partition = STp->new_partition = 0
> to match the LOAD behaviour. (Usually
> STp->partition == STp-> new_partition
> and the partition would not be changed even if STp->partition
> is not correct. But if later the partition is changed to the wrong
> value,
> the change does not occur.)
> 
> > + if (retval == CHKRES_READY && STp->partition == 0) {
> > + STps = &(STp->ps[0]);
> > + STps->drv_file = STps->drv_block = 0;
> > + STps->eof = ST_NOEOF;
> > + STps->at_sm = 0;
> > + STps->last_block_valid = 0;
> > + }
> > if (retval > 0)
> > retval = 0;
> > }
> > -- 
> > 2.55.0
> > 
> 
> Thanks, Kai

Thanks Kai. A LOAD leaves the medium at the beginning of partition 0,
so v3 now sets STp->partition = STp->new_partition = 0 for all
partitions, as check_tape() does for a new session. I reproduced the
problem on an IBM LTO-5 with v2 (MTLOAD while in partition 1, then
MTSETPART 1 was not performed). Fixed in v3 with your Suggested-by.