Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 26 Jul 1996 21:57:50 +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:   Re: ncr53c810 driver in stable/current 
Message-ID:  <199607261957.VAA00315@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:
 > On Mon, 22 Jul 1996, Marc G. Fournier wrote:
 > > 	Same, on shutdown, not startup...
 > 
 > I have a vague recollection of a panic on not being able to write to assigned
 > vnode (or something along those lines - it *was* 3:30am)
 > 
 > > 	requires a power-off, but am not 100% certain, since I've gotten
 > > into the habit of doing a cold boot (99.9% certain the habit is because
 > > ctl-alt-del didn't work)
 > 
 > Definately requires a power off - the keyboard doesn't respond to any key
 > or combination that I've tried.
 > 
 > > > 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.

Ok. Today I found some time to have my system crash for 
the sake of science :-)

Well, the hang occurs and it really can't be interrupted
from the keyboard.

But the code did work at some time, and it in fact still
does. Mostly ...

The dump writes out the first few MB within less than a
second, and then the SCSI LED stays on and the system 
hangs, always after accessing the same virtual address.

It took me some time to think about checking which physical 
address that corresponds to that page, and to my surprise I 
found that the BIOS region at e8000 is the last thing touched
by the NCR chip. I have no idea why the page at 0e8000 is 
mapped into the kernel, and I do not think that I got some
device at that address. But it still causes the hang :(

I will add a debugging printf to the VM code, to identify 
the subroutine that registers a mapping for that physical 
address.

Just wanted to let those interested in obtaining core dumps
with the NCR know, that I'm working on this. 

I'd really appreciate if somebody could tell me why writing
the page at 0e8000 to disk is a bad idea :)

Regards, STefan



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