Date: Sat, 27 Jul 1996 14:36:44 +0200 From: se@zpr.uni-koeln.de (Stefan Esser) To: Bruce Evans <bde@zeta.org.au> Cc: current@freebsd.org, stable@freebsd.org, scrappy@ki.net Subject: Re: ncr53c810 driver in stable/current Message-ID: <199607271236.AA14447@Sisyphos> In-Reply-To: Bruce Evans <bde@zeta.org.au> "Re: ncr53c810 driver in stable/current" (Jul 27, 20:49)
next in thread | previous in thread | raw e-mail | index | archive | help
On Jul 27, 20:49, Bruce Evans wrote: } Subject: Re: ncr53c810 driver in stable/current } >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 :( } } 0xe8000 is in the first MB so it's surprising that the first } few MB got written. Yes, sure, you are of course right! I wrote the message whiledoing the tests, and in fact had estimated that 2MB had been written at the time of the hand, when it in fact was a little less than 1MB ... } sddump() and wddump() write all pages from page #0 to page } #MaxMem-1, so they always write the entire BIOS area. Perhaps } they should write only RAM. phys_avail[] almost says where } RAM is. Unfortunately, it is truncated at the start to skip } the BIOS page and at the end to skip the message buffer. I'm not sure about the right way to deal with that region. There might be interesting data in some devices buffer (e.g. of an ISA ethernet card) that should go into the dump. PCI is different from ISA in that each transfer has to be acknowledged. But the ISA memory hole is subtractively decoded: If no PCI chip signals a "DEVSEL" (some device is selected) state within a few PCI bus clocks, then the PCI to ISA bridge will forward the request to the ISA bus. The NCR won't actually know whether the address was decoded on ISA, so I'm again not sure why the system hangs when the NCR tries to read from that address. I will add a few more micro-tests to find out what actually causes the hang. As a work around to those people in need to have kernel dumps written to disk on a NCR system: Is it worth the effort to detect the special situation and have the driver ignore the memory hole in the dump ? If all you want is to have the system come up automatically after crash, then you might as well just turn off the kernel dump feature (using the dumpon command or by not having a "sump on sd0" in the kernel config file ...) Regards, STefan -- Stefan Esser, Zentrum fuer Paralleles Rechnen Tel: +49 221 4706021 Universitaet zu Koeln, Weyertal 80, 50931 Koeln FAX: +49 221 4705160 ============================================================================== http://www.zpr.uni-koeln.de/~se <se@ZPR.Uni-Koeln.DE>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199607271236.AA14447>