From root@koellers.net  Mon Apr  7 11:44:20 2003
Return-Path: <root@koellers.net>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 72B7737B401
	for <FreeBSD-gnats-submit@freebsd.org>; Mon,  7 Apr 2003 11:44:20 -0700 (PDT)
Received: from sally.dts-online.net (sally.dts-online.net [212.62.68.35])
	by mx1.FreeBSD.org (Postfix) with ESMTP id C751543F85
	for <FreeBSD-gnats-submit@freebsd.org>; Mon,  7 Apr 2003 11:44:18 -0700 (PDT)
	(envelope-from root@koellers.net)
Received: from door.koellers.net (dsl82-34.teleos-web.de [212.62.82.34])
	by sally.dts-online.net (Postfix) with ESMTP
	id 8BF4F203CCB; Mon,  7 Apr 2003 20:44:16 +0200 (CEST)
Received: from odie.koellers.net (root@odie.koellers.net [192.168.4.2])
	by door.koellers.net (8.12.8p1/8.12.6) with ESMTP id h37HYjH4019037;
	Mon, 7 Apr 2003 19:34:45 +0200 (CEST)
	(envelope-from root@koellers.net)
Received: from odie.koellers.net (smmsp@localhost [127.0.0.1])
	by odie.koellers.net (8.12.8p1/8.12.6) with ESMTP id h37HYjZD002835;
	Mon, 7 Apr 2003 19:34:45 +0200 (CEST)
	(envelope-from root@odie.koellers.net)
Received: (from root@localhost)
	by odie.koellers.net (8.12.8p1/8.12.8/Submit) id h37HYjfL002834;
	Mon, 7 Apr 2003 19:34:45 +0200 (CEST)
Message-Id: <200304071734.h37HYjfL002834@odie.koellers.net>
Date: Mon, 7 Apr 2003 19:34:45 +0200 (CEST)
From: lkoeller@freebsd.org
Reply-To: lars@koellers.net
To: FreeBSD-gnats-submit@freebsd.org
Cc: lars.koeller@uni-bielefeld.de
Subject: EOT detection in sa driver prevents mutli volume dump
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         50691
>Category:       kern
>Synopsis:       EOT detection in sa driver prevents mutli volume dump
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Mon Apr 07 11:50:16 PDT 2003
>Closed-Date:    Sun Aug 31 14:54:17 PDT 2003
>Last-Modified:  Sun Aug 31 14:54:17 PDT 2003
>Originator:     Lars Kller
>Release:        FreeBSD 4.8-RELEASE i386
>Organization:
Computing Center, University of Bielefeld, Germany
>Environment:
System: FreeBSD odie.koellers.net 4.8-RELEASE FreeBSD 4.8-RELEASE #29: Sun Apr 6 15:36:57 CEST 2003 root@odie.koellers.net:/usr/src/sys/compile/ODIE i386

Fresh source upgrade from 4.7-RELEASE-p3 to 4.8-RELEASE on March 6th 2003.

>Description:

When dumping a volume on an SCSI magnetic tape, a tape change request
leads to the abort of the dump process (dump ant tape on same machine):

root@odie:~/
129569 : dump -0ua /opt
  DUMP: Date of this level 0 dump: Mon Apr  7 14:16:21 2003
  DUMP: Date of last level 0 dump: the epoch
  DUMP: Dumping /dev/ccd1a (/opt) to /dev/nrsa0
  DUMP: mapping (Pass I) [regular files]
  DUMP: mapping (Pass II) [directories]
  DUMP: estimated 3659849 tape blocks.
  DUMP: dumping (Pass III) [directories]
  DUMP: dumping (Pass IV) [regular files]
  DUMP: 12.90% done, finished in 0:33
  DUMP: 19.75% done, finished in 0:40
  DUMP: 26.95% done, finished in 0:40
  DUMP: 34.42% done, finished in 0:38
  DUMP: 39.71% done, finished in 0:37
  DUMP: 45.12% done, finished in 0:36
  DUMP: 50.15% done, finished in 0:34
  DUMP: 53.43% done, finished in 0:34
  DUMP: 57.82% done, finished in 0:32
  DUMP: 61.61% done, finished in 0:31
  DUMP: 64.98% done, finished in 0:29
  DUMP: 70.55% done, finished in 0:25
  DUMP: 75.63% done, finished in 0:20
  DUMP: 82.06% done, finished in 0:15
  DUMP: End of tape detected
  DUMP: Closing /dev/nrsa0
  DUMP: Change Volumes: Mount volume #2
  DUMP: Is the new volume mounted and ready to go?: ("yes" or "no") yes
  DUMP: Volume 2 begins with blocks from inode 516537
  DUMP: EOT detected at start of the tape!
  DUMP: The ENTIRE dump is aborted.


