From owner-freebsd-stable Fri Jul 26 13:19:45 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA21514 for stable-outgoing; Fri, 26 Jul 1996 13:19:45 -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 NAA21443; Fri, 26 Jul 1996 13:19:32 -0700 (PDT) Received: from x14.mi.uni-koeln.de (annexr2-42.slip.Uni-Koeln.DE) by Sisyphos with SMTP id AA02251 (5.67b/IDA-1.5); Fri, 26 Jul 1996 22:18:48 +0200 Received: (from se@localhost) by x14.mi.uni-koeln.de (8.7.5/8.6.9) id VAA00315; Fri, 26 Jul 1996 21:57:50 +0200 (MET DST) Date: Fri, 26 Jul 1996 21:57:50 +0200 (MET DST) Message-Id: <199607261957.VAA00315@x14.mi.uni-koeln.de> From: Stefan Esser To: Cat Okita Cc: "Marc G. Fournier" , Stefan Esser , jkh@freebsd.org, current@freebsd.org, stable@freebsd.org, dg@root.com Subject: Re: ncr53c810 driver in stable/current In-Reply-To: References: Sender: owner-stable@freebsd.org X-Loop: FreeBSD.org Precedence: bulk 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