From owner-freebsd-hackers Sat Oct 25 13:06:04 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA19053 for hackers-outgoing; Sat, 25 Oct 1997 13:06:04 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from ns2.cetlink.net (root@ns2.cetlink.net [209.54.54.20]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA19043 for ; Sat, 25 Oct 1997 13:05:59 -0700 (PDT) (envelope-from jak@cetlink.net) Received: from ts1-cltnc-30-s19.cetlink.net (ts1-cltnc-30-s19.cetlink.net [209.54.58.30]) by ns2.cetlink.net (8.8.5/8.8.5) with SMTP id QAA29372; Sat, 25 Oct 1997 16:05:37 -0400 (EDT) From: jak@cetlink.net (John Kelly) To: dwhite@resnet.uoregon.edu To: hackers@FreeBSD.ORG Subject: Re: 48 meg double fault moved to 64 meg in 2.2.5 Date: Sat, 25 Oct 1997 14:24:29 -0400 Message-ID: In-Reply-To: Lines: 77 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Doug White wrote: >> I have extra parts to build a third machine identical to the >> configuration which shows the problem. >Keep us posted. If you find anything consistent, you should send >it using send-pr and maybe followup to hackers@freebsd.org. The problem does occur with no SCSI present -- just the motherboard and a video card. When testing it this way, I had to use the floppy controller on the motherboard instead of the faster one on the Buslogic SCSI card. That seems to rule out either floppy controller as a cause of the problem. I found a CMOS option called "DRAM Hole for UNIX(64MB)" which I enabled to see what would happen. With 64 meg and 2.2.5, the problem disappeared. But with 48 meg and 2.2.2 it had no effect, and the double fault still occurred. I'm guessing that's because the BIOS does not try to create that DRAM hole unless you fill the board with 64 meg of memory -- as they do say in parentheses "(64MB)." Unfortunately, I can't keep the "DRAM hole" enabled, because after a reboot the memory test fails, and the only cure is the hardware reset button. Even if I could leave it enabled, it's of no help at all with 48 meg and the 2.2.2 boot floppy. The memory test failure after a reboot may happen because this motherboard does not have address line 26 wired to the chipset, and thus anything over 64 meg cannot be addressed properly. Presumably, to create the "DRAM hole," the BIOS remaps some memory from below the 64 meg line to above 64 meg, and once it's put there, it can no longer be seen, since A26 is unusable -- at least not by the chipset (although A26 is wired between the CPU and the local bus). I learned about the A26 problem on this motherboard when I tried using the linear addressing feature of XFree86 with my Cirrus 5430 video card. Although the video card tries to use the A26 line to remap its memory above the 64 meg line, the motherboard could not handle it. The XFree docs have a good explanation of this situation in X11R6/lib/X11/doc/README.cirrus. But as for the motherboard and the boot floppy problem, I don't understand the purpose of the "DRAM hole for UNIX," although it clearly does have a positive effect on the boot floppy problem when it's activated with 64 meg in the machine. Is it true that this problem only occurs with the boot floppy? The last good message I see with the 2.2.2 boot floppy and 48 meg is "changing root device to fd0c," and then immediately the "panic: double fault" appears. Since floppy controllers use DMA, perhaps DMA and the bounce buffers are an issue? Addressing memory remapped above 64 meg may also be part of the problem, at least on this motherboard. I did find an interesting tidbit in Messmer's "Indispensable PC Hardware Book" (second edition). On page 621 he says: "DMA transfer is not a trivial job, especially when paging is enabled, even for the operating system ... as the DMA controller overwrites the physical memory contents mercilessly without any care for the protection mechanisms of the protected mode ... an incorrectly initialized DMA chip may ... crash ... the complete computer system." Hmmm... sounds familiar. Oh well, I've reached the limits of my knowledge in these areas. I hope my report is of some help to the experts. John