Bug 18319

>Number:         18319
>Category:       bin
>Synopsis:       "dump" fails with "cannot reopen disk: interrupted system call"
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sun Apr 30 23:00:00 PDT 2000
>Closed-Date:
>Last-Modified:
>Originator:     Charlie &
>Release:        FreeBSD 4.0-RELEASE i386
>Organization:
Peter Much, Fichtenstrasse 28, D-65527 Niedernhausen, Germany
>Environment:

IBM ThinkPad 600
IBM 12GB "DARA-212000" Drive
atapci0 identifies: "Intel PIIX4 ATA33 controller"
Filesystem is made just standard out-of-the-box.
Reproduceable with kernel.GENERIC.

>Description:

When doing an incremental backup with dump on the root filesystem (29MB),
or possibly on any small filesystem, and writing to /dev/null or something
able to take the data rather fast, then possibly the dump fails and the
following output is produced:

  DUMP: Date of this level 1 dump: Sun Apr 30 21:12:22 2000
  DUMP: Date of last level 0 dump: Wed Apr 26 22:18:30 2000
  DUMP: Dumping /dev/rad0s3a (/) to /dev/null
  DUMP: mapping (Pass I) [regular files]
  DUMP: mapping (Pass II) [directories]
  DUMP: estimated 91 tape blocks on 0.00 tape(s).
  DUMP: dumping (Pass III) [directories]
  DUMP: dumping (Pass IV) [regular files]
  DUMP: slave couldn't reopen disk: Interrupted system call
  DUMP: The ENTIRE dump is aborted.

>How-To-Repeat:

This seems timing-critical, because it did already work some times. And now
even after a reboot it always gives this error message. 

>Fix:

At the appropriate place in the sourcecode, if I put a sleep(1) between the
close and the open, the problem is gone away. usleep(1) is also good enough.

>Release-Note:
>Audit-Trail:
>Unformatted:


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message