Bug 527 - dump causes assertion in ncr.c
Summary: dump causes assertion in ncr.c
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: Unspecified
Hardware: Any Any
: Normal Affects Only Me
Assignee: dufault
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 1995-06-17 07:40 UTC by koeck
Modified: 1999-06-22 14:57 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description koeck 1995-06-17 07:40:02 UTC
The dump command will cause kernel assertion messages of the ncr scsi 
driver to be printed out. Appended is the printout of two examples showing 
the kernel message produced by ncr.c. It is possible to restore a previously
written dump without a problem.
 
1. Example: dump to /dev/rst0 (DAT) :
=====================================

bash# dump 0fds /dev/nrst0 10000 10000 /
  DUMP: Date of this level 0 dump: Sat Jun 17 15:22:14 1995
  DUMP: Date of last level 0 dump: the epoch
  DUMP: Dumping /dev/rsd0a (/) to /dev/nrst0
  DUMP: mapping (Pass I) [regular files]
  DUMP: mapping (Pass II) [directories]
  DUMP: estimated 13396 tape blocks on 0.01 tape(s).
  DUMP: dumping (Pass III) [directories]
Jun 17 15:22:22 fbsd /kernel: assertion "cp == np->header.cp" failed: file "../.
./pci/ncr.c", line 5395
Jun 17 15:22:22 fbsd /kernel: assertion "cp == np->header.cp" failed: file "../.
./pci/ncr.c", line 5395
Jun 17 15:22:22 fbsd /kernel: assertion "cp" failed: file "../../pci/ncr.c", lin
e 5396
Jun 17 15:22:22 fbsd /kernel: assertion "cp" failed: file "../../pci/ncr.c", lin
e 5396
  DUMP: dumping (Pass IV) [regular files]
  DUMP: DUMP: 13407 tape blocks on 1 volumes(s)
  DUMP: Closing /dev/nrst0
  DUMP: DUMP IS DONE


2. Example: dump to /dev/null:
==============================
bash# dump 0fds /dev/null 10000 10000 /
  DUMP: Date of this level 0 dump: Sat Jun 17 15:24:16 1995
  DUMP: Date of last level 0 dump: the epoch
  DUMP: Dumping /dev/rsd0a (/) to /dev/null
  DUMP: mapping (Pass I) [regular files]
  DUMP: mapping (Pass II) [directories]
  DUMP: estimated 13396 tape blocks on 0.01 tape(s).
  DUMP: dumping (Pass III) [directories]
Jun 17 15:24:24 fbsd /kernel: assertion "cp == np->header.cp" failed: file "../.
./pci/ncr.c", line 5395
Jun 17 15:24:24 fbsd /kernel: assertion "cp == np->header.cp" failed: file "../.
./pci/ncr.c", line 5395
Jun 17 15:24:24 fbsd /kernel: assertion "cp" failed: file "../../pci/ncr.c", lin
e 5396
Jun 17 15:24:24 fbsd /kernel: assertion "cp" failed: file "../../pci/ncr.c", lin
e 5396
  DUMP: dumping (Pass IV) [regular files]
  DUMP: DUMP: 13407 tape blocks on 1 volumes(s)
  DUMP: Closing /dev/null
  DUMP: DUMP IS DONE

How-To-Repeat: 
see above
Comment 1 Stefan Eßer freebsd_committer freebsd_triage 1996-02-07 22:58:00 UTC
State Changed
From-To: open->analyzed

This appears to be caused by the generic SCSI code sending a  
START STOP UNIT command at each open of the raw disk device. 
Two programs are known to possibly open such a device multiple 
times within a fraction of a second: DUMP and FSCK. 
The NCR driver sends these commands with ORDERED TAG messages, 
which appears to confuse some IBM drives, if several are issued 
concurrently. 

This should be changed in the generic SCSI code, which easily 
could count the number of times a device has been opened and 
which should start the drive only once. 
Comment 2 pst freebsd_committer freebsd_triage 1996-02-08 17:37:03 UTC
Responsible Changed
From-To: freebsd-bugs->dufault

Peter has a fix being tested. 
Peter, when you're happy, please apply the fix and close out this bug. 
Comment 3 Poul-Henning Kamp freebsd_committer freebsd_triage 1998-04-12 18:48:38 UTC
State Changed
From-To: analyzed->feedback

Is this still a problem ? 
Comment 4 Sheldon Hearn freebsd_committer freebsd_triage 1999-06-22 14:57:20 UTC
State Changed
From-To: feedback->closed

Timed out waiting for feedback from submitter.