From admin@citylink.dinoex.sub.org  Sun Apr 30 22:59:48 2000
Return-Path: <admin@citylink.dinoex.sub.org>
Received: from mail.dinoex.sub.org (mail.dinoex.sub.de [195.243.29.14])
	by hub.freebsd.org (Postfix) with ESMTP id D923837B61A
	for <FreeBSD-gnats-submit@freebsd.org>; Sun, 30 Apr 2000 22:59:44 -0700 (PDT)
	(envelope-from admin@citylink.dinoex.sub.org)
Received: (from uucp@localhost)
	by mail.dinoex.sub.org (8.10.1/8.10.1) with UUCP id e410BY028659
	for FreeBSD-gnats-submit@freebsd.org; Mon, 1 May 2000 02:11:34 +0200 (CEST)
	(envelope-from admin@citylink.dinoex.sub.org)
Received: from citylink.dinoex.sub.org (uucp@localhost)
	by net2.dinoex.sub.org (8.10.1/8.10.1) with UUCP id e3UK1WW09411
	for freebsd.org!FreeBSD-gnats-submit; Sun, 30 Apr 2000 22:01:32 +0200 (CEST)
	(envelope-from admin@citylink.dinoex.sub.org)
Received: (from root@localhost) by citylink.dinoex.sub.org (8.8.5/PMuch-B3b)
	id VAA18267; Sun, 30 Apr 2000 21:50:20 +0200 (CEST)
Message-Id: <200004301950.VAA18267@citylink.dinoex.sub.org>
Date: Sun, 30 Apr 2000 21:50:20 +0200 (CEST)
From: root@citylink.dinoex.sub.org
Sender: admin@citylink.dinoex.sub.org
Reply-To: peter@citylink.dinoex.sub.org
To: FreeBSD-gnats-submit@freebsd.org
Subject: dump: "cannot reopen disk: interrupted system call"
X-Send-Pr-Version: 3.2

>Number:         18319
>Category:       bin
>Synopsis:       dump(8) 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:  Wed May 21 20:43:02 UTC 2008
>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:

From: root@citylink.dinoex.sub.org
To: FreeBSD-gnats-submit@freebsd.org
Cc:  
Subject: bin/18319: dump: "cannot reopen disk: interrupted system call"
Date: Sun, 30 Apr 2000 21:50:20 +0200 (CEST)

 >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
 
 
>Unformatted:
