From owner-freebsd-current  Sat Jul 27 03:53:04 1996
Return-Path: owner-current
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id DAA28994
          for current-outgoing; Sat, 27 Jul 1996 03:53:04 -0700 (PDT)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id DAA28964;
          Sat, 27 Jul 1996 03:52:54 -0700 (PDT)
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id UAA08492; Sat, 27 Jul 1996 20:49:41 +1000
Date: Sat, 27 Jul 1996 20:49:41 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199607271049.UAA08492@godzilla.zeta.org.au>
To: cat@uunet.ca, se@ZPR.Uni-Koeln.DE
Subject: Re: ncr53c810 driver in stable/current
Cc: current@FreeBSD.org, dg@Root.COM, jkh@FreeBSD.org, scrappy@ki.net,
        stable@FreeBSD.org
Sender: owner-current@FreeBSD.org
X-Loop: FreeBSD.org
Precedence: bulk

>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.

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.

Bruce