Re: st.c update has broken dump multi-tape support

[Frank Kardel <kardel%netbsd.org@localhost>]

Hi Brett,

that was my impression too. Just check that the write return count on 
EOM is zero to indicate EOF.

My stab at this would be the attached patch.

Could you check whether my suspicion that biodone() may be missing the 
ststart1 function in the

error == 0 case?

I have not tested the patch as my machine with the tapes is remote and 
has no remote console

and I don't want to brick that while being off-site.

Frank


On 06/10/21 04:53, Brett Lymn wrote:
> Hi Frank,
>
> On Wed, Jun 09, 2021 at 07:06:07PM +0200, Frank Kardel wrote:
> > A quick analysis leaves me to believe that the culprit is in this commit:
> >
> >     revision 1.234
> >     date: 2018-03-24 09:08:19 +0100;  author: mlelstv;  state: Exp;
> >     lines: +176 -134;  commitid: xU4Kh6YFLfDywGvA;
> >     branches:  1.234.2;
> >     Use separate lock to protect internal state and release locks when
> >     calling biodone.
> >
> > Here the logic for ST_EARLY_WARN got lost. So the EOM always delivers EIO
> > instead
> Yes, I think you are correct looking at that change.  My backup script
> does set the early warning flag.  I will have a stab at fixing this
> later today, I think if I just avoid returning EIO in the ST_EOM_PENDING
> case inside ststart it should be good.

--- st.c	2021-06-09 18:31:50.860128750 +0200
+++ st.c.240	2021-06-10 07:30:55.828024537 +0200
@@ -1242,6 +1242,7 @@
 				bp->b_resid = bp->b_bcount;
 				error = 0;
 				st->flags &= ~ST_AT_FILEMARK;
+				/* XXX missing a biodone() here? */
 				goto out;
 			}
 		}
@@ -1251,7 +1252,13 @@
 	 * yet then we should report it now.
 	 */
 	if (st->flags & (ST_EOM_PENDING|ST_EIO_PENDING)) {
-		error = EIO;
+		if (st->flags & ST_EIO_PENDING) {
+			error = EIO;
+		} else {
+			error = 0;
+			bp->b_resid = bp->b_bcount;
+			biodone(bp);			
+		}
 		goto out;
 	}