>Number:         16744
>Category:       kern
>Synopsis:       st(4) doesn't handle EOM of a DLT4000
>Confidential:   no
>Severity:       non-critical
>Priority:       high
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri May 10 11:06:00 PDT 2002
>Closed-Date:
>Last-Modified:
>Originator:     Bernd Ernesti
>Release:        NetBSD 1.5ZC 10-May-2002 10:00 UTC
>Organization:
	
>Environment:
System: NetBSD 1.5ZC (ARRESUM) #669: Fri May 10 11:00:10 CEST 2002
Architecture: i386
Machine: i386
>Description:
	The current scsi code doesn't check the end-of-media of a
	DLT4000. This wasn't a problem last year, when I had the
	same situation.

st0 at scsibus0 target 5 lun 0: <Quantum, DLT4000, DA97> SCSI2 1/sequential removable

	First I wasn't using the -a option for dump, but even after using it
	I get the same error.

	Maybe one has to use mt eew 1, but neither dump(8) mentions that
	option for mt(1) nor the mt(1) manpage talks about if this is on by
	default or not. mt doesn't show the status while using 'mt status'.
	Only the cvs log of sbin/dump/tape.c mentiones something about the eew
	support.

>How-To-Repeat:
	Try to dump a file system and notice the restart prompt:

  DUMP: 97.23% done, finished in 0:06
  DUMP: write error 18317952 blocks into volume 1
  DUMP: Do you want to restart?: ("yes" or "no") 

	I do NOT want to restart a 4h backup again.
>Fix:
	Back out some of the tape EOM handling which breaks this behaviour.
>Release-Note:
>Audit-Trail:
>Unformatted: