From owner-freebsd-hackers Tue Sep 9 14:17:57 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA06525 for hackers-outgoing; Tue, 9 Sep 1997 14:17:57 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id OAA06512 for ; Tue, 9 Sep 1997 14:17:50 -0700 (PDT) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id XAA26087 for freebsd-hackers@freebsd.org; Tue, 9 Sep 1997 23:17:48 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.7/8.8.5) id XAA00796; Tue, 9 Sep 1997 23:11:53 +0200 (MET DST) Message-ID: <19970909231153.EH58106@uriah.heep.sax.de> Date: Tue, 9 Sep 1997 23:11:53 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-hackers@freebsd.org (FreeBSD hackers) Subject: Re: kern/4486: ahc(4) in RELENG_2_2 can't do kernel core dumps References: <199709071604.SAA19531@uriah.heep.sax.de> <199709091650.SAA28404@pat.idi.ntnu.no> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199709091650.SAA28404@pat.idi.ntnu.no>; from Tor Egge on Sep 9, 1997 18:50:44 +0200 Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk (Moved to -hackers.) As Tor Egge wrote: > Some S3 cards does not like accesses to the monocrome > video memory address region (starting at memory address 0xb8000), > and the memory dump hangs when dumping that region. > > With the following ugly hack/workaround, and defining SDDUMP_HANGS > as an option in the kernel config file, the kernel will probably be > able to perform a core dump. I've already been exchanging a couple of private mails with Tor. His suggested hack indeed fixes my problem, so we could at least change the status of the PR to `analyzed'. Anyway, it's now my belief that kernel core dumps should avoid the ``ISA hole'' completely, and dump zeros in this region instead. The devices that are mapped there are free to imply whatever semantics with these memory regions, and it doesn't make much sense to try dumping it at all. The coredump hangs that are the subject of this PR are one point (perhaps a problem of the S3 Trio64 chip), another thing that quickly came to my mind are some HP network cards (HP 100VG) that have some very weird and specific semantics for their memory-mapped operation. They are likely to go belly up if you access their memory regions without sticking to the proper protocol. I'm sure this list could be continued. So unless somebody objects, i would convert all disk drivers to not attempt to dump the ``ISA hole''. This would then close my PR. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-)