The kernel reports:

(sa0:ahc0:0:4:0): WRITE FILEMARKS. CDB: 10 0 0 0 2 0
(sa0:ahc0:0:4:0): DATA PROTECT asc:30,0
(sa0:ahc0:0:4:0): Incompatible medium installed
(sa0:ahc0:0:4:0): failed to write terminating filemark(s)
(sa0:ahc0:0:4:0): tape is now frozen- use an OFFLINE, REWIND or MTEOM command to clear this state.

The first tape was a 4GB DDS2 tape the second a 2GB DDS1 here are the mt output
before the dump starts and during the change of the tape:

root@odie:~/
129570 : mt stat
Mode      Density              Blocksize      bpi      Compression
Current:  0x24:DDS-2           variable       61000    DCLZ
---------available modes---------
0:        0x24:DDS-2           variable       61000    DCLZ
1:        0x24:DDS-2           variable       61000    DCLZ
2:        0x24:DDS-2           variable       61000    DCLZ
3:        0x24:DDS-2           variable       61000    DCLZ
---------------------------------
Current Driver State: at rest.
---------------------------------
File Number: 6  Record Number: 0        Residual Count 0
root@odie:~/
129571 : mt off
root@odie:~/
129572 : mt stat
Mode      Density              Blocksize      bpi      Compression
Current:  0x13:X3B5/88-185A    variable       61000    DCLZ
---------available modes---------
0:        0x13:X3B5/88-185A    variable       61000    DCLZ
1:        0x13:X3B5/88-185A    variable       61000    DCLZ
2:        0x13:X3B5/88-185A    variable       61000    DCLZ
3:        0x13:X3B5/88-185A    variable       61000    DCLZ
---------------------------------
Current Driver State: at rest.
---------------------------------
File Number: 0  Record Number: 0        Residual Count 0
root@odie:~/
129573 : mt rew

At this point I enter the "yes" statement in the dump window.

Before entering yes the new tape was mounted and the "mt stat" and
"mt rew" succeeded. Befor the upgrade (from source) the exact same setup
worked well a day before.


Note: I notice a change of the behaviour of the tape driver somehow in October
2002. Till there a EOT of the tape was correct signaled by the driver during
writing. After there was only an error reportet and the nuber of bytes written:

Aug 24 23:57:21 door dattape: dattape: Write returned: -1 instead 1048576 Bytes. No space left on device
Aug 25 21:36:35 door dattape: dattape: Write returned: -1 instead 1048576 Bytes. No space left on device
Aug 25 23:54:19 door dattape: dattape: Write returned: -1 instead 1048576 Bytes. No space left on device
Aug 27 21:34:08 door dattape: dattape: Write returned: -1 instead 1048576 Bytes. No space left on device
Oct  6 21:48:50 door dattape: dattape: Write returned: -1 instead 1048576 Bytes. No space left on device
Oct  6 23:36:47 door dattape: dattape: Write returned: -1 instead 1048576 Bytes. No space left on device
Oct 21 21:37:13 door dattape: dattape: Write returned: 0 instead 1048576 Bytes. No such file or directory
Oct 27 21:32:50 door dattape: dattape: Write returned: 589824 instead 1048576 Bytes. No such file or directory
Oct 27 23:17:27 door dattape: dattape: Write returned: 65536 instead 1048576 Bytes. No such file or directory
Nov  4 00:25:39 door dattape: dattape: Write returned: 65536 instead 1048576 Bytes. No such file or directory
Nov  4 00:32:00 door dattape: dattape: Write returned: 65536 instead 1048576 Bytes. No such file or directory
Nov  4 07:37:18 door dattape: dattape: Write returned: 786432 instead 1048576 Bytes. No such file or directory
Nov 10 23:46:53 door dattape: dattape: Write returned: 589824 instead 1048576 Bytes. No such file or directory
Nov 12 21:16:44 door dattape: dattape: Write returned: 589824 instead 1048576 Bytes. No such file or directory

