Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 26 Jul 1996 22:09:39 +0200 (MET DST)
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
Message-ID:  <199607262009.WAA00324@x14.mi.uni-koeln.de>
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>

next in thread | previous in thread | raw e-mail | index | archive | help
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199607262009.WAA00324>