Date: Sat, 27 Jul 1996 00:23:26 +0200 (MET DST) From: Stefan Esser <se@zpr.uni-koeln.de> To: dg@root.com Cc: current@freebsd.org, stable@freebsd.org, "Marc G. Fournier" <scrappy@ki.net> Subject: Re: ncr53c810 driver in stable/current Message-ID: <199607262223.AAA00256@x14.mi.uni-koeln.de> In-Reply-To: <199607220803.BAA10665@root.com> References: <Pine.NEB.3.94.960722032035.268A-100000@ki.net> <199607220803.BAA10665@root.com>
next in thread | previous in thread | raw e-mail | index | archive | help
David Greenman writes: > > The last time I reported this, someone made mention that > >the cause was the NCR driver not switching modes or something like > >that, so that it can't dump core...? > > > > If anyone remembers this thread, or knows what the hell I'm > >talking about...has this been fixed in -current? > > We've seen this problem on freefall (which uses the NCR controller). It > likes to hang when we try to reboot it. I don't recall any fixes for this, > and I don't know what causes it. Hmmm, it hangs when you try to reboot it ? This is more probably related to some problem with the motherboard than the SCSI controller. (Ie. the (in)famous BROKEN_KEYBOARD_RESET.) But I now know how to make the NCR write a kernel dump in case of a crash: Just leave alone the "hole" between 0xe8000 and 0xfffff ... It seems that the NCR gets some error accessing this addresses. I did not have time to completely analyse the resulting chip status, but it appears that the failed memory access (which is reported to a PCI bus-master on a PCI bus line !) causes the hang. Isn't it dangerous to touch that region from the dump code, anyway ? There might be memory mapped registers that make some device change state when read ... I will try to make the driver ignore the access error in the dump, but it might be a good idea to not include the BIOS region in the dump (???) Regards, STefan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199607262223.AAA00256>