From owner-freebsd-stable  Fri Jul 26 13:11:34 1996
Return-Path: owner-stable
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id NAA20746
          for stable-outgoing; Fri, 26 Jul 1996 13:11:34 -0700 (PDT)
Received: from Sisyphos (Sisyphos.MI.Uni-Koeln.DE [134.95.212.10])
          by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id NAA20708;
          Fri, 26 Jul 1996 13:11:20 -0700 (PDT)
Received: from x14.mi.uni-koeln.de (annexr2-42.slip.Uni-Koeln.DE) by Sisyphos with SMTP id AA02113
  (5.67b/IDA-1.5); Fri, 26 Jul 1996 22:10:13 +0200
Received: (from se@localhost) by x14.mi.uni-koeln.de (8.7.5/8.6.9) id WAA00324; Fri, 26 Jul 1996 22:09:39 +0200 (MET DST)
Date: Fri, 26 Jul 1996 22:09:39 +0200 (MET DST)
Message-Id: <199607262009.WAA00324@x14.mi.uni-koeln.de>
From: Stefan Esser <se@zpr.uni-koeln.de>
To: Cat Okita <cat@uunet.ca>
Cc: "Marc G. Fournier" <scrappy@ki.net>, Stefan Esser <se@zpr.uni-koeln.de>,
        jkh@freebsd.org, current@freebsd.org, stable@freebsd.org, dg@root.com
Subject: Obtaining a kernel core with NCR
In-Reply-To: <Pine.SUN.3.93.960722182751.24159F-100000@troll.uunet.ca>
References: <Pine.NEB.3.94.960722175748.1614G-100000@ki.net>
	<Pine.SUN.3.93.960722182751.24159F-100000@troll.uunet.ca>
Sender: owner-stable@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

Cat Okita writes:
 > > > 4) does it always hang ?
 > > 	Everytime it crashes, yes...doing reboot from the console
 > > has never hung it...
 > 
 > *Only* when it crashes - a planned reboot, be it remote or local always seems
 > to work.

Well, I just thought it might be a good idea
to let you know, whether your system suffers
form the same hang in the kernel dump code as
mine. If you can afford the time to test this,
I'd really appreciate receiving your results!

The test requires a kernel compile a few more
minutes of time for a the actual test. It does 
not cause a corrupt or dirty file system to be
left over. (The FS is mounted R/O in single user
mode anyway).


1) build a kernel with

	options "SCSI_DEBUG_FLAGS=DEBUG_SCATTER"
	options DDB

2) boot this kernel into single user mode

3) enter the command "dumpon /dev/sd0b" if you
   did not already define the dump device on
   the "config kernel" line in the config file

4) enter DDB by pressing CTL+ALT+ESC or CTL+Print
   depending on your keyboard (this is for syscons,
   don't know about PCVT)

5) enter the command "panic" at the debugger prompt.

You will see a lot of trace output flow by, and it
will stop with the well-known SCSI hang. My guess
is, that the physical address of the last memory
page touched is in the BIOS region. Please let me
know what actual addresses (virtual and physical)
there are at the start of the last scatter/gather 
block reported.

Regards, STefan