The logs are gerenrated by the same application without any change!


>How-To-Repeat:

Perform a dump of a lage filesystem on more than one tape.

>Fix:

Don't know
>Release-Note:
>Audit-Trail:

From: Bruce Evans <bde@zeta.org.au>
To: lars@koellers.net
Cc: FreeBSD-gnats-submit@freebsd.org,
	"" <lars.koeller@uni-bielefeld.de>, "" <freebsd-bugs@freebsd.org>,
	"" <njl@freebsd.org>
Subject: Re: kern/50691: EOT detection in sa driver prevents mutli volume
 dump
Date: Tue, 8 Apr 2003 14:33:36 +1000 (EST)

 On Mon, 7 Apr 2003 lkoeller@freebsd.org wrote:
 
 > >Description:
 >
 > When dumping a volume on an SCSI magnetic tape, a tape change request
 > leads to the abort of the dump process (dump ant tape on same machine):
 > ...
 > Note: I notice a change of the behaviour of the tape driver somehow in October
 > 2002. Till there a EOT of the tape was correct signaled by the driver during
 > writing. After there was only an error reportet and the nuber of bytes written:
 
 This was the only change in the driver between 4.7 and 4.8.
 
 %%%
 RCS file: /home/ncvs/src/sys/cam/scsi/scsi_sa.c,v
 Working file: scsi_sa.c
 head: 1.92
 ...
 ----------------------------
 revision 1.85
 date: 2002/12/16 17:40:17;  author: trhodes;  state: Exp;  lines: +4 -0
 The HP DAT 40 tape drive should be able to handle variable block sizes.
 But for some reason the block size is different when a different type of
 tape is placed in the drive.  This commit fixes that.
 
 PR:		46209
 Submitted by:	Alex Wang <alex@alexwang.com>
 Approved by:	mjacob
 ----------------------------
 %%%
 
 %%%
 Index: scsi_sa.c
 ===================================================================
 RCS file: /home/ncvs/src/sys/cam/scsi/scsi_sa.c,v
 retrieving revision 1.45.2.12
 retrieving revision 1.45.2.13
 diff -u -r1.45.2.12 -r1.45.2.13
 --- scsi_sa.c	2 Aug 2002 06:25:56 -0000	1.45.2.12
 +++ scsi_sa.c	17 Dec 2002 17:08:50 -0000	1.45.2.13
 [Id change deleted]
 @@ -304,6 +304,10 @@
  		  "C15*", "*"}, SA_QUIRK_VARIABLE|SA_QUIRK_NO_CPAGE, 0,
  	},
  #endif
 +	{
 +		{ T_SEQUENTIAL, SIP_MEDIA_REMOVABLE, "HP",
 +		  "C56*", "*"}, SA_QUIRK_VARIABLE|SA_QUIRK_2FM, 0
 +	},
  	{
  		{ T_SEQUENTIAL, SIP_MEDIA_REMOVABLE, "HP",
  		  "T20*", "*"}, SA_QUIRK_FIXED|SA_QUIRK_1FM, 512
 %%%
 
 Try changing the code to match the log message.  The log message only
 claims to change to variable block sizes, but the code also sets the
 EOD handling and this is apparently causes changed and wrong EOD handling.
 The wildcards are also inconsistent with the log message.
 
 Bruce

From: Nate Lawson <nate@root.org>
To: Bruce Evans <bde@zeta.org.au>
Cc: lars@koellers.net, FreeBSD-gnats-submit@freebsd.org
Subject: Re: kern/50691: EOT detection in sa driver prevents mutli volume
 dump
Date: Mon, 7 Apr 2003 23:05:25 -0700 (PDT)

 On Tue, 8 Apr 2003, Bruce Evans wrote:
 > On Mon, 7 Apr 2003 lkoeller@freebsd.org wrote:
 > > Note: I notice a change of the behaviour of the tape driver somehow in October
 > > 2002. Till there a EOT of the tape was correct signaled by the driver during
 > > writing. After there was only an error reportet and the nuber of bytes written:
 > 
 > This was the only change in the driver between 4.7 and 4.8.
 > 
 > ----------------------------
 > revision 1.85
 > date: 2002/12/16 17:40:17;  author: trhodes;  state: Exp;  lines: +4 -0
 > The HP DAT 40 tape drive should be able to handle variable block sizes.
 > But for some reason the block size is different when a different type of
 > tape is placed in the drive.  This commit fixes that.
 > 
 > PR:		46209
 > Submitted by:	Alex Wang <alex@alexwang.com>
 > Approved by:	mjacob
 > ----------------------------
 > %%%
 > 
 > %%%
 > Index: scsi_sa.c
 > ===================================================================
 > RCS file: /home/ncvs/src/sys/cam/scsi/scsi_sa.c,v
 > retrieving revision 1.45.2.12
 > retrieving revision 1.45.2.13
 > diff -u -r1.45.2.12 -r1.45.2.13
 > --- scsi_sa.c	2 Aug 2002 06:25:56 -0000	1.45.2.12
 > +++ scsi_sa.c	17 Dec 2002 17:08:50 -0000	1.45.2.13
 > [Id change deleted]
 > @@ -304,6 +304,10 @@
 >  		  "C15*", "*"}, SA_QUIRK_VARIABLE|SA_QUIRK_NO_CPAGE, 0,
 >  	},
 >  #endif
 > +	{
 > +		{ T_SEQUENTIAL, SIP_MEDIA_REMOVABLE, "HP",
 > +		  "C56*", "*"}, SA_QUIRK_VARIABLE|SA_QUIRK_2FM, 0
 > +	},
 >  	{
 >  		{ T_SEQUENTIAL, SIP_MEDIA_REMOVABLE, "HP",
 >  		  "T20*", "*"}, SA_QUIRK_FIXED|SA_QUIRK_1FM, 512
 > %%%
 
 I agree with Bruce.  Remove the "|SA_QUIRK_2FM" from the C56 line above,
 recompile your kernel, and try again.  Let us know if this fixes things
 for you.  Variable block size has little to do with requiring 2 end of
 file marks and the original commit should have been more careful about
 this.
 
 -Nate
 

From: "Lars =?iso-8859-1?Q?K=F6ller?=" <Lars@koellers.net>
To: Nate Lawson <nate@root.org>
Cc: Bruce Evans <bde@zeta.org.au>, lars@koellers.net,
	FreeBSD-gnats-submit@freebsd.org
Subject: Re: kern/50691: EOT detection in sa driver prevents mutli volume dump 
Date: Tue, 08 Apr 2003 20:40:28 +0200

 Hi,
 
 first of all thanks for the quick replay!
 
 In reply to Nate Lawson who wrote:
 
 >> %%%
 >> Index: scsi_sa.c
 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 >> RCS file: /home/ncvs/src/sys/cam/scsi/scsi_sa.c,v
 >> retrieving revision 1.45.2.12
 >> retrieving revision 1.45.2.13
 >> diff -u -r1.45.2.12 -r1.45.2.13
 >> --- scsi_sa.c	2 Aug 2002 06:25:56 -0000	1.45.2.12
 >> +++ scsi_sa.c	17 Dec 2002 17:08:50 -0000	1.45.2.13
 >> [Id change deleted]
 >> @@ -304,6 +304,10 @@
 >>  		  "C15*", "*"}, SA_QUIRK_VARIABLE|SA_QUIRK_NO_CPAGE, 0,
 >>  	},
 >>  #endif
 >> +	{
 >> +		{ T_SEQUENTIAL, SIP_MEDIA_REMOVABLE, "HP",
 >> +		  "C56*", "*"}, SA_QUIRK_VARIABLE|SA_QUIRK_2FM, 0
 >> +	},
 >>  	{
 >>  		{ T_SEQUENTIAL, SIP_MEDIA_REMOVABLE, "HP",
 >>  		  "T20*", "*"}, SA_QUIRK_FIXED|SA_QUIRK_1FM, 512
 >> %%%
 >
 >I agree with Bruce.  Remove the "|SA_QUIRK_2FM" from the C56 line above,=
 
 >recompile your kernel, and try again.  Let us know if this fixes things
 >for you.  Variable block size has little to do with requiring 2 end of
 >file marks and the original commit should have been more careful about
 >this.
 
 If I understand the code change right, it is only valid for HP DAT =
 
 drives. Sorry I've forgotten to mention my is a =
 
 
   ARCHIVE Python 28388-XXX
 
 So this couldn't be the reason. The last successful backup on a DDS2 =
 
 and a second DDS1 tape was done at Jan 11th.
 
 So .... sorry, but I've checked both tapes tapes I've tried and both are
 defect! No cleaning has helped they are unusable I've never seen this
 before in my 8 year DAT usage:
 
 root@odie:/usr/src/sys/cam/scsi/
 129612 : mt rew
 root@odie:/usr/src/sys/cam/scsi/
 129613 : mt stat
 Mode      Density              Blocksize      bpi      Compression
 Current:  0x13:X3B5/88-185A    variable       61000    DCLZ
 ---------available modes---------
 0:        0x13:X3B5/88-185A    variable       61000    DCLZ
 1:        0x13:X3B5/88-185A    variable       61000    DCLZ
 2:        0x13:X3B5/88-185A    variable       61000    DCLZ
 3:        0x13:X3B5/88-185A    variable       61000    DCLZ
 ---------------------------------
 Current Driver State: at rest.
 ---------------------------------
 File Number: 0  Record Number: 0        Residual Count 0
 root@odie:/usr/src/sys/cam/scsi/
 129614 : tar cpv /sbin =
 
 tar: Removing leading `/' from member names
 sbin/
 sbin/dhclient-script
 sbin/adjkerntz
 tar: /dev/nrsa0: Wrote only 0 of 10240 bytes
 tar: Error is not recoverable: exiting now
 
 Syslog shown:
 
 Such an error didn't come into my mind until I see the cvs diff above.
 
 So please close the PR!
 
 Thanks and best regards
 
 Lars
 
 -- =
 
 Lars K=F6ller
 E-Mail: lars@koellers.net (LKoeller@FreeBSD.ORG)
 -------- FreeBSD, was sonst? ---- http://www.de.freebsd.org --------
 
 

From: Nate Lawson <nate@root.org>
To: Lars =?iso-8859-1?Q?K=F6ller?= <Lars@koellers.net>
Cc: Bruce Evans <bde@zeta.org.au>, FreeBSD-gnats-submit@freebsd.org
Subject: Re: kern/50691: EOT detection in sa driver prevents mutli volume
 dump 
Date: Tue, 8 Apr 2003 11:51:05 -0700 (PDT)

 On Tue, 8 Apr 2003, Lars [iso-8859-1] Kller wrote:
 > In reply to Nate Lawson who wrote:
 > 
 > >I agree with Bruce.  Remove the "|SA_QUIRK_2FM" from the C56 line above,
 > >recompile your kernel, and try again.  Let us know if this fixes things
 > >for you.  Variable block size has little to do with requiring 2 end of
 > >file marks and the original commit should have been more careful about
 > >this.
 > 
 > If I understand the code change right, it is only valid for HP DAT 
 > drives. Sorry I've forgotten to mention my is a 
 > 
 >   ARCHIVE Python 28388-XXX
 > 
 > So this couldn't be the reason. The last successful backup on a DDS2 
 > and a second DDS1 tape was done at Jan 11th.
 
 Please reply with the results of "camcontrol devlist" for the history of
 this PR and I'll close it.
 
 -Nate
 

From: =?ISO-8859-1?Q?Lars_K=F6ller?= <lars@koellers.net>
To: Nate Lawson <nate@root.org>
Cc: Bruce Evans <bde@zeta.org.au>, FreeBSD-gnats-submit@freebsd.org
Subject: Re: kern/50691: EOT detection in sa driver prevents mutli volume
 dump
Date: Tue, 08 Apr 2003 23:55:52 -0400

 Nate Lawson wrote:
 
 > On Tue, 8 Apr 2003, Lars [iso-8859-1] K?ller wrote:
 >
 > >In reply to Nate Lawson who wrote:
 > >
 > >
 > >>I agree with Bruce.  Remove the "|SA_QUIRK_2FM" from the C56 line above,
 > >>recompile your kernel, and try again.  Let us know if this fixes things
 > >>for you.  Variable block size has little to do with requiring 2 end of
 > >>file marks and the original commit should have been more careful about
 > >>this.
 > >
 > >If I understand the code change right, it is only valid for HP DAT
 > >drives. Sorry I've forgotten to mention my is a
 > >
 > >  ARCHIVE Python 28388-XXX
 > >
 > >So this couldn't be the reason. The last successful backup on a DDS2
 > >and a second DDS1 tape was done at Jan 11th.
 >
 >
 > Please reply with the results of "camcontrol devlist" for the history of
 > this PR and I'll close it.
 
 
 root@odie:~/
 129660 : camcontrol devl
 <ARCHIVE Python 28388-XXX 5ACB>    at scbus0 target 4 lun 0 (sa0,pass10)
 <PLEXTOR CD-ROM PX-40TS 1.04>      at scbus0 target 5 lun 0 (cd0,pass11)
 <SEAGATE ST19101W 0014>            at scbus0 target 8 lun 0 (pass0,da2)
 <SEAGATE ST19101W 0014>            at scbus0 target 9 lun 0 (pass1,da3)
 <SEAGATE ST32171W 0338>            at scbus0 target 10 lun 0 (pass2,da4)
 <IBM DCAS-34330 S61A>              at scbus1 target 0 lun 0 (pass3,da0)
 <DEC RZ2DD-LS (C) DEC 0306>        at scbus1 target 1 lun 0 (pass4,da1)
 <IBM DCAS-34330 S61A>              at scbus1 target 2 lun 0 (pass5,da6)
 <IBM DNES-309170 SA30>             at scbus1 target 3 lun 0 (pass6,da7)
 <SEAGATE ST32171W 0338>            at scbus1 target 11 lun 0 (pass7,da5)
 <PIONEER CD-ROM DR-U10X 1.07>      at scbus2 target 5 lun 0 (pass8,cd2)
 <PIONEER CD-ROM DR-U12X 1.06>      at scbus2 target 6 lun 0 (pass9,cd3)
 
 
 What still has changed is the behaviour of the write command when EOT is 
 reached. See my note in the PR. Do you have any idea for this?
 
 Best regards
 
 Lars
 
 -- 
 Lars Kller
 E-Mail: lars@koellers.net (LKoeller@FreeBSD.ORG)
 -------- FreeBSD, was sonst? ---- http://www.de.freebsd.org --------
 
State-Changed-From-To: open->closed 
State-Changed-By: njl 
State-Changed-When: Sun Aug 31 14:53:42 PDT 2003 
State-Changed-Why:  
The write behavior should be submitted as a separate PR.  Since we can't 
make more headway on this, I'm closing it. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=50691 
>Unformatted:
