You might want to check port-sparc - I believe someone recently
	reported a codegen bug that affected dump on sparc...

		David/absolute

	"Its just another ultimate battle of good against evil..."

On Wed, 23 Jun 1999, Herb Peyerl wrote:

> Is anyone else experiencing a problem with dump?
> 
> On my sparc I'm running a relatively -current kernel due to some scsi issues
> that PK took care of; and a 1.4 userland... The symptoms exhibited themselves
> with a 1.3H userland as well however.
> 
> The problem is that after writing 100-1000MB, dump just 'stops' doing anything.
> I saw this happen while doing a 'dump|restore' from one filesystem onto another
> and last night while doing a 'dump | dd' onto a tapedrive...
> 
>  # dump 0f - /usr/local/cd | dd of=/dev/rst1 bs=64k
>   DUMP: Date of this level 0 dump: Tue Jun 22 21:53:39 1999
>   DUMP: Date of last level 0 dump: the epoch
>   DUMP: Dumping /dev/rccd0a (/usr/local/cd) to standard output
>   DUMP: Label: none
>   DUMP: mapping (Pass I) [regular files]
>   DUMP: mapping (Pass II) [directories]
>   DUMP: estimated 16265359 tape blocks.
>   DUMP: Volume 1 started at: Tue Jun 22 21:58:12 1999
>   DUMP: dumping (Pass III) [directories]
>   DUMP: dumping (Pass IV) [regular files]
>   DUMP: 1.69% done, finished in 4:51
>   DUMP: 3.43% done, finished in 4:41
>   DUMP: 5.13% done, finished in 4:37
>    .....
> 
> 
> That was how I left it last night when I went to bed. This morning, it hadn't
> changed at all... 'systat iostat' showed no disk activity whatsoever.
> 
> a "kill -INFO" then produced:
> 
> 5.19% done at 22 KB/s, finished in 187:05
> 5.19% done at 22 KB/s, finished in 188:05
> 
> finally, interrupting the dump produces:
> 
> ^C^?0+212257 records in
> 0+212257 records out
> 864552960 bytes transferred in 37382 secs (23127 bytes/sec)
>   DUMP: Interrupt received.
>   DUMP: Do you want to abort dump?: ("yes" or "no")
> 
> which is normal.
> 
> Same thing when not going through 'dd':
> 
>  # dump 0Bf 25000000 /dev/rst1 /usr/local/cd
>   DUMP: Date of this level 0 dump: Wed Jun 23 08:26:33 1999
>   DUMP: Date of last level 0 dump: the epoch
>   DUMP: Dumping /dev/rccd0a (/usr/local/cd) to /dev/rst1
>   DUMP: Label: none
>   DUMP: mapping (Pass I) [regular files]
>   DUMP: mapping (Pass II) [directories]
>   DUMP: estimated 16265362 tape blocks on 0.65 tape(s).
>   DUMP: Volume 1 started at: Wed Jun 23 08:31:08 1999
>   DUMP: dumping (Pass III) [directories]
>   DUMP: dumping (Pass IV) [regular files]
>   DUMP: 2.17% done, finished in 3:45
>   DUMP: 4.45% done, finished in 3:34
>   DUMP: 6.76% done, finished in 3:26
> 	....				<----- at this point I confirmed no I/O
> ^?  DUMP: Interrupt received.
>   DUMP: Do you want to abort dump?: ("yes" or "no") yes
>   DUMP: The ENTIRE dump is aborted.
> 
> 
> I know the problem is not with the tapedrive because I can 'tar cf - | dd' onto
> it just fine.  Plus the problem occurs with 'dump|restore' from one filesystem
> onto another...
> 
> The tape drive in case anyone cares is a DLT-4000...
> 
> Is anyone else seeing this? I wanted to find out before doing a send-pr because
> it could be some sort of localized weirdness..
> 